Sent: Wednesday, August 11, 2021 at 4:13 PM
From: "Martin Kletzander" <mkletzan(a)redhat.com>
To: "daggs" <daggs(a)gmx.com>
Cc: dan(a)berrange.com, libvirt-users(a)redhat.com
Subject: Re: issues with vm after upgrade
On Wed, Aug 11, 2021 at 03:09:34PM +0200, daggs wrote:
>Greetings Martin,
>
>> Sent: Wednesday, August 11, 2021 at 10:14 AM
>> From: "Martin Kletzander" <mkletzan(a)redhat.com>
>> To: "daggs" <daggs(a)gmx.com>
>> 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>
>> >> To: "Martin Kletzander" <mkletzan(a)redhat.com>
>> >> 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>
>> >> > To: "daggs" <daggs(a)gmx.com>
>> >> > 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>
>> >> > >> To: "daggs" <daggs(a)gmx.com>
>> >> > >> 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>
>> >> > >> >> To: dan(a)berrange.com
>> >> > >> >> Cc: "Martin Kletzander"
<mkletzan(a)redhat.com>, 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>
>> >> > >> >> > To: "daggs"
<daggs(a)gmx.com>
>> >> > >> >> > Cc: "Martin Kletzander"
<mkletzan(a)redhat.com>, 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>
>> >> > >> >> > > > To: "daggs"
<daggs(a)gmx.com>
>> >> > >> >> > > > Cc: "Martin Kletzander"
<mkletzan(a)redhat.com>, 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>
>> >> > >> >> > > > > > To: "daggs"
<daggs(a)gmx.com>
>> >> > >> >> > > > > > Cc: "Martin
Kletzander" <mkletzan(a)redhat.com>, 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.
>I'll ping the eqmu devs on this.
>
>>
>> 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.
>that is the issue, there wasn't any error. the vm just didn't booted.
Oh, so I misunderstood. What was the state of the VM in libvirt?
"paused" or "running"? Was there serial console working?
>I can diff the original xml with the new one to see the diffs and post them here if
you wish
>
Would be nice to see if there are any differences. The newly created
one works then?