[libvirt] [PATCH v2 2/6] virsh: add support for VIR_DOMAIN_CONSOLE_FORCE flag

[Eric Blake]

On 12/14/2011 01:46 AM, Peter Krempa wrote:
>> But maybe we could add a new API, to allow probing whether a console is
>> in use.  If the API exists, then we know whether the console is in use
>> (and we also know whether --force will work); if the API does not exist,
>> the we know we are talking to an older server that multiplexes
>> connections.  Maybe we should have:
>>
>> virsh console domain --safe =>  refuse to connect unless connection is
>> safe (fails on older servers)
>> virsh console domain --force =>  force connection (fails on older
>> servers)
>> virsh console domain =>  existing behavior (connects on older servers,
>> even if it corrupts connection, and safely connects on newer servers)
> 
> Yes, that's definitely a good idea.
> 
>> that is, I'm thinking it might be worth it to add a new --safe option
>> that lets the user probe (via a new API virDomainConsoleInUse(dom,
>> dev_name, flags)) whether the attempt will be safe.
> 
> I was thinking about adding another flag. With that flag specified, the
> virDomainConsoleOpen function would return success without any
> operation, confirming, that the server is capable of handling console
> connections in a safe way. The client could then open the connection
> calling this function again.
> 
> What do you think about this option?

Good idea - using a new flag instead of a new API entry point should be
sufficient.  I see a couple of possibilities:

virDomainConsoleOpen(,0) -> existing behavior on older servers, safe
behavior on newer servers
virDomainConsoleOpen(,_FORCE) -> rejected on older servers, forces
behavior on newer servers
virDomainConsoleOpen(,_PROBE) -> rejected on older servers, probes (but
does not connect) on newer servers

I'm not sure whether _PROBE should succeed or fail if it detects the
server has support for safe behavior, but that the console is currently
in use.  Since probe does not do the open, we _must_ make Open(,0) check
for other users when probe is supported, in order to avoid a TOCTTOU
race.  At which point, we can either have _PROBE blindly succeed when
(,0) is safe (merely as a witness that can be exploited by virsh), or
actually check the state of the console and return a distinct error if
the console is in use at the time (but applications can't put too much
trust in that return, since only the actual open attempt will tell
whether the console situation changed between the probe and the open).

Or maybe we do:

virDomainConsoleOpen(,0) -> existing behavior on older servers, safe
behavior on newer servers
virDomainConsoleOpen(,_FORCE) -> rejected on older servers, forces
behavior on newer servers
virDomainConsoleOpen(,_SAFE) -> rejected on older servers, identical to
(,0) on newer servers

Either semantic works for me; and if we go with _PROBE instead of _SAFE,
I'm also okay with either choice of blindly succeeding on _PROBE to
indicate capability, or actually probing and returning a distinct error
to indicate an in-use console.  I guess at this point it's up to you in
your v3, unless anyone else also expresses a preference.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20111214/9b8c5224/attachment-0001.sig>