Bug 694420

Summary: After excute update-device comman CDROM device have not be updated.
Product: Red Hat Enterprise Linux 5 Reporter: wangyimiao <yimwang>
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.7CC: ccui, dallan, dyuan, eblake, gren, llim, mrezanin, xen-maint
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-24 08:22:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 699611    
Attachments:
Description Flags
run without mounted cdrom
none
run with mounter cdrom none

Description wangyimiao 2011-04-07 10:18:56 UTC
Description of problem:
After excute update-device comman CDROM device have not be updated.

Version-Release number of selected component (if applicable):
libvirt-0.8.2-18.el5
xen-3.0.3-127.el5
kernel-xen-2.6.18-252.el5

How reproducible:
5/5

Steps to Reproduce:
1. Prepare 2 different ISO files.

Create temp1.iso and temp2.iso

# mkisofs -o /var/lib/xen/images/temp1.iso /tmp

Do some changes in /tmp directory, such as, add/change/remove some new file to make a different iso file

# mkisofs -o /var/lib/xen/images/temp2.iso /tmp

2. Define a guest with a cdrom devcie witch is connected with temp1.iso. Make sure the following is seen in your domain xml file.

<disk type='file' device='cdrom'>
      <driver name='file' />
      <source file='/var/lib/xen/images/temp1.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

3. Prepare a xml as following:

<disk type='file' device='cdrom'>
      <driver name='file' />
      <source file='/var/lib/xen/images/temp2.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>

4. When doaming is inactive, try to update the media in cdrom device.

# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
 36 r5.6                 idle

5.Login guest r5.6 to check CDROM.

# mount /dev/cdrom /media

# ls /media


6.# virsh update-device r5.6 cdrom.xml
Device updated successfully

7.Login guest r5.6 to check CDROM.

# mount /dev/cdrom /media

# ls /media

Actual results:
Content of CDROM  device have not be changed. 

Expected results:

Content of CDROM device should be update to "temp2.iso"

Comment 1 Michal Privoznik 2011-04-28 11:01:18 UTC
Just to make things clear: you did umount /media before update-device, right?
Because I am able to reproduce this bug only without unmounting.

Comment 2 Michal Privoznik 2011-04-28 14:05:27 UTC
Created attachment 495549 [details]
run without mounted cdrom

Comment 3 Michal Privoznik 2011-04-28 14:06:05 UTC
Created attachment 495550 [details]
run with mounter cdrom

Comment 4 Michal Privoznik 2011-04-28 14:10:39 UTC
I belive this is XEN bug, as we can see from attachments.

I've added some debug printings to see communication between libvirt <-> xen.
From the first attachement we can see changing cdrom without being mounted in guest. It works well and xen returns code 200 OK.

From the 2nd attachement we can see how things went wrong. The cdrom was mounted, and update-device was run afterwards. Xen returned 200 OK, which is why libvirt responded "Device updated successfully".

Comment 5 Cui Chun 2011-05-06 05:22:35 UTC
According to comment4, change component to "xen" and continue to track this issue.

Comment 6 Miroslav Rezanina 2011-05-06 07:09:49 UTC
This behavior is partly correct. When cdrom is mounted, device won't be changed. However, this block is not propagated to xenstore as it is done in qemu. This should be change.

Comment 8 Miroslav Rezanina 2011-06-24 08:22:55 UTC
Change of cdrom uses asynchronous xenstore way so there's no way to propagate error into caller. Possible solution is to prevent xenstore change using some flag.

However, upstream does not solve this problem and developing such a solution is out of xen support scope in rhel. As this is internally reported problem and it's not critical issue, we won't fix current behavior.