recommendations for handling Hyper-V version number

Ján Tomko jtomko at
Thu Sep 24 08:02:08 UTC 2020

On a Wednesday in 2020, Matt Coleman wrote:
>Hello again,
>Hyper-V version numbers are not compatible with the encoding used in
>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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <>

More information about the libvir-list mailing list