Created attachment 454726 [details] file to define original guest Description of problem: when trying to attach unexisting cdrom to running xen guest , will get successfully prompt , and virsh dumpxml shows that the guest cdrom section is changed to the unexisting file Version-Release number of selected component (if applicable): libvirt-0.8.2-8.el5 kernel-2.6.18-227.el5 xen-3.0.3-117.el5 How reproducible: always Steps to Reproduce: 1. create a vm with attached xml file 2. try to attach an unexisting iso to vm # virsh attach-disk hello /var/lib/libvirt/images/test.iso hdc --driver xen --subdriver raw --type cdrom --mode readonly --sourcetype file Disk attached successfully 3. dump guest xml to check whether the cdrom is attached # virsh dumpxml hello |grep cdrom -A 5 -B 5 <disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/xen/images/test.img'/> <target dev='hda' bus='ide'/> </disk> <disk type='block' device='cdrom'> <driver name='xen'/> <source dev='/var/lib/libvirt/images/test.iso'/> <target dev='hdc' bus='ide'/> <readonly/> </disk> Actual results: could attach unexisting cdrom to guest without error message Expected results: could prompt error message , and don't touch the guest xml file Additional info:
Fix built into xen-3.0.3-118.el5
Version-Release number of selected component (if applicable): libvirt-0.8.2-8.el5 kernel-2.6.18-227.el5 xen-3.0.3-117.el5 Steps to Reproduce: 1. create a vm with attached xml file # virsh define $test.xml # virsh start $vm_name 2. try to attach an unexisting iso to vm # virsh attach-disk hello /var/lib/libvirt/images/test.iso hdc --driver xen --subdriver raw --type cdrom --mode readonly --sourcetype file Disk attached successfully 3. dump guest xml to check whether the cdrom is attached. # virsh dumpxml hello |grep cdrom -A 5 -B 5 <disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/xen/images/RHEL-Server-5.5-32-hvm.raw'/> <target dev='hda' bus='ide'/> </disk> <disk type='block' device='cdrom'> <driver name='xen'/> <source dev='/var/lib/libvirt/images/test.iso'/> <target dev='hdc' bus='ide'/> <readonly/> Actual results: could attach unexisting cdrom to guest without error message
Version-Release number of selected component (if applicable): libvirt-0.8.2-8.el5 kernel-2.6.18-227.el5 xen-3.0.3-118.el5 Actual steps： 1. create a vm with attached xml file # virsh define $test.xml # virsh start $vm_name 2. try to attach an unexisting iso to vm。 # virsh attach-disk hello /var/lib/libvirt/images/test.iso hdc --driver xen --subdriver raw --type cdrom --mode readonly --sourcetype file error: Failed to attach disk error: Requested operation is not valid: Xm driver only supports modifying persistent config 3. dump guest xml to check whether the cdrom is attached. # virsh dumpxml hello |grep cdrom -A 5 -B 5 <disk type='file' device='disk'> <driver name='file'/> <source file='/var/lib/xen/images/RHEL-Server-5.5-32-hvm.raw'/> <target dev='hda' bus='ide'/> </disk> <disk type='file' device='cdrom'> <target dev='hdc' bus='ide'/> <readonly/> </disk> <interface type='bridge'> <mac address='00:16:36:27:22:e3'/> Actual results: 1. guest prompts error msgs.
In comment#6, with xen-118, we can see cdrom through "xm block-list" # xm block-list 2 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 6 4 8 /local/domain/0/backend/vbd/2/768 5632 0 0 3 5 9 /local/domain/0/backend/vbd/2/5632 But if we use "xm block-attach", we CANNOT see cdrom through "xm block-list". 1). # xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 6 4 8 /local/domain/0/backend/vbd/5/768 2). # xm block-attach 5 file:/var/lib/libvirt/images/test.iso hdc:cdrom r Error: Device 5632 (vbd) could not be connected. /etc/xen/scripts/block failed; error detected. Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> Create a new virtual block device. 3). # xm block-list 5 Vdev BE handle state evt-ch ring-ref BE-path 768 0 0 6 4 8 /local/domain/0/backend/vbd/5/768 Should I change it to verified?
Hi Yang, if attach fail, there's no cdrom in guest so block-list is correct. As comment #6 shows, error is reported so the bz can be set to verified.
During "virsh disk-attached". we can find a cdrom with "xm block-list". But after "virsh disk-attached", an error info occurs and cdrom is removed.
Considering the patch just modify the reconfigureDevice() method, I don't think this bug should be verified with 'xm block-attach', which has nothing to do with reconfigureDevice(). Looking into xm codes, I find that 'xm block-configure' is the right one to verify this bug, which triggers reconfigureDevice() to change cdrom device. Bellow is my step to verify this bug(patch?): (1) Create a HVM guest, with cdrom device configured in config file like: disk = ['file:/xen-autotest/xen-autotest/client/tests/xen/images/RHEL-Server-5.5-64-hvm.raw,hda,w', 'file:/root/sol-10-u9-ga-x86-dvd.iso,hdc:cdrom,r'] (2) Reconfigure the cdrom device via xm block-configure command: #xm block-configure vm1 file:/root/bot.iso hdd:cdrom r You could use a non-existed ISO as the back-end device. However, there is misspelling in the patch: if not os.access(new_back['params'],os.R_OK): raise VmError("Can't read disk file %" % new_back['params']) should be: if not os.access(new_back['params'],os.R_OK): raise VmError("Can't read disk file %s" % new_back['params']) Thus we could only get "ValueError: incomplete format" output by now from the command. I have to reopen this bug so that the fix could be fixed in the next version.
(In reply to comment #11) > Considering the patch just modify the reconfigureDevice() method, I don't think > this bug should be verified with 'xm block-attach', which has nothing to do > with reconfigureDevice(). Looking into xm codes, I find that 'xm > block-configure' is the right one to verify this bug, which triggers > reconfigureDevice() to change cdrom device. Bellow is my step to verify this > bug(patch?): > > (1) Create a HVM guest, with cdrom device configured in config file like: > > disk = > ['file:/xen-autotest/xen-autotest/client/tests/xen/images/RHEL-Server-5.5-64-hvm.raw,hda,w', > 'file:/root/sol-10-u9-ga-x86-dvd.iso,hdc:cdrom,r'] > > (2) Reconfigure the cdrom device via xm block-configure command: > > #xm block-configure vm1 file:/root/bot.iso hdd:cdrom r should be: #xm block-configure vm1 file:/root/bot.iso hdc:cdrom r Sorry for inconvenience :) > > You could use a non-existed ISO as the back-end device. However, there is > misspelling in the patch: > > if not os.access(new_back['params'],os.R_OK): > raise VmError("Can't read disk file %" % new_back['params']) > > should be: > > if not os.access(new_back['params'],os.R_OK): > raise VmError("Can't read disk file %s" % new_back['params']) > > Thus we could only get "ValueError: incomplete format" output by now from the > command. I have to reopen this bug so that the fix could be fixed in the next > version.
Fix built into xen-3.0.3-120.el5
Try to verify this bug: Actual steps: same with comment#11 Actual Results: 1). With xen-117 and kernel-xen-233, host doesn't print any error message. 2). With xen-118 and kernel-xen-233, host prints an error message:"incomplete format". 3). With xen-118 and kernel-xen-233, host prints an error message: "Error: Can't read disk file /root/bot.iso Usage: xm block-configure <Domain> <BackDev> <FrontDev> <Mode> [BackDomId] Change block device configuration " With results, I change it to verified.
Sorry, the result 3). 3). With xen-120 and kernel-xen-233. (In reply to comment #15) > Try to verify this bug: > > Actual steps: > same with comment#11 > > Actual Results: > 1). With xen-117 and kernel-xen-233, host doesn't print any error message. > 2). With xen-118 and kernel-xen-233, host prints an error message:"incomplete > format". > 3). With xen-118 and kernel-xen-233, host prints an error message: > "Error: Can't read disk file /root/bot.iso > Usage: xm block-configure <Domain> <BackDev> <FrontDev> <Mode> [BackDomId] > > Change block device configuration > " > > With results, I change it to verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0031.html