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
signature.asc
Description: OpenPGP digital signature
