From: Fima Shevrin <efim.shevrin@virtuozzo.com>

When the guest OS starts, qemu-ga sends an event to the host.
This event allows services on the host to start configuring
the already running guest OS. When configuring network settings,
it is possible that an external service will receive a signal
from qemu-ga about the start of guest OS, while NetworkManager
may not be running yet. Therefore, network setting may not
be available. With the current patch, we eliminate the described
race condition between qemu-ga and NetworkManager for guest OS
network setting cases.

Signed-off-by: Fima Shevrin <efim.shevrin@virtuozzo.com>
---
 contrib/systemd/qemu-guest-agent.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/systemd/qemu-guest-agent.service b/contrib/systemd/qemu-guest-agent.service
index 51cd7b37ff..6e2d059356 100644
--- a/contrib/systemd/qemu-guest-agent.service
+++ b/contrib/systemd/qemu-guest-agent.service
@@ -2,6 +2,7 @@
 Description=QEMU Guest Agent
 BindTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
 After=dev-virtio\x2dports-org.qemu.guest_agent.0.device
+After=NetworkManager.service
 
 [Service]
 ExecStart=-/usr/bin/qemu-ga
-- 
2.34.1

On Thu, Aug 17, 2023 at 04:04:46AM +0800, Efim Shevrin via wrote:
> From: Fima Shevrin <efim.shevrin@virtuozzo.com>
> 
> When the guest OS starts, qemu-ga sends an event to the host.
> This event allows services on the host to start configuring
> the already running guest OS. When configuring network settings,
> it is possible that an external service will receive a signal
> from qemu-ga about the start of guest OS, while NetworkManager
> may not be running yet. Therefore, network setting may not
> be available. With the current patch, we eliminate the described
> race condition between qemu-ga and NetworkManager for guest OS
> network setting cases.

A host mgmt app should not be assuming that networking is
running at all, and if it is, the guest might not even be
on the same subnet as the host. Conceivably someone could
even be using QGA to inject files to configure networking.

Overall, IMHO, it is wrong to correlate host notification
that QGA is running, with any assumption about state of
the guest networking.

IOW, I don't think we should make an attempt to serialize
startup of QGA after guest networking. The QGA should be
run as soon as its data transport (virtio-serial/vsock)
is available, which is the current state.

If a host consumer of QGA wants to do something with
guest networking, they should check for guest network
state with the 'guest-network-get-interfaces' command.



With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

17.08.2023 13:26, Daniel P. Berrangé wrote:
..
> A host mgmt app should not be assuming that networking is
> running at all, and if it is, the guest might not even be
> on the same subnet as the host. Conceivably someone could
> even be using QGA to inject files to configure networking.
> 
> Overall, IMHO, it is wrong to correlate host notification
> that QGA is running, with any assumption about state of
> the guest networking.
> 
> IOW, I don't think we should make an attempt to serialize
> startup of QGA after guest networking. The QGA should be
> run as soon as its data transport (virtio-serial/vsock)
> is available, which is the current state.
> 
> If a host consumer of QGA wants to do something with
> guest networking, they should check for guest network
> state with the 'guest-network-get-interfaces' command.

Full nod.

/mjt