cyborgworkshop.org

ESXi 4 can procedure can be found here

Updated for ESXi  3.5 update 4
This is ridiculously cool.  I have a quad core motherboard with 8 gig of RAM that won’t install VMWare ESXi (it’s an ICH8 board and only ICH7 and ICH9 will work), but I’ve been hearing that you can install ESXi onto a thumbdrive and run it on boards that wouldn’t work otherwise.  Most instructions are for windows and, being the windows dude that I am, I decided to tweak it for linux.  First, you’ll need a linux box and a 1 gig or larger USB drive.  Download the ESXi ISO and then mount it in linux like so

mount -t iso9660 -o loop VMware-VMvisor-InstallerCD-3.5.0_Update_4-153875.i386.iso /mnt/esx

Now we’re going to write the installer file to the thumbdrive. I’m assuming the thumbdrive is /dev/sdb

tar xvzf /mnt/esx/install.tgz usr/lib/vmware/installer/VMware-VMvisor-big-3.5.0_Update_4-153875.i386.dd.bz2 -O | bzip2 -d -c | dd of=/dev/sdb

This will take a little bit, but once it’s done you’re good to go. pop that drive into a USB boot capable board, configure iSCSI storage and emulate away!

Not being a windows guy, this may be a really newbie thing, but.. When working in Pocket Internet Explorer on a windows mobile 5 device, I was unable to get to any internal sites without using the fully qualified domain name of that site. So I couldn’t reach http://test, but I could reach http://test.cyborgworkshop.org . I pulled my hair out on this one until I found a foot note on a random google page suggesting that I change my connection type from Internet to Work. Guess what. If you are using a connection type of Internet, domain searching is disabled. In order to reach a hosts by its canonical name, you have to be on a connection type of Work. As far as I can tell, that is the only difference between the two and is L-A-M-E.

With ESXi being free, I set out on a mission to build the least expensive ESX server I possibly could. That meant reusing a lot of gear and buying as little as possible which led me to a discovery. Intel ICH7 and ICH9 southbridge motherboards seem to work very well in ESXi (SATA included). ICH8 and ICH10, not so much.  With that discovery in hand, I built a P4 3ghz with an old Socket 478 chip, 4 gig of RAM and a 500 gig SATA drive smacked into an MSI 945GCM478-L board for 50 bucks total new invested. Works like a charm with the single drive being the only real bottleneck.  So, nab ESXi Update2, an ICH7 or ICH9 board and make yourself more marketable!
UPDATE:

MaRiN noticed that the onboard NIC on this board doesn’t, well, function. I forgot to mention that part The easy route is to buy an Intel Pro 100 NIC for a few bucks from ebay or your local computer store. A brand new Intel Gig Pro NIC from newegg will run you about 25 bucks, and then you’ll be good to go!

A TCP packet is normally 1500 bytes large, 40 bytes of that being header information and 1640 of it being data. Trouble is, sometimes you don’t have 1640 bytes of data to send. In a telnet session for example, hitting enter is 1 byte, but we still need to send an entire packet for that single byte meaning 41 bytes on the wire.  This isn’t efficient and too many small packets like this can bring a firewall to its knees. A solution was put in place years ago called Nagles Algorithm that holds off on sending data until a larger packet can be assembled. Good for general use, not good for an iSCSI SAN.  Here are some worthless and misleading numbers.

Single SATA drive, P4 OpenSolaris Build 91 shared via iSCSI on a dedicated gig network with MTU at 1500.

while true; do dd if=/dev/zero of=test.img bs=1024 count=100000; rm test.img; done
102400000 bytes (102 MB) copied, 3.84045 s, 26.7 MB/s
102400000 bytes (102 MB) copied, 4.24423 s, 24.1 MB/s

Now with Nagle disabled

while true; do dd if=/dev/zero of=test.img bs=1024 count=100000; rm test.img; done
102400000 bytes (102 MB) copied, 2.13878 s, 47.9 MB/s
102400000 bytes (102 MB) copied, 2.14086 s, 47.8 MB/s

For the statisticians among you, I did several more tests and used other utilities like cp, but this is a blog and blogs are quick so work with me here.

A bug was opened with the OpenSolaris folks (6621560) but in the meantime, we can take care of this ourselves with one little command.   To check the status of Nagle, run the following as root

ndd -get /dev/tcp tcp_naglim_def

If that comes back with anything other then 1, Nagle is kicking you in the shorts. So lets fix that.

ndd -set /dev/tcp tcp_naglim_def 1

Tada. things should be a fair bit speedier now.  Unfortunatly, this is system wide and may impact thigs like webservers, but if you are running apache on your SAN you pretty much get what you deserve. Enjoy!

Solaris had seen better days with the release of Solaris 9.  No ground breaking innovations had occurred, the sparc architecture had started to lose it’s place as the data center chip of choice and linux was really kicking it in the teeth with it’s ease of access by the younger sysadmins. An x86 version existed, but it was really just a hobby OS  and no data center in its right mind would deploy it as production.  Things looked bleak, and then came Solaris 10. Solaris 10, and the cool threads/niagra CPUs, helped to put the shine back on Sun. Zones and containers helped to virtualize server hardware, giving a bit more return on investment, but what really did it for the geeks was ZFS.   ZFS is coined “the last word in file systems” and I gotta say, I believe it.  It combines LVM, RAID a journaled atomic file system and manages to increase performance all at the same time. Add to the equation that VMWare recently released ESXi (the bare metal hypervisor that they had been charging 3500 per node for) and you have a really sweet SAN backed virtualization solution in the making.

First things first, install open solaris and immediatly patch it.  You can find instructions on how to do that Here but the condensed version is

pfexec pkg refresh
pfexec pkg image-update
pfexec mount -F zfs rpool/ROOT/opensolaris-2 /mnt
pfexec /mnt/boot/solaris/bin/update_grub -R /mnt

Depending on your internet connection this may take an hour or a few.  The reason for the upgrade is that the shipping version of Open Solaris (2008.5) has a bug with the serial number generation that prevents VMWare from using volumes exported via iscsi.   Once you’ve upgraded solaris, we need to create our pool. We’re going to assume three drives, c0t0d0, c0t0d1 and c0t0d2 and we’re going to put them into a raidz (better look this up, think raid 5 but better)

zpool create tank raidz c0t0d0 c0t0d1 c0t0d2

And you can check your handy work by running

zpool status -v tank

So, we now have a zfs pool called tank that is made of 3 drives we’re going to create a 100 gig volume that we’ll use in the SAN.

zfs create -V 100g tank/iscsi-vol

We now have a 100 gig volume in /tank called iscsi-vol. Next step is to share that bugger out via iscsi

zfs set shareiscsi=on tank/iscsi-vol

and we’re done. you can verify with

iscsitadm list target -v

Now that we have the volume shared out, we need to get access to it with vmware. I’m assuming here that you have a single ESXi 3.5 Update 2 node to play with, so this is assuming a virtual center client to a single ESXi node. This is a pretty simple operation.  In the vmware console, click on configuration and go to networking.  add a vmkernel and then click properties and enable iscsi for that adapter.  Back to the main configuration tab,  click on storage adapters and select properties for the iscsi software adapter.  You’ll need to enable the device and then click on and close the window.  Open that property window again and go to dynamic discovery. Here you’ll add the IP of the Solaris box and then click ok.

Right click on the iscsi adapter and select rescan, this may take a minute.   When it’s done go into storage and click add storage. Looky what shows up in your vmfs storage pools, our new 100 gig volume.