[libvirt] VMX parser: limitation of numvcpus

[Matthias Bolte]

2018-05-30 11:05 GMT+02:00 Pino Toscano <ptoscano at redhat.com>:
> Hi Matthias,
>
> while testing the recent improvements I did in the VMX parser for CPU
> topology (see https://bugzilla.redhat.com/1568148), our QE Ming Xie set
> a guest in ESXi 5.5 to 7 cores. The result was the error triggered by
> the following code:
>
>     /* vmx:numvcpus -> def:vcpus */
>     if (virVMXGetConfigLong(conf, "numvcpus", &numvcpus, 1, true) < 0)
>         goto cleanup;
>
>     if (numvcpus <= 0 || (numvcpus % 2 != 0 && numvcpus != 1)) {
>         virReportError(VIR_ERR_INTERNAL_ERROR,
>                        _("Expecting VMX entry 'numvcpus' to be an unsigned "
>                          "integer (1 or a multiple of 2) but found %lld"), numvcpus);
>         goto cleanup;
>     }
>
> Looking into the history, this check dates back to the initial addition
> of the esx driver, commit e2aeee6811917bc5ad28326c6a860ded39802a88.
> Considering the VMX format is proprietary of VMware, and officially
> undocumented, do you know remember why that limitation was added?
> Do you think removing it might break anything?

Hi,

I cannot exactly remember why that specific limitation is there, I
wrote that code a long time ago.

The VMX parser/formatter code is based on this unofficial
documentation (that is by no means complete):

http://sanbarrow.com/vmx.html

and on testing with an actual ESX setup, by changing VM parameters in
the vSphere Client GUI and observing how that maps to the VMX file.

My best guess is that the vSphere Client at the time would only allow
you to set numvcpus to 1 or an even number, and I just replicated that
behavior.

If you remove that check now nothing bad can happen. In the worst case
the ESX server would probably just refuse to start a VM with an
invalid/unsupported configuration in the VMX file. The checks in the
libvirt code are there for better feedback about possible
misconfigurations. The ESX server most of the time produced a generic
error that didn't indicate very well what the actual problem was.

It seems that you have an ESX server at hand. So you could just test
if the vSphere Client allows you to set the numvcpus to an odd value.
It seems that you already did that, that's how you got in this
situation.

If the vSphere Client allows you to set the numvcpus value to an odd
number nowadays, then I think its okay to relax this check in libvirt
as well.

Regards,
Matthias Bolte