Xen devel - Dec 2004 - About block device mapping for guests

I am a bit puzzled on how the block device mapping works for Xen
guests. Or particularily the fact on how the device shows on the guest
side. When configuring the domain, one can specify the device name the
partition should appear with inside the guest. And if that device does
not exist on the host side, xend complains. A workaround for this was
to specify the device with explicit minor and major number, instead of
a name.

So, from this I would conclude that you can specify the major and
minor device number, which will map to the device you specify.

Now, can these numbers be picked arbitrarily? I know I can mimic an
entire disk (hda) or just a partition (hda1), for either IDE or SCSI -
but is there any difference on the Xen side? Does Xen behave
differently depending on the minor and major that I specify?

Then, are the exported devices just plain block devices with nothing
special to configure? I guess I can use the ''blockdev'' command
to
change the blocksize and readahead size for the device? But do any
special ioctl''s or something like that pass through? If I export an
entire hard disk, can the parameters for it tuned from inside the
guest? What about CD/DVD/etc. drives? Do media insert notifications go
through? Could I use a CD-burner from a guest?

And yet more, how do these devices play along with devfs? Does the Xen
blockdev frontend driver automatically create some nodes for devfs? 
Can it somehow make /dev/hda or /dev/sda appear on the guest side with
devfs? How about udev? Does udev get boottime events to initialize the
device nodes for the block devices? And what about sysfs? Is there a
sysfs interface to see what has been mapped where and with what major
and minor numbers?

I''ve used to using UML, where devices ubd0 and onwards are UML block
devices - they have their own major device number. They show up in
devfs as /dev/ubd/disc0/disc, /dev/ubd/disc1/disc and so on. I think
there was supposed to be a sysfs interface as well, but I''m not sure
about that.

So, how is this all handled in Xen?

-- Naked




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

OK, here goes:
> So, from this I would conclude that you can specify the major and
> minor device number, which will map to the device you specify.
Yup.
> Now, can these numbers be picked arbitrarily? I know I can mimic an
> entire disk (hda) or just a partition (hda1), for either IDE or SCSI -
> but is there any difference on the Xen side? Does Xen behave
> differently depending on the minor and major that I specify?
Yes you can choose an arbitrary IDE or SCSI drive''s major / minor pair
and
export as that.  There''s no difference to the backend driver, the
frontend in
the guest uses different blocksize for fake IDE vs fake SCSI, I think.
> Then, are the exported devices just plain block devices with nothing
> special to configure?
Yes
> But do any
> special ioctl''s or something like that pass through?
Nope.  Ioctls are handled in the guest.
> If I export an 
> entire hard disk, can the parameters for it tuned from inside the
> guest?
The guest can tune its own parameters for the virtual drive but the parameters 
for the real disk are unaffected.
> What about CD/DVD/etc. drives? Do media insert notifications go 
> through? Could I use a CD-burner from a guest?
You can e.g. export ISOs or whole disks to the guest but things like media 
insert notifications and the various controls required for CD burners are not 
part of the virtual disk interface and so won''t work at the moment.

It''s technically possible to make the frontend behave more like a CD
drive,
it''s just that there''s not a lot of demand for this, so
it''s not implemented.
> And yet more, how do these devices play along with devfs? Does the Xen 
> blockdev frontend driver automatically create some nodes for devfs?
Guest domains can''t use devfs because the frontend driver
doesn''t support it.
The developers feeling is that since devfs is deprecated, it''s probably
not
worth the pain of adding support for.
> How about udev? Does udev get boottime events to initialize the
> device nodes for the block devices? And what about sysfs?
Yes, all Xen virtual devices should appear in SysFS in the guest, which udev 
will use to do the right thing - this should all work fine.
> Is there a 
> sysfs interface to see what has been mapped where and with what major
> and minor numbers?
In the guest, sysfs will show block devices with whatever major / minor was 
specified.  It won''t tell you what the drive is mapped to in dom0.

State regarding which block devices in dom0 are mapped to what in the guests 
is maintained inside Xend.
> So, how is this all handled in Xen?
HTH,
Mark
>
> -- Naked
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Mark Williamson wrote:
> Yes you can choose an arbitrary IDE or SCSI drive''s major / minor
> pair and export as that.  There''s no difference to the backend
> driver, the frontend in the guest uses different blocksize for fake
> IDE vs fake SCSI, I think.
Right. Uh. I''ll take a peek at the code to get the exact answer.
> It''s technically possible to make the frontend behave more like a
CD
> drive, it''s just that there''s not a lot of demand for
this, so it''s
> not implemented.
Right, understood. Seems like this need would be better served by
being able to give entire IDE/SCSI devices to some guests, so they can
run all the IDE/SCSI commands they will ever need.
> Guest domains can''t use devfs because the frontend driver
doesn''t
> support it.  The developers feeling is that since devfs is
> deprecated, it''s probably not worth the pain of adding support
for.
I assume this specifically means that guest domains will not have the
block devices created by devfs at all - but if one were to manually
create the block devices with the correct major and minor, it would
work.

I can understand that it might not be worth the effort - but larger
warnings somewhere that ''devfs will not work, plain dev or udev will
work'' might be in order.
> Yes, all Xen virtual devices should appear in SysFS in the guest,
> which udev will use to do the right thing - this should all work
> fine.
Hmm. How will the devices be named under sysfs? If I just specify a
major and minor device number, where does Xen dig up the name it
should be registered under? And how does udev pick the right name for
the actual device file?
> In the guest, sysfs will show block devices with whatever major /
> minor was specified.  It won''t tell you what the drive is mapped
to
> in dom0.
>
> State regarding which block devices in dom0 are mapped to what in
> the guests is maintained inside Xend.
Right.
> HTH,
Immensely. Now I know why none of my domains ever manage to find a
root device ;-)

-- Naked


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> > It''s technically possible to make the frontend behave more
like a CD
> > drive, it''s just that there''s not a lot of demand
for this, so it''s
> > not implemented.
> 
> Right, understood. Seems like this need would be better served by
> being able to give entire IDE/SCSI devices to some guests, so they can
> run all the IDE/SCSI commands they will ever need.
I guess you could do that but we''d need back / frontend drives that
carried
IDE / SCSI commands between guests and domain 0.

If you really want to give a whole device to a guest or make a CD writer 
work you could: * give the domain a whole PCI SCSI / IDE / USB controller 
and plug the device into that * export a USB drive to the domain with USB 
virtualisation
> I assume this specifically means that guest domains will not have the
> block devices created by devfs at all - but if one were to manually
> create the block devices with the correct major and minor, it would
> work.
Yes, that should work.
> Hmm. How will the devices be named under sysfs? If I just specify a
> major and minor device number, where does Xen dig up the name it
> should be registered under? And how does udev pick the right name for
> the actual device file?
First off, Xen doesn''t know / care about the devices at all -
it''s the
drivers in XenLinux that take care of that.

The guest operating system (e.g. XenLinux) will bind the major / minor to a 
name according to it''s own policy. e.g. under Linux 0x801 is
conventionally
/dev/sda1 so unless you have a weird setup, that''s what it''ll
appear as. I
guess the files appear under SysFS similarly to how devices with the same 
major / minor would under vanilla Linux.

Udev knows the right name for the device file according to its own policy 
setup.
> Immensely. Now I know why none of my domains ever manage to find a
> root device ;-)
Ahh good ;-)

Cheers,
Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

M. A. Williamson wrote:
> The guest operating system (e.g. XenLinux) will bind the major /
> minor to a name according to it''s own policy. e.g. under Linux
0x801
> is conventionally /dev/sda1 so unless you have a weird setup,
that''s
> what it''ll appear as. I guess the files appear under SysFS
similarly
> to how devices with the same major / minor would under vanilla
> Linux.
Well, I dug into this more deeply, since the argument seemed a bit
odd. To be able to convert 0x801 to a name, there has to be a mapping
table for it somewhere inside the kernel - and in vanilla linux, there
is none, since it is the driver that assigns both the sysfs name and
the major device number.

So I looked into the code and found this:

,----[ drivers/xen/blkfront/vbd.c ]
| static struct xlbd_type_info xlbd_ide_type = {
|        .partn_shift = 6,
|        .partn_per_major = 2,
|        // XXXcl todo blksize_size[major]  = 1024;
|        .hardsect_size = 512,
|        .max_sectors = 128,  /* ''hwif->rqsize'' if we knew
it */
|        // XXXcl todo read_ahead[major]    = 8; /* from drivers/ide/ide-probe.c
*/
|        .name = "hd",
| };
| 
| static struct xlbd_type_info xlbd_scsi_type = {
|        .partn_shift = 4,
|        .partn_per_major = 16,
|        // XXXcl todo blksize_size[major]  = 1024; /* XXX 512; */
|        .hardsect_size = 512,
|        .max_sectors = 128*8, /* XXX 128; */
|        // XXXcl todo read_ahead[major]    = 0; /* XXX 8; -- guessing */
|        .name = "sd",
| };
| 
| static struct xlbd_type_info xlbd_vbd_type = {
|        .partn_shift = 4,
|        .partn_per_major = 16,
|        // XXXcl todo blksize_size[major]  = 512;
|        .hardsect_size = 512,
|        .max_sectors = 128,
|        // XXXcl todo read_ahead[major]    = 8;
|        .name = "xvd",
| };
`----

And that answers all my remaining questions :-)

Thanks,
-- Naked



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel