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.
>
> 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.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
