VM Junkie

July 20, 2009

VMware Plea Part Deux: ESXi Boot from SAN

Filed under: esx, Uncategorized, vmware, vSphere — ermac318 @ 10:08 am

As some of you are aware, ESXi can officially boot from all the following sources:
USB Flash Device
SD Card
Local Hard Drive
PXE Boot (experimental)

There’s one big missing piece here: Boot from SAN. Why is this a big deal? It means customers who want to BFS (like HP VirtualConnect customers, or in the future Cisco UCS customers) in order to get the most out of their dynamic datacenter cannot use the next generation hypervisor architecture; they must stick to ESX “Classic.” We have been going back and forth with VMware support on this, but still even in ESXi 4.0 Boot from SAN is not officially supported.

This is despite the fact that on the ESXi Features Page, one of the features listed is Boot from SAN! Instead, you need to dig into the Install and Setup guide to find this gem:

You use the ESXi 4.0 CD to install the ESXi 4.0 software onto a SAS, SATA, or SCSI hard drive.
Installing on a Fibre Channel SAN is supported experimentally. Do not attempt to install ESXi with a SAN attached, unless you want to try this experimental feature.

That said, it works fine. I haven’t had any problems. But we can’t deploy it for customers that way if it’s not supported.

VMWare: Why is your next-generation hypervisor crippled in this way?

Advertisements

5 Comments

  1. because it is free

    Comment by JR — July 20, 2009 @ 10:40 am

  2. JR,
    The problem with this logic is that ESXi does not HAVE to be the low-end product. ESXi comes in a free version, but nothing’s stopping you from adding an ESX Enterprise license to it and turning on all the functionality.
    If VMware restricted the free version of ESXi so it couldn’t BFS, I would understand. But it’s a technical restriction at the moment, not a marketing one.

    Comment by ermac318 — July 20, 2009 @ 11:25 am

  3. Justin,
    Given that you are a fan of BFS, maybe you can explain as to why it is a Good Thing for ones ESX servers.
    I’ve toyed with it a bit, but didn’t feel the pros I knew about were worth the extra effort.
    Care to enlighten me?
    David

    Comment by d_glynn — July 20, 2009 @ 4:55 pm

  4. David,
    I think Boot from SAN on its own has a few good points:
    1) Less power usage (servers don’t need to run internal drives)
    2) Lower cost (no need to spend money on any kind of internal storage)
    3) Higher reliability (instead of two drives or a single USB key keeping you up, your SAN with many drives is)
    But the real key use case for Boot from SAN is when using it in conjunction with a technology like HP Virtual Connect (or products similar to it like Cisco’s UCS profile system, or IBM’s).
    I won’t speak specifically about IBM or Cisco’s product because I haven’t used them personally, but the way HP’s VirtualConnect works is you can create a profile for a blade that includes all the network connectivity as well as things like Boot from SAN parameters. So if you blade ever dies, you replace it with a new one and all the personality of the old blade stays. Or, if you want to change which blade is your ESX server on the fly, you can shut down the first system, move the profile, and power up the new one.
    That’s the main reason I would like ESXi BFS support – right now, if customers are taking advantage of blade profiles, you will need to either move the USB key around, or use ESX classic…

    Comment by ermac318 — July 21, 2009 @ 1:27 pm

  5. Hey ermac318, thanks for the reply.
    I’m going to give you zero credit for points 1 & 2, as using ESXi on internal flash/USB already gives these benefits.
    And you only get partial credit for point 3, as I’ve not had a disk failure in a while, well not one that hadn’t been well abused 🙂
    Having discussed HP’s Virtual Connect with a co-worker I think that here is the big win, replace the blade and getting the host back on-line can be performed by an entry level tech rather then requiring the SAN admin to get involved (assuming FC storage) or other high-level admins.
    In large enterprise environments this is a large benefit.

    Given VMware’s track history I think we can expect the experimental limitation to be removed in 4.5 or one of the updates, especially given that ESX classic is rumored to be going away. So a wait of 12 to 18 months.

    Comment by d_glynn — July 24, 2009 @ 10:38 am


RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Create a free website or blog at WordPress.com.

%d bloggers like this: