Diff for "KVM/Installation"

Differences between revisions 1 and 26 (spanning 25 versions)
⇤ ← Revision 1 as of 2008-12-24 16:10:49 →
Size: 6961
Editor: mx
Comment:
← Revision 26 as of 2010-07-28 07:13:56 → ⇥
Size: 4830
Editor: office
Comment: Fixed error in cmd line example
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
<<Include(KVM/Header)>>
Line 6: Line 7:
== How to check if your CPU supports hardware virtualisation == == Check that your CPU supports hardware virtualization ==
Line 8: Line 9:
To run KVM, you need a processor that supports virtualisation; Intel and AMD both have developed extensions for their processors, respectively INTEL-VT and AMD-V. To see if your processor supports one of these, you can run the following command: To run KVM, you need a processor that supports hardware virtualization. Intel and AMD both have developed extensions for their processors, deemed respectively Intel VT-x (code name Vanderpool) and AMD-V (code name Pacifica). To see if your processor supports one of these, you can review the output from this command:
Line 11: Line 12:
egrep '(vmx|svm)' --color=always /proc/cpuinfo egrep -c '(vmx|svm)' /proc/cpuinfo
Line 15: Line 16:
If nothing is printed, it means that your CPU doesn't support hardware virtualisation. Otherwise, it does - but you still need to make sure that virtualisation is enabled in the BIOS. If '''0''' it means that your CPU doesn't support hardware virtualization.
Line 17: Line 18:
== Use a 64 bit kernel if you need more than 2GB RAM for your VMs == If '''1''' (or more) it does - but you still need to make sure that virtualization is enabled in the BIOS.
Line 19: Line 20:
To serve more than 2047 MB of RAM for your VMs, you '''must''' use a 64 bit kernel (see [[32bit_and_64bit]]). On a 32 bit kernel install, you'll be limited to 2GB RAM at maximum for a given VM. == Use a 64 bit kernel (if possible) ==
Line 21: Line 22:
To see if your processor is 64 bit, you can run the following command:  1. To serve more than 2GB of RAM for your VMs, you '''must''' use a 64-bit kernel (see [[32bit_and_64bit]]). On a 32-bit kernel install, you'll be limited to 2GB RAM at maximum for a given VM.
 1. Also, a 64-bit system can host both 32-bit and 64-bit guests. A 32-bit system can only host 32-bit guests.

To see if your processor is 64-bit, you can run this command:
Line 23: Line 27:
grep ' lm ' /proc/cpuinfo egrep -c ' lm ' /proc/cpuinfo
Line 26: Line 30:
If nothing is printed, it means that your CPU is not 64 bit. ''lm'' stands for Long Mode, so 64 bit CPU. If '''0''' is printed, it means that your CPU is not 64-bit.
Line 28: Line 32:
To see if your running kernel is 64 bit, just issue the following command: If '''1''' or higher, it is. Note: ''lm'' stands for Long Mode which equates to a 64-bit CPU.

Now see if your running kernel is 64-bit, just issue the following command:
Line 33: Line 39:
'''x86_64''' indicates a 64-bit kernel running. If you use see i386, i486, i586 or i686, you're running a 32 bit kernel. '''x86_64''' indicates a running 64-bit kernel. If you use see i386, i486, i586 or i686, you're running a 32-bit kernel.

Note: x86_64 is synonymous with amd64.
Line 42: Line 51:
$ sudo apt-get install kvm libvirt-bin ubuntu-vm-builder qemu bridge-utils $ sudo aptitude install kvm libvirt-bin ubuntu-vm-builder bridge-utils
Line 50: Line 59:
You might also want to install ''virt-viewer'', for viewing instances
Line 52: Line 60:
'''8.10 (intrepid) Notes''':
 * Two meta packages have been added: {{{ubuntu-virt-server}}} and {{{ubuntu-virt-mgmt}}}. {{{Ubuntu-virt-server}}} installs the packages needed to setup a base virtulization host (kvm, libvirt-bin and openssh-server) and {{{ubuntu-virt-mgmt}}} installs what you need to administer it from a management station (virt-manager, python-vm-builder and virt-viewer).
 * {{{ubuntu-vm-builder}}} has been replaced by {{{python-vm-builder}}} ([[JeOSVMBuilder|tutorial]]).

'''Note:'''
libdevmapper does not load its module when it is installed ([[https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/277648|bug 277648]]) , so you will either need to do a
 {{{ $ sudo modprobe dm-loop }}}
or reboot your system before being able to use it.

== Adding Users ==

Add yourself to the ''libvirtd'' group (note that there is no need to add yourself to the ''kvm'' group):

{{{
$ sudo adduser `id -un` libvirtd
}}}

This will give you access to the system-wide libvirtd instance. This is preferable for you because it gives you access to the advanced networking options rather than simply the "userspace networking" option as you may know it from QEmu.

'''Note: You need to log out and log back in for the new group membership to take effect.'''

Note: The `id -un` command will return the current username, for example if your username is ''joe'' you will be effectively be running ''sudo adduser joe libvirtd''.		 You might also want to install ''virt-viewer'', for viewing instances.
Line 78: Line 65:
$ virsh -c qemu:///system list $ sudo virsh -c qemu:///system list
Line 95: Line 82:
= Configuring the network = == Version-specific Notes ==
=== 10.04 (Lucid) Notes ===
 * The package 'kvm' is replaced by 'qemu-kvm'. The kvm package is now marked as transitional so it still works to install it.
Line 97: Line 86:
There are a few different ways to allow a virtual machine access to the external network. The default virtual network configuration is usermode networking, which uses the SLIRP protocol and traffic is NATed through the host interface to the outside network. If you do not want to access network services on your virtual machine then you can skip this next step. === 9.10 (Karmic) Notes ===
'''Adding Users:'''
 * The libvirt-bin package will now automatically add members of the ''admin'' group to the ''libvirtd'' group. You still need to log out, and log back in for this change to take effect.
Line 99: Line 90:
However to enable external hosts to directly access services on virtual machines a bridge needs to be configured. This allows the virtual interfaces to connect to the outside network through the physical interface, making them appear as normal hosts to the rest of the network. Add yourself to the ''libvirtd'' group (note that there is no need to add yourself to the ''kvm'' group):
{{{
$ sudo adduser `id -un` libvirtd
}}}
Line 101: Line 95:
'''Warning:''' Network bridging will not work when the physcial network device (eg eth1, ath0) used for bridging is a wireless device (eg ipw3945), as most wireless device drivers do not support bridging! This will give you access to the system-wide libvirtd instance. This is preferable for you because it gives you access to the advanced networking options rather than simply the "userspace networking" option as you may know it from QEmu.
Line 103: Line 97:
'''Warning 2:''' It seems that due to the implementation of CAP_NET_ADMIN in kernel 2.6.18, root access is needed to bring tap interfaces up and down. This means you'll need to run the VM Manager with gksudo (bad) or place a wrapper around the bits that bring up the taps (messy). More info when I figure this one out. (srodden) Note: You need to log out and log back in for the new group membership to take effect.

Note: The `id -un` command will return the current username, for example if your username is ''joe'' you will be effectively be running ''sudo adduser joe libvirtd''.

=== 8.10 (Intrepid) Notes ===
 * Two meta packages have been added: {{{ubuntu-virt-server}}} and {{{ubuntu-virt-mgmt}}}. {{{Ubuntu-virt-server}}} installs the packages needed to setup a base virtulization host (kvm, libvirt-bin and openssh-server) and {{{ubuntu-virt-mgmt}}} installs what you need to administer it from a management station (virt-manager, python-vm-builder and virt-viewer).
 * {{{ubuntu-vm-builder}}} has been replaced by {{{python-vm-builder}}} ([[JeOSVMBuilder|tutorial]]).

Note: libdevmapper does not load its module when it is installed ([[https://bugs.launchpad.net/ubuntu/+source/vm-builder/+bug/277648|bug 277648]]) , so you will either need to do a
 {{{ $ sudo modprobe dm-loop }}}
or reboot your system before being able to use it.
Line 107: Line 111:
== Creating a network bridge on the host ==

Install the bridge-utils package:
{{{
sudo apt-get install bridge-utils
}}}

We are going to change the network configuration. To do it properly, we should first stop networking<<FootNote(This is needed for example when you move from DHCP to static address: it will stop the DHCP client, which a restart won't do if you changed the configuration already. If you are changing this remotely, then you should prepare your new configuration into a separate file and the use a script to stop networking, put the new configuration in place and start it back.)>>:
{{{
sudo invoke-rc.d networking stop
}}}

To setup a bridge interface, edit /etc/network/interfaces and either comment or replace the existing config with ('''replace with the values for ''your'' network'''):

{{{
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

}}}

or to use DHCP

{{{
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

}}}

This will create a virtual interface br0.

Now restart networking:

{{{
sudo /etc/init.d/networking restart
}}}		 <<Include(KVM/Header)>>

Installation

Check that your CPU supports hardware virtualization

To run KVM, you need a processor that supports hardware virtualization. Intel and AMD both have developed extensions for their processors, deemed respectively Intel VT-x (code name Vanderpool) and AMD-V (code name Pacifica). To see if your processor supports one of these, you can review the output from this command: 

egrep -c '(vmx|svm)' /proc/cpuinfo

If 0 it means that your CPU doesn't support hardware virtualization.

If 1 (or more) it does - but you still need to make sure that virtualization is enabled in the BIOS.

Use a 64 bit kernel (if possible)

  1. To serve more than 2GB of RAM for your VMs, you must use a 64-bit kernel (see 32bit_and_64bit). On a 32-bit kernel install, you'll be limited to 2GB RAM at maximum for a given VM.

  2. Also, a 64-bit system can host both 32-bit and 64-bit guests. A 32-bit system can only host 32-bit guests.

To see if your processor is 64-bit, you can run this command: 

egrep -c ' lm ' /proc/cpuinfo

If 0 is printed, it means that your CPU is not 64-bit.

If 1 or higher, it is. Note: lm stands for Long Mode which equates to a 64-bit CPU.

Now see if your running kernel is 64-bit, just issue the following command: 

uname -m

x86_64 indicates a running 64-bit kernel. If you use see i386, i486, i586 or i686, you're running a 32-bit kernel.

Note: x86_64 is synonymous with amd64.

Installation of KVM

For the following setup, we will assume that you are deploying KVM on a server, and therefore do not have any X server on the machine.

You need to install a few packages first: 

$ sudo aptitude install kvm libvirt-bin ubuntu-vm-builder bridge-utils
  • libvirt-bin provides libvirtd which you need to administer qemu and kvm instances using libvirt
  • kvm is the backend
  • ubuntu-vm-builder powerful command line tool for building virtual machines
  • bridge-utils provides a bridge from your network to the virtual machines

You might also want to install virt-viewer, for viewing instances.

You can test if your install has been successful with the following command: 

$ sudo virsh -c qemu:///system list
 Id Name                 State
----------------------------------

$

If on the other hand you get something like this: 

$ virsh -c qemu:///system list
libvir: Remote error : Permission denied
error: failed to connect to the hypervisor
$

Something is wrong and you probably want to fix this before you move on. The critical point here is whether or not you have write access to /var/run/libvirt/libvirt-sock.

Version-specific Notes

10.04 (Lucid) Notes

  • The package 'kvm' is replaced by 'qemu-kvm'. The kvm package is now marked as transitional so it still works to install it.

9.10 (Karmic) Notes

Adding Users:

  • The libvirt-bin package will now automatically add members of the admin group to the libvirtd group. You still need to log out, and log back in for this change to take effect.

Add yourself to the libvirtd group (note that there is no need to add yourself to the kvm group): 

$ sudo adduser `id -un` libvirtd

This will give you access to the system-wide libvirtd instance. This is preferable for you because it gives you access to the advanced networking options rather than simply the "userspace networking" option as you may know it from QEmu.

Note: You need to log out and log back in for the new group membership to take effect.

Note: The id -un command will return the current username, for example if your username is joe you will be effectively be running sudo adduser joe libvirtd.

8.10 (Intrepid) Notes

  • Two meta packages have been added: ubuntu-virt-server and ubuntu-virt-mgmt. Ubuntu-virt-server installs the packages needed to setup a base virtulization host (kvm, libvirt-bin and openssh-server) and ubuntu-virt-mgmt installs what you need to administer it from a management station (virt-manager, python-vm-builder and virt-viewer).

  • ubuntu-vm-builder has been replaced by python-vm-builder (tutorial).

Note: libdevmapper does not load its module when it is installed (bug 277648) , so you will either need to do a

  •  $ sudo modprobe dm-loop 

or reboot your system before being able to use it.

KVM/Installation (last edited 2020-03-23 20:00:34 by hamishmb)