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.
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list