On 14.07.2011 16:14, Ian Campbell wrote:
> 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.
>
No, I must admit I had not (as my approach is is more from the kernel side). But
thanks for pointing towards that. I will have a read there.
>> 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 :-/.
>
Unfortunately its always hard to convince people if something seems to work. And
it can be hard to argue people are wrong when they complain about the latest
change of preserving xvda-d for hd* mapping in 3.0. :(
-Stefan
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home