libvirt users - Aug 2021 - issues with vm after upgrade

On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
> > Sent: Tuesday, August 03, 2021 at 6:29 PM
> > From: "Daniel P. Berrange" <dan at berrange.com>
> > To: "daggs" <daggs at gmx.com>
> > Cc: "Martin Kletzander" <mkletzan at redhat.com>,
libvirt-users at redhat.com
> > Subject: Re: issues with vm after upgrade
> >
> > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
> > > Greetings Daniel,
> > >
> > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
> > > > From: "Daniel P. Berrange" <dan at
berrange.com>
> > > > To: "daggs" <daggs at gmx.com>
> > > > Cc: "Martin Kletzander" <mkletzan at
redhat.com>, libvirt-users at redhat.com
> > > > Subject: Re: issues with vm after upgrade
> > > >
> > > > The <audio> element just refers to the *host* backend
used for audio
> > > > playback. It would not affect guest hardware. Further, this
has always
> > > > existed - it just wasn't exposed in the XML previously.
> > > >
> > > >
> > >
> > > the upgrade changed something, here is the qemu cmd before the
upgrade: https://dpaste.com/F2N5T8CT8
> > > here is after https://dpaste.com/F2N5T8CT8
> >
> > Those links are both the same I'm afraid
> >
> 
> Duh! my bad!
> good log: http://dpaste.com/F2N5T8CT8
> bad log: http://dpaste.com/6ECUHD2J8
The new log has a CLI flag

 -audiodev id=audio1,driver=none

but the old log has an env variable

  QEMU_AUDIO_DRV=none

which should be functionally identical, as QEMU will parse them both
to the same internal config.

The obvious difference in the logs which can cause your guest to fail
is the different QEMU version. The old log shows QEMU 5.2.0, while the
new log shows QEMU 6.0.0

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

Greetings Daniel,
> Sent: Tuesday, August 03, 2021 at 6:39 PM
> From: "Daniel P. Berrange" <dan at berrange.com>
> To: "daggs" <daggs at gmx.com>
> Cc: "Martin Kletzander" <mkletzan at redhat.com>,
libvirt-users at redhat.com
> Subject: Re: issues with vm after upgrade
>
> On Tue, Aug 03, 2021 at 05:34:53PM +0200, daggs wrote:
> > > Sent: Tuesday, August 03, 2021 at 6:29 PM
> > > From: "Daniel P. Berrange" <dan at berrange.com>
> > > To: "daggs" <daggs at gmx.com>
> > > Cc: "Martin Kletzander" <mkletzan at redhat.com>,
libvirt-users at redhat.com
> > > Subject: Re: issues with vm after upgrade
> > >
> > > On Tue, Aug 03, 2021 at 05:21:52PM +0200, daggs wrote:
> > > > Greetings Daniel,
> > > >
> > > > > Sent: Tuesday, August 03, 2021 at 4:12 PM
> > > > > From: "Daniel P. Berrange" <dan at
berrange.com>
> > > > > To: "daggs" <daggs at gmx.com>
> > > > > Cc: "Martin Kletzander" <mkletzan at
redhat.com>, libvirt-users at redhat.com
> > > > > Subject: Re: issues with vm after upgrade
> > > > >
> > > > > The <audio> element just refers to the *host*
backend used for audio
> > > > > playback. It would not affect guest hardware. Further,
this has always
> > > > > existed - it just wasn't exposed in the XML
previously.
> > > > >
> > > > >
> > > >
> > > > the upgrade changed something, here is the qemu cmd before
the upgrade: https://dpaste.com/F2N5T8CT8
> > > > here is after https://dpaste.com/F2N5T8CT8
> > >
> > > Those links are both the same I'm afraid
> > >
> >
> > Duh! my bad!
> > good log: http://dpaste.com/F2N5T8CT8
> > bad log: http://dpaste.com/6ECUHD2J8
>
> The new log has a CLI flag
>
>  -audiodev id=audio1,driver=none
>
> but the old log has an env variable
>
>   QEMU_AUDIO_DRV=none
>
> which should be functionally identical, as QEMU will parse them both
> to the same internal config.
>
> The obvious difference in the logs which can cause your guest to fail
> is the different QEMU version. The old log shows QEMU 5.2.0, while the
> new log shows QEMU 6.0.0
>
thanks for the help, I went to look why the efi fw and found out that the nvram
entry in /etc/libvirt/eqmu.conf was deleted upon update.
I'm sure fixing this will solve he boot issue, hopefully audio issue too.

Thanks,

Dagg.