Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
I managed to upgrade to qemu 4.1 on a test KVM host and I can confirm I can't repro the issue in this version. Great news that is fixed in 4.1. Thanks everyone for your inputs and the fast replies. Kind regards, Fernando On vie, oct 25, 2019 at 12:28 PM, Fernando Casas Schössow wrote: Thanks for the reply Kevin. I will do my best to upgrade to 4.1, test again and report back if this is fixed or not in that version. Hopefully it is. Fernando On vie, oct 25, 2019 at 12:07 PM, Kevin Wolf wrote: Am 23.10.2019 um 19:28 hat Fernando Casas Schössow geschrieben: Hi John, Thanks for looking into this. I can quickly repro the problem with qemu 4.0 binary with debugging symbols enabled as I have it available already. Doing the same with qemu 4.1 or development head may be too much hassle but if it's really the only way I can give it try. We had a lot of iothread related fixes in 4.1, so this would really be the only way to tell if it's a bug that still exists. I suspect that it's already fixed (and to be more precise, I assume that commit d0ee0204f fixed it). Kevin
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Thanks for the reply Kevin. I will do my best to upgrade to 4.1, test again and report back if this is fixed or not in that version. Hopefully it is. Fernando On vie, oct 25, 2019 at 12:07 PM, Kevin Wolf wrote: Am 23.10.2019 um 19:28 hat Fernando Casas Schössow geschrieben: Hi John, Thanks for looking into this. I can quickly repro the problem with qemu 4.0 binary with debugging symbols enabled as I have it available already. Doing the same with qemu 4.1 or development head may be too much hassle but if it's really the only way I can give it try. We had a lot of iothread related fixes in 4.1, so this would really be the only way to tell if it's a bug that still exists. I suspect that it's already fixed (and to be more precise, I assume that commit d0ee0204f fixed it). Kevin
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Am 23.10.2019 um 19:28 hat Fernando Casas Schössow geschrieben: > Hi John, > > Thanks for looking into this. I can quickly repro the problem with > qemu 4.0 binary with debugging symbols enabled as I have it available > already. Doing the same with qemu 4.1 or development head may be too > much hassle but if it's really the only way I can give it try. We had a lot of iothread related fixes in 4.1, so this would really be the only way to tell if it's a bug that still exists. I suspect that it's already fixed (and to be more precise, I assume that commit d0ee0204f fixed it). Kevin
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
BTW just to be clear, qemu is crashing in this scenario *only* if iothread is enabled for the guest. Without iothread enabled the operation is completed without any problems. On jue, oct 24, 2019 at 11:07 PM, Fernando Casas Schössow wrote: > Today I updated to qemu 4.0.1 since this was the latest version > available for Alpine and I can confirm that I can repro the issue > with this version as well. > Not sure if relevant but I can also confirm that the problem happens > with Windows Server 2012 R2 but also with Linux guests (it doesn't > matter if the guest use uefi or bios firmware). I made this tests > just to discard things. > > Also as discussed I compiled qemu with debug symbols, repro the > problem, collected a core dump and run both through gdb. This is the > result: > > (gdb) thread apply all bt > > Thread 42 (LWP 33704): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fee02380b64 in ?? () > #3 0x in ?? () > > Thread 41 (LWP 33837): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc1ad5b64 in ?? () > #3 0x in ?? () > > Thread 40 (LWP 33719): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fee02266b64 in ?? () > #3 0x in ?? () > > Thread 39 (LWP 33696): > #0 0x7fee04233171 in syscall () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee02be8b64 in ?? () > #2 0x0030 in ?? () > #3 0x7fee02be2540 in ?? () > #4 0x7fee02be2500 in ?? () > #5 0x7fee02be2548 in ?? () > #6 0x55d7e4987f28 in rcu_gp_event () > #7 0x in ?? () > > Thread 38 (LWP 33839): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc1a83b64 in ?? () > #3 0x in ?? () > > Thread 37 (LWP 33841): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc1737b64 in ?? () > #3 0x in ?? () > > Thread 36 (LWP 33863): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8c83b64 in ?? () > #3 0x in ?? () > > Thread 35 (LWP 33842): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc170eb64 in ?? () > #3 0x in ?? () > > Thread 34 (LWP 33862): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8cacb64 in ?? () > #3 0x in ?? () > > Thread 33 (LWP 33843): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc16e5b64 in ?? () > #3 0x in ?? () > > Thread 32 (LWP 33861): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8cd5b64 in ?? () > #3 0x in ?? () > > Thread 31 (LWP 33844): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc16bcb64 in ?? () > #3 0x in ?? () > > Thread 30 (LWP 33858): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8e83b64 in ?? () > #3 0x in ?? () > > Thread 29 (LWP 33845): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc1693b64 in ?? () > #3 0x in ?? () > > Thread 28 (LWP 33857): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8eacb64 in ?? () > #3 0x in ?? () > > Thread 27 (LWP 33846): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc166ab64 in ?? () > #3 0x in ?? () > > Thread 26 (LWP 33856): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedb8ed5b64 in ?? () > #3 0x in ?? () > > Thread 25 (LWP 33847): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 > #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 > #2 0x7fedc142ab64 in ?? () > #3 0x in ?? () > > Thread 24 (LWP 33855): > #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Today I updated to qemu 4.0.1 since this was the latest version available for Alpine and I can confirm that I can repro the issue with this version as well. Not sure if relevant but I can also confirm that the problem happens with Windows Server 2012 R2 but also with Linux guests (it doesn't matter if the guest use uefi or bios firmware). I made this tests just to discard things. Also as discussed I compiled qemu with debug symbols, repro the problem, collected a core dump and run both through gdb. This is the result: (gdb) thread apply all bt Thread 42 (LWP 33704): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fee02380b64 in ?? () #3 0x in ?? () Thread 41 (LWP 33837): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc1ad5b64 in ?? () #3 0x in ?? () Thread 40 (LWP 33719): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fee02266b64 in ?? () #3 0x in ?? () Thread 39 (LWP 33696): #0 0x7fee04233171 in syscall () from /lib/ld-musl-x86_64.so.1 #1 0x7fee02be8b64 in ?? () #2 0x0030 in ?? () #3 0x7fee02be2540 in ?? () #4 0x7fee02be2500 in ?? () #5 0x7fee02be2548 in ?? () #6 0x55d7e4987f28 in rcu_gp_event () #7 0x in ?? () Thread 38 (LWP 33839): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc1a83b64 in ?? () #3 0x in ?? () Thread 37 (LWP 33841): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc1737b64 in ?? () #3 0x in ?? () Thread 36 (LWP 33863): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8c83b64 in ?? () #3 0x in ?? () Thread 35 (LWP 33842): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc170eb64 in ?? () #3 0x in ?? () Thread 34 (LWP 33862): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8cacb64 in ?? () #3 0x in ?? () Thread 33 (LWP 33843): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc16e5b64 in ?? () #3 0x in ?? () Thread 32 (LWP 33861): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8cd5b64 in ?? () #3 0x in ?? () Thread 31 (LWP 33844): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc16bcb64 in ?? () #3 0x in ?? () Thread 30 (LWP 33858): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8e83b64 in ?? () #3 0x in ?? () Thread 29 (LWP 33845): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc1693b64 in ?? () #3 0x in ?? () Thread 28 (LWP 33857): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8eacb64 in ?? () #3 0x in ?? () Thread 27 (LWP 33846): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc166ab64 in ?? () #3 0x in ?? () Thread 26 (LWP 33856): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8ed5b64 in ?? () #3 0x in ?? () Thread 25 (LWP 33847): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedc142ab64 in ?? () #3 0x in ?? () Thread 24 (LWP 33855): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedb8efeb64 in ?? () #3 0x in ?? () Thread 23 (LWP 33848): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedbd0feb64 in ?? () #3 0x in ?? () Thread 22 (LWP 33854): #0 0x7fee04252080 in ?? () from /lib/ld-musl-x86_64.so.1 #1 0x7fee0424f4b6 in ?? () from /lib/ld-musl-x86_64.so.1 #2 0x7fedbd031b64 in
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
In virsh I would do this while the guest is running: virsh attach-disk--type cdrom --mode readonly Following the example for guest from my first email: virsh attach-disk DCHOMENET01 /resources/virtio-win-0.1.171-stable.iso sdb --type cdrom --mode readonly Right after executing this, qemu crashes and log the assertion. I can repro this also from virt-manager by selecting the cdrom device -> Connect -> selecting the ISO file -> Choose volume -> Ok (basically the same but in the gui). I may be able to try 4.1. Will look into it and report back. On mié, oct 23, 2019 at 7:33 PM, John Snow wrote: On 10/23/19 1:28 PM, Fernando Casas Schössow wrote: Hi John, Thanks for looking into this. I can quickly repro the problem with qemu 4.0 binary with debugging symbols enabled as I have it available already. Doing the same with qemu 4.1 or development head may be too much hassle but if it's really the only way I can give it try. Would it worth it to try with 4.0 first and get the strack trace or it will not help and the only way to go is with 4.1 (or dev)? Thanks, Fernando If 4.0 is what you have access to, having the stack trace for that is better than not, but confirming it happens on the latest release would be nice. Can you share your workflow for virsh that reproduces the failure? --js On mié, oct 23, 2019 at 5:34 PM, John Snow mailto:js...@redhat.com>> wrote: On 10/18/19 5:41 PM, Fernando Casas Schössow wrote: Hi, Hi! Thanks for the report. Today while working with two different Windows Server 2012 R2 guests I found that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt (virsh or virt-manager) while the guest is running, qemu crashes and the following message is logged: Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to try to attach an ISO file to the SCSI CDROM while the guest is running. The SCSI controller model is virtio-scsi with iothread enabled. Please find below all the details about my setup that I considered relevant but I missed something please don't hesitate to let me know: Looks like we got aio_context management wrong with iothread for the media change events somewhere. Should be easy enough to fix if we figure out where the bad assumption is. Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 Do you have the ability to try 4.1, or the latest development head with debugging symbols enabled? Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: virtio-scsi (with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers version: 171 (current stable) qemu command line: /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=45,server,nowait -device
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Hi John, Thanks for looking into this. I can quickly repro the problem with qemu 4.0 binary with debugging symbols enabled as I have it available already. Doing the same with qemu 4.1 or development head may be too much hassle but if it's really the only way I can give it try. Would it worth it to try with 4.0 first and get the strack trace or it will not help and the only way to go is with 4.1 (or dev)? Thanks, Fernando On mié, oct 23, 2019 at 5:34 PM, John Snow wrote: On 10/18/19 5:41 PM, Fernando Casas Schössow wrote: Hi, Hi! Thanks for the report. Today while working with two different Windows Server 2012 R2 guests I found that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt (virsh or virt-manager) while the guest is running, qemu crashes and the following message is logged: Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to try to attach an ISO file to the SCSI CDROM while the guest is running. The SCSI controller model is virtio-scsi with iothread enabled. Please find below all the details about my setup that I considered relevant but I missed something please don't hesitate to let me know: Looks like we got aio_context management wrong with iothread for the media change events somewhere. Should be easy enough to fix if we figure out where the bad assumption is. Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 Do you have the ability to try 4.1, or the latest development head with debugging symbols enabled? Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: virtio-scsi (with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers version: 171 (current stable) qemu command line: /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=45,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on I
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
On 10/23/19 1:28 PM, Fernando Casas Schössow wrote: > Hi John, > > Thanks for looking into this. > I can quickly repro the problem with qemu 4.0 binary with debugging > symbols enabled as I have it available already. > Doing the same with qemu 4.1 or development head may be too much hassle > but if it's really the only way I can give it try. > > Would it worth it to try with 4.0 first and get the strack trace or it > will not help and the only way to go is with 4.1 (or dev)? > > Thanks, > > Fernando > If 4.0 is what you have access to, having the stack trace for that is better than not, but confirming it happens on the latest release would be nice. Can you share your workflow for virsh that reproduces the failure? --js > On mié, oct 23, 2019 at 5:34 PM, John Snow wrote: >> On 10/18/19 5:41 PM, Fernando Casas Schössow wrote: >> >> Hi, >> >> Hi! Thanks for the report. >> >> Today while working with two different Windows Server 2012 R2 >> guests I found that when I try to attach an ISO file to a SCSI >> CD-ROM device through libvirt (virsh or virt-manager) while the >> guest is running, qemu crashes and the following message is >> logged: Assertion failed: blk_get_aio_context(d->conf.blk) == >> s->ctx >> (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: >> virtio_scsi_ctx_check: 246) I can repro this at will. All I have >> to do is to try to attach an ISO file to the SCSI CDROM while the >> guest is running. The SCSI controller model is virtio-scsi with >> iothread enabled. Please find below all the details about my setup >> that I considered relevant but I missed something please don't >> hesitate to let me know: >> >> Looks like we got aio_context management wrong with iothread for the >> media change events somewhere. Should be easy enough to fix if we >> figure out where the bad assumption is. >> >> Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 >> >> Do you have the ability to try 4.1, or the latest development head >> with debugging symbols enabled? >> >> Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI >> controller: virtio-scsi (with iothread enabled) Guest firmware: >> OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers >> version: 171 (current stable) qemu command line: >> /usr/bin/qemu-system-x86_64 -name >> guest=DCHOMENET01,debug-threads=on -S -object >> >> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes >> -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu >> >> IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff >> -drive >> >> file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on >> -drive >> >> file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 >> -m 1536 -overcommit mem-lock=off -smp >> 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid >> f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults >> -chardev socket,id=charmonitor,fd=33,server,nowait -mon >> chardev=charmonitor,id=monitor,mode=control -rtc >> base=localtime,driftfix=slew -global >> kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global >> PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot >> strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device >> >> virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 >> -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 >> -drive >> >> file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads >> -device >> >> scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on >> -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device >> >> scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 >> -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device >> >> virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 >> -chardev >> socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait >> -device >> isa-serial,chardev=charserial0,id=serial0 -chardev >> spicevmc,id=charchannel0,name=vdagent -device >> >> virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 >> -chardev socket,id=charchannel1,fd=45,server,nowait -device >> >> virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 >> -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 >> -device
Re: qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
On 10/18/19 5:41 PM, Fernando Casas Schössow wrote: > Hi, > Hi! Thanks for the report. > Today while working with two different Windows Server 2012 R2 guests I > found that when I try to attach an ISO file to a SCSI CD-ROM device > through libvirt (virsh or virt-manager) while the guest is running, > qemu crashes and the following message is logged: > > Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx > (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: > virtio_scsi_ctx_check: 246) > > I can repro this at will. All I have to do is to try to attach an ISO > file to the SCSI CDROM while the guest is running. > The SCSI controller model is virtio-scsi with iothread enabled. > Please find below all the details about my setup that I considered > relevant but I missed something please don't hesitate to let me know: > Looks like we got aio_context management wrong with iothread for the media change events somewhere. Should be easy enough to fix if we figure out where the bad assumption is. > Host arch: x86_64 > Distro: Alpine Linux 3.10.2 > qemu version: 4.0 Do you have the ability to try 4.1, or the latest development head with debugging symbols enabled? > Linux kernel version: 4.19.67 > libvirt: 5.5.0 > Emulated SCSI controller: virtio-scsi (with iothread enabled) > Guest firmware: OVMF-EFI > Guest OS: Window Server 2012 R2 > Guest virtio drivers version: 171 (current stable) > > qemu command line: > > /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S > -object > secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes > > -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu > IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff > > -drive > file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on > > -drive > file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 > > -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 > -object iothread,id=iothread1 -uuid > f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults > -chardev socket,id=charmonitor,fd=33,server,nowait -mon > chardev=charmonitor,id=monitor,mode=control -rtc > base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay > -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global > PIIX4_PM.disable_s4=1 -boot strict=on -device > qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device > virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 > -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive > file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads > > -device > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on > > -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device > scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 > > -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 > > -chardev > socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait > -device isa-serial,chardev=charserial0,id=serial0 -chardev > spicevmc,id=charchannel0,name=vdagent -device > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 > > -chardev socket,id=charchannel1,fd=45,server,nowait -device > virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 > > -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 > -device > virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 > > -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice > port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on > -device > qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 > > -chardev spicevmc,id=charredir0,name=usbredir -device > usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev > spicevmc,id=charredir1,name=usbredir -device > usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox > on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny > -msg timestamp=on > > I can provide a core dump of the process if needed for debugging and > the guest XML as well. > A backtrace is probably a great starting point (from gdb: `thread apply all bt`.) I don't know exactly what codepath is being exercised when you "attach an ISO file" through
qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Hi, Today while working with two different Windows Server 2012 R2 guests I found that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt (virsh or virt-manager) while the guest is running, qemu crashes and the following message is logged: Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to try to attach an ISO file to the SCSI CDROM while the guest is running. The SCSI controller model is virtio-scsi with iothread enabled. Please find below all the details about my setup that I considered relevant but I missed something please don't hesitate to let me know: Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: virtio-scsi (with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers version: 171 (current stable) qemu command line: /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=45,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on I can provide a core dump of the process if needed for debugging and the guest XML as well. Thanks. Fernando
qemu crashing when attaching an ISO file to a virtio-scsi CD-ROM device through libvirt
Hi, Today while working with two different Windows Server 2012 R2 guests I found that when I try to attach an ISO file to a SCSI CD-ROM device through libvirt (virsh or virt-manager) while the guest is running, qemu crashes and the following message is logged: Assertion failed: blk_get_aio_context(d->conf.blk) == s->ctx (/home/buildozer/aports/main/qemu/src/qemu-4.0.0/hw/scsi/virtio-scsi.c: virtio_scsi_ctx_check: 246) I can repro this at will. All I have to do is to try to attach an ISO file to the SCSI CDROM while the guest is running. The SCSI controller model is virtio-scsi with iothread enabled. Please find below all the details about my setup that I considered relevant but I missed something please don't hesitate to let me know: Host arch: x86_64 Distro: Alpine Linux 3.10.2 qemu version: 4.0 Linux kernel version: 4.19.67 libvirt: 5.5.0 Emulated SCSI controller: virtio-scsi (with iothread enabled) Guest firmware: OVMF-EFI Guest OS: Window Server 2012 R2 Guest virtio drivers version: 171 (current stable) qemu command line: /usr/bin/qemu-system-x86_64 -name guest=DCHOMENET01,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-78-DCHOMENET01/master-key.aes -machine pc-i440fx-4.0,accel=kvm,usb=off,dump-guest-core=on -cpu IvyBridge,ss=on,vmx=off,pcid=on,hypervisor=on,arat=on,tsc_adjust=on,umip=on,xsaveopt=on,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -drive file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/DCHOMENET01_VARS.fd,if=pflash,format=raw,unit=1 -m 1536 -overcommit mem-lock=off -smp 1,sockets=1,cores=1,threads=1 -object iothread,id=iothread1 -uuid f06978ad-2734-44ab-a518-5dfcf71d625e -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=33,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device qemu-xhci,id=usb,bus=pci.0,addr=0x4 -device virtio-scsi-pci,iothread=iothread1,id=scsi0,num_queues=1,bus=pci.0,addr=0x5 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/storage/storage-hdd-vms/virtual_machines_hdd/dchomenet01.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=none,discard=unmap,aio=threads -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,device_id=drive-scsi0-0-0-0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on -drive if=none,id=drive-scsi0-0-0-1,readonly=on -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,device_id=drive-scsi0-0-0-1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1 -netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=43 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:99:b5:62,bus=pci.0,addr=0x3 -chardev socket,id=charserial0,host=127.0.0.1,port=4900,telnet,server,nowait -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -chardev socket,id=charchannel1,fd=45,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spiceport,id=charchannel2,name=org.spice-space.webdav.0 -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.spice-space.webdav.0 -device virtio-tablet-pci,id=input2,bus=pci.0,addr=0x7 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on I can provide a core dump of the process if needed for debugging and the guest XML as well. Thanks. Fernando
