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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list