WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Question on "xen-blkfront: handle Xen major numbers

On Thu, 2011-07-14 at 14:26 +0100, Stefan Bader wrote:
> On 13.07.2011 19:25, John Haxby wrote:
> > On 13/07/11 17:19, Stefan Bader wrote:
> >>
> >> So for HVM they would be called hda in the cfg but sda in the domU.
> > 
> > Something like this caused a lot of confusion for folks around here:
> > they were expecting the _name_ used in the cfg to be the name in the
> > guest, ignoring the fact that neither hdX, xvdX nor sdX ever appear in a
> > Windows HVM.  Or indeed that, IDE, SCSI and SATA disks are all called
> > sdX nowadays.
> > 
> > As Stefan said, the name actually only tells you what sort of emulated
> > controller the disk is attached to: hd for IDE, sd for SCSI and xvd for
> > PV disks (no actual controller as such).    It might have been better to
> > have things like IDE(0,0), SCSI(0,3) and XVD(0) and let the guest OS
> > decide how to map those to names, much like it does for real hardware.
> > 
> 
> That seems to be the sad root of the story. If it wasn't for the fact that 
> some
> naming convention (related to some real kernel names) gets translated into
> (emulated) physical connections and the fact that the xvd driver did lie to 
> the
> domU (by using a IDE or SCSI major and name), there would be no need to meddle
> around it. The faking major,minor,name thing probably was required in the
> beginning when there was no other thing than hd* and sd*...
> 
> I will post a few patches as replies to this email, one to turn off the offset
> and two other things I believe are wrong. But please, better check whether I 
> am
> really right there.
> 
> For future resolve of this issue, my feeling would be that a naming scheme of
> xvsd*, for emulated scsi and xvhd* for emulated ide and xvd* for devices 
> likely
> would mean some confusion. Still it sounds like, after a bit of education, the
> concept of how names get translated between the cfg and the guest should be
> simpler to grasp.

Have you seen docs/misc/vbd-interface.txt? It clarifies (or at least
tries to) some of this stuff. If there are things which could be
improved (esp. from the end-user perspective) there then patches would
be gratefully accepted.

> In theory the minor numbers could be even dynamically allocated, but I guess
> minors of partitions should always be an offset of the base device and minors 
> of
> devices in the same namespace should also be in a way sorted. So maybe a range
> of minor numbers reserved for the ide emulated, one for the scsi emulated and
> the rest for devices defined as virtual ones sounds like a simple approach.
> Anyway, that is just my loud thinking. And maybe not completely thought 
> through.
> 
> One other way would be to stop allowing ide or scsi disk names for defining
> disks of the virtual controller... Though that might be a bit radical after
> allowing it for so long.

Personally I think it would be great but I don't think its feasible.
I've been trying to encourage the use of xvd* for years :-/.

Ian.

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



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

<Prev in Thread] Current Thread [Next in Thread>