October 25, 2009
~6k lines of C code, and you have a x86 hypervisor in the Linux kernel!
lguest is a very minimal x86 hypervisor for Linux, very easy to set up, and due to its very small code base, it can be fun to hack/tweak.
Besides its small code base, it’s very well documented, thus ‘studying’ the lguest code is probably the best way to start learning a few things about virtualization and hypervisors.
Actually, the Makefile in drivers/lguest/ can be used to ‘extract’ the comments from the lguest code, in a very organized way, which makes it even easier to understand how lguest works(just cd to the directory and type make Beer, or make Puppy, if you want some ascii puppies : )
lguest requires some kernel configuration. Except for lguest itself, you must include some virtio modules, particularly virtio_blk and virtio_net, if you need networking inside the guest.
Afterwards, you must compile the Documentation/lguest/lguest.c, which you’ll run in userspace every time you want to ‘launch’ a new guest.
In order to run a new guest, you just run the lguest launher you just compiled, with some parameters, like the amount of memory the guest should have, the kernel image(usually the same image, that the host runs) and/or the initrd needed, a rootfs(you can either download a minimal rootfs for testing, or create one using qemu), and the virtual block device(/dev/vda), where the rootfs will be mounted inside the guest.
lguest 64m vmlinux --initrd=initrd.img --block=rootfile root=/dev/vda
That’s it! You have a guest running.
Of course lguest lacks features, included in other hypervisors/virtualization solutions, but that’s the point. A small ‘experimental’ hypervisor, easy to understand and maybe tweak. ;)
October 19, 2009
This post is mainly for ‘self reference’, in case something like this happens again.
According to the sshd man page, by default, sshd will perform a reverse DNS lookup, based on the client’s IP, for various reasons.
A reverse DNS lookup is used in order to add the hostname to the utmp file, that keeps track of the logins/logouts to the system. One way to ‘switch it off’ is by using the -u0 option when stating sshd. The -u option is used to specify the size of the field of the utmp structure that holds the remote host name.
A reverse lookup is also performed when the configuration(or the authentication mechainsm used) requires such a lookup. The HostBasedAuthentication auth mech, a “from=hostname” option in the .authorized_keys file, or the AllowUsers/DenyUsers option that includes hostnames, in the sshd_config, require a reverse DNS lookup.
Btw, the UseDNS option in the sshd_config, which I think is enable by default, will not prevent sshd from doing a reverse lookup, for the above mentioned reasons. However, if this option is set to ‘No’, sshd will not try to verify that the resolved hostname maps back to the same IP that the client provided(adding an extra ‘layer’ of security).
So, the point is that if for some reason the ‘primary’ namserver in the resolv.conf is not responding, you’ll experience a lag when trying to login using ssh, which can be confusing if you don’t know the whole reverse DNS story.
Another thing that I hadn’t thought before I learned about sshd reverse lookups, is that a DNS problem can easily ‘lock you out’ of a computer, if you use hostname based patterns with TCP wrappers(hosts.allow, hosts.deny). And maybe this can explain some “Connection closed by remote host” errors, when trying to login to a remote computer. :P