My good friend Clay sent me a link to Vallish Guru’s blog, which contains a number of PDFs that describe the Solaris NFS client and server implementations. I read through the NFSv3 RFC and Brent Callaghan’s awesome book on NFS a while back, and both of these resources came in handy while I was reading through some of the PDFs. The fact that NFS has been alive for over 20 years amazes me, and it’s awesome to see that the NFS folks are taking it in new and interesting directions.
During my KVM testing, I wanted to be able to use the virsh “console” command to access the console of my guests. This would make remote management a whole lot easier, since the default remote management interface (vnc) was a bit of overkill. To get virsh to allow me to console in, the first thing I did was update the menu.lst to get grub to write to the serial port:
serial –speed=115200 –unit=0 –word=8 –parity=no –stop=1 terminal –timeout=10 serial
In addition to the two items above, you also need to make sure you disable the splash screen. Next up, I had to adjust the kernel entries in the menu.lst to write to the serial port (ttyS0). Here is a sample entry that does just this:
title CentOS (2.6.18-128.1.10.el5) root (hd0,0) kernel /boot/vmlinuz-2.6.18-128.1.10.el5 ro root=LABEL=/ console=ttyS0 initrd /boot/initrd-2.6.18-128.1.10.el5.img
The items listed above will configure grub and the kernel to write to the serial port, but you will not be able to login since a getty process isn’t configured to monitor the serial port. To fix this, you can add the serial device name to /etc/inittab (the entry below assumes you want to use agetty instead of one of the other getty implementations):
S0:12345:respawn:/sbin/agetty ttyS0 115200
After I configured init to spawn a getty process, I had to tell init that it was ok for root to login through ttyS0. Privileged logins are managed through /etc/securetty, which contains a list of devices that root is approved to log in on. To allow root logins over ttyS0, I appended it to the file:
echo “ttyS0” » /etc/securetty
Once the items listed above were in place, I was able to fire up virsh and access the console through SSH:
$ virsh
virsh # console kvmnode1 Connected to domain kvmnode1 Escape character is ^]
CentOS release 5.3 (Final) Kernel 2.6.18-128.1.10.el5 on an x86_64
kvmnode1 login:
This is amazingly cool, and makes remote management super easy.
As you may surmise from several of my recent posts, I have been doing a ton of Linux virtualization (Xen, KVM, openvz) testing. In the case of KVM, numerous bug fixes are integrated into each kernel release, so it’s often beneficial to stick to the bleeding edge kernels (though great for testing, I wouldn’t feel comfortable running these in production). Fedora provides the latest and greatest kernels and virtualization packages (libvirt, qemu, etc.) in the rawhide repository, which you can access by setting the enabled flag to 1 in /etc/yum.repos.d/fedora-rawhide.repo:
[rawhide]
name=Fedora - Rawhide - Developmental packages for the next Fedora release
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/$basearch/os/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch
[rawhide-debuginfo]
name=Fedora - Rawhide - Debug
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/development/$basearch/debug/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=rawhide-debug&arch=$basearch
enabled=1
Once you have the repository enabled, you can use yum to install the latest kernel:
$ yum update kernel
This will install the latest kernel, and allow you to take advantage of the latest Linux kernel features.
I just came across a link from OSNews about Sun dropping development on the ROCK processor. At first I was a bit surprised by this, given the ROCK feature set Sun had been touting for several years. But in practice, this decision doesn’t surprise me for a few reasons:
1. By the time the ROCK was feature complete and ready for market, Intel and AMD should be able to match its performance when you took cost into account.
2. The cost of the ROCK processor would be significantly more than the Intel or AMD counterparts, especially when you factor in things like system redundancy.
3. While the ROCK has some killer technology (e.g., transactional memory), software isn’t quite ready to take advantage of these features.
4. Few applications can truly take advantage of large numbers of hardware execution threads (and using virtualization to run multiple apps on these hosts has its own drawbacks).
5. More and more people are migrating away from SPARC, so I’m not entirely sure a market would exist for the product when it eventually shipped.
While this is definitely a bummer for the SPARC followers, this may actually be a good thing for Sun. I would love to see them focus more on their X64 product line, and use their top notch hardware designers to get more bang for the buck out of their X64 product line. At the end of the day things always boil down to the cost/performance ratio, and given recent advancements in X64 hardware, it’s extremely hard to justify spending an order of magnitude more for SPARC gear when you can get X64 gear at a fraction of the price. I would love to hear what others think about this topic.
I have been playing around with libvirt, which is a virtualization toolkit that sits on top of the native virtualization technologies in various operating systems. Libvirt provides built-in support for managing remote nodes, which is useful when you need to enable one or more virtualization properties, or when you need to perform some type of administrative action (e.g., migrate a host to another machine). To allow secure access, libvirt supports transport layer security as well as authentication. TLS is typically used to secure the network transport, and SASL is used to provide authentication.
SASL currently supports MD5 and GSSAPI authentication. To configure libvirt to use the SASL DIGEST-MD5 mechanism, you will need to add a user to the SASL database. This can be accomplished with the saslpasswd2 command:
$ saslpasswd2 -a libvirt virt
Password:
Again (for verification):
The “-a” option specifies the application name to tie the user to, and the name passed to command is the account to create. To view the list of users in the SASL database, you can pass the name of the sasl password database (a Berkeley DB database) to the sasldblistusers2 command:
$ sasldblistusers2 -f /etc/libvirt/passwd.db
virt@thecrue: userPassword
After the accounts are created, you will need to make sure the digest-md5 mechanism is enabled in the /etc/sasl2/libvirt.conf configuration file:
# Default to a simple username+password mechanism
mech_list: digest-md5
Next you will need to edit /etc/libvirt/libvirtd.conf to enforce SASL authentication. If you are using a TCP socket to connect to your hosts (not recommended), you can update the auth_tcp directive:
# Change the authentication scheme for TCP sockets.
#
# If you don't enable SASL, then all TCP traffic is cleartext.
# Don't do this outside of a dev/test scenario. For real world
# use, always enable SASL and use the GSSAPI or DIGEST-MD5
# mechanism in /etc/sasl2/libvirt.conf
auth_tcp = "sasl"
If you are using TLS over TCP to connect to your hosts (this is recommended, since the user credentials will be encrypted and not passed to the remote nodes as plain text), you can update the auth_tls directive:
# Change the authentication scheme for TLS sockets.
#
# TLS sockets already have encryption provided by the TLS
# layer, and limited authentication is done by certificates
#
# It is possible to make use of any SASL authentication
# mechanism as well, by using 'sasl' for this option
auth_tls = "sasl"
After sasl is active, you will be prompted by libvirt to provide a user account and password each time an operation is performed:
$ virsh
virsh # **migrate --live kvmnode2 qemu+tls://disarm/system**
Please enter your authentication name:virt
Please enter your password:
Using TLS requires a bit more work to get operational, so I will leave that for a separate post. Libvirt is pretty sweet, and when KVM is fully integrated life will be grand!!