Re: issues with vm after upgrade

Sent: Wednesday, August 11, 2021 at 10:14 AM From: "Martin Kletzander" <mkletzan(a)redhat.com&gt; To: "daggs" <daggs(a)gmx.com&gt; Cc: dan(a)berrange.com, libvirt-users(a)redhat.com Subject: Re: issues with vm after upgrade On Tue, Aug 10, 2021 at 09:21:00PM +0200, daggs wrote: >Greetings Martin, Dan > >> Sent: Wednesday, August 04, 2021 at 1:54 PM >> From: "daggs" <daggs(a)gmx.com&gt; >> To: "Martin Kletzander" <mkletzan(a)redhat.com&gt; >> Cc: libvirt-users(a)redhat.com, dan(a)berrange.com >> Subject: Re: issues with vm after upgrade >> >> Greetings Martin, >> >> > Sent: Wednesday, August 04, 2021 at 11:52 AM >> > From: "Martin Kletzander" <mkletzan(a)redhat.com&gt; >> > To: "daggs" <daggs(a)gmx.com&gt; >> > Cc: libvirt-users(a)redhat.com, dan(a)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(a)redhat.com&gt; >> > >> To: "daggs" <daggs(a)gmx.com&gt; >> > >> Cc: libvirt-users(a)redhat.com, dan(a)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(a)gmx.com&gt; >> > >> >> To: dan(a)berrange.com >> > >> >> Cc: "Martin Kletzander" <mkletzan(a)redhat.com&gt;, libvirt-users(a)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(a)berrange.com&gt; >> > >> >> > To: "daggs" <daggs(a)gmx.com&gt; >> > >> >> > Cc: "Martin Kletzander" <mkletzan(a)redhat.com&gt;, libvirt-users(a)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(a)berrange.com&gt; >> > >> >> > > > To: "daggs" <daggs(a)gmx.com&gt; >> > >> >> > > > Cc: "Martin Kletzander" <mkletzan(a)redhat.com&gt;, libvirt-users(a)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(a)berrange.com&gt; >> > >> >> > > > > > To: "daggs" <daggs(a)gmx.com&gt; >> > >> >> > > > > > Cc: "Martin Kletzander" <mkletzan(a)redhat.com&gt;, libvirt-users(a)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 >> > >I was able to get the vm running again by creating the xml again. the only issue I'm facing is the fact that only the one playback device is visible: >**** List of PLAYBACK Hardware Devices **** >card 0: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog] > Subdevices: 1/1 > Subdevice #0: subdevice #0 >prior to the upgrade I had hdmi entries too. >I've check with two different oses and the issue persists. >as mentioned before, if I drop this line: -audiodev id=audio1,driver=none from the cmd, I see all the playback channels. > >any idea? > So to clean up this thread let me reply to the two issues separately. 1) if your device-assigned audio is not visible with '-audiodev id=audio1,driver=none', but *is* visible with QEMU_AUDIO_DRV=none, then that is a bug in QEMU and needs to be dealt with there.

2) To your issue with starting the domain it would be good to know what is the error you get from virsh (or however you are starting the domain) and the debug logs of libvirtd, ideally just for the part of the domain starting.