The Storage Architect » ESXi

Why Does Microsoft Hyper-V Not Support NFS?

Chris M Evans — Thu, 02 Jun 2011 06:27:40 +0000

I recently wrote an article covering storage for virtualisation and was surprised to find out that Microsoft does not support the use of NFS shares with Hyper-V. At first I thought perhaps I was doing something wrong and that my configuration was in error. But after a lot of lab testing and eventually finding some obscure forum posts, I’ve concluded that NFS cannot be used for storing Hyper-V guests. But why?

Client for NFS

Microsoft has supported an NFS server and client within Windows for some time. In Windows Server 2008, the Client for NFS can be added through the “Services for Network File System” role. This creates a new MMC plugin on the start menu that allows administration of both Client and Server services for NFS. From that point on there’s not much to configure in the GUI and all NFS shares are mapped via the command line, or within WMI for Windows Server 2008 R2 (look for future posts describing NFS installation and configuration).

Hyper-V Fail

Any attempts to create Hyper-V guests fail with the error code shown in the screenshot attached. I’ve tried lots of options; pre-creating the VHD, importing the guest and so on, however all fail to allow a VHD to be created. Where does this leave me? Well, I can fall back to standard block-based Fibre Channel and iSCSI LUNs but this is potentially limiting if I’m looking to be more efficient with my Hyper-V installation. SCVMM 2012 for instance assumes I’m storing VMs on an entire single LUN as it uses LUN snapshots to replicate virtual machines. To make this kind of configuration work best, I’d need a storage system that does LUN level thin provisioning; this escalates my costs somewhat.

So the question is, why would Microsoft put in such a restriction? It’s not as if network share-based guests are totally banned as I can use CIFS to store them. Of course I wouldn’t want to do that because CIFS has some severe performance and integrity limitations that make it unsuitable. Perhaps it’s just that Microsoft still don’t “get” storage. After all, the latest recommendations for Exchange 2010 are to use DAS. Redmond needs to embrace the use of storage agnostic connectivity for Hyper-V; it’s these kind of features that keep VMware ahead and for many will make ESXi a preferred option.

Playing with Virtual Box

Chris M Evans — Wed, 25 Aug 2010 09:25:48 +0000

I’ve been using VMware products for close to 10 years now. Scanning back on my purchase history, the first version of VMware Workstation I bought was 2.0.1 for NT & 2000 back in August 2001. I was an immediate fan of the product and at the time used it on a software development project I was doing. I developed the software on my laptop then used Workstation to run Windows 98 to test client interaction. When I bought my first MacBook last year, I also bought VMware Fusion and I found the experience OK, but not great. Despite having 4GB of memory, Windows 7 seemed sluggish and Unity mode was cool but slowed the machine down somewhat.

Now that I’ve moved my main desktop to Mac, (new iMac 27″ with the i7 processor and 8GB of RAM) I decided to revisit desktop virtualisation to plug the gaps on the Windows tools that don’t have a direct Mac equivalent. It was also a great opportunity to set up an environment to use Office 2010 more frequently. I decided to move away from VMware and try out the free Virtual Box from Oracle (nee Sun). So far I’ve been quite impressed.

Installation of the software was a breeze; I’ve included some screen shots of the installation process in the gallery at the end of this post. I installed version 3.2.8 for OS X, which is a 74.5MB download.

Before diving into a “production” Windows 7 installation, I thought I would have a bit of fun seeing whether I could virtualise hypervisors. First off was Hyper-V. I had no problem with the installation but Windows wouldn’t let me add the Hyper-V feature after installation. Next I tried ESXi, 4.0.0. This time I was more successful, after setting on using RedHat Linux as the emulation type. I also managed to get the installation to work with FreeBSD. However despite installation working, I found it wasn’t possible to start a virtual machine; Virtual Box just hung and had to be force quitted. I guess I shouldn’t have been too surprised by this behaviour, however I did think ESXi might work as older versions of VMware Workstation worked on processors without any virtualisation capabilities.

So back to my Windows 7 experiences. I installed Windows 7 64-bit onto a new virtual machine, giving it 1GB of memory. Once I had Office 2010 & Visio (2010) installed, I gave Visio a spin. So far, I’ve found that Windows 7 in Virtual Box on Mac runs better than my previous native Windows 7 PC. I suspect there are few reasons for this.

Firstly the i7 processor in the new Mac is way quicker than the previous machine spec (AMD Athlon 64 x2 Dual Core 4400+). Second (and possibly more importantly) the graphics capability of the iMac are far superior and Virtual Box supports 3D and 2D Video acceleration. 3D support attempts to use the underlying 3D graphics hardware (if it exists). I was fortunate that when I recently ordered my iMac the new models with enhanced graphics had just been released, so I have the ATI Radeon HD 5750 with 1GB of RAM. This definitely improves the overall responsiveness of Windows 7 in this situation, even when not running full-screen, which most of the time it isn’t.

Overall I’ve found Virtual Box simpler and easier to use than VMware Fusion. Whether it’s as fully function or not remains to be seen as I use it further. However for free, it’s an excellent and worthy tool.

VMware Release vSphere 4.1: Vendors Rush to Support VAAI?

Chris M Evans — Tue, 13 Jul 2010 14:17:48 +0000

Today VMware announced the release of vSphere 4.1, the next generation of their ever evolving hypervisor. To be honest it would be hard to miss this announcement judging by the flurry of “first to blog” posts I’ve seen on RSS feeds and Twitter today (see the list at the end of this post). I’d advise you to read the press release (which can be found here) as I don’t typically do product announcments on behalf of vendors, however as usual I’ll be picking out things I find relevant.

Scalability Improvements

VMware claim significant increases in the numbers of VMs that can be supported via VMware vCenter Server – now up to 10,000 concurrently powered on virtual machines. This is a *huge* number and I’m sure other folks out there will point to installations scaling to this size, but really, this is a big number. It confirms to me that virtualisation is the only way forward for supporting large server installations. Ironically I was looking today at the history of VM (IBM’s VM that is), which is now 38 years old. I remember managing 8-10 MVS systems under VM in the early 90′s. Things have certainly scaled since then.

Quality of Service

New features in vSphere 4.1 enable more granular control over shared storage and network resources. Whilst I don’t know the detail, I can appreciate that the ability to prioritise any shared workload is a must as environments scale. This means not reverting to the blunt instrument of physical partitioning or partitioning without due consideration to load prioritisation. I mention this specifically as it has increased relevance to the storage environment where partitioning and multi-tenancy solutions are still crudely implemented. For example, MultiStore with FlexShare only prioritises workload; it doesn’t guarantee QOS.

Storage

There are a number of storage improvements within vSphere 4.1.

SIOC (Storage I/O Control) – Provides I/O prioritisation of virtual machines running on shared storage across a cluster of ESX servers.
Full support for 8Gb/s Fibre Channel HBAs
Support for iSCSI hardware offload with Broadcom’s NetXtreme II iSCSI HBA
Boot from SAN for ESX
vStorage API for Array Integration (VAAI) support

The last two are probably the most interesting. Booting ESX(i) from SAN enables stateless deployment with all of the metadata for running the hypervisor separated from the hardware. This means ESX(i) installations can be booted from a SAN disk on any machine and that the hypervisor can be moved around either the local data centre or remote data centre – failover of the hypervisor itself. Ultimately the resources of hypervisor and guests need to be entirely hardware independemt. Boot from SAN goes a way to enabling this.

VAAI support has a number of separate components; Full Copy, Hardware Assisted Locking and Block Zeroing.

Full Copy – this feature offloads the copying of a virtual machine to the underlying storage hardware and has a number of benefits; in VDI this significantly benefits templated deployments; for vMotion it reduces the amount of CPU, memory and I/O overhead between storage and hypervisor. Most interesting is the concept of xcopy to copy virtual machines between arrays.
Hardware Assisted Locking – this feature reduces the overhead of SCSI reservations on VMFS volumes by providing an “atomic set and test” functionality at the block level. Although this will improve VMFS performance, it also opens the door to federated storage infrastructures where individual VMDKs can be reserved to a host. This complementary to the features seen in VPLEX.
Block Zeroing – Why write zeros when you can mark the data as empty and throw the writes away? This is exactly what Block Zeroing does; don’t write streams of data; simply tell the storage which blocks are zeros and move on. The quoted benefit for this is eagerzeroedthick VMDKs. These can be created much faster when Block Zeroing is supported (something 3Par InServ has been doing for some time)

VAAI Support

EMC and 3Par have already announced VAAI support today; but with no immediate availability. 3Par VAAI support is available from September; EMC VAAI support depends on platform; CLARiiON requires FLARE 30 (currently not GA) and VMAX requires an update to Enginuity due in 4Q2010 – no mention of VPLEX. Of the other vendors, Netapp have a vague press release with no specifics on support timescales or code versions. Hitachi have also announced support on the AMS platform but not provides timescales or code versions.

Summary

vSphere 4.1 pushes the virtualisation boundaries further on; the storage integrations are a welcome step forward in reducing resource overheads and improving data mobility. It’s a shame that vendors have announced support today without any direct support from day one. Those of you rushing to download ESX(i) 4.1 will have to wait just that little bit longer to test with your storage systems.

Here’s a roundup of some of the posts so far.

Virtualisation: Learning The Hard Way

Chris M Evans — Wed, 20 Jan 2010 10:37:55 +0000

They say that you learn the most when you make mistakes and things go wrong. Well, last night I certainly must have learned a lot. What started as a simple physical re-organisation of my hardware turned into a rebuild of my production VMware ESXi server – finishing at 1am. Here’s what happened.

Failing Disk

I started by shutting down and moving my production ESXi Server out and back into the standard rack it occupies. On power up, the server failed to reboot, claiming the boot disk was no longer present. A quick check inside showed that the SAS connector on the boot disk had come loose, so I plugged it back in and tried again (Oh, SAS specification guys – bad design, no retainers on the plugs). Unfortunately, the boot disk had somehow become corrupted and the server wouldn’t come up. No problem, I thought, just repair using the installation media. This is where things started to get complicated.

My ESXi server runs off a Seagate Savvio 2.5″ 15K 73GB drive, one of four Seagate generously loaned me last year for long term testing. More on that another day. The server has two disks installed, one of which has VMs on it. During the repair process I wasn’t sure which disk was the O/S and which was data. ESXi doesn’t help much, only indicating that both disks contained data in partitions, data that would be lost if I reinstalled.

Lesson 1 – Make sure you know exactly how your hardware is configured, down to the SAS ports each drive is plugged into.

Actually having multiple drives of the same type is a pain. So rather than risk data loss, I removed both drives and re-installed the ESXi O/S from a third Savvio drive. All good. Now I need to locate and import all my VMs, however some were on the removed Savvio disks. This meant installing each disk independently and checking the contents to determine which contained VMs and which contained the broken O/S.

Lesson 2 – Wherever possible, place your VMs on disks separate from the server itself.

Yes, I do have most of my VMs on my Iomega ix4-200d, but, rather crucially, not my Windows 2008 AD Server, which needed to be moved from internal disk to the ix4 before I continued (schoolboy error there). The AD server was rather important for accessing my, ahem, ix4, which is configured to validate logins using AD. This creates a bit of a circular reference which could have been a disaster.

Lesson 3 – Place your Windows domain controller on a physical server, or have another independent backup elsewhere.

Having a physical server just for AD control isn’t part of my total virtualisation plan, so I’m looking at whether I can host a backup controller with Amazon AWS and use VPN to secure it into my private network. This way, if I ever have an issue, I can still authenticate. The issue of course is cost, which may make a dedicated server the cheaper option.

So, by 1am everything was back up and running. Did I learn anything else? Well yes…

Lesson 4 – after 22 years in IT, I should remember that adequate documentation and a DR plan are crucial. In fact, in a virtualised environment, they are essential due to the concentration of risk placing all systems on a single server causes.

So what next for my virtual infrastructure? I have a few changes planned; I’ll create a backup ESXi server that can import and run the VMs in the event of a future server failure. I will also be investigating AWS with Windows 2008 and VPN to create a backup domain controller and see if I can continue to work if both server’s hardware failed.

That leaves one Single Point of Failure… my ix4-200d. Anyone want to donate me a spare one?

ESXi: Learning The Hard Way

Chris M Evans — Wed, 20 Jan 2010 10:37:55 +0000

Failing Disk

Lesson 1 – Make sure you know exactly how your hardware is configured, down to the SAS ports each drive is plugged into.

Lesson 2 – Wherever possible, place your VMs on disks separate from the server itself.

Lesson 3 – Place your Windows domain controller on a physical server, or have another independent backup elsewhere.

So, by 1am everything was back up and running. Did I learn anything else? Well yes…

Lesson 4 – after 22 years in IT, I should remember that adequate documentation and a DR plan are crucial. In fact, in a virtualised environment, they are essential due to the concentration of risk placing all systems on a single server causes.

That leaves one Single Point of Failure… my ix4-200d. Anyone want to donate me a spare one?

Review: DroboPro – Part II

Chris M Evans — Mon, 07 Dec 2009 16:27:33 +0000

This is the second in a series of posts looking at the DroboPro from Data Robotics Inc. Previous post(s):

Review: DroboPro – Part I

Previously I discussed a few frustrations with connecting my new DroboPro to ESXi, the target environment for my new device. I’ve now managed to get the ‘Pro connected and visible within ESXi. See the attached screenshot image taken from my production ESXi server.

So far, I’ve configured eight 2TB LUNs (although the DroboPro itself only has a capacity of 5TB, 2x 2TB and a single 1TB drive) which are numbered 0-7; the LUN column on the screenshot. Compare this to the LUNs presented from my ix4-200d, which has three LUNs all numbered ’0′. The difference is in the way the DroboPro is choosing to present iSCSI devices and the Runtime Name column gives a clue. In standard Controller/Target/LUN or CxTyLz/CxTyDz methodology, the ix4 disks are using separate targets to map out each iSCSI LUN, with the LUN number always ’0′. The Target setting is analagous to a storage port, typically a physical port on large fibre channel arrays. The LUNs are then numbered on that port. The DroboPro presents all its iSCSI LUNs on the same target (in this instance number 3) and so the LUNs are numbered from 0.

This method of presentation doesn’t necessarily cause a problem, but is just a different way of presenting the LUNs. Presumably with the Drobo Elite the multi-user functionality is achieved by enabling multiple targets per Drobo, each mapped to a separate user. In any case, I now have visibility of my DroboPro within ESXi. Time, to write some data.

Virtualisation: Virtualising MY SOHO Infrastructure

Chris M Evans — Wed, 02 Dec 2009 12:48:29 +0000

I’m in the process of migrating my existing physical infrastructure into a virtual environment. There’s nothing like “eating your own dog food” (there’s got to be a better expression than that) for testing out your beliefs on how technology should be implemented, so it’s only fitting I virtualise the IT infrastructure I rely on.

In summary, I run a “production” Windows AD domain, Exchange, IIS and file services. This is a typical scenario for many small businesses, with perhaps a few variations thrown in for good measure, such as SharePoint. I’m moving to a virtual environment that is built on ESXi v4.0, a custom design Intel-based server with 2x Quad Core Intel 5420 processors and 16GB of memory. Local hard drives include 2x SAS 7.2K 500GB drives and 2x 73GB SAS 15K drives.

Storage Choices

The first question I posed for my infrastructure is to decide on a storage platform. As this is a SOHO type deployment, I don’t have the luxury of a fibre channel SAN environment. I expect that many SMBs will feel the same and not want to commit to fibre channel deployments when the alternative options out there are low cost and probably more suitable. Therefore here are my choices:

Internal drives. I have over a terabyte of internal storage but unfortunately its not RAID protected. The disks are deployed on SAS connectors on the motherboard rather than through a dedicated RAID card. Although I could change the configuration and include a card, there are a number of issues; (a) increased cost (b) downtime to replace failed drives (c) physical intervention and downtime on the server to replace drives. My goal is to deploy this infrastructure to run 24×7, so having to take the system down to replace a drive is not an option. I also think that internal drives wouldn’t give me the scalability I might need.
iSCSI. In this environment, iSCSI is a great solution; there are lots of SMB iSCSI solutions on the marketplace today, offering low cost storage with simple operations. iSCSI is definitely a possibility.
NAS. Using NAS (more specifically NFS) for storage on VMware provides lots of flexibility. The management of the filesystem itself moves to the NAS hardware and so any VMware host files appear as standard files on the NAS device. When people see this, they usually get the “light bulb moment” as they realise the possibilities this kind of deployment offers. Whole virtual machines can be cloned, backed up or even simply copied as files around the infrastructure. NAS offers easy access to log and configuration files too.

So, for me the choice is NAS. I have iSCSI deployed, but for my production environments, NAS will be used to store my VMware hosts. This is for a variety of reasons, however there’s one additional benefit I haven’t discussed and that’s portability. Placing my vmdk’s on NAS means I can move them around at will. I can replicate them, I can back them up and I can move them easily to another NAS device without using ESXi as the data mover.

Stay tuned for more discussions as I evolve my setup.