From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Lalancette Subject: Re: [PATCH]: Fix xm block-detach Date: Tue, 02 Dec 2008 17:24:19 +0100 Message-ID: <49356133.6070004@redhat.com> References: <49352971.6020605@redhat.com> <96C95486AAA6EEkanno.masaki@jp.fujitsu.com> <49354440.3080003@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <49354440.3080003@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Masaki Kanno Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Chris Lalancette wrote: > Masaki Kanno wrote: >> Hi Chris, >> >> I could not reproduce the problem by using the latest xen-unstable. >> >> I also found a problem of block tap devices included by c/s 18562, >> then I have fixed the problem by c/s 18843. But the problem occurred >> by using xm shutdown or xm destroy or etc, not xm block-detach. >> >> Could you try xm block-detach by using the latest xen-unstable? >> >> Best regards, >> Kan > > OK, interesting. I'll give it a shot, but it's going to take a little while > since I have to build from scratch. I'll report when I'm done. Ah, now I see. Testing it on xen-unstable does, indeed, show xm block-detach working as expected. There were some changes made in the meantime that actually make it work. That means the first hunk of my changes to DevController.py aren't required. However, I think the other two hunks are actually "correct", even though we don't see the xm block-detach bug in current xen-unstable. That is, they move the device section from /vm/UUID/device/tap to /vm/UUID/device/vbd, which seems more right to me. -- Chris Lalancette