[Top][All Lists]

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

Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH v2 3/6] qapi: add nbd-server-remove
Date: Wed, 17 Jan 2018 18:51:38 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

17.01.2018 18:23, Eric Blake wrote:
On 01/17/2018 07:36 AM, Vladimir Sementsov-Ogievskiy wrote:

looks interesting. what about the following naming?

@mode: possible values:
                hide - just hide server from new clients, maintain
existing connections,
                            remove after all clients disconnected
                soft - like hide, but answer with ESHUTDOWN for all
further requests from
                            existing connections
                hard - hard disconnect all clients and remove server
                (default: soft)
Or even a fourth mode that causes an immediate error return without
state change if there are any connected clients, but otherwise removes
the server.

new corresponding states of nbd export:
hidden, shutting_down

and we allow transitions:

normal_execution -> hidden
normal_execution -> shutting_down
normal_execution -> exit
hidden -> shutting_down
hidden -> exit
shutting_down -> exit
Seems reasonable.  Are you planning on tackling a respin of this series
incorporating that idea?

yes, will do.

Discussed with Nikolay.
For now we actually need only one mode: hard.
In near future we _may be_ will need your proposed fourth mode (what
about "safe" name for it ?)
'safe' sounds reasonable.

Of course, if we only have two modes at front ('safe' which returns an
error if a client is connected, and 'hard' which disconnects all clients
immediately; leaving 'hide' and 'soft' for the future), then we don't
have to worry about a state transition or any hidden exports.

A QAPI enum with only two values now is at least extensible in the
future if someone has a need for another mode, and introspectible to
learn which modes are currently supported.

I was going to implement all 4 modes, but now I doubt, isn't it too
hastily, to introduce 3 new modes to the
interface, which we (personally) do not need. May be it is better to
start from one or two modes.
Starting with just two modes is fine as well.

Finally what do you think, Eric? Which modes do you need?
'hide' may be interesting for the purpose of connecting a single client,
then hiding the export so no other clients can connect, while waiting
for the first client to take its time.  But right now, I don't have
actual use cases in mind so much as making sure we aren't limiting
ourself from future expansion as needs are identified, so a conservative
choice of just 'safe' and 'hard' for now is reasonable.

ok, I agree. 'safe' looks like better option for default behavior. So I'll post these two options in v3.

ps: I've created hmp version for 2/6, it will be in v2.
  also, I'm going to add query-nbd-server, which should list all exports
Sounds good.

also, about HMP: If I understand correctly, people use it because
writing qmp command by hand is not very comfortable.
I have a script (for managing libvirt guest, but it can be adopted for
qemu or even used for qemu monitor), which allows
me run qmp commands on vms as easy as:

|qmp VMNAME query-block-jobs or qmp VMNAME nbd-server-remove name exp1
mode hard or even |

|qmp VMNAME blockdev-add id disk driver qcow2 cache {writeback true
direct true} aio native discard unmap file {driver file filename
/tmp/somedisk} |||
Yeah, there are various scripting solutions around QMP that can make it
easier; but HMP is often still an easy front-line interface for experiments.

isn't it because these solutions are not available directly in monitor, when HMP is? may be, we need third type of monitor HQMP which is QMP with simplified syntax? Or
allow qmp commands in simplified syntax directly in HMP?

Best regards,

reply via email to

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