Bug 288460 - XEN: cannot change CD-ROM media
Summary: XEN: cannot change CD-ROM media
Status: RESOLVED FEATURE
Alias: None
Product: openSUSE 10.2
Classification: openSUSE
Component: Xen (show other bugs)
Version: Final
Hardware: i686 openSUSE 10.2
: P5 - None : Enhancement with 4 votes (vote)
Target Milestone: ---
Assignee: David Reveman
QA Contact: Bryan Perry
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-29 12:46 UTC by Forgotten User 42maXmOW7B
Modified: 2008-07-16 21:02 UTC (History)
2 users (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Forgotten User 42maXmOW7B 2007-06-29 12:46:59 UTC
Changing a CD-ROM for a running VM appears impossible:

- The drive button is disabled.

- Software eject from within the VM has no effect.

- Software eject from the host results in the drive appearing permanently "not ready" within the VM.

- Trying to detach the drive first and reattach it afterwards with:

  # xm block-detach myvm hdc
  # eject cdrom
  # xm block-attach myvm phy:sr0 hdc r

doesn't help, and the last command emits the error message:

  Error: Device /dev/hdc (5632, vbd) is already connected.

The only way out seems to be a restart of the VM.

Tested on a Pentium D940, openSuSE 10.2 retail, 32 bit install, with a "full virtualization" VM running Microsoft Windows 2000 Professional.
Comment 1 Albert Jan Stevens 2007-07-10 10:17:34 UTC
I also experience this problem when installing OES Linux on Xen for development. The bug is even mentioned in the xm man page. 

Quote: 

"            FIXME: this is currently broken.  Even though a block device is
           removed from domU, it appears to still be allocated in the domain
           0.
"

I would love a fix for this issue, or even a workaround, as I feel changing CD's is a nifty feature which will increase my productivity ;). 

Comment 2 Frank Kohler 2007-07-11 13:35:20 UTC
Due to the overall project status of Xen this is not likely to be fixed in 10.2 but there are initiatives to drive this for 10.3. 

It might be easier to use iso images though.
Comment 3 Torsten Hallmann 2007-07-17 09:07:11 UTC
This is not only limited to "real" block devices within dom0 that are mapped to a vm. I just see the same issue with SLES10SP1 x86_64 when trying to remove the following part from a fullvirt VM:

    (device
        (vbd
            (uuid bc518bc0-bc01-6e1a-171e-a7c2f0499b4a)
            (dev hdc:cdrom)
            (uname file:/srv/ftp/isos/SLES-9-SP-3-x86-64-RC4-CD1.iso)
            (mode r)
            (type cdrom)
            (backend 0)

And as we do not provide an SLES9SP3 overlay DVD for installation the block-detach is important to run fullvirt SLES9.
Comment 4 Albert Jan Stevens 2007-07-17 12:38:30 UTC
For now you can work around it (when using images) by directly altering the xenstore using xenstore-write 

An example, only last step is required off course. 

theLuggage:/etc/xen/vm # xm list
Name                                      ID Mem(MiB) VCPUs State   Time(s)
Domain-0                                   0     1477     2 r-----   2076.4
OESL-IDM                                   1      512     1 r-----      2.2

theLuggage:/etc/xen/vm # xm block-list 1
Vdev  BE handle state evt-ch ring-ref BE-path
768    0    0     1      -1     -1    /local/domain/0/backend/vbd/1/768  
5632    0    0     1      -1     -1    /local/domain/0/backend/vbd/1/5632  


//Now that you have the virtual CD and store path you can read what its parameters are.

theLuggage:/etc/xen/vm # xenstore-read /local/domain/0/backend/vbd/1/5632/params
/media/BOOK/iso/oessp2linux01.iso


//Or you can update it with your new iso file.

theLuggage:/etc/xen/vm # xenstore-write /local/domain/0/backend/vbd/1/5632/params /media/BOOK/iso/oessp2linux02.iso 

This will immediately change the attached iso. 

Comment 5 Forgotten User 42maXmOW7B 2007-07-25 07:53:56 UTC
While using ISO images is a functional workaround, it certainly doesn't qualify as easier if you have to copy every CD/DVD you need to use completely to a hard disk image from dom0 first, always provide sufficient free disk space for any ISO images you might need, etc. So it's still desirable to have the original issue fixed.