qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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?

  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).