recommendations for handling Hyper-V version number

[Matt Coleman]

> On Sep 25, 2020, at 4:42 AM, Daniel P. Berrangé <berrange at redhat.com <mailto:berrange at redhat.com>> wrote:
> 
> 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.

I wrote this up and examined the `virsh version` output for several 
Windows/Hyper-V versions.

For Windows Server 2016 that I previously mentioned, its version number 
is 10.0.14393. `virsh version` displays it as 1000.14.393.

The first version of Windows that supported Hyper-V is Windows Server 
2008. Its version number is 6.0.6001, which `virsh version` displays as 
600.6.1. Would you prefer it to visually preserve more of the “6001”, and 
produce 600.600.1 as the result?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200926/adabe78b/attachment-0001.htm>