On Fri, Mar 01, 2013 at 02:28:37PM +0100, Jiri Denemark wrote:
On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
= Querying host capabilities =
Requirement: libvirt needs to know which feature can really be enabled, before it tries to start a VM, and before it tries to start a live-migration process.
The set of available capabilities depend on:
• Host CPU (hardware) capabilities; • Kernel capabilities (reported by GET_SUPPORTED_CPUID); • QEMU capabilities; • Specific configuration options (e.g. in-kernel IRQ chip is required for some features).
Actually, one more thing. Can any of these requirements change while a host is up and QEMU is not upgraded? I believe, host CPU capabilities can only change when the host starts. Kernel capabilities are a bit less clear since I guess they could possibly change when kvm module is unloaded and loaded back with a different options. QEMU capabilities should only change when different version is installed. And the specific configuration options are the most unclear to me. The reason I'm asking is whether libvirt could run-time cache CPU definitions (including all model details) in the same way we currently cache QEMU capabilities, such as availability of specific QMP commands.
That's a good question. Let's check each item so I don't forget any detail:
• Host CPU (hardware) capabilities;
This shouldn't change without a host reboot.
• Kernel capabilities (reported by GET_SUPPORTED_CPUID);
This may possibly change if the KVM module is unloaded and reloaded with different options, but... I guess we should simply require libvirtd to be restarted if any user does that?
• QEMU capabilities;
This shouldn't change as long as the QEMU binary doesn't change.
• Specific configuration options (e.g. in-kernel IRQ chip is required for some features).
This part seems tricky. Currently kernel-irqchip is probably the only option that affects which features are available, but what if other QEMU options affect the set of features too? I believe the answer is to rely on machine-types. I mean: if a new option that affects "-cpu host" and the set of available CPU features is created, there are two options: 1) Using the default value; 2) Setting the option explicitly. 1) If using the default value, the default will depend on machine-type, so libvirt should already consider machine-type as an option that affects available-CPU-features. 2) If using an explicit value, libvirt should use the explicit value only after being changed to take into account the fact that the option affects available-CPU-features. So, let's add one more item to the list. The set of available capabilities depend on: • Host CPU (hardware) capabilities; • Kernel capabilities (reported by GET_SUPPORTED_CPUID); • QEMU capabilities; • Specific configuration options: • kernel-irqchip (currently affects tsc-deadline and x2apic, but may affect other features in the future) • machine-type (may affect any feature in the future) -- Eduardo