All,
The recent changes to where xenstore stores data about domains (c/s 18562,
in particular) seem to have broken xm block-detach. What happens is that
attaching a disk works just fine, but detaching a disk ends with:
Error: 51776 not connected
Usage: xm block-detach <Domain> <DevId> [-f|--force]
Destroy a domain''s virtual block device.
The problem basically boils down to where the new code is placing the xenstore
entries. Previously, it was storing them in
/local/domain/<number>/device/vbd;
it is now storing them in /vm/UUID/device/tap. The tap is wrong; tap describes
the backend, not the frontend, which should always be vbd. The attached patch
fixes this by overriding deviceRoot() in the BlktapController class, similar to
how frontendRoot() is done, and then changing devicePath() to use deviceRoot().
There is also a small fix for destroyDevice, to make sure we remove the proper
/vm/UUID/device/vbd entry on removal.
With the patch in place, I was able to successfully block-attach and
block-detach disks again. Note that I only tested this on RHEL-5 xend, which
has diverged quite a bit from upstream. However, a quick glance at the code in
xen-unstable shows that this is probably a problem there as well; only testing
will tell for sure.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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 Tue, 02 Dec 2008 13:26:25 +0100, Chris Lalancette wrote:>All, > The recent changes to where xenstore stores data about domains (c/s >18562, >in particular) seem to have broken xm block-detach. What happens is that >attaching a disk works just fine, but detaching a disk ends with: > >Error: 51776 not connected >Usage: xm block-detach <Domain> <DevId> [-f|--force] > >Destroy a domain''s virtual block device. > >The problem basically boils down to where the new code is placing the >xenstore >entries. Previously, it was storing them in /local/domain/<number>/device/ >vbd; >it is now storing them in /vm/UUID/device/tap. The tap is wrong; tap >describes >the backend, not the frontend, which should always be vbd. The attached >patch >fixes this by overriding deviceRoot() in the BlktapController class, >similar to >how frontendRoot() is done, and then changing devicePath() to use >deviceRoot(). > There is also a small fix for destroyDevice, to make sure we remove the >proper >/vm/UUID/device/vbd entry on removal. > With the patch in place, I was able to successfully block-attach and >block-detach disks again. Note that I only tested this on RHEL-5 xend, which >has diverged quite a bit from upstream. However, a quick glance at the >code in >xen-unstable shows that this is probably a problem there as well; only >testing >will tell for sure. > >Signed-off-by: Chris Lalancette <clalance@redhat.com> > >-------------------------------text/plain------------------------------- >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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, > KanOK, 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. Thanks, -- Chris Lalancette _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tue, 02 Dec 2008 17:24:19 +0100, Chris Lalancette wrote:>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.Hi Chris, I have tried the other two hunks of your changes on the latest xen-unstable. I have found two issues. Could you see the attaching file? 1. Information of xm list When I tried xm list to an active domain, both "vbd" and "tap" were shown. They were same uuid and same uname. 2. Double wait in xend I checked xend.log after I started a domain. Xend was waiting for both "vdb" and "tap" by using waitForDevices(). If the other two hunks of your changes are correct, I think that there is some kind of lack in your changes yet. Best regards, Kan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Masaki Kanno wrote:> Tue, 02 Dec 2008 17:24:19 +0100, Chris Lalancette wrote: > >> 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. > > Hi Chris, > > I have tried the other two hunks of your changes on the latest > xen-unstable. I have found two issues. Could you see the attaching > file? > > 1. Information of xm list > When I tried xm list to an active domain, both "vbd" and "tap" > were shown. They were same uuid and same uname. > > 2. Double wait in xend > I checked xend.log after I started a domain. Xend was waiting > for both "vdb" and "tap" by using waitForDevices(). > > If the other two hunks of your changes are correct, I think that > there is some kind of lack in your changes yet.Yes, I see what you mean (both from the data you sent, and from reproducing it on my own). There is probably something missing. Honestly, I''m not sure how sxpr''s are generated, so I''ll have to look into it. Probably not until tomorrow though. Thanks for testing. -- Chris Lalancette _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel