From: Corey Bryant <bryntcor@us.ibm.com>
To: Eric Blake <eblake@redhat.com>
Cc: libvir-list@redhat.com, Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel@nongnu.org, Tyler C Hicks <tchicks@us.ibm.com>
Subject: Re: [Qemu-devel] [libvirt] [PATCH v2] Add support for fd: protocol
Date: Tue, 14 Jun 2011 15:55:11 -0400 [thread overview]
Message-ID: <4DF7BC9F.10506@us.ibm.com> (raw)
In-Reply-To: <4DF788AF.3010103@redhat.com>
On 06/14/2011 12:13 PM, Eric Blake wrote:
> On 06/14/2011 07:31 AM, Corey Bryant wrote:
>> > - Starting Qemu with a backing file
> What do you mean by this? Taking a guess:
>
> In the case of a qcow2 image with a backing file, does that mean that
> both the qcow2 image and it's backing file can both be passed to qemu
> via fd: notations? That is, if the -drive file=fd:4,format=qcow2 option
> is passed, and fd4 is a qcow2 image that also has a backing file, it
> seems like libvirt should also be able to pass that backing file via
> another fd, so that qemu doesn't have to open() the backing file
> directly. So we would need something like -drive
> file=fd:4,format=qcow2,backing=fd:5
>
> and since backing files can be nested, we'd need some way of specifying
> more than one level of backing file. Libvirt already knows how to walk
> a chain of backing images in qcow2 files (it has to, in order to set
> sVirt SELinux permissions on all of those files so that qemu can open()
> each file), so it wouldn't be much harder for libvirt to instead do the
> open() and pass each fd.
>
> -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization
> library http://libvirt.org
Right. So what I was talking about here (and poorly stated) is that
starting Qemu with a copy-on-write image file causes a reopen of the
backing file. In this case you would only be passing the fd of the
copy-on-write file to Qemu. I've fenced that off as unsupported for now.
I like your approach for passing multiple fds. Do you think backing file
support is needed immediately with this patch?
next prev parent reply other threads:[~2011-06-14 19:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 13:31 [Qemu-devel] [PATCH v2] Add support for fd: protocol Corey Bryant
2011-06-14 16:13 ` [Qemu-devel] [libvirt] " Eric Blake
2011-06-14 19:55 ` Corey Bryant [this message]
2011-06-14 20:18 ` Eric Blake
2011-06-14 21:39 ` Corey Bryant
2011-06-14 21:52 ` Eric Blake
2011-06-15 19:12 ` [Qemu-devel] " Blue Swirl
2011-06-16 14:48 ` Corey Bryant
2011-06-18 20:50 ` Blue Swirl
2011-06-20 13:08 ` Corey Bryant
2011-06-20 13:40 ` Avi Kivity
2011-06-20 13:50 ` Anthony Liguori
2011-06-20 17:35 ` Avi Kivity
2011-06-20 19:11 ` Anthony Liguori
2011-06-21 8:21 ` Avi Kivity
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=4DF7BC9F.10506@us.ibm.com \
--to=bryntcor@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=eblake@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=tchicks@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).