Xen users - Dec 2006 - Using CD drives with Xen 3.0.3 on CentOS 4.4

I''d like to be able to use a CD drive on the Dom0 to be accessible on 
the DomU systems. I do see some notes involving cdrom drives in the Xen 
3.1 Enterprise notes, and in the VT notes, but not for systems without 
that on-board virtualization feature. And the syntax of the cdrom 
command options are documented nowhere in 3.0.3.

I found completely useless notes at 
http://www.xensource.com/support/3.1/xenserver-userguide.html. 
Unfortunately, the Xen 3.0.3 RPM''s for RHEL4 and which seem quite
usable
for CentOS 4.4 do not include even the manual pages of the 
documentation, not even the manual pages or HTML docs, and attempting to 
build them from the SRPM fails miserably. Note that the Fedora SRPM''s 
seem to have fixed this: bad RPM''s hurt your credibility in the 
developer''s world, folks, as badly as poor documentation!
Unfortunately,
the Fedora RPM''s have a whole plethora of requirements not easily 
available on RHEL 4.x or CentOS 4.x.

The samples in the xmexample.hvm and xmexample.vti files seem to be 
unhelpful as well. Using the same kernel as Dom0, or the DomU kernel, 
I''m simply not seeing the /dev/hdb or /dev/cdrom entry for the CD
drive,
and it''s not showing up in /proc on the DomU at all.

Has anyone else been through this with a non-virtualized CPU as well, or 
with Xen 3.0.3, not the enterprise version?
   

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>I''d like to be able to use a CD drive on the Dom0 to be accessible
on
>the DomU systems. I do see some notes involving cdrom drives in the Xen 
>3.1 Enterprise notes, and in the VT notes, but not for systems without 
>that on-board virtualization feature. And the syntax of the cdrom 
>command options are documented nowhere in 3.0.3.
You can export the CD-ROM drive to the guest by using the file: directive, 
as you would for other disks. This will work for iso files and for 
/dev/cdrom

e.g. something like

disk = [ ''file:/dev/cdrom,hdd,r'', <your entries for other
disks go here> ]

will give the domain access to the contents of the real physical CD-ROM 
drive. Note that you''ll want to have the CD-ROM you want to use in the 
drive when the domain boots, otherwise it''ll confuse the
guest''s probing of
disk size. Using an ISO file is probably more straightfoward and 
convenient. If you want to change ISO file you should be able to use xm 
block-detach and xm block-attach to add a new ISO to the guest. If you 
change the CD-ROM in an exported physical drive, I''d suggest doing xm 
block-detach, then changing the CD, then xm block-attach, so that the guest 
knows something has changed.

Note that the Xen paravirtualised block drive doesn''t provide full
CD-ROM
emulation: you should be able to mount the filesystem, but you won''t be
able to treat it entirely like a CD drive because some of the special 
operations will not be supported (eject springs to mind, but there are 
other CD-ROM specific operations).
>I found completely useless notes at 
>http://www.xensource.com/support/3.1/xenserver-userguide.html. 
>Unfortunately, the Xen 3.0.3 RPM''s for RHEL4 and which seem quite
usable
>for CentOS 4.4 do not include even the manual pages of the 
>documentation, not even the manual pages or HTML docs, and attempting to 
>build them from the SRPM fails miserably. Note that the Fedora
SRPM''s
>seem to have fixed this: bad RPM''s hurt your credibility in the 
>developer''s world, folks, as badly as poor documentation!
Unfortunately,
>the Fedora RPM''s have a whole plethora of requirements not easily 
>available on RHEL 4.x or CentOS 4.x.
>
>The samples in the xmexample.hvm and xmexample.vti files seem to be 
>unhelpful as well. Using the same kernel as Dom0, or the DomU kernel, 
>I''m simply not seeing the /dev/hdb or /dev/cdrom entry for the CD
drive,
>and it''s not showing up in /proc on the DomU at all.
A domU won''t have any drives unless they''re configured in
it''s config file
(or attached to the domain at runtime). There''s not a default CD-ROM
device
for paravirtualised guests. Using the above method you should be able to 
export the CD-ROM''s contents to the guest, although it won''t
actually be
specifically aware that it''s a CD-ROM drive.
>Has anyone else been through this with a non-virtualized CPU as well, or 
>with Xen 3.0.3, not the enterprise version?
Hopefully the above method will be sufficient from your needs. I run my 
development machine on CentOS 4.4 (albeit running xen-unstable built from 
source for my purposes) so can try to replicate and resolve any specific 
problems you run into.

Hope that helps some. You''re quite right that this sort of thing should
be
documented more thoroughly. Since the next release of RHEL will include 
Xen, hopefully CentOS (5) integration will be an improvement - sorry you 
had problems with the existing packages.

Cheers,
Mark

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

M.A. Williamson wrote:
>> I''d like to be able to use a CD drive on the Dom0 to be
accessible on
>> the DomU systems. I do see some notes involving cdrom drives in the 
>> Xen 3.1 Enterprise notes, and in the VT notes, but not for systems 
>> without that on-board virtualization feature. And the syntax of the 
>> cdrom command options are documented nowhere in 3.0.3.
>
> You can export the CD-ROM drive to the guest by using the file: 
> directive, as you would for other disks. This will work for iso files 
> and for /dev/cdrom
>
> e.g. something like
>
> disk = [ ''file:/dev/cdrom,hdd,r'', <your entries for
other disks go
> here> ]
Hmm. That seems only fully workable for already mounted drives, but
I''ll
check it out.

I am amused and confused by the use of  
''file:/var/lib/xen/images/file.img,hda,w '' as opposed to 
''file:/var/lib/xen/images/file.img,hda1,w''  and the
fascinating
partition adventures involved. It could also use some documentation. 
Having to deduce that sort of thing from scratch is asking for pain and 
work out the tradeoffs for yourself is asking for pain.
> will give the domain access to the contents of the real physical 
> CD-ROM drive. Note that you''ll want to have the CD-ROM you want to
use
> in the drive when the domain boots, otherwise it''ll confuse the 
> guest''s probing of disk size. Using an ISO file is probably more 
> straightfoward and convenient. If you want to change ISO file you 
> should be able to use xm block-detach and xm block-attach to add a new 
> ISO to the guest. If you change the CD-ROM in an exported physical 
> drive, I''d suggest doing xm block-detach, then changing the CD,
then
> xm block-attach, so that the guest knows something has changed.
ISO files are great, but wind up taking space on your Dom0 to build. And 
creating them from DVD''s becomes even more burdensome, and *burning* 
CD''s or DVD''s from the guest domain would be even more
awkward.
> Note that the Xen paravirtualised block drive doesn''t provide full
> CD-ROM emulation: you should be able to mount the filesystem, but you 
> won''t be able to treat it entirely like a CD drive because some of
the
> special operations will not be supported (eject springs to mind, but 
> there are other CD-ROM specific operations).
Yeah, that''s why I hadn''t even considered the file: approach.
I may have
to use it after all.
>
> Hopefully the above method will be sufficient from your needs. I run 
> my development machine on CentOS 4.4 (albeit running xen-unstable 
> built from source for my purposes) so can try to replicate and resolve 
> any specific problems you run into.
>
> Hope that helps some. You''re quite right that this sort of thing 
> should be documented more thoroughly. Since the next release of RHEL 
> will include Xen, hopefully CentOS (5) integration will be an 
> improvement - sorry you had problems with the existing packages.
>
Thanks. How are you downloading the unstable source?

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>> You can export the CD-ROM drive to the guest by using the file: 
>> directive, as you would for other disks. This will work for iso files 
>> and for /dev/cdrom
>>
>> e.g. something like
>>
>> disk = [ ''file:/dev/cdrom,hdd,r'', <your entries
for other disks go
>> here> ]
>Hmm. That seems only fully workable for already mounted drives, but
I''ll
>check it out.
That''s the physical device file, so you won''t need to actually
mount the
drive. You will need to have the disk in the drive before you start the 
domain / block-attach it, otherwise the size probing may go wrong :-(
>I am amused and confused by the use of  
>''file:/var/lib/xen/images/file.img,hda,w '' as opposed to 
>''file:/var/lib/xen/images/file.img,hda1,w''  and the
fascinating
>partition adventures involved. It could also use some documentation. 
>Having to deduce that sort of thing from scratch is asking for pain and 
>work out the tradeoffs for yourself is asking for pain.
It is a bit "unconventional", to say the least!

Just to clarify, it''s perfectly valid to export as a whole device (e.g.
''file:/var/lib/xen/images/file.img,hda,w '') as you would on
other virtual
machine systems. The ability to export as a partition (e.g. 
''file:/var/lib/xen/images/file.img,hda1,w '') is provided for
ease of
management: you don''t really *need* to have a partition table in a
paravirt
guest, and it''s nice to simply be able to work with individual guest 
filesystems when configuring from dom0, rather than having to deal with 
accessing subranges of a guest disk file.
>> will give the domain access to the contents of the real physical 
>> CD-ROM drive. Note that you''ll want to have the CD-ROM you
want to use
>> in the drive when the domain boots, otherwise it''ll confuse
the
>> guest''s probing of disk size. Using an ISO file is probably
more
>> straightfoward and convenient. If you want to change ISO file you 
>> should be able to use xm block-detach and xm block-attach to add a new 
>> ISO to the guest. If you change the CD-ROM in an exported physical 
>> drive, I''d suggest doing xm block-detach, then changing the
CD, then
>> xm block-attach, so that the guest knows something has changed.
>ISO files are great, but wind up taking space on your Dom0 to build. And 
>creating them from DVD''s becomes even more burdensome, and
*burning*
>CD''s or DVD''s from the guest domain would be even more
awkward.
I''m afraid you''re not going to be able to burn and optical
disks from
either paravirt or HVM domains for the time being :-(

You *could* add a second IDE controller card to your system, export that to 
a guest via the PCI passthrough and then use that to drive a CD writer, but 
this would be rather heavyweight and imply trust of the guest OS.

When USB virtualisation is working (it may already work in HVM) it should 
be possible to pass a USB burner through to the guest, and that would 
enable this kind of use.
>> Note that the Xen paravirtualised block drive doesn''t provide
full
>> CD-ROM emulation: you should be able to mount the filesystem, but you 
>> won''t be able to treat it entirely like a CD drive because
some of the
>> special operations will not be supported (eject springs to mind, but 
>> there are other CD-ROM specific operations).
>Yeah, that''s why I hadn''t even considered the file:
approach. I may have
>to use it after all.
Afraid so, sorry :-( For many uses (e.g. just grabbing some files from the 
disk), it should work OK. But you can''t just boot off a CD-ROM in a PV 
domain, nor can you place CD music, etc.
>Thanks. How are you downloading the unstable source?
I get mine using mercurial:
hg clone http://xenbits.xensource.com/xen-unstable.hg

I''d generally recommend using a release version for production systems,
3.0.4 being the latest and (hopefull) greatest. 
http://xenbits2.xensource.com/xen-3.0.4-testing.hg should contain 3.0.4 + 
bugfixes that are being tested to be rolled up into the next 3.0.4.x 
update.

There will be tarballs of 3.0.4 linked off one of the Xen homepages, once 
they have been updated. Building your own Xen is reasonably straightforward 
once you know your way around the components, and there should be various 
HOWTOs hanging around.

Hope that helps. If you still have problems with the CD-ROM we can try and 
find a workaround for you.

Cheers,
Mark

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

M.A. Williamson wrote:
> I''m afraid you''re not going to be able to burn and
optical disks from
> either paravirt or HVM domains for the time being :-(
Drat. I was looking at using a DomU to run rsnapshot for network 
snapshot access, and do DVD burning from those, rather than having to do 
it on Dom0.
> You *could* add a second IDE controller card to your system, export 
> that to a guest via the PCI passthrough and then use that to drive a 
> CD writer, but this would be rather heavyweight and imply trust of the 
> guest OS.
Hmm. All the drives are SATA, it''s only the CD/DVD drive that is IDE. 
Adding in another ATA card is begging for pain, especially physically 
routing the cables to the CD drive in the 1U servers I''m working with.
That seems unwise.
> When USB virtualisation is working (it may already work in HVM) it 
> should be possible to pass a USB burner through to the guest, and that 
> would enable this kind of use.
I''m already using an external USB storage device, via the 
"file:/dev/sdc1,sdc1,w'' syntax, which seems workable for external
USB
drives.
>>> Note that the Xen paravirtualised block drive doesn''t
provide full
>>> CD-ROM emulation: you should be able to mount the filesystem, but 
>>> you won''t be able to treat it entirely like a CD drive
because some
>>> of the special operations will not be supported (eject springs to 
>>> mind, but there are other CD-ROM specific operations).
>> Yeah, that''s why I hadn''t even considered the file:
approach. I may
>> have to use it after all.
>
> Afraid so, sorry :-( For many uses (e.g. just grabbing some files from 
> the disk), it should work OK. But you can''t just boot off a CD-ROM
in
> a PV domain, nor can you place CD music, etc.
Yeah. that needs to be made clear. The Xen configuration files simply 
accept it and seem to ignore it. Putting in useful error messages would 
help.
>> Thanks. How are you downloading the unstable source?
>
> I get mine using mercurial:
> hg clone http://xenbits.xensource.com/xen-unstable.hg
Hmm. I''m not familiar with that source control system. (Ghods know
I''ve
worked with CVS, Perforce, Subversion, and some unspeakable homebrews!) 
Is there any reason to prefer it to the others, such as Subvresion which 
also supports branching properly?
> I''d generally recommend using a release version for production 
> systems, 3.0.4 being the latest and (hopefull) greatest. 
> http://xenbits2.xensource.com/xen-3.0.4-testing.hg should contain 
> 3.0.4 + bugfixes that are being tested to be rolled up into the next 
> 3.0.4.x update.
>
> There will be tarballs of 3.0.4 linked off one of the Xen homepages, 
> once they have been updated. Building your own Xen is reasonably 
> straightforward once you know your way around the components, and 
> there should be various HOWTOs hanging around.
>
> Hope that helps. If you still have problems with the CD-ROM we can try 
> and find a workaround for you.
It did help. I''d be happy to write up such notes and adventures for the
FAQ''s or installation notes, but I''m seeing significant
divergence
between packages such as RedHat''s with the virtmanager tool on top of 
it, and the bare Xen tools. Weirdness such as the failure of the RHEL 
4.x SRPM published by Xensource  to be able to build the documentation 
put me off it for a while. Other oddness such as using non-getopt based 
command line arguments have also slowed me down. Examples include 
arguments using "create" instead of "--create", and
alternating the use
of "DomU", and "guest", or of "migrate" and
"relocate" in both
configuration files nad actual command line arguments, or the "xm 
migrate" command having its flags at the end, just waste my time having 
to look up and remember all the different argument structures.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

>> I''m afraid you''re not going to be able to burn and
optical disks from
>> either paravirt or HVM domains for the time being :-(
>Drat. I was looking at using a DomU to run rsnapshot for network 
>snapshot access, and do DVD burning from those, rather than having to do 
>it on Dom0.
Mmmmm. The best you could do at the moment would be to make isos and have 
dom0 pick them up somehow and burn them.
>> You *could* add a second IDE controller card to your system, export 
>> that to a guest via the PCI passthrough and then use that to drive a 
>> CD writer, but this would be rather heavyweight and imply trust of the 
>> guest OS.
>Hmm. All the drives are SATA, it''s only the CD/DVD drive that is
IDE.
>Adding in another ATA card is begging for pain, especially physically 
>routing the cables to the CD drive in the 1U servers I''m working
with.
>That seems unwise.
Agreed. It''s a theoretical option, but not something one would really
want
to do usually. The trouble is that it''s only really possible to pass 
through complete PCI devices to domains, which would mean an entire 
controller.
>> When USB virtualisation is working (it may already work in HVM) it 
>> should be possible to pass a USB burner through to the guest, and that 
>> would enable this kind of use.
>I''m already using an external USB storage device, via the 
>"file:/dev/sdc1,sdc1,w'' syntax, which seems workable for
external USB
>drives.
Yep, that''ll work but again breaks any special functionality. The
advantage
of the USB passthrough is that the guest can be given (almost) complete 
control of a USB device plugged into the host - and thus would be able to 
access all special features, including burning CDs, streaming video from 
webcams, etc.
>> Afraid so, sorry :-( For many uses (e.g. just grabbing some files from 
>> the disk), it should work OK. But you can''t just boot off a
CD-ROM in
>> a PV domain, nor can you place CD music, etc.
>Yeah. that needs to be made clear. The Xen configuration files simply 
>accept it and seem to ignore it. Putting in useful error messages would 
>help.
Yep. Well, exporting CD-ROMs to guests *is* a valid thing to do in the 
config files, so it''s not exactly an error... however it would probably
be
worth clarifying what it can and can''t do, e.g. in a comment in the
example
config.

It would also be nice if the guest kernel could maybe issue a more helpful 
error if unknown ioctls() were applied to the paravirt block device...
>>> Thanks. How are you downloading the unstable source?
>>
>> I get mine using mercurial:
>> hg clone http://xenbits.xensource.com/xen-unstable.hg
>Hmm. I''m not familiar with that source control system. (Ghods know
I''ve
>worked with CVS, Perforce, Subversion, and some unspeakable homebrews!) 
>Is there any reason to prefer it to the others, such as Subvresion which 
>also supports branching properly?
Main reasons: Speed, Simplicity (easy to modify and enhance), Distributed 
(so each developer copy of the source is represented by a first class 
private repository, and there is no central server required).

It also has a rather elegant design and a similar usage model to our 
previous tool of choice, BitKeeper.

hg supports lightweight branching as of 0.9.3, I think - before that, a 
"branch" was a separate repository...

It''s a system that''s gaining support now: Sun have picked it
up for some of
their OpenSolaris public repositories and are in the process of converting 
to it.

>> There will be tarballs of 3.0.4 linked off one of the Xen homepages, 
>> once they have been updated. Building your own Xen is reasonably 
>> straightforward once you know your way around the components, and 
>> there should be various HOWTOs hanging around.
>>
>> Hope that helps. If you still have problems with the CD-ROM we can try 
>> and find a workaround for you.
>It did help. I''d be happy to write up such notes and adventures for
the
>FAQ''s or installation notes, but I''m seeing significant
divergence
>between packages such as RedHat''s with the virtmanager tool on top
of
>it, and the bare Xen tools.
The wiki at http://wiki.xensource.com/xenwiki/ would be a good place to put 
such notes - if there''s not an existing section that fits, you could
always
create one.
> Weirdness such as the failure of the RHEL 
>4.x SRPM published by Xensource  to be able to build the documentation 
>put me off it for a while.
Mmmm. That''s quite unfortunate... Maybe this could be entered into the 
bugzilla? Would you mind doing that?
>Other oddness such as using non-getopt based 
>command line arguments have also slowed me down. Examples include 
>arguments using "create" instead of "--create", and
alternating the use
>of "DomU", and "guest", or of "migrate" and
"relocate" in both
>configuration files nad actual command line arguments, or the "xm 
>migrate" command having its flags at the end, just waste my time having
>to look up and remember all the different argument structures.
Yes, it would be nice for useability if we could standardise the 
terminology and, perhaps, the command structure somewhat.

Cheers,
Mark

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users