On 02/27/2018 04:42 AM, Star Guo wrote: This indicates that disk->info.alias is NULL meaning that qemuAssignDeviceDiskAlias needs to be called as well prior to qemuDomainPrepareDiskSource from Michal's patch; however, ... ... this wouldn't be right anyway I believe... First of all, there's another path to qemuDomainChangeEjectableMedia via the attach command which wouldn't alter the "new" disk source (even if the disk->info.alias was set prior to this call). Secondly we "know" that the guest was started using some sort of disk source provided without the "tray='open'" being set. For example, if my similar type test using: <disk type='network' device='cdrom'> <driver name='qemu' type='raw'/> <source protocol='iscsi' name='iqn.2013-12.com.example:iscsi-1g-disks/1'> <host name='192.168.122.1' port='3260'/> <auth username='redhat'> <secret type='iscsi' usage='libvirtiscsi'/> </auth> </source> <target dev='hdb' bus='ide'/> <readonly/> </disk> had set "tray='open'" on the <target> element, then (as I found out after lots of debugging) qemuBuildDriveSourceStr would end up creating a CDROM, but the type would be 'file' as the subsequent dumpxml shows when the guest is running: <disk type='file' device='cdrom'> <target dev='hdb' bus='ide' tray='open'/> <readonly/> <alias name='ide0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> So, back to the original issue and away from the diversion... "Theoretically speaking" the original guest start should have added a secret object for the original disk source using that disk source's alias. For example (using the iSCSI example from above) the following command line is created: -object secret,id=ide0-0-1-secret0,data=AtxGltyV5HoTvGhIaSOEeA==,keyid=masterKey0,iv=4l3Uancr25jF/rD5oTuFaw==,format=base64 -drive file.driver=iscsi,file.portal=192.168.122.1:3260,file.target=iqn.2013-12.com.example:iscsi-1g-disks,file.lun=1,file.transport=tcp,file.user=redhat,file.password-secret=ide0-0-1-secret0,format=raw,if=none,id=drive-ide0-0-1,readonly=on That means the secret object exists and "unlike" the other Attach paths that go through qemuDomainAttachDiskGeneric, we would already have the object and thus "should" be able to use the object if we could... The problem is - I see no way to do that. Both the QEMU "rbd" and "iscsi" driver open code need to have some way to authenticate to the server, but no mechanism in the "change" command is provided. For example, for the rbd example we start in qmp_change calling qmp_blockdev_change_medium calling bdrv_open calling qemu_rbd_open calling rados_connect whereupon the failure generates the "error connecting" message with the EOPNOTSUPP message as seen in the original posting (since snipped out): 2018-02-26 13:09:13.678+0000: 50516: error : qemuMonitorJSONCheckError:392 : internal error: unable to execute QEMU command 'change': error connecting: Operation not supported FWIW: The iSCSI code is a bit better at telling you what went wrong: error: internal error: unable to execute QEMU command 'change': iSCSI: Failed to connect to LUN : Failed to log in to target. Status: Authentication failure(513) But I was only able to get that far by making an adjustment to qemuBuildGeneralSecinfoURI to break on VIR_DOMAIN_SECRET_INFO_TYPE_AES so that the qemuGetDriveSourceString called in ChangeEjectableMedia wouldn't fail with "error: An error occurred, but the cause is unknown". I also read in qapi-schema.json that the "@change" command has the following dubious comment: # Notes: This interface is deprecated, and it is strongly recommended that you # avoid using it. For changing block devices, use # blockdev-change-medium; for changing VNC parameters, use # change-vnc-password. Digging slightly deeper into the @blockdev-change-medium command doesn't appear to show a way to also provide a secret object to use for the open, but I didn't follow that code any further In summary, this is a (very) long and winding way to say, you can't get there from here as far as I can tell. Someone at the very least needs to add a "password-secret" attribute/option (whatever it's called) to the qemu blockdev-change-medium command. Then libvirt needs to support the newer code and figure out the correct magic incantation in order to allow adding a network source change for a cdrom. May I also say/point out that qemuDomainDiskSourceDiffers has a comment that starts "This won't be a network storage..." which seems is not entirely true, but that's a different issue. Might be nice to file a couple of bug reports for feature requests so this isn't entirely lost. John Not the way I thought I'd start my post vacation day ;-)... Nothing like jumping headfirst into the very deep end of a particularly thorny and convoluted problem.