Comment 14 for bug 368962

On Sun, Apr 25, 2010 at 04:35:25PM -0000, Neil Wilson wrote:
>> So you would have the call hang for some amount of time until you
>> decide that by then it should have shut down and then return failure?
>> How long would you suggest? Remember, libvirt API calls are not
>> asynchronous, so
> Pick a number. it's a synchronous call. Where's the 80% case? Anybody
> else can use the underlying primitives and poll a bit longer/shorter.

So you'd err out instead of falling back to forcibly killing the domain?
Hm. Interesting.

>> this is a concern that needs to be addressed. We can't just have the
>> call tentatively return succesfully and then later call back into the
>> calling application telling it that it didn't work out.
> It'll only return successful if a call to the libvirt status element
> returns 'off' during the poll period and it was able to successfully
> issue 'boot'.

So in the succesful case, the call will take as long as the VM takes to
shut down, and in the failure case, it'd take some amount of time longer
(and in the case of the VM not having ACPI enabled, it'll be
instantaneous). I don't know, really. I'm not super hot on the idea of
function calls that block for that long. Maybe I'm just too used to
writing async code these days. :)

>> For fully virtualised guests, I really believe you'd be better off
>> with a tool that knows about the guests in question and that can Do
>> The Right
> Excellent. Where is said tool?

That's the point. I don't know what's running in your VM's, so I can't
write the tool for you. Chances are that said tool wouldn't even be
using libvirt to do it (in which case libvirt obviously can't (or at
least very much shouldn't)) help you. If an OS doesn't support or
respond correctly to ACPI events, you may want to connect to it over SSH
and issue a command or maybe connect to it over VNC and send it a
ctrl-alt-delete.

>>> Simples
>> Sorry, but I beg to differ. If not, I'd have done this a long, long
>> time ago. I have to deal with this (rebooting guests) on a reasonably
>> regular basis.
> Don't you think you are searching for perfection rather than
> implementing something that is 'good enough' for the majority of uses?

I think I just have different measures of "good enough".

> Get it to log a warning if you're worried about bugs. At the moment
> *everybody* has to implement 'shutdown, poll for a bit, startup' (or
> would do if the acpi scripts worked). I've just written another one
> this week, whereas a default one that hung around for a bit and worked
> with a standard Ubuntu server would have been plenty good enough.

...and as I've said, what you're suggesting would not work with Ubuntu
Server out of the box, so it's a moot point. The only thing I can think
of that would work out of the box on Ubuntu Server is something that
would send ctrl-alt-delete to the guest.

--
Soren Hansen
Ubuntu Developer
http://www.ubuntu.com/