From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ewan Mellor <ewan@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: HVM guest with file backed disks using loop devices ?
Date: Wed, 22 Nov 2006 17:10:54 +0000 [thread overview]
Message-ID: <20061122171054.GH11685@redhat.com> (raw)
In-Reply-To: <20061122094918.GA2005@leeni.uk.xensource.com>
On Wed, Nov 22, 2006 at 09:49:18AM +0000, Ewan Mellor wrote:
> On Tue, Nov 21, 2006 at 02:02:13PM +0000, Daniel P. Berrange wrote:
>
> > I've been looking at an issue with HVM guests and file backed virtual disks.
> > A user reported that they were unable to create more than 8 HVM guests as
> > the hotplug scripts failed to find a free loop device on the 9th guest.
> > I can think of two reasons for the creation of loop devices for HVM:
[snip]
> > - This was needed in the past, but is now obsolete & we simply forgot to
> > turn off loop device code for HVM
> > - This is an accidental consequence changing the way HVM disks are
> > configured (ie when we droppped :ioemu tag from disks).
> >
> > Can anyone who is more familiar with the history of HVM development shed
> > some light on this behaviour ?
>
> It's there to support paravirtual drivers within HVM domains. In that case,
> you will be using blkback, just as with PV domains, and so you need the
> backend there.
Ok, that makes sense now. This raises another question though - is it possible
to make the PV-for-HVM drivers work against the blktap backend ? The loop
back driver has bad data integrity issues upon crash & poor performance in
comparison to blktap, so I'd really like to avoid loopback altogether.
> > I'd like to update the hotplug scripts to stop the loopback device being
> > created for HVM, but don't see any obvious data available in the hotplug
> > scripts which would allow me to distinguish between paravirt & HVM disk
> > configurations.
>
> The best thing would be to add a device option and a corresponding node in the
> store that told blkback "this device is not for you, don't bring it up". That
> way, you don't pay the cost of the device backend and the loop device, in the
> case where you are using QEMU-emulated devices, and not using the PV drivers.
>
> The flag has to be this way around for compatibility -- old configurations
> will be expecting the backend to be created unconditionally, to support the PV
> drivers.
Ok, sounds like I'l need to investigate how the PV-HVM drivers integrate
in a little more detail before attempting such a change
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 -=|
next prev parent reply other threads:[~2006-11-22 17:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-21 14:02 HVM guest with file backed disks using loop devices ? Daniel P. Berrange
2006-11-22 9:49 ` Ewan Mellor
2006-11-22 17:10 ` Daniel P. Berrange [this message]
2006-11-22 18:17 ` Andrew Warfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061122171054.GH11685@redhat.com \
--to=berrange@redhat.com \
--cc=ewan@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.