[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MirageOS-devel] xen and multiple block devices



Hi,

I've just changed the way the xen blkfront "connect" function maps BLOCK.ids to xen virtual devices. It uses the following heuristics, first match wins:

1. the id is a "xen virtual disk number" (e.g. "51712"). Each disk has a unique slot number on the "virtual bus" (like what you get with IDE, SCSI). This is the pure but somewhat low-level interface.

2. the id is a "Linux device string (with or without "/dev/" prefix)" (e.g. "xvda"). This is what you normally write in your xl/xm config files. This works because the slot numbers on the xen "virtual bus" were originally derived from Linux device major/minor numbers. This notation has survived as the slightly more human-readable low-level interface.

3. the id uniquely matches the "params" key in a xenstore disk *backend*. This is a bit of a hack, but a potentially convenient one in future. If you BLOCK.connect to "/dev/loop0" then it should find the virtual device backed by "/dev/loop0" (wherever it happens to be on the "virtual bus"). This is likely to work well in simple setups, but advanced users with driver domains won't find it sufficiently reliable.

So in mirage-skeleton/basic_block/config.ml you can change the line to:

  let block = block_of_file "/dev/loop0" in

and then your VM console will have lines like:

Block.connect /dev/loop0: interpreting /dev/loop0 as a backend params key, translating to 51712
Block.connect /dev/loop0 -> 51712
Blkfront.create; vdev=51712

HTH all the multi-disk users out there!

Cheers,
--
Dave Scott
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.