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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home