On Sun, Jul 01, 2007 at 10:41:37PM +0100, Daniel P. Berrange wrote:
> 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.
Thinking about it from the safety POV, the QEMU process could register
a xenstore watch to be notified when the paravirt frontend driver
connected to the backend. At this time it could forceably disable the
IDE device associated with the backend, thus ensuring you never have
two concurrently active data paths to the same underlying disk.
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