qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 0/2] help libvirt know what's up with qga
Date: Thu, 29 May 2014 15:12:26 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 05/29/2014 02:54 PM, Laszlo Ersek wrote:
>> 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 :)

Ooh, fairly convincing argument against tracking sticky history, and
just going with the simpler boolean solution.  Okay, never mind this
suggestion, libvirt will make do without it :)

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]