On Tue, Jan 05, 2016 at 10:34:16 +0100, Peter Krempa wrote:
On Tue, Jan 05, 2016 at 10:23:59 +0100, Michal Privoznik wrote:
> On 04.01.2016 16:28, Peter Krempa wrote:
> > On Tue, Dec 22, 2015 at 15:41:16 +0100, Michal Privoznik wrote:
> >>
https://bugzilla.redhat.com/show_bug.cgi?id=1293351
> >>
...
Okay, I had to actually look at the code at this point. So the above
statement is not entirely true either. There is a bug in the code that
would not set the state to _CONNECTED if qemuConnectAgent failed.
Otherwise the state is always updated and for non-agent VIRTIO channels
it even doesn't have a condition that would allow this to fail.
As the channel state doesn't necessarily have to denote that the agent
socket is connected due to various reasons the state should always be
updated.
>
> Moreover, I realized we will need to format @config->state into domain
> XML more often - e.g. during migration - we want to connect on the other
> side iff we are connected on the source. I have v3 patches ready.
I don't think so. This state can be re-queried at the destination of the
migration once the migration is complete and thus it does not need to be
transported. The only reason why the virtio channel state is parsed from
the XML is to report correct transitions in the event.
So I just figured out that we should do the correct tranistion event
even after migration, so yes, the port state should be formatted also
into the migratable XML. The problem there is that the migration might
transfer the VM to a qemu instance that doesn't support this event which
will then render a lot of this stuff not working properly though so the
migration code will need to correctly handle the state after that.