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