WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>
Subject: Re: [Xen-users] Re: [Xen-devel] Re: Writing a tool for Shared Persistent Windows Boot Image
From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Sun, 1 Jul 2007 22:41:37 +0100
Cc: Anthony Liguori <anthony@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx, Jim Burnes <jvburnes@xxxxxxxxx>
Delivery-date: Sun, 01 Jul 2007 14:39:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <eacc82a40707011328k57453279sef8b7cc076e9f7b3@xxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <467AE21F.1020700@xxxxxxxxxxxxx> <37B43CC2-BED7-4336-9CC4-0CE1C7894458@xxxxxxxxx> <467AF0C6.5010101@xxxxxxxxxxxxx> <b3ec41ba0706281118k751e90bajf2f3095fd92d0939@xxxxxxxxxxxxxx> <20070628182736.GB12711@xxxxxxxxxx> <eacc82a40706290738r354123f3x459d1ba27b279f31@xxxxxxxxxxxxxx> <20070629144251.GC25518@xxxxxxxxxx> <eacc82a40706290918s284681fjfea2baafe53f69d2@xxxxxxxxxxxxxx> <20070629201622.GA7204@xxxxxxxxxx> <eacc82a40707011328k57453279sef8b7cc076e9f7b3@xxxxxxxxxxxxxx>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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

<Prev in Thread] Current Thread [Next in Thread>