Working hotplug, but still timing out waiting for vbd device ("changing physical-device not supported"?)

[Charles Duffy <cduffy@spamcop.net>]

This has previously been posted to xen-users, but not seen any response 
as of yet. (Granted, it's a weekend and only 15 hours since my initial 
post; I hope I'm not being excessively impatient).

I'm running Xen3 7775 with udev 073. My dom0 is Gentoo-based. When I try 
to start a DomU, it times out waiting for hotplug-based notification, as 
per the following:

DEBUG (DevController:69) Waiting for devices vif.
DEBUG (DevController:75) Waiting for 0.
DEBUG (DevController:69) Waiting for devices usb.
DEBUG (DevController:69) Waiting for devices vbd.
DEBUG (DevController:75) Waiting for 769.
ERROR (SrvBase:87) Request wait_for_devices failed.
Traceback (most recent call last):
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/web/SrvBase.py", 
line 85, in perform
     return op_method(op, req)
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/xend/server/SrvDomain.py", 
line 68, in op_wait_for_devices
     return self.dom.waitForDevices()
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py", 
line 1200, in waitForDevices
     self.waitForDevices_(c)
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/xend/XendDomainInfo.py", 
line 856, in waitForDevices_
     return self.getDeviceController(deviceClass).waitForDevices()
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevController.py", 
line 71, in waitForDevices
     return map(self.waitForDevice, self.deviceIDs())
   File 
"/usr/src/xen-unstable.hg/dist/install/usr/lib64/python/xen/xend/server/DevController.py", 
line 80, in waitForDevice
     raise VmError( ("Device %s (%s) could not be connected. "
VmError: Device 769 (vbd) could not be connected. Hotplug scripts not 
working

However, based on the following passage from /var/log/messages, the 
relevant vbd backend *really did* start up and try to provide 
notification of its new state:

logger: /etc/xen/scripts/block: bind XENBUS_PATH=backend/vbd/1/769
logger: /etc/xen/scripts/block: bind XENBUS_PATH=backend/vbd/1/770
logger: /etc/xen/scripts/block: Writing 
backend/vbd/1/770/physical-device 0xfd04 backend/vbd/1/770/node 
/dev/data/demo-1-swap to xenstore.
changing physical-device not supported
changing physical-device not supported
logger: /etc/xen/scripts/block: Writing backend/vbd/1/770/hotplug-status 
connected to xenstore.
changing physical-device not supported
logger: /etc/xen/scripts/block: Writing 
backend/vbd/1/769/physical-device 0xfd03 backend/vbd/1/769/node 
/dev/data/demo-1 to xenstore.
logger: /etc/xen/scripts/vif-bridge: bridge=xenbr0 up 
XENBUS_PATH=backend/vif/1/0
logger: /etc/xen/scripts/block: Writing backend/vbd/1/769/hotplug-status 
connected to xenstore.
changing physical-device not supported
changing physical-device not supported
changing physical-device not supported
device vif1.0 entered promiscuous mode
xenbr0: port 3(vif1.0) entering learning state
logger: /etc/xen/scripts/vif-bridge: Writing 
backend/vif/1/0/hotplug-status connected to xenstore.
xenbr0: topology change detected, propagating
xenbr0: port 3(vif1.0) entering forwarding state
logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge operation for 
vif1.0, bridge xenbr0.

Note the "changing physical-device not supported" messages. My disks are 
indeed specified as phy devices, as per the following:

disk = [ 'phy:data/demo-1,hda1,w', 'phy:data/demo-1-swap,hda2,w' ]

However, I'd hope that being specified as physical devices wouldn't 
impede hotplug notification.


Running diagnose.py on the relevant domain yields the following output:

Domain ID is 2.
Domain name is demo-1.
Found 2 device classes in use.
Found 1 vbd devices.
Found device vbd, 770.
Backend is stuck waiting for frontend for device vbd, 770.
Device vbd, 770 hotplugging has completed successfully.
Found 1 vif devices.
Found device vif, 0.
Backend is stuck waiting for frontend for device vif, 0.

Notably, this identifies the backend as blocking on vif,0; whereas the 
message log indicates "Successful vif-bridge operation for vif1.0, 
bridge xenbr0".


Any suggestions as to why I would be seeing the present behaviour?