Since my last blog entry, I've received a couple emails asking about getting started with KVM. Compared to Xen, which requires a slight change in mindset considering that it's actually its own kernel, the KVM server install process is actually quite painless. Install the packages, configure your bridge, and away you go.
Package installation on Red Hat Enterprise / CentOS 5.4+
At a minimum, you'll need the KVM group and the kvm-tools package, but some others can be incredibly handy. libguestfs is a "library for accessing and modifying virtual machine disk images." Its big tool is guestfish which allows for a whole host of interactive VM fun. The author works for Red Hat and has a great blog which I've been following for some time: Richard WM Jones. EPEL is the Extra Packages for Enterprise Linux fedora project. It brings a massive number of useful fedora packages to RHEL and CentOS. I couldn't live without it any more.
yum -y groupinstall KVM yum -y install kvm-tools libguestfs-tools virt-top e4fsprogs rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
Package installation on Red Hat Enterprise 6 (Beta 2 as of this writing)
Red Hat has changed it up a bit in RHEL6. I'm not sure why the KVM stack isn't in a single package group (perhaps I'm missing something), but it's still easy enough. Note that, at least in the beta, the repo needs to be enabled after OS installation. Otherwise, yum commands will report that there are no packages available. Also keep in mind that, once the full version of RHEL6 has been released, there may be changes. The base repo will likely be enabled by default and the epel url will no doubt change.
# enable the rhel-beta repo vim /etc/yum.repos.d/rhel-beta.repo # set enabled=1 in the rhel-beta block # fyi, I also enable rhel-beta-optional yum groupinstall -y 'Virtualization Platform' \ 'Virtualization Client' \ 'Virtualization Tools' yum -y install python-virtinst libguestfs-tools virt-top \ e4fsprogs qemu-kvm-tools rpm -Uvh http://download.fedora.redhat.com/pub/epel/beta/6/x86_64/epel-release-6-4.noarch.rpm
Bridging Configuration
Every libvirt-enabled system I've used has installed a NAT forwarding "virtual network" by default. In server scenarios I have never had a use for this so I remove it first.
# if you haven't rebooted since the package install # you'll need to start libvirtd service libvirtd start virsh net-list virsh net-destroy default virsh net-undefine default virsh net-list
The next step is to create the bridge that will be presented to your guests. Since it's rather common these days to bond multiple network interfaces together for (at the very least) redundancy, I'll also show that piece here. The network interface "flow" for a single adapter will look like this now: eth0 -> bond0 -> br0. Obviously, you'll want at least a second adapter, but if you get started this way with only one it will be very easy to add the second.
I actually do all this with a custom script out of my kickstarts, but getting the process down manually can be extremely helpful.
# create the bridge cat > /etc/sysconfig/network-scripts/ifcfg-br0 <<+++ DEVICE=br0 TYPE=Bridge BOOTPROTO=static ONBOOT=yes IPADDR=192.168.0.7 NETMASK=255.255.255.0 +++ # create the bond and add it to the bridge cat > /etc/sysconfig/network-scripts/ifcfg-bond0 <<+++ DEVICE=bond0 ONBOOT=yes BRIDGE=br0 BONDING_OPTS='mode=1 miimon=100' +++
Now all that remains is to update the individual ethernet adapter configuration files to become slaves of the bond. You'll need at least one interface to be part of the bond. :) A sample file could look like this:
# /etc/sysconfig/network-scripts/ifcfg-eth0 # be sure to keep the correct HWADDR DEVICE=eth0 HWADDR=00:19:B9:F3:F3:F3 ONBOOT=yes MASTER=bond0 SLAVE=yes
The next step is to restart your network and validate the changes. A serial console comes in very handy for situations like these where you'll (at least briefly) lose network connectivity. In the worst case, if the configuration is botched, you'll be off the network until you fix it. That can be slightly problematic with remote servers. :)
# restart the network from the serial console # you *did* configure a serial console, right? :) root# service network restart root# ip -4 -o addr 1: lo inet 127.0.0.1/8 scope host lo 7: br0 inet 192.168.0.7/24 brd 192.168.0.255 scope global br0 # examine your bond # note that I haven't plugged in eth1 yet root# cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:19:b9:F3:F3:f3 Slave Interface: eth1 MII Status: down Link Failure Count: 1 Permanent HW addr: 00:19:b9:F4:F4:F4
From here, I do like to reboot in order to make sure everything will come up cleanly before relying on it. I'm a paranoid guy, though, and it's not absolutely necessary. :) Otherwise, you should be ready to install and run some guests. I hope this helps so please let me know either way. Until next time!
No comments:
Post a Comment