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

Re: [Xen-devel] [PATCH v2 1/3] Add vmware_hw to xl.cfg

On 09/10/14 05:30, Ian Campbell wrote:
> On Tue, 2014-09-09 at 13:02 -0400, Don Slutz wrote:
>> On 09/09/14 05:39, Ian Campbell wrote:
>>> Just updating the description to give users some clue as to what number
>>> they should use would be enough.
>> How does the following look:
>>     vmware_hw numbers come from VMware config files.
>>     In a .vmx it is virtualHW.version
>>     In a .ovf it is part of the value of vssd:VirtualSystemType
>>     for vssd:VirtualSystemType == vmx-07, vmware_hw = 7
>> Should I refer them to the vmware web site?
> Probably. Will the above make sense to a normal vmware user? Since it is
> essentially Greek to me. The includes how to dig into a .vmx or .ovf to
> find these values. e..g are they plain text files? Are specific tools
> needed?

Yes, I would expect a normal vmware user to understand this.

Both files are "text".  .vmx is a list of "key = value" lines.
.ovf is a xml file.  Any text editor is enough (or more or less).

    -Don Slutz

>>>>> Other than parroting this value back to the guest in a cpuid leaf does
>>>>> this value control anything else? If so then we may want to consider
>>>>> something like an enum to allow us to advertise more precisely which
>>>>> versions of vmware we are prepared to ape, but at the least we need to
>>>>> range check this input somewhere along the way.
>>>> See above, mostly just QEMU.
>>> What does qemu do with a number which it doesn't understand, perhaps
>>> corresponding to a newer vmware version which it hasn't learnt about
>>> yet?
>> My version currently checks for various ranges.  Like != 0, >= 4,
>>   >= 4 && < 7, >= 7.  I do not expect that I can upstream it with this,
>> but it should be similar.
>>> This sort of issue is why I was proposing an enum, or at least some sort
>>> of range checking.
>> Since most of the use is in QEMU, I see no need for an enum in xen.
>> All xen uses I know of are == 0 or != 0.  I can add some range checking
>> but think a warning might be better so that a newer QEMU with support
>> for a given value could be used with an older xen without change to
>> xen.
> Will qemu error out in an obvious way if an unsupported number is used?

My version does not.  However, that is the kind of change I expect to make
when I get there.   Since this is not yet done, not sure it matters.

Today the valid values are 0,3-4,6-11.  When I first coded this it was
0,3-4,6-7.   At that time all my testing showed only 0, 4 and 7 as the key
points. 6 was the same as 4.  VMware does have differences
between 6 and 4 but they were all around things like 4 does not support
device pvscsi, 6 and 7 do.   Trying and embedding this knowledge in Xen
to me is not the right way to go.  I would expect some one using this to
know the "right" value,

Xen-devel mailing list



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