[libvirt] [PATCH v4] qemu: Connect to guest agent iff needed

[Michal Privoznik]

On 02.02.2016 18:47, John Ferlan wrote:
> 
> 
> On 01/18/2016 05:54 AM, Michal Privoznik wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1293351
>>
>> Since we already have virtio channel events, we know when guest
>> agent within guest has (dis-)connected. Instead of us blindly
>> connecting to a socket that no one is listening to, we can just
>> follow what qemu-ga does. This has a nice benefit that we don't
>> need to 'guest-ping' the agent just to timeout and find out
>> nobody is listening.
>>
>> The way that this commit is implemented:
>> - don't connect in qemuProcessStart directly, defer that to event
>>   callback (which already follows the agent).
> 
> The qemuConnectAgent is called in qemuProcessLaunch... Curious, are you
> referring to processSerialChangedEvent handling the connect on event
> callback?
> 

Oh right. I will update the commit message. I am still not used to
qemuProcessStart split. Yes, it should have been qemuProcessLaunch and
processSerialChangedEvent.

>> - after migration is settled, before we resume vCPUs, ask qemu
>>   whether somebody is listening on the socket and if so, connect
>>   to it.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>
>> diff to v3:
>> -Move cap detection into qemuConnectAgent
>>
>>  src/qemu/qemu_driver.c    | 13 ++++++++++++-
>>  src/qemu/qemu_migration.c | 12 ++++++++++++
>>  src/qemu/qemu_process.c   | 24 ++++++++++++++++++++++++
>>  3 files changed, 48 insertions(+), 1 deletion(-)
>>
> 
> Concept seems reasonable - have a question though...
> 
> With the change to qemuConnectAgent that means the qemuProcessReconnect
> would call qemuProcessReconnectRefreshChannelVirtioState again later in
> processing.  So should it matter?

Good catch. I guess my patch can be updated so that Refresh() is called
just once. Generally it wouldn't matter but what's the point in calling
it twice, right?

> 
> Is there anything in the interceding code between he qemuConnectAgent
> call and where that Refresh call is now that may do "something" that
> perhaps the Channel code may be assuming would be done?  I'm perhaps
> thinking most of security mgr settings. Compared to when AgentConnect is
> called during qemuProcessLaunch processing - it's done much earlier for
> Reconnect
> 

Yes. it's called very early. But even though it is, I don't think that
any code should have problem. Firstly, host visible part (= agent
socket) is always there regardless of qemu-ga running inside or not. So
seclabel mgrs have something to work with. Secondly, the rest of or code
that actually relies on qemuAgent connection must be adopted to
disappearing agent because we already follow (dis-)connecting agent.

Thanks!
Michal