[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |