according to https://libvirt.org/formatdomain.html#elementsCPU
setting the model is not supported when using "host-model" and
with recent libvirt this actually results in errors like this:
Call to virDomainCreateWithFlags failed:
the CPU is incompatible with host CPU:
Host CPU does not provide required features: svm
Call `dup` on default prefix before amending it via `concat` and
`<<`. Previously when default_prefix was used, it was amended in place,
so it was changing with every VM definition and kept getting longer,
leading to wrong domain names.
set :trust_guest_rx_filters => true in the network definition to enable
trustGuestRxFilters for the public interface.
Details from http://www.libvirt.org/formatdomain.html#elementsNICSDirect:
"If the model type is set to virtio and interface's trustGuestRxFilters
attribute is set to yes, changes made to the interface mac address,
unicast/multicast receive filters, and vlan settings in the guest will
be monitored and propagated to the associated macvtap device on the host
(Since 1.2.10). If trustGuestRxFilters is not set, or is not supported
for the device model in use, an attempted change to the mac address
originating from the guest side will result in a non-working network
connection."
closes#650
To simulate shared SAN storage an additional libvirt
disk property needs to be set which disables caching.
Also updated the documentation to document this new
property and added an example on how to simulate
shared SAN storage
Closes#648
libvirt has supported specification of a guest NUMA topology since
0.9.8. This functionality can be used for basic validation of some
NUMA-dependent features during development. Add basic configuration
support, by allowing the user to specify how many NUMA nodes the
instance may have.
The following options are added:
* numa_nodes - Defaults to none
For additional information on specifying NUMA nodes with Libvirt, see:
* https://libvirt.org/formatdomain.html#elementsCPU
* Wrap to 80 characters
* Use 'Vagrant', not 'vagrant', where appropriate
* Format code as such
* Mark up code type where possible (shell, ruby, etc.)
* Don't use code fences inline
* Misc other changes
