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

Re: recommendations for handling Hyper-V version number



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 redhat com <mailto:berrange 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.

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 :|


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