[Qemu-devel] export root node for write through NBD

[Qemu-devel] export root node for write through NBD

[Vladimir Sementsov-Ogievskiy]

Hi all.

We need the following option: start vm in stopped mode (-S) and write 
it's disk before start through NBD.
It should be absolutely safe, but unfortunately it is disallowed by root 
role of the disk.
Is there any workaround or if not, what is a true way to implement this 
possibility?

----
error message:
     unable to execute QEMU command 'nbd-server-add': Conflicts with use 
by drive0 as 'root', which does not allow 'write' on #block100

-- 
Best regards,
Vladimir

Re: [Qemu-devel] export root node for write through NBD

[Max Reitz]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On 2017-11-30 08:47, Vladimir Sementsov-Ogievskiy wrote:
> Hi all.
> 
> We need the following option: start vm in stopped mode (-S) and write
> it's disk before start through NBD.
> It should be absolutely safe, but unfortunately it is disallowed by root
> role of the disk.
> Is there any workaround or if not, what is a true way to implement this
> possibility?
> 
> ----
> error message:
>     unable to execute QEMU command 'nbd-server-add': Conflicts with use
> by drive0 as 'root', which does not allow 'write' on #block100
> 
> -- 

One thing that comes to mind is adding the guest device only after you
are done with NBD.

The other of course is to set share-rw=on for the device.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: [Qemu-devel] export root node for write through NBD

[Kevin Wolf]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Am 30.11.2017 um 15:21 hat Max Reitz geschrieben:
> On 2017-11-30 08:47, Vladimir Sementsov-Ogievskiy wrote:
> > Hi all.
> > 
> > We need the following option: start vm in stopped mode (-S) and write
> > it's disk before start through NBD.
> > It should be absolutely safe, but unfortunately it is disallowed by root
> > role of the disk.
> > Is there any workaround or if not, what is a true way to implement this
> > possibility?
> > 
> > ----
> > error message:
> >     unable to execute QEMU command 'nbd-server-add': Conflicts with use
> > by drive0 as 'root', which does not allow 'write' on #block100
> 
> One thing that comes to mind is adding the guest device only after you
> are done with NBD.
> 
> The other of course is to set share-rw=on for the device.

We already allow this with incoming migration, in that case the
BlockBackend for the guest device stays inactive and doesn't request
permissions yet.

I've been thinking for a while that it would be nice to unify the
startup of "normal" VMs and incoming migration, so that images are
always opened inactive first and then get activated.

The interesting point for you could be that opening the image happens
immediately when the process starts, but activation would only happen
when the VM actually starts running (i.e. on 'cont').

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [Qemu-devel] export root node for write through NBD

[Vladimir Sementsov-Ogievskiy]

30.11.2017 17:33, Kevin Wolf wrote:
> Am 30.11.2017 um 15:21 hat Max Reitz geschrieben:
>> On 2017-11-30 08:47, Vladimir Sementsov-Ogievskiy wrote:
>>> Hi all.
>>>
>>> We need the following option: start vm in stopped mode (-S) and write
>>> it's disk before start through NBD.
>>> It should be absolutely safe, but unfortunately it is disallowed by root
>>> role of the disk.
>>> Is there any workaround or if not, what is a true way to implement this
>>> possibility?
>>>
>>> ----
>>> error message:
>>>      unable to execute QEMU command 'nbd-server-add': Conflicts with use
>>> by drive0 as 'root', which does not allow 'write' on #block100
>> One thing that comes to mind is adding the guest device only after you
>> are done with NBD.
>>
>> The other of course is to set share-rw=on for the device.
> We already allow this with incoming migration, in that case the
> BlockBackend for the guest device stays inactive and doesn't request
> permissions yet.
>
> I've been thinking for a while that it would be nice to unify the
> startup of "normal" VMs and incoming migration, so that images are
> always opened inactive first and then get activated.
>
> The interesting point for you could be that opening the image happens
> immediately when the process starts, but activation would only happen
> when the VM actually starts running (i.e. on 'cont').
>
> Kevin

Could it be as simple as:

diff --git a/block/block-backend.c b/block/block-backend.c
index 3064cb888f..b8cbb43f02 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -709,7 +709,9 @@ static int blk_do_attach_dev(BlockBackend *blk, void 
*dev)
      /* While migration is still incoming, we don't need to apply the
       * permissions of guest device BlockBackends. We might still have 
a block
       * job or NBD server writing to the image for storage migration. */
-    if (runstate_check(RUN_STATE_INMIGRATE)) {
+    if (runstate_check(RUN_STATE_INMIGRATE) ||
+        runstate_check(RUN_STATE_PRELAUNCH))
+    {
          blk->disable_perm = true;
      }


(at least it fixes my case)

-- 
Best regards,
Vladimir