Xen - can't create domain because 'vdb could not be connected'

I'm trying to start up a Xen VM, however I'm getting the following error:

Error: Device 2049 (vbd) could not be connected. Hotplug scripts not working.

what does this mean?

The dom0 is CentOS and the guest OS is Debian Lenny. The network interfaces I'm using are:

vif = [ 'mac=00:16:3e:3e:53:5f, bridge=xenbr0', 'mac=00:16:3e:18:16:e5, bridge=xenbr1' ]

The root filesystem of the guest OS is set to mount over NFS from the dom0, this is working for other guest OSs on the same host. The swap (and /var) is mounted from a local LVM logical volume

UPDATE My fault. I hadn't written the config correctly, and hadn't set up the filesystems correctly. I was able to look at /var/log/xen/xen-hotplug.log to see that it was accessing the wrong device.

Short version:

Check that you have /etc/udev/rules.d/xen-backend.rules. The file may or may not be prefixed by a number.

If not, check whether you have /etc/udev/xen-backend.rules and create a symlink from that to /etc/udev/rules.d/xen-backend.rules.

Long version:

I've seen this with a Gentoo 3.3 dom0, not CentOS. But I suspect the fix will be the same or similar.

The Xen build scripts call a command udevinfo -V to determine the version of udev installed on the machine. The udevinfo utility was depreciated a while ago in favour of udevadm. In more recent releases of udev the old utility has been removed altogether.

The build scripts use the version of udev acquired as described to determine what installations steps need to be undertaken. If it can't find/match the udev version then it won't installed the required udev rule. By not having udevinfo present, this is what's occurring.

Now it's probably given that you don't want to downgrade udev. So that leaves two solutions.

You can either check whether your package distributor has fixed the issue. For instance it is fixed in Xen 4.4 on Gentoo in accordance with this bug.

Alternatively, you can work around it temporarily, by fooling it that udevinfo is still present and behaving in the way that it expects. We can do this by scripting/proxying to the new udevadm command:

# echo -e '#!/bin/bash\n/sbin/udevadm info $1' > /usr/bin/udevinfo
# chmod +x /usr/bin/udevinfo
*** Install Xen ***
# rm /usr/bin/udevinfo

This will get it working again. But you will still need to fix the issue in the long run.