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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list