Re: Disk naming (Was Re: [Xen-devel] [PATCH] Guest boot loadersupport [1/2])

[Gerd Knorr <kraxel@xxxxxxxxxxx>]

"Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> writes:

> I don't think there's a huge problem with exposing vbd's as sdX/hdX
> within a guest. We used to have our own xdX device, but it just broke
> too much stuff, hence we hijacked had/sda.

Huh?  Really?  What exactly broke?

I can share a bit of experience with user mode linux again: UML uses
it's own major range for virtual block devices.  Making the suse
installer work within a UML machine was surprisingly easy.  The major
stumbling block was that parted had a hard-coded white-list for block
device major numbers, which didn't include #98 (the uml virtual block
device major), thus the installer didn't recognised the virtual disk
or refused to partition it (don't remember exactly).  The other issue
was that the device files in /dev didn't exist (should be easier these
days with udev ;).

Once these two points where fixed it worked just fine.  Well, there
still were some minor issues, like the installer being a bit confused
and printing a warning due to the fact that it hasn't found any PCI
IDE or SCSI storage controller.

The important bit is that you'll have to take care to use the usual
linux interfaces, naming schemes and so on.  If the virtual disks and
partitions show up in /proc/partitions and /sys/block correctly most
software will be happy.

I think we should have our own xd virtual block devices for xen and
use them by default.  It's cleaner, and probably also has less
problems when using virtual disks and iSCSI at the same time ;)

Using hd/sd instead probably is a useful option in some cases, I
wouldn't drop that altogether, but only use that if the user
explicitly asks for it.

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

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