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

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



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


 


Rackspace

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