[libvirt] [PATCH 03/12] vcpu: add new public API

[Matthias Bolte]

2010/9/30 Eric Blake <eblake at redhat.com>:
> API agreed on in
> https://www.redhat.com/archives/libvir-list/2010-September/msg00456.html
>
> * include/libvirt/libvirt.h.in (virDomainVcpuFlags)
> (virDomainSetVcpusFlags, virDomainGetVcpusFlags): New
> declarations.
> * src/libvirt_public.syms: Export new symbols.
> ---
>
> However, in implementing things, I'm wondering if I should use the names:
>
> VIR_DOMAIN_VCPU_CONFIG (instead of VIR_DOMAIN_VCPU_PERSISTENT)
> VIR_DOMAIN_VCPU_LIVE (instead of VIR_DOMAIN_VCPU_ACTIVE)
>
> to match virDomainDeviceModifyFlags, where _CONFIG and _LIVE have
> the same semantics of setting one or both aspects of a domain.
>

If you want to match the semantics of _CONFIG and _LIVE from
virDomainDeviceModifyFlags then you need to change the ESX driver
differently in patch 7/12.

If I understand the semantics of virDomainDeviceModifyFlags correctly,
then _LIVE is only affecting the runtime state of the domain and
changes done with the _LIVE flag only are lost on domain restart. In
the same way _CONFIG only affects the persistent config and not the
runtime state.

With ESX there is no such thing as a distinct runtime state. Changes
to the number of vCPUs affect the runtime state and the persistent
config at the same time.

Currently you altered the ESX driver in patch 7/12 to

  esxDomainSetVcpus = esxDomainSetVcpusFlags(VIR_DOMAIN_VCPU_ACTIVE)

But this should actually use _LIVE | _CONFIG as flags to match what
ESX can do only.

Also in 5/12 you state that trying to change the vCPU count of an
inactive domain using the _LIVE flag should fail. The implementation
in the ESX driver in 7/12 doesn't match this either.

esxDomainSetVcpus needs to call esxDomainSetVcpusFlags with _CONFIG
and add _LIVE to the set of flags when the domain is active. Likewise
esxDomainSetVcpusFlags needs to enforce that _CONFIG is always set and
that _LIVE is set iff the domain is active.

The same might apply to other drivers, I didn't check this yet.

Matthias