If you are running a platform with nodes with different types of CPU, you may find that live migration between nodes fails under Xen. This is because moving a guest workload from a processor that supports one CPU feature to one that doesn't would result in the guest crashing (as the guest will assume the CPU remains the same throughout its operation), and Xen will thus prevent the migration.
This is normally not a problem on hypervisors other than Xen, as such hypervisors tend to emulate a fixed type of CPU.
To work around this problem, you can use CPU levelling, which can be used to mask off CPU features that one type of processor might support, but another might not.
You can specify a
xen_cpu_id setting using the format set out in the
xl.cfg manpage, which is a string beginning with the word '
host' and followed by comma separated CPU flags.
To remove a CPU flag:
Determine the name of the flag you want to remove, by logging onto the node and typing:
and looking at the line starting with the text 'Flags'.
For instance, you might see the following output:
If you wanted to remove the
sse4afeature, you would use the flag name
All the flags are documented here.
- Log in to the console of the cluster control server.
Using the editor of your choice, edit the
/etc/extility/nodeconfig/nodetemplate.xmlfile and add the following text:
replacing the text
example_masked_flag(etc) with the name of the flag to disable.
Perform a software update on each of the nodes. For information on how to do this, see Managing Nodes.
- Create a virtual machine, start it, and log in to its console.
Check that the required CPU flags are disabled using the following command:
Any CPU flags that you have disabled should not appear in the returned results.