losetup fails when using the 'file:/', preventing the DomU from being created

Qemu Log

Hotplug

Bizarelly, losetup fails - but the devices are there, e.g.:

root@mintaka:~# losetup -a
/dev/loop0: [0807]:26738701 (/home/xen/domains/beastie/disk.img)
/dev/loop1: [0807]:26738703 (/home/xen/domains/beastie/freebsd7bootonly.iso)

niere_ in #xen on Freenode recommended manually running losetup and then using phy:/dev/loop/xxxx in my xen config

I did this for both the iso and empty disk image with the following results:

It works! I'm testing with a freeBSD install which borks all over the place, but that's an installer problem

I have successfully started a windows install by manually doing the losetup's and using phy:/ - this isn't a solution just a very temporary work around!

Henri

I simply wanted to confirm this error, I did an minimal install from the ubuntu 8.04 server edition beta iso (without any fancy extras except openssh and xen).

and replaching
disk = ['file:/images/win2k3disk.img,ioemu:hda,w',
'file:/images/win2k3iso.img,ioemu:hdc:cdrom,r']

by

disk = ['phy:/dev/loop0,ioemu:hda,w',
'phy:/dev/loop1,ioemu:hdc:cdrom,r']

does the trick as well for me after the loopback devices are created offcourse.

It's annoying and poorly documented but it now seems necessary to use "tap:aio" instead of "file".

i.e. for your example:

disk = [ 'tap:aio:/images/win2k3disk.img,ioemu:hda,w',
'tap:aio:/images/win2k3iso.img,ioemu:hdc:cdrom,r']

This should work.

I beg your pardon, I didn't read the first line of your bug report!

But yes I can confirm the same problems with losetup ... or rather with the xen block daemon, which called losetup and then broke.

In Hardy using tap:aio: fixed this issue for PVM guests but with HVM guests I get these errors.

I always get this in xen-hotplug.log:
xenstore-read: couldn't read path /local/domain/1/vm
xenstore-read: couldn't read path /local/domain/1/vm

for HVM guests i have to manually setup the loopbacks and use phy: disk type that point to /dev/loop*. Once I setup the loopback manually and change to phy: the domain will boot correctly and the hotplug errors are gone.

For me using tap:aio: fixed it for both my PVM'ed centos and my HVM'ed win2k3.

Elie, when you use tap:aio: the mount of the iso for installing the os was working well ?

Because I didn't work and I had to use the workaround of mounting them in de Dom0 and passing it with phy:/dev/loop*

For the installation itself i'm not sure, by the time I discovered I had to use tap:aio: I had already installed the OS using the /dev/loop trick.

xen-tools needs to be patched to use tap:aio: instead of file:

it's not a massive changed, 1 line in xen-create-image,
file

Confirming: booting HVM from cdrom-iso as tap:aio: does not work! (As mentioned before, losetup and phy: did the trick...)

Anyone out there familiar with this issue and capable of troubleshooting it? Its a real showstopper for any kind of automation.

Not yet,

As it seems the bug still persists and the only available solution is the phy /dev/loop trick...

Hope it will be soon fixed, couse it is making the everyday hvm testing work such a pain...

So.... Could we please clarify a couple of things:
- Is the current Xen3.2 (the one in the repos) patched and working with the "tap:aio" tip?
- Is there a working Xen3.2 on Ubuntu Hardy? (somewhere in a private repo)?
- What of thos patches should be OK, which of them should be applied,... any documentation?

The goal is to have XP or Vista running in one or more domUs. More generally, using HVM.

Is that comment reliable? :
http://www.nabble.com/vbd-could-not-be-connected-td16661943.html

The issue is very simple:

in the /etc/xen/scripts/block script it creates the loopback device twice

First it does it with losetup /dev/loopx /some-image
Then if you want read-only it does
losetup -r /dev/loopx /some-image
and this second one fails cause the first one already mounted it read/write.

@Patrick

I was looking into your theory about the losetup twice.

I am trying to compare vs. the current block file in xen-unstable:
http://xenbits.xensource.com/xen-unstable.hg?file/78a29cf8476b/tools/examples/block

I am not so sure that that is the problem. Can you take a closer look?

Would it be possible for you to produce a working and tested patch that we could try?