> Sent: Tuesday, August 03, 2021 at 6:51 PM
> From: "daggs" <daggs at gmx.com>
> To: dan at berrange.com
> Cc: "Martin Kletzander" <mkletzan at redhat.com>,
libvirt-users at redhat.com
> Subject: Re: issues with vm after upgrade
>
> 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.
>
unfortunately, that didn't helped, vm still wont come up, latest log at
http://dpaste.com/2XZA4VQZA
any ideas?
Dagg