From: Corey Bryant <coreyb@linux.vnet.ibm.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
libvir-list@redhat.com, aliguori@us.ibm.com,
qemu-devel@nongnu.org, tchicks@us.ibm.com
Subject: Re: [Qemu-devel] [PATCH v3] Add support for fd: protocol
Date: Wed, 27 Jul 2011 09:09:57 -0400 [thread overview]
Message-ID: <4E300E25.8010407@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110727084304.GH27072@redhat.com>
On 07/27/2011 04:43 AM, Daniel P. Berrange wrote:
> On Wed, Jul 27, 2011 at 10:36:25AM +0200, Kevin Wolf wrote:
>> Am 27.07.2011 10:22, schrieb Daniel P. Berrange:
>>> On Wed, Jul 27, 2011 at 10:11:06AM +0200, Kevin Wolf wrote:
>>>> Am 26.07.2011 18:57, schrieb Corey Bryant:
>>>>>>>> diff --git a/block/cow.c b/block/cow.c
>>>>>>>> index 4cf543c..e17f8e7 100644
>>>>>>>> --- a/block/cow.c
>>>>>>>> +++ b/block/cow.c
>>>>>>>> @@ -82,6 +82,11 @@ static int cow_open(BlockDriverState *bs, int flags)
>>>>>>>> pstrcpy(bs->backing_file, sizeof(bs->backing_file),
>>>>>>>> cow_header.backing_file);
>>>>>>>>
>>>>>>>> + if (bs->backing_file[0] != '\0'&& bdrv_is_fd_protocol(bs)) {
>>>>>>>> + /* backing file currently not supported by fd: protocol */
>>>>>>>> + goto fail;
>>>>>>>> + }
>>>>>> I don't think these checks are strictly needed. Without the check you
>>>>>> can open the image itself using an fd, and the backing file using good
>>>>>> old raw-posix. We shouldn't decide for our users that this isn't useful.
>>>>>>
>>>>>> In any case, it would have to move into block.c, you can't modify
>>>>>> independent drivers for this.
>>>>>>
>>>>>
>>>>> I understand the point on not modifying independent drivers.
>>>>>
>>>>> But if the backing file resides on NFS, wouldn't the the proposed
>>>>> SELinux changes prevent the open?
>>>>
>>>> Probably. But what about cases where the backing file is local? Or even
>>>> a non-libvirt, non-SELinux use case?
>>>>
>>>>> Or are you talking about support where libvirt opens the backing file
>>>>> and passes the fd to Qemu? If so there was some discussion about future
>>>>> support for this here:
>>>>> http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg01496.html
>>>>
>>>> Not really, but implementing this will be a bit easier if you don't
>>>> forbid using backing files with fd.
>>>
>>> In any case, for 'fd:' to be actually used by libvirt, we need to have
>>> backing files supported. There are major users of libvirt who rely on
>>> NFS and also use backing files, so an 'fd:' impl which can't deal with
>>> the backing file problem isn't much use to libvirt.
>>
>> I'm perfectly aware of that. But seriously, repeating it over and over
>> again isn't going to make it happen any sooner. It requires -blockdev
>> which we may or may not have by 1.0.
>
> Yes, I understand we need also -blockdev for this. Other messages in this
> mail thread have impied that this proposed patch on its own is useful for
> libvirt's requirements, so I just wanted to remind people in general that
> we can't use this patch on its own until we have something like -blockdev.
>
> Regards,
> Daniel
Kevin/Daniel, thanks a lot for your input.
In terms of the support that libvirt requires, I just want to make sure
all bases are covered.
In order for this support to be useful to libvirt, the following are
required (sorry if this is repetitive):
1) -blockdev (backing file support)
2) savevm (snapshot support)
3) snapshot_blkdev (snapshot support)
4) 'change' monitor command
5) -cdrom
and as far as I know, the status of the above is:
1) Someone is slated to work on this (not me)
2) I need to figure out how to "re-open" file without an open (me)
3) This will be covered by live snapshots feature (not me)
4) Should just work as is (me)
5) May also just work as is (me)
In other words, 1 and 3 will not be implemented by me (except perhaps
some re-usable infrastructure). Could you confirm my understanding?
Regards,
Corey
next prev parent reply other threads:[~2011-07-27 13:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-26 12:51 [Qemu-devel] [PATCH v3] Add support for fd: protocol Corey Bryant
2011-07-26 13:02 ` Christoph Hellwig
2011-07-26 13:15 ` Corey Bryant
2011-07-26 14:02 ` [Qemu-devel] [libvirt] " Eric Blake
2011-07-26 14:05 ` [Qemu-devel] " Kevin Wolf
2011-07-26 14:46 ` Corey Bryant
2011-07-26 14:54 ` Kevin Wolf
2011-07-26 14:00 ` [Qemu-devel] [libvirt] " Eric Blake
2011-07-26 14:19 ` Kevin Wolf
2011-07-26 15:18 ` [Qemu-devel] " Kevin Wolf
2011-07-26 16:57 ` Corey Bryant
2011-07-26 17:10 ` Alexander Graf
2011-07-26 19:00 ` Corey Bryant
2011-07-27 8:11 ` Kevin Wolf
2011-07-27 8:22 ` Daniel P. Berrange
2011-07-27 8:36 ` Kevin Wolf
2011-07-27 8:43 ` Daniel P. Berrange
2011-07-27 13:09 ` Corey Bryant [this message]
2011-07-27 14:57 ` Kevin Wolf
2011-07-27 21:36 ` Blue Swirl
2011-08-11 16:28 ` Corey Bryant
2011-08-12 10:07 ` Kevin Wolf
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=4E300E25.8010407@linux.vnet.ibm.com \
--to=coreyb@linux.vnet.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=berrange@redhat.com \
--cc=kwolf@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 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.