On Sun, Jul 01, 2007 at 01:28:56PM -0700, Andrew Warfield wrote:
> The problem with this approach is that you end up using two instances
> of whatever virtual disk code you want. In the case of raw writes to
> an image file (tap:aio) this is more or less okay, except for the fact
> that qemu has a bad habit of buffering writes and so you can get stuck
> in a nasty late write race when you switch from emulated writes over
> to using pv drivers.
AFAIR, if the guest OS sends a flush request to the IDE device, then
QEMU should immediately be flushing the data to disk in the host - if
it doesn't, then this is already a potential data corrupter if either
the guest or host crashes because journaling fileystems rely on the
fact that when they ask for a journal flush it is not buffered in RAM.
I don't think a guest OS would ever be activating both the IDE and
paravirt drivers for a device though would it ? You either load IDE
drivers, or paravirt at any given time. If you've got a guest using
PV drivers, then the only point where the IDE interface would come
into play is for the initial BIOS boot process & that should be
read-only access.
> For non-raw writes this is worse, because most of the image file
> drivers cache metadata in memory and don't necessarily pick up changes
> to the image files when you switch from emulated to pv. Also, the
> disparate implementations make me a bit nervous about headers exactly
> matching and so on.
Are you refering to the qcow file format headers here ? If blktap isn't
in compliance with the QEMU QCOW spec then that is a bug in itself which
needs fixing, because it is not good for portability of FS images.
> The intention of the phantom device is to try to keep things down to a
> single data path, and a single driver implementation.
Can you explain just how the phantom device is supposed to work, because
its not working in current code, even with the fix I mentioned blow & it
is not immediately clear to me what else needs fixing ...
> >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.
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-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home