QGA installation issue on Windows

QGA installation issue on Windows

[Kostiantyn Kostiuk]

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

Hi Michal,

I want to discuss your patch
https://gitlab.com/qemu-project/qemu/-/commit/c6f5dd7ac8ef62dcdec4cdeda1467c658161afff

Unfortunately, we found bad behaviour on Windows. On Windows, we run QGA
with `-d --retry-path` options by default, so we expect that QGA will start
even without the vioserial driver and will wait for communication
forever.

This worked previously, but after your patch QGA service fails if the
vioserial communication channel is missing. This behavior is totally
unacceptable for us.

You send this patch to fix a Linux problem, but it causes a Windows problem.
So, what we need on Windows, if --retry-path specified, we should ignore
any channel error and retry the connection. If -d and --retry-path are
specified, it should become a daemon first to make Windows Service Manager
happy.

What problem did you fix for Linux? Can you explain in more detail, so we
can find a proper solution for both Linux and Windows?

Best Regards,
Kostiantyn Kostiuk.

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

Re: QGA installation issue on Windows

[Daniel P. Berrangé]

On Mon, Aug 04, 2025 at 01:54:09PM +0300, Kostiantyn Kostiuk wrote:
> Hi Michal,
> 
> I want to discuss your patch
> https://gitlab.com/qemu-project/qemu/-/commit/c6f5dd7ac8ef62dcdec4cdeda1467c658161afff
> 
> Unfortunately, we found bad behaviour on Windows. On Windows, we run QGA
> with `-d --retry-path` options by default, so we expect that QGA will start
> even without the vioserial driver and will wait for communication
> forever.
> 
> This worked previously, but after your patch QGA service fails if the
> vioserial communication channel is missing. This behavior is totally
> unacceptable for us.
> 
> You send this patch to fix a Linux problem, but it causes a Windows problem.
> So, what we need on Windows, if --retry-path specified, we should ignore
> any channel error and retry the connection. If -d and --retry-path are
> specified, it should become a daemon first to make Windows Service Manager
> happy.

This looks pretty simple to fix - in the initialize_agent() method, if
channel_init() fails, then simply ignore the failure if 'retry_path'
is set, because the later code in run_agent() will already correctly
retry the connection.

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: QGA installation issue on Windows

[Michal Prívozník]

On 8/4/25 13:01, Daniel P. Berrangé wrote:
> On Mon, Aug 04, 2025 at 01:54:09PM +0300, Kostiantyn Kostiuk wrote:
>> Hi Michal,
>>
>> I want to discuss your patch
>> https://gitlab.com/qemu-project/qemu/-/commit/c6f5dd7ac8ef62dcdec4cdeda1467c658161afff
>>
>> Unfortunately, we found bad behaviour on Windows. On Windows, we run QGA
>> with `-d --retry-path` options by default, so we expect that QGA will start
>> even without the vioserial driver and will wait for communication
>> forever.
>>
>> This worked previously, but after your patch QGA service fails if the
>> vioserial communication channel is missing. This behavior is totally
>> unacceptable for us.
>>
>> You send this patch to fix a Linux problem, but it causes a Windows problem.
>> So, what we need on Windows, if --retry-path specified, we should ignore
>> any channel error and retry the connection. If -d and --retry-path are
>> specified, it should become a daemon first to make Windows Service Manager
>> happy.

The original problem I tried to fix was (and I am bit hazy on all the
details): when somebody built their own kernel but forgot to enable
virtio-serial then qemu-ga would fail to initialize but with a
completely irrelevant error message.

> 
> This looks pretty simple to fix - in the initialize_agent() method, if
> channel_init() fails, then simply ignore the failure if 'retry_path'
> is set, because the later code in run_agent() will already correctly
> retry the connection.

Yeah, do you want me to post such patch?

Michal

Re: QGA installation issue on Windows

[Kostiantyn Kostiuk]

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

On Thu, Aug 14, 2025 at 11:06 AM Michal Prívozník <mprivozn@redhat.com>
wrote:

> On 8/4/25 13:01, Daniel P. Berrangé wrote:
> > On Mon, Aug 04, 2025 at 01:54:09PM +0300, Kostiantyn Kostiuk wrote:
> >> Hi Michal,
> >>
> >> I want to discuss your patch
> >>
> https://gitlab.com/qemu-project/qemu/-/commit/c6f5dd7ac8ef62dcdec4cdeda1467c658161afff
> >>
> >> Unfortunately, we found bad behaviour on Windows. On Windows, we run QGA
> >> with `-d --retry-path` options by default, so we expect that QGA will
> start
> >> even without the vioserial driver and will wait for communication
> >> forever.
> >>
> >> This worked previously, but after your patch QGA service fails if the
> >> vioserial communication channel is missing. This behavior is totally
> >> unacceptable for us.
> >>
> >> You send this patch to fix a Linux problem, but it causes a Windows
> problem.
> >> So, what we need on Windows, if --retry-path specified, we should ignore
> >> any channel error and retry the connection. If -d and --retry-path are
> >> specified, it should become a daemon first to make Windows Service
> Manager
> >> happy.
>
> The original problem I tried to fix was (and I am bit hazy on all the
> details): when somebody built their own kernel but forgot to enable
> virtio-serial then qemu-ga would fail to initialize but with a
> completely irrelevant error message.
>
> >
> > This looks pretty simple to fix - in the initialize_agent() method, if
> > channel_init() fails, then simply ignore the failure if 'retry_path'
> > is set, because the later code in run_agent() will already correctly
> > retry the connection.
>
> Yeah, do you want me to post such patch?
>

If you agree with Daniel's idea, I will post a patch.



Best Regards,
Kostiantyn Kostiuk.


>
> Michal
>
>

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