VMotion and “Isolation Addresses”
Recently I setup a VMWare infrastructure at work, and when I finally thought I had everything right, I began getting errors about systems not being able to contact the “Isolation Address”. Naturally, I said “LOLWTFLOL” as I Googled for my error message.
It turns out that in order to enable VMotion, every system on the network has to be able to ping the aforementioned isolation address, which defaults to .1 of their subnet. Well, I’ll be. If somebody had mentioned this to me, I wouldn’t be in such a pickle! Since I was setting this up in a management vlan like a good admin, I didn’t have a .1!
After nearly 2 hours of being on hold (no, I’m not joking…), I got a tech to let me in on a little tip! He told me to go to my options, and in advanced settings, I could set das.isolationaddress to whatever I wanted! Wooo!
Oh, wait. VMotion also requires that every host can resolve every other host using an FQDN, and therefore DNS. Kindof quirky to me, as that seems to almost necessitate a secondary DNS server, and you’re not even out of your management vlan yet.
named inside a FreeBSD jail
If you’ve ever tried to run named inside a FreeBSD jail you’ve seen this error:
/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
The reason for this is that by default in FreeBSD named tries to run within a chroot. The chroot for named requires /dev/zero, and /dev/random, so the rc script that starts named tries to mount a devfs for named. The problem is that jails cannot mount, for obvious reasons.
The quick solution is to tell FreeBSD not to try to run named within a chroot. The idea is that a jail is good enough. You can do this by seting:
named_chrootdir=""
within the JAIL’S /etc/rc.conf.
The other option is to create the chroot dir for named from the host system for the jail before you start it. This really doesn’t have too much of a benefit. But it’s possible by issuing the following commands from the host system for your jail:
# mount -t devfs devfs /jails/jailhost.whatever.com/var/named/dev/ # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule -s 1 applyset # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path null unhide # devfs -m /jails/jailhost.whatever.com/var/named/dev/ rule apply path random unhide
Once you’ve done that, you can start named in the jail, and you’ll have named running inside a chroot within a jail. This doesn’t quell the error messages, but you can trust that they’re irrelevant, or if you feel like it, you can patch /etc/rc.d/named within the jail to not try to create/destroy chroots. Find these lines of code:
# Mount a devfs in the chroot directory if needed
#
umount ${named_chrootdir}/dev 2>/dev/null
devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
devfs -m ${named_chrootdir}/dev rule apply path null unhide
devfs -m ${named_chrootdir}/dev rule apply path random unhide
and make them look like this:
# Mount a devfs in the chroot directory if needed
#
#umount ${named_chrootdir}/dev 2>/dev/null
#devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
#devfs -m ${named_chrootdir}/dev rule apply path null unhide
#devfs -m ${named_chrootdir}/dev rule apply path random unhide
Now you have to maintain this stupidity, if your mergemaster changes /etc/rc.d/named, but I guess it’s nice not to see errors. You also can’t start your jails automatically at boot, because the chroot won’t exist yet… So…. whatever.
IIS, FTP Sites, and “Isolation”
Note to self: In Windows Server Land, FTP User Isolation does not mean what you think it would.
By default, users are restricted to the FTP Site’s home, and no directories above it, only below.
To get a better idea of what isolation is: Google It!
Buildworld Benchmark: My New Server (ULE)
Buildworld Benchmark: My New Server Continued.
This leads me to believe that I probably screwed up somewhere, but I just don’t want to spend more time doing something this … boring.
Buildworld Benchmark: My New Server
This chart shows build times vs. j-levels in FreeBSD when running buildworlds. The fastest buildworld time observed here is at j-level 3 (n+1 cores) and the fastest time observed was 1473.44 seconds (24.56 minutes). Pretty quick, but still not a quadcore…
I’ll run another trial with the ULE Scheduler enabled some time if I feel like it… But I don’t suspect I’ll see too large a change.
