Re: [Xen-users] Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image

["Jim Burnes" <jvburnes@xxxxxxxxx>]

Daniel,

Does this take care of both "tap:aio" and "tap:qcow" disk specifications or is "tap:qcow" deprecated?

Thanks,

Jim Burnes

On 6/29/07, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:

On Fri, Jun 29, 2007 at 09:18:50AM -0700, Andrew Warfield wrote:
> If you can send some more details on the crash we should be able to
> sort this out -- it's certainly something that has worked in the past.

Ok, so here's the scenario. Traditionally with HVM I have a disk

   file:/xen/rhel4i386.img,hda,w

Having seen the changeset 13827:6524e02edbeb I tried

  tap:aio:/xen/rhel4i386.img,hda,w

And

  tap:aio:/xen/rhel4i386.img,xvda,w

The latter is the preferred, since paravirt drivers should not be hijacking
the IDE devices inside the guest. However, the changeset 13827 doesn't seem
to support xvd* since QEMU filters out any devices with such a name.

With vanilla  Xen 3.1.0 qemu goes defunct when starting the guest
logging

qemu: could not open hard disk image 'aio:/xen/rhel4i386.img'

After a little investigation I found that in BlktapController

       try:
           imagetype = self.vm.info['image']['type']
       except:
           imagetype = ""

Has long ago been broken and should instead be

        try:
            imagetype = self.vm.info.image_type()
        except:
            imagetype = ""


Once I made that change I can see a phantom device being created, but QEMU
still crashes & burns with   qemu-dm-XXXX.log showing

  qemu: could not open hard disk image '/dev/xvdc1'

I started to debug this, but looking at changeset 13827:6524e02edbeb I rapidly
came to the conclusion that the whole idea of phantom devices is complete
overkill & the entire problem could be addressed with a couple of lines in
ioemu/xenstore.c.  QEMU already knows how to handle all the different
types of file format blktap does, so there's no need to setup extra phantom
devices. All thats needed is for QEMU to a) strip the aio: (or equivalent)
prefix and b) convert xvdN -> hdN if required.

So I'm attaching two patches. The first reverts 13827:6524e02edbeb
and the second tweaks ioemu/xenstore.c so it can handle blktap devices
directly. With these applied ontop of Xen 3.1.0 I can successfully
start HVM guests using  the two example tap:aio lines I show earlier
in this mail. The patch also adds a couple of logging lines which
end up in qemu-dm-XXX.log as they'll be useful if ever debugging QEMU
boot issues - it is far too silent when things go wrong which makes
diagnosis hard.

    Signed-off-by: Daniel Berrange < berrange@xxxxxxxxxx>


The patch being reverted:

$ diffstat xen-revert-phantom.patch
ioemu/xenstore.c                           |   46 ---------------------
python/xen/xend/XendConfig.py              |   41 -------------------
python/xen/xend/XendDomainInfo.py          |   58 ---------------------------
python/xen/xend/server/BlktapController.py |   62 -----------------------------
python/xen/xend/server/DevController.py    |   13 ------
5 files changed, 3 insertions(+), 217 deletions(-)

The new patch:

$ diffstat xen-qemu-blktap.patch
xenstore.c |   28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/               -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel