[libvirt] CPU type/flags when converting a physical machine to run on libvirt

[Eduardo Habkost]

CCing Cole, as he had to deal with libvirt and "host-cpu" before, and
may have some comments about the bugs he has found.

On Fri, May 02, 2014 at 01:07:05PM +0100, Richard W.M. Jones wrote:
> I'm in the process of rewriting virt-p2v which is our program for
> converting physical machines to become virtual machines, running on
> top of libvirt + KVM.
> 
> The physical machine has certain characteristics -- eg:
> 
>  - number of physical cores
>  - amount of RAM
>  - CPU type (eg. AMD Opteron, Intel Core i7)
>  - CPU flags (eg. ACPI, SSE4)
> 
> which it might make sense to reflect in the libvirt XML of the virtual
> machine we create.
> 
> The old version of virt-p2v is pretty simplistic about this.  It
> generates *only* an i386 or x86-64 VM, and the only flags it considers
> are 'apic', 'acpi', 'pae' and 'lm' [the latter to distinguish between
> 32 and 64 bit x86].
> 
> What should the new version do?
> 
> Particular questions:
> 
>  - Should we try to reflect the CPU type of the physical machine in
>    the virtual machine?  eg. If it's an Opteron, we generate an
>    Opteron target machine.  (I believe the answer is *no*, because
>    this is not live migration, and most guests can boot on any
>    compatible CPU).

I see no reason to _not_ choose Opteron_Gx, if you know the host CPU is
always going to be an Opteron_Gx.

If the user simply plans to convert an existing physical machine to a
single-VM machine and has no plans to ever migrate the VM, it makes
sense to use "-cpu host" (but beware: this may uncover a few QEMU bugs).

if the user plans to migrate the VM to a _similar_ host later, it makes
sense to use an existing CPU model name that matches the host CPU (see
"host-cpu-model" below).

If the user plans to migrate the VM to a very different host later it
makes sense to be more conservative and simply use the default CPU
model.

In other words: I don't know what's a good default because I don't know
your use case very well.


> 
>  - How can I ask libvirt to give me the best possible CPU, and not
>    some baseline?  Normally I use host-model, but I think that
>    prevents migration.

The best possible CPU is "-cpu host" (host-passthrough in libvirt), but
that doesn't allow migration. This may uncover QEMU bugs (but it is much
better today than it was 1 or 2 years ago).

The best possible CPU which allows migration is the one you get when
explicitly asking libvirt to expand host-model (including baseline +
flags). This is likely to uncover QEMU and libvirt bugs.

A safer option is to use only the base CPU model (not the additional
flags) provided by libvirt when asking about the host CPU model (I
believe this is called "host-cpu-model" on virt-manager code).


> 
>  - What CPU flags should be reflected in the target libvirt XML?
> 
>  - Is it worth modelling CPU thread layout?  (I suspect this will be a
>    lot of work with the potential to break things rather than provide
>    any measurable benefits.)

I wouldn't recommend this unless: 1) you know the VM will be kept
running in the same host or on a similar host; 2) you pin the
VCPUs/threads to corresponding host CPUs/threads.

This may also uncover QEMU bugs, so I wouldn't do this by default unless
the user explicitly asks for it.

> 
>  - Is there anything else I haven't thought about?

In the future you may want to support multi-node NUMA VMs. This is
similar to the multi-core/multi-thread case: it makes sense if you know
the VM is going to run on a host with similar topology, and if you
manually pin the guest nodes to the host nodes (something which is not
possible yet, but should be possible in the near future).

> 
> However the overriding rule is:
> 
>  - We *must not* end up with a target virtual machine which doesn't work!
> 
> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v

-- 
Eduardo