recommendations for handling Hyper-V version number
Hello again, Hyper-V version numbers are not compatible with the encoding used in virParseVersionString: https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L246 For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, so its “micro” is over 14 times larger than the encoding allows. My current workaround is to truncate it to something that works (E.G. 10.0.143), but that's clearly less than ideal. Is the output of virParseVersionString stored on disk at any point? Would changing its output type from unsigned long to unsigned long long cause any compatibility issues? That would allow “minor” and “micro” to be up to 6 digits each and would be a quick, easy change. Thanks, Matt
On Wed, Sep 23, 2020 at 8:36 PM Matt Coleman <mcoleman@datto.com> wrote: By the way, due to your domain's DMARC policy, gmail puts your emails into spam. Therefore it's possible quite a lot of list subscribers aren't seeing them. ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of libvir-list-bounces@redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=datto.com -- Chris Murphy
On a Wednesday in 2020, Matt Coleman wrote:
Hello again,
Hyper-V version numbers are not compatible with the encoding used in virParseVersionString: https://gitlab.com/libvirt/libvirt/-/blob/master/src/util/virutil.c#L246
For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, so its “micro” is over 14 times larger than the encoding allows.
My current workaround is to truncate it to something that works (E.G. 10.0.143), but that's clearly less than ideal.
Is the output of virParseVersionString stored on disk at any point? Would changing its output type from unsigned long to unsigned long long cause any compatibility issues? That would allow “minor” and “micro” to be up to 6 digits each and would be a quick, easy change.
virParseVersionString is just an internal helper, those can be changed at will if you don't break existing users. The problem here is the virConnectGetVersion public API - we cannot alter its signature. One solution would be to introduce a new API (that possibly returns a string), but it will take time until apps start using it. Jano
Thanks, Matt
For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, so its “micro” is over 14 times larger than the encoding allows.
My current workaround is to truncate it to something that works (E.G. 10.0.143), but that's clearly less than ideal. The problem here is the virConnectGetVersion public API - we cannot alter its signature. I hadn’t realized this was exposed by the public API.
One solution would be to introduce a new API (that possibly returns a string), but it will take time until apps start using it. That would be necessary to be able to convey the full Hyper-V version, but I’m not sure if that’s needed anywhere at the moment. Also, I’d
Since the API can’t change, should I update my code to only output major.minor instead of truncating micro to an incorrect/misleading value? The downside of this is that Microsoft has referred to Windows 10 as “the last version of Windows” and Hyper-V versions are the same as the OS’s kernel version. So, this would result in libvirt’s Hyper-V driver reporting version 10.0 until Microsoft reconsiders that approach. like to flesh out Hyper-V support within the current API before adding new functionality. Matt
On Thu, Sep 24, 2020 at 06:43:56PM -0400, Matt Coleman wrote:
For example, the Windows Server 2016 Hyper-V version is 10.0.14393.0, so its “micro” is over 14 times larger than the encoding allows.
My current workaround is to truncate it to something that works (E.G. 10.0.143), but that's clearly less than ideal. The problem here is the virConnectGetVersion public API - we cannot alter its signature. I hadn’t realized this was exposed by the public API.
Since the API can’t change, should I update my code to only output major.minor instead of truncating micro to an incorrect/misleading value?
The downside of this is that Microsoft has referred to Windows 10 as “the last version of Windows” and Hyper-V versions are the same as the OS’s kernel version. So, this would result in libvirt’s Hyper-V driver reporting version 10.0 until Microsoft reconsiders that approach.
Our current encoding scheme allows 1000 for each part of the version number. Realistically the major and minor version numbers are unlikely to exceed 99 respectively. 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. 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 :|
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?
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 :|
participants (4)
-
Chris Murphy -
Daniel P. Berrangé -
Ján Tomko -
Matt Coleman