A week ago while ‘defending’ a design for a ‘customer’ we were talking about the best option to place ESXi4.1.
Basically there are three options that popped up into my mind, either you install your hypervisor on:

Local disk, most of the time in a RAID1 configuration

SAN boot disk

USB key or SD card

Since you do not design an environment with solutions that are not supported by VMware, you try to avoid them.

In this case we eventually talked about the USB key option and as I wanted to stick with VMware guidelines I declined the option in favor of one of the two other options, local disk or SAN boot disk.

But actually the third option is not incompatible with VMware guidelines and I found a VMware KB clearly saying that VMware support USB keys and SD cards with two conditions:

Share this:

Like this:

LikeLoading...

Related

About PiroNet

Didier Pironet is an independent blogger and freelancer with +15 years of IT industry experience.
Didier is also a former VMware inc. employee where he specialised in Datacenter and Cloud Infrastructure products as well as Infrastructure, Operations and IT Business Management products.
Didier is passionate about technologies and he is found to be a creative and a visionary thinker, expressing with passion and excitement, hopefully inspiring and enrolling people to innovation and change.

3 Responses to VMware To Support ESXi 4.x On USB Keys And SD Cards

Great post, a few questions though regarding your statement: “could potentially save my ‘customer’ some money”:

– How are you going to defend the SPOF that you will have with USB to your customer?
– What is the cost of possible downtime compared to 2 disks in RAID1?
– Where do you see the CAPEX / OPEX savings when using USB instead of the other options?

Hi Marnix and thx for your comment.
Maybe I should have elaborated a bit more my statement in the post.
Read my answers to your questions below:
– How are you going to defend the SPOF that you will have with USB to your customer?
ESXi loads up in memory and works from there. So I would say is your server’s memory reliable rather do you have a RAID1 for your ESXi boot disk?
Two folders are important though, /bootbank and /scratch. But again it all depends where you go diskless/diskful and/or stateless/stateful.
So properly configured ESXi can do the job with or without its boot disk.

– What is the cost of possible downtime compared to 2 disks in RAID1?
For the reasons cited above I don’t think you augment the risk by going USB instead of a regular disks setup in RAID1.

– Where do you see the CAPEX / OPEX savings when using USB instead of the other options?
A USB key is cheaper than the smallest server disk available at HP for instance. As you would need a minimum of two disks in a RAID1 config, the price goes up even further and the USB key is even more appealing in that perspective.
On the operational side, I would put SAN boot disk being the most expensive solution to manage and USB key the cheapest solution to manage. But that’s only my thoughts.

At the end it’s all about sticking to your customer’s functional requirements. If a USB key is a no go for your customer, you drop the option from your design.

Another interesting information regarding ESXi scratch partition and USB/SD cards/BOOT from SAN scenario.

Here are two examples where scratch space may not be automatically defined on persistent storage. In each case, the temporary scratch location will be configured on a ramdisk.

1.ESXi deployed on a Flash or SD device, including a USB key. Scratch partitions are not created on Flash or SD storage devices even if connected during install, due to the potentially limited read/write cycles available.

2.ESXi deployed in a Boot from SAN configuration or to a SAS device. A Boot from SAN or SAS LUN is considered Remote, and could potentially be shared among multiple ESXi hosts. Remote devices are not used for scratch to avoid collisions between multiple ESXi hosts.

DISCLAIMER

Views expressed here are mine, they are not read or approved in advance by any company and don’t reflect the views of my employer, my employer’s business partners, or clients. I am solely responsible for all content produced here. No information provided here was reviewed by or endorsed by my employer or any other vendor or organization. This is my own blog. Comments are moderated!