Re: [Qemu-devel] [PATCH 0/2] help libvirt know what's up with qga

[Laszlo Ersek]

On 05/29/14 22:24, Eric Blake wrote:
> On 05/29/2014 01:36 PM, Laszlo Ersek wrote:
>> In this series I try to implement the ideas that (I believe) were
>> suggested by Gerd and Amit in
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1080376>.
>>
>> When the guest agent exits or dies (disconnects from the virtio-serial
>> port), the backend (eg. a host-side unix domain socket) doesn't (in
>> general, can't) reflect it. This lack of info tends to trip up libvirt
>> in some cases, waiting indefinitely for an agent that doesn't exist.
>>
>> The series adds two monitor events that report about virtio-serial ports
>> being opened and closed (for online notification), and extends the
>> "query-chardev" QMP command's return type with a "frontend_open" bool
>> (for querying at late libvirt startup).
> 
> Thinking about it a bit more, would it help to make the frontend_open a
> tri-state?  It would be nice to know the difference between a guest that
> has no idea how to use the channel (has never opened it in the past;
> possibly because we're still too early in booting the guest) vs. a guest
> that has had a channel up at least once in its lifetime (presumably if
> it is back down, management deserves to be made aware that the guest
> agent is no longer behaving; meanwhile, a guest that has a systemd loop
> to re-establish the agent after any crash may be opening it back up
> shortly).  That is, tracking 'unused', 'open', and 'closed', where the
> 'unused' state is default, but can only be left, and where the 'closed'
> state cannot be entered unless the 'open' state has occurred at least once.

I can try that, but we'll need (more) input from Gerd and/or Amit. The
underlying (backend) CharDriverState.fe_open field (which I expose
directly now) is used elsewhere.

I'd either need to introduce a new "history"-like field, and update it
accordingly in qemu_chr_fe_set_open(), or rework the current field
everywhere.

Then perhaps I'd have to think about migration... which is something I'd
really like to avoid! :) Consider, when you migrate the guest to another
host, the target host should preserve this history for libvirt (because
the guest "inside" is the same of course). You probably can't (won't)
pass this history (the initial value of the tri-state) on the target's
command line, so we'd have to migrate something that's not guest RAM and
also not frontend (== guest device) state... This is where stuff begins
to explode :)

Laszlo