[PATCH] qga: Start qemu-ga service after NetworkManager start

[PATCH] qga: Start qemu-ga service after NetworkManager start

[Efim Shevrin via]

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

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

Hi, Efim

Thanks for your contribution.

I think your patch is a partial solution because other network managers can
be used
for example systemd-networkd or dhcpcd. Maybe a better solution is
After=network.target.

Do you have any other suggestions?

Best Regards,
Konstantin Kostiuk.


On Wed, Aug 16, 2023 at 11:20 PM Efim Shevrin <efim.shevrin@virtuozzo.com>
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.
>
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2374 bytes --]

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Daniel P. Berrangé]

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 :|

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Daniel P. Berrangé]

On Thu, Aug 17, 2023 at 09:15:08AM +0300, Konstantin Kostiuk wrote:
> Hi, Efim
> 
> Thanks for your contribution.
> 
> I think your patch is a partial solution because other network managers can
> be used
> for example systemd-networkd or dhcpcd. Maybe a better solution is
> After=network.target.

network.target does not imply that any NICs are configured with
an IP address, merely that the networking mgmt daemon(s) are
running.  A dep on NetworkManager.service has the same issue.
NetworkManager has started, but this doesn't imply DHCP has
completed

network-online.target has the semantics that an IP is present,
but per my other reply I don't think we should be serializing
QGA startup against network configuration.


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 :|

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Denis V. Lunev]

On 8/17/23 12:26, Daniel P. Berrangé wrote:
> 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.

This is very tight question at my opinion.

Frankly speaking my original intention here would be
to put QGA at the very end of the startup sequence
in order to avoid complications. In the other case
any host side software, which would like to control
the guest behavior will be in trouble.

For example, yet another common application is a
guest backup, here I would say application based
backup. In a normal case this is done through
    /etc/qemu-ga/fsfreeze-hook

I would say that agent should start very last, in the
other case *ANY* software working through the agent
must take efforts to avoid such transient state, which
is complicated.

Den

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Michael Tokarev]

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

Re: [PATCH] qga: Start qemu-ga service after NetworkManager start

[Daniel P. Berrangé]

On Thu, Aug 17, 2023 at 12:47:48PM +0200, Denis V. Lunev wrote:
> On 8/17/23 12:26, Daniel P. Berrangé wrote:
> > 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.
> 
> This is very tight question at my opinion.
> 
> Frankly speaking my original intention here would be
> to put QGA at the very end of the startup sequence
> in order to avoid complications. In the other case
> any host side software, which would like to control
> the guest behavior will be in trouble.
> 
> For example, yet another common application is a
> guest backup, here I would say application based
> backup. In a normal case this is done through
>    /etc/qemu-ga/fsfreeze-hook

It will already be started after local-fs.target, since it does not
have DefaultDependencies=no set. This should be sufficient for
fsfreeze use cases IIUC.

> I would say that agent should start very last, in the
> other case *ANY* software working through the agent
> must take efforts to avoid such transient state, which
> is complicated.



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 :|