Description of problem: As reported by Don Dutile, xm block-detach no longer seems to work in the RHEL 5.3 beta. The following sequence of actions: # xm create -c rhel5pv_x86_64 # xm block-attach rhel5pv_x86_64 tap:aio:/var/lib/xen/images/test.dsk /dev/xvde w # xm block-detach rhel5pv_x86_64 51776 Results in: Error: 51776 not connected Usage: xm block-detach <Domain> <DevId> [-f|--force] Destroy a domain's virtual block device. Doing a bisection, this seems to have started with xen-3.0.3-74.el5; prior to that, xm block-detach seemed to work fine.
OK, I think I got it. The patch to fix up a CVE caused this breakage by moving some stuff around in xenstore. Luckily, I think it is pretty easy to fix; the attached patch seems to fix it for me. I'll post this upstream as well, since I think the same problem probably exists there. Chris Lalancette
Created attachment 325364 [details] Fix up block detach
Built into xen-3.0.3-78.el5
This patch caused a regression in guest reboots for bz 471588
Created attachment 326512 [details] Correct fix for block-detach There are two core problems with block detach - virsh & xm both pass 'type=vbd' even for TAP devices. This causes the wrong device controller to be used. This is the cause of the detach failure. This patch checks for the bogus type=vbd and fixes it - The /vm/$UUID/device/{vbd,tap}/$DEVID path is not removed from xenstore, preventing a later re-attachment. This patch removes that path upon detach
*** Bug 475588 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-0118.html