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
Description: PGP signature