First off, VMWare BFS and a regular OS install BFS are two different monkeys.

In most environments, Booting from SAN is almost always faster than booting from internals, because instead of the typical 128Meg – 512Meg internally cached controllers, you have storage arrays like the Clariion with 4-8 *GIGS* of cache. All swapping is done directly to cache, and as such I’ve seen as much as a 20% – 30% performance improvement just from swap.

However, that being said, boot from SAN on VMWare isn’t like booting from SAN with a natively installed OS. VMWare itself swaps to the boot disks, and as I said above, a caching array will almost always perform better on cached writes over physical drives, and the read-hit rate on swap data is quite high (estimated 80% or better) because by definition memory thrown to swap isn’t there for long, it’s almost always recalled to active memory quickly.

For the VM’s themselves, swapping is done within the VMFS volume (remember the checkbox for where you want to store your paging file , so even in a situation where you have vmware booting off internal volumes, your VM Swapping is being done to SAN disks and not internal. (Remember, this is also a requirement for vmotion, because it allows active-state memory to get offloaded to a common area quickly, then handed over to the receiving system)

If you right-click on the cluster, click on Edit Settings, and then go down to “Swapfile Location” in the tree on the left you’ll see what I’m getting at.

Hope this helps. Give me a call some time, I owe you a beer.

on Saturday morning at about 4:30am in an IHOP in Arlington, VA, I was tasked with showing how VMWare will provide DR.

I set up the remote mirrors yesterday afternoon, took me about 10 minutes.

I set up the snaps (since this was clariion) today of the Secondary volumes today and brought them online in about 10 minutes.

I mounted a server from the downtown VMWare server on the DR VMWare server and booted it. All you have to do is change the IP’s and you have an EXACT image of your production server, up to the MINUTE of the split/failure.

Why don’t more people do this?

1) Initial SAN configuration is much easier I actually have a OS I can interact with rather than just a HBA bios
2) I can now roll back the entire system to a snapshot during patching, etc
3) I now have a complete DR of the system
4) Sys admins are happy in that if some storage event occurs they can still get to system logs
5) Backup windows… how about snapshots or clones instead

It’s cool that way, a blade fails, server monkey pulls it, drops a replacement in, hits the power, and presto, new server.

However I’ve booted Windows from the Symm before, and given that you’re swapping directly to cache, the OS performance boost is amazing.

The other bonus to it is being able to replciate (using SRDF) the boot volumes to a cold DR site. Add that to fixed DHCP (Assigning your IP by DHCP to the mac address of the box) you can have the same host boot at two different sites, grab different IP addresses, and register that IP with DNS so as to provide, god forbid, the ability to have an actual zero-RPO on the ENTIRE server.

Which of course you can do much more easily using VMWare.

Really, I’d go there again, with san boot, but it’s so much of a headache, and I don’t really need it. I lose a blade, no biggie, another blade takes the workload, I rebuild the host and move the workload back. We build in N+1, so I don’t have any heartburn over the outage to begin with.

What I think might make it take off is if you are able to abstract the HBA’s WWN from it’s physical hardware. Where it truely becomes a physically replaceable bit of equipment have a datacenter monkey pull a cpu and push in a new one in a blade chassis. This is also where I think they are trying to take FCOE (which scares the living crap out of me… my FC switches don’t even take a 1 sec outage; but every other day the networking guys are causing some minute long spanning tree event).

I could see using something like this in a smallish cluster, 6-12 hosts, where you’re booting from san to allow for a QUICK replacement of a failed host. Swap the hardware, zone/mask, and you’re back up and no new configuration needs to be done.