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 at gmx.com>
>> To: "Martin Kletzander" <mkletzan at redhat.com>
>> Cc: libvirt-users at redhat.com, dan at berrange.com
>> Subject: Re: issues with vm after upgrade
>>
>> 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
>>
>
>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.
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20210811/3d701d55/attachment.sig>