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