Bug 694420 - After excute update-device comman CDROM device have not be updated.
Summary: After excute update-device comman CDROM device have not be updated.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.7
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Xen Maintainance List
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 699611
TreeView+ depends on / blocked
 
Reported: 2011-04-07 10:18 UTC by wangyimiao
Modified: 2011-06-24 08:22 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-24 08:22:55 UTC
Target Upstream Version:


Attachments (Terms of Use)
run without mounted cdrom (8.66 KB, text/plain)
2011-04-28 14:05 UTC, Michal Privoznik
no flags Details
run with mounter cdrom (4.33 KB, text/plain)
2011-04-28 14:06 UTC, Michal Privoznik
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.