qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] commit: Add top-node/base-node options


From: Alberto Garcia
Subject: Re: [Qemu-devel] [PATCH 1/2] commit: Add top-node/base-node options
Date: Tue, 04 Sep 2018 16:42:17 +0200
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Tue 04 Sep 2018 04:17:30 PM CEST, Peter Krempa wrote:
>> >> libvirt-3-format is read-write and all other node names are
>> >> readonly in the above example.
>> >> 
>> >> The same also happens when using filenames:
>> >> 
>> >> {"execute":"block-commit",
>> >>  "arguments" : {"device":"libvirt-3-format",
>> >>                 "job-id":"libvirt-3-format",
>> >>                 "top":"/var/lib/libvirt/images/rhel7.3.1483615252",
>> >>                 "base":"/var/lib/libvirt/images/rhel7.3.1483605924",
>> >>                 "auto-finalize":true,
>> >>                 "auto-dismiss":false},
>> >>  "id":"libvirt-13"}
>> >> 
>> >> {"id":"libvirt-13","error":{"class":"GenericError","desc":"Block node is 
>> >> read-only"}}
>> >
>> > I see what's happening here. So we have a graph like this:
>> >
>> >      guest device
>> >           |
>> >           v
>> >     overlay-format -------> backing-format
>> >     [read-only=off]         [read-only=on]
>> >           |                        |
>> >           v                        v
>> >     overlay-proto           backing-proto
>> >     [read-only=off]         [read-only=on]
>> >
>> > The difference between your -blockdev use and -drive is that you
>> > explicitly specify the read-only option for backing-proto (and you use
>> > a separate -blockdev option anyway), so it doesn't just inherit it
>> > from backing-format.
>> 
>> Are these format and protocol block devices opened with four separate
>> -blockdev parameters? Is that how libvirt does it?
>
> Yes. This goes along with the fact that for 'blockdev-create' you need
> to blockdev-add the file which you want to format, but the formatted
> file is not automatically added.
>
> If we'd use the approach where the protocol layer is opened as part of
> the format layer it would complicate the snapshot code where we need
> to add a file and then format it to qcow2. It would mean that we'd
> have to blockdev-add a file, format it via blockdev-create, then
> blockdev-del it and open it together with the format layer. Otherwise
> the disk hot-unplug code would be plain crazy.

Do you need to add the protocol layer in order to format it, though? :-?

(I'm just trying to understand how this works, I'm not too familiar with
blockdev-create)

{'execute': 'blockdev-create',
 'arguments': {'job-id': 'job0',
               'options': {'driver': 'file',
                           'filename': 'test.qcow2',
                           'size': 0}}}
{'execute': 'job-dismiss', 'arguments': {'id': 'job0'}}

{'execute': 'blockdev-create',
 'arguments': {'job-id': 'job1',
               'options': { 'driver': 'qcow2',
                            'size': 1048576,
                            'file': {'driver': 'file',
                                     'filename': 'test.qcow2'}}}}
{'execute': 'job-dismiss', 'arguments': {'id': 'job1'}}

Berto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]