Description of problem: I'm trying to using virsh update-device to update the CDROM from type='file' to ceph rbd iso with type='network'. But I always get error: Failed to update device from disk error: internal error: unable to execute QEMU command 'change': error connecting: Operation not supported I'm using libvirt-libs-3.10.0-1.el7.x86_64 with centos7.4 my original cdrom xml: <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hdc' bus='ide' tray='open'/> <readonly/> <alias name='ide0-1-0'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> my rbd cdrom xml: <disk device="cdrom" type="network"> <driver name='qemu' type='raw'/> <auth username="zstack"> <secret type="ceph" uuid="efd3eb93-014f-4a0f-ba1f-84d7e70c9a89"/> </auth> <source name="ssd/4922ebebd7b52f11bf13b3a482b6ab7e@4922ebebd7b52f11bf13b3a482b6ab7e" protocol="rbd"> <host name="192.168.250.35" port="6789"/> </source> <target bus="ide" dev="hdc"/> <readonly/> </disk> From the libvirtd.log, I got Send command '{"execute":"change","arguments":{"device":"drive-ide0-1-0","target":"rbd:ssd/4922ebebd7b52f11bf13b3a482b6ab7e@4922ebebd7b52f11bf13b3a482b6ab7e:auth_supported=none:mon_host=192.168.250.35\\:6789","arg":"raw"},"id":"libvirt-286"}' which seems it pass the auth_support=none to the qemu, while I'm using an authentication ceph, it should use auth_support=cephx instead. I also tried to boot the VM with rbd iso and then update-device to another rbd iso, but got no luck with the same error. I have succeeded to update-device with libvirt-1.3.3, Version-Release number of selected component (if applicable): libvirt-libs-3.10.0-1.el7.x86_64 How reproducible: Steps to Reproduce: 1. start a vm with <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <target dev='hdc' bus='ide' tray='open'/> <readonly/> <alias name='ide0-1-0'/> <address type='drive' controller='0' bus='1' target='0' unit='0'/> </disk> 2. virsh update-device $vm $xml <disk device="cdrom" type="network"> <driver name='qemu' type='raw'/> <auth username="zstack"> <secret type="ceph" uuid="efd3eb93-014f-4a0f-ba1f-84d7e70c9a89"/> </auth> <source name="ssd/4922ebebd7b52f11bf13b3a482b6ab7e@4922ebebd7b52f11bf13b3a482b6ab7e" protocol="rbd"> <host name="192.168.250.35" port="6789"/> </source> <target bus="ide" dev="hdc"/> <readonly/> </disk> 3. Actual results: error: Failed to attach device from disk error: internal error: unable to execute QEMU command 'change': error connecting: Operation not supported Expected results: Additional info:
The cdrom code does not setup authentication so this will not work properly currently. I hope to address this together with the change to use -blockdev in libvirt. I'll assign it to myself for the time being.
(In reply to Peter Krempa from comment #1) > The cdrom code does not setup authentication so this will not work properly > currently. I hope to address this together with the change to use -blockdev > in libvirt. I'll assign it to myself for the time being. Thanks for the reply, so it doesn't support update cdrom using rbd protocol with authentication in the current version? and is there any plan to fix this or will it be the default behavior? Thanks.
(In reply to chao.zhou from comment #2) > (In reply to Peter Krempa from comment #1) > > The cdrom code does not setup authentication so this will not work properly > > currently. I hope to address this together with the change to use -blockdev > > in libvirt. I'll assign it to myself for the time being. > > Thanks for the reply, so it doesn't support update cdrom using rbd protocol > with authentication in the current version? No as I've said in the comment above, the code does not work with authenticated images. > and is there any plan to fix > this or will it be the default behavior? Thanks. Yes, as I've said above, my work on using qemu's -blockdev infrastructure instead of -drive should result into fixing that.
(In reply to Peter Krempa from comment #3) > (In reply to chao.zhou from comment #2) > > (In reply to Peter Krempa from comment #1) > > > The cdrom code does not setup authentication so this will not work properly > > > currently. I hope to address this together with the change to use -blockdev > > > in libvirt. I'll assign it to myself for the time being. > > > > Thanks for the reply, so it doesn't support update cdrom using rbd protocol > > with authentication in the current version? > > No as I've said in the comment above, the code does not work with > authenticated images. > > > and is there any plan to fix > > this or will it be the default behavior? Thanks. > > Yes, as I've said above, my work on using qemu's -blockdev infrastructure > instead of -drive should result into fixing that. got it, thanks for the explanation.
Hi Peter, do we have any update on this issue?
I'm still working on integrating block jobs with blockdev. That blocks enablement of use of -blockdev. The only way to test the new disk change code is to make code change to libvirt to enable -blockdev use and obviously block jobs will break everything.
commit da7123a686f6d0d65dc14263d35f8ecd66f89fd1 Author: Peter Krempa <pkrempa> Date: Fri Jul 13 18:06:09 2018 +0200 qemu: hotplug: Implement removable media change for -blockdev Use the new APIs which allow to manipulate the tray and media separately and also allow using a nodename to refer to a media to implement media changing. With the new approach we don't have to call eject twice as the media is removed by calling qemuMonitorBlockdevMediumRemove. The blockdev feature was enabled since: commit c6a9e54ce3252196f1fc6aa9e57537a659646d18 Author: Peter Krempa <pkrempa> Date: Mon Jan 7 11:45:19 2019 +0100 qemu: enable blockdev support Now that all pieces are in place (hopefully) let's enable -blockdev. We base the capability on presence of the fix for 'auto-read-only' on files so that blockdev works properly, mandate that qemu supports explicit SCSI id strings to avoid ABI regression and that the fix for 'savevm' is present so that internal snapshots work. v5.9.0-390-gc6a9e54ce3 (note this corresponds to the upcomming 5.10 upstream release) and requires upstream qemu-4.2 or appropriate downstream.