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@xxxxxxxxxx <mailto: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? 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 :|
