recommendations for handling Hyper-V version number
Daniel P. Berrangé
berrange at redhat.com
Mon Sep 28 08:40:38 UTC 2020
On Sat, Sep 26, 2020 at 06:03:41PM -0400, Matt Coleman wrote:
> > 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?
I don't think we need to do that - it'll make the Win Server 2016 case
look wierd instead.
|: 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 :|
More information about the libvir-list