[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
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. 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. The intention of the phantom device is to try to keep things down to a single data path, and a single driver implementation. a. 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-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |