This allows for specific CPU selection and enforcement when cpu_mode =
custom, which is important when emulating CPUs of different architecture
than the host.
i tried to install on a fresh ubuntu 14.04, installation did not work unless adding ruby-dev. it failed with error below:
```bash
# vagrant plugin install vagrant-libvirt
Installing the 'vagrant-libvirt' plugin. This can take a few minutes...
/usr/lib/ruby/1.9.1/rubygems/installer.rb:562:in `rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)
/usr/bin/ruby1.9.1 extconf.rb
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- mkmf (LoadError)
from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from extconf.rb:4:in `<main>'
Gem files will remain installed in /root/.vagrant.d/gems/gems/nokogiri-1.6.7.2 for inspection.
Results logged to /root/.vagrant.d/gems/gems/nokogiri-1.6.7.2/ext/nokogiri/gem_make.out
from /usr/lib/ruby/1.9.1/rubygems/installer.rb:540:in `block in build_extensions'
from /usr/lib/ruby/1.9.1/rubygems/installer.rb:515:in `each'
from /usr/lib/ruby/1.9.1/rubygems/installer.rb:515:in `build_extensions'
from /usr/lib/ruby/1.9.1/rubygems/installer.rb:180:in `install'
from /usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:297:in `block in install'
from /usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each'
from /usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `each_with_index'
from /usr/lib/ruby/1.9.1/rubygems/dependency_installer.rb:270:in `install'
from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:65:in `block in call'
from /usr/share/vagrant/plugins/commands/plugin/gem_helper.rb:42:in `block in with_environment'
from /usr/lib/ruby/1.9.1/rubygems/user_interaction.rb:40:in `use_ui'
from /usr/share/vagrant/plugins/commands/plugin/gem_helper.rb:41:in `with_environment'
from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:52:in `call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
from /usr/share/vagrant/plugins/commands/plugin/action/bundler_check.rb:20:in `call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in `call'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:69:in `block in run'
from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in `busy'
from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:69:in `run'
from /usr/share/vagrant/plugins/commands/plugin/command/base.rb:17:in `action'
from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:27:in `execute'
from /usr/share/vagrant/plugins/commands/plugin/command/root.rb:56:in `execute'
from /usr/lib/ruby/vendor_ruby/vagrant/cli.rb:38:in `execute'
from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:484:in `cli'
from /usr/bin/vagrant:127:in `<main>'
```
Before this change, vagrant-libvirt assumed that all
port forwards should be done on eth0 adapter. Now
user can provide a custom adapter via "adapter" option
when calling forwarded_port.
Added TPM device support to include switching out the TPM device on
reboot if necessary.
The following options were added:
* tpm_model - Defaults to 'tpm-tis'
* tpm_type - Defaults to 'passthrough'
* tpm_path - Must be specified, other options are ignored if this is
not specified. Most users will set this to /dev/tpm0.
For additional information on using a TPM with Libvirt see the following:
* http://wiki.qemu.org/Features/TPM
* https://libvirt.org/formatdomain.html#elementsTpm
Background
----------
The default private_network template we supply has the following tag:
<network ipv6='yes'>
This enables ipv6 on guest interfaces for guest-to-guest communication.
This causes a problem on hosts that either do not have ipv6 enabled or
configured correctly, resulting in an error on 'vagrant up' as follows:
Error while activating network: Call to virNetworkCreate failed: internal error: Failed to apply firewall rules /usr/sbin/ip6tables --table filter --insert FORWARD --in-interface virbr1 --jump REJECT: ip6tables v1.4.21: can't initialize ip6tables table `filter': Address family not supported by protocol
Perhaps ip6tables or your kernel needs to be upgraded.
Reading here:
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=705e67d40b09a905cd6a4b8b418d5cb94eaa95a8
would suggest the above option should really be off by default, however,
I don't want to break existing behaviour or setups. This patch adds two
new config items, one for the default management network, and one for
additional user defined private networks.
Usage
-----
To disable ipv6 for the managment network:
config.vm.provider :libvirt do |libvirt|
libvirt.management_network_guest_ipv6 = "no"
end
To disable for a custom private network:
config.vm.network "private_network", ip: "192.168.33.10", libvirt__guest_ipv6: "no"
Extra Notes:
------------
Also note, if you get hit by the above error and want to apply the above
fix, you will need to clear out the management network manually:
$ sudo virsh net-list --all
Name State Autostart Persistent
----------------------------------------------------------
default active yes yes
vagrant-libvirt inactive no yes
$ sudo virsh net-undefine vagrant-libvirt
Network vagrant-libvirt has been undefined
* Fixed regression when using additional disks. Now disk_bus setting
applies only to main disk.
* Added ability to change additional disk bus on reload. Updated readme.
Task-Url: https://github.com/pradels/vagrant-libvirt/issues/418
Signed-off-by: Max Kutsevol <max@coolvds.com>
* Added the suspend_mode domain specific option. Now it can perform a
managed save/resume. Switching this domain specific option can be done
when the domain is supended, it will correctly resume the domain.
Task-Url: https://github.com/pradels/vagrant-libvirt/issues/411
Signed-off-by: Max Kutsevol <max@coolvds.com>
* Added support to modify domain specific options on already defined
domain, updated relevant documentation. For list of modifiable options
please see updated documentation.
* Added new domain specific option - uuid. To force domain UUID when
creating new VM.
Task-Url: https://github.com/pradels/vagrant-libvirt/issues/418
Signed-off-by: Max Kutsevol <max@coolvds.com>
Readme file is large, so navigation may be quite compilated.
Table of contents improves navigation but adds a little work when the content is changed.
Table of Contents was generated with http://doctoc.herokuapp.com/
For better VM performance CPU type should be set not to qemu64, but to
the host cpu type.
For example see the difference (uppercased)
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc
rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2
x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm
tpr_shadow vnmi flexpriority ept xsaveopt
Added extensions when emulating host cpu model:
flags : fpu VME de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
PAT pse36 clflush mmx fxsr sse sse2 SS syscall nx RDTSCP lm CONSTANT_TSC
rep_good nopl EAGERFPU pni PCLMULQDQ vmx SSSE3 cx16 PCID SSE4_1 SSE4_2
x2apic popcnt TSC_DEADLINE_TIMER AES XSAVE AVX hypervisor lahf_lm
tpr_shadow vnmi flexpriority ept XSAVEOPT
Nested virtualization requires VMX/SVM capabilities, which are still
being added when domain.nested is set to true.
Using the current default value for cpu_mode everyone will benefit from
the better VMs performance.
Signed-off-by: Max Kutsevol <max@kutsevol.com>
This is required because in current versions of libvirt, it is not
possible to specify a boot order when attaching a device; therefore we
can only parse the entire domain XML after all devices have been created
and then assign boot ordering according to the Vagrantfile
specification. This allows us to specify exact boot order for hd, cdrom
and network.
Vagrant already supports VMs without boxes with Docker.
We leverage this in libvirt as well. The use case for this is to PXE
oot a vagrant VM that is then installed over the network then
installed over the network; a different use case would be to test PXE
booted clients that do not use a hard drive whatsoever.
