Re: recommendations for handling Hyper-V version number
On Thu, Sep 24, 2020 at 06:43:56PM -0400, Matt Coleman wrote:
>> For example, the Windows Server 2016 Hyper-V version is
10.0.14393.0,
>> so its “micro” is over 14 times larger than the encoding allows.
>>
>> My current workaround is to truncate it to something that works (E.G.
>> 10.0.143), but that's clearly less than ideal.
> The problem here is the virConnectGetVersion public API - we cannot
> alter its signature.
I hadn’t realized this was exposed by the public API.
Since the API can’t change, should I update my code to only output
major.minor instead of truncating micro to an incorrect/misleading
value?
The downside of this is that Microsoft has referred to Windows 10 as
“the last version of Windows” and Hyper-V versions are the same as the
OS’s kernel version. So, this would result in libvirt’s Hyper-V driver
reporting version 10.0 until Microsoft reconsiders that approach.
Our current encoding scheme allows 1000 for each part of the
version number. Realistically the major and minor version numbers
are unlikely to exceed 99 respectively.
IOW we could stuff both the hyper-v major + minor version digits
into the libvirt major digits. Then we can split the hyperv micro
digits across the libvirt minor + micro.
ie pack it using
version = (major * 100,000,000) + (minor * 1,000,000) + micro
If any libvrt apps are trying to reverse parse this and turn it
back into dotted values, it is going to look wierd, but at least
we won't be discarding information.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|