Greetings Martin,
> Sent: Wednesday, August 04, 2021 at 11:52 AM
> From: "Martin Kletzander" <mkletzan at redhat.com>
> To: "daggs" <daggs at gmx.com>
> Cc: libvirt-users at redhat.com, dan at berrange.com
> Subject: Re: issues with vm after upgrade
>
> On Wed, Aug 04, 2021 at 10:30:29AM +0200, daggs wrote:
> >Greetings Martin ,
> >
> >> Sent: Wednesday, August 04, 2021 at 11:11 AM
> >> From: "Martin Kletzander" <mkletzan at redhat.com>
> >> To: "daggs" <daggs at gmx.com>
> >> Cc: libvirt-users at redhat.com, dan at berrange.com
> >> Subject: Re: issues with vm after upgrade
> >>
> >> On Tue, Aug 03, 2021 at 08:47:20PM +0200, daggs wrote:
> >> >> 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?
> >> >
> >>
> >> Seems like the issue is:
> >>
> >> 2021-07-16T10:29:19.259409Z qemu-system-x86_64: vfio: Cannot reset
device 0000:00:1f.3, no available reset mechanism.
> >> 2021-07-16T10:29:19.369391Z qemu-system-x86_64: vfio: Cannot reset
device 0000:00:1f.3, no available reset mechanism.
> >>
> >> did you upgrade anything else?
> >>
> >
> >are you sure? you can see the same prints in the good log at
http://dpaste.com/F2N5T8CT8
> >
>
> Oh, sorry, my bad. Then I do not see why it would not start. You said
> you managed to make the VM start on your own, what was the change that
> made it boot? Maybe there's a bug somewhere in qemu...
>
since the upgrade I wasn't able to boot it using libvirt. however the
following qemucmd works:
qemu-system-x86_64 \
-machine pc-q35-5.0,accel=kvm,usb=off,smm=on,dump-guest-core=off \
-cpu host,migratable=on \
-m 15360 \
-smp 4,sockets=1,dies=1,cores=2,threads=2 \
-drive file=/home/streamer/streamer.img.qcow2.new,if=virtio,format=qcow2 \
-device
vfio-pci,host=0000:00:02.0,romfile=/home/streamer/gpu-8086:5912-uefi.rom,multifunction=on
\
-device vfio-pci,host=0000:00:1f.3,multifunction=on \
-usb \
-device usb-host,vendorid=0x046d,productid=0xc52e \
-device usb-host,vendorid=0x2548,productid=0x1002 \
-display none \
-netdev tap,id=hostnet0,ifname=virtsw-streamer,script=no,downscript=no \
-device e1000e,netdev=hostnet0,id=net0,mac=52:54:00:5a:4c:8c \
-blockdev
'{"driver":"file","filename":"/usr/share/edk2-ovmf/OVMF_CODE.secboot.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/streamer-vm-q35_VARS.fd","node-name":"libvirt-pflash1-storage","auto-readonly":true,"discard":"unmap"}'
Dagg