In virsh I would do this while the guest is running: virsh attach-disk <vmname> <path_to_ISO_file> <guest_device> --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 <js...@redhat.com> 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 <js...@redhat.com<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 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 libvirt's interface. If you don't mind the hassle, trying on the 4.1 (or a development build would be even more luxurious) and giving a stacktrace would be nice. Thanks. Fernando Thanks! --js
