Re: recommendations for handling Hyper-V version number

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

 



On Sep 25, 2020, at 4:42 AM, Daniel P. Berrangé <berrange@xxxxxxxxxx> 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?

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux