esxi - Gabes Virtual World

Add Fusion IO driver to VMware Auto Deploy

17 June, 2013 By Gabrie van Zanten Leave a Comment

A customer of mine, who was already running a vSphere environment on Cisco UCS blades, asked to expand his environment with a number of ESXi hosts that could run a VMware View environment. To be able to run as much View desktops on each host as possible, we offered them Cisco UCS Blades equipped with a Fusion IO card, the UCS 785GB MLC Fusion-io ioDrive2 to be exact.

For this customer I had already deployed a vSphere environment a year ago, fully based on VMware Auto Deploy and it now was time to try and add a driver to this Auto Deploy environment, which I had never done before. It wasn’t an easy road, but I wrote down all the steps and hope it helps you should you ever have to do this too. [Read more...]

Filed Under: Auto Deploy, esxi, storage, VDI, VMware Tagged With: add, autodeploy, driver, fusion io, VDI, vib, view, VMware, zip

The Doctor is IN on SRM, Upgrade to vSphere 5.1, vCSA and VCAP-DCA

7 June, 2013 By Gabrie van Zanten Leave a Comment

A few days ago I blogged about my new idea in this post: “The Doctor is: IN” and I received a lot of positive comments and even my first request for assistance. So… here we go !!!

Tonight ( June 7th ) at 19:00 CEST the first session will go live. That is, if Google Hangouts works because last night during my test run there were some issues with Google Hangouts.

This first session has been requested by Ryan Conley. Ryan is originally from Nashville area, moved to Greenville for two years which is where he got his feet wet with ESX/ESXi 4.x and 5.0. He took a position in San Francisco over a year ago and is now the primary person for managing two vSphere 5.0 clusters for two separate companies. He passed VCP5 in April and as a result of the prep time he is now hooked on learning more and more. He has his IaaS exam scheduled for the 17th of June and plans to attend VMworld in SF and sit the VCAP-DCA exam since it will be 75% off. Work wise he is about to standup a DR cluster in SF and begin implementing SRM to tie the two together. [Read more...]

Filed Under: esxi, Live Blog Tagged With: chat, design, help, helpdesk, srm, support, vcap-dca, vcsa

The Doctor is: IN

3 June, 2013 By Gabrie van Zanten 1 Comment

Many of us in IT read a lot of whitepapers, blogposts, how-to articles and view numerous Podcasts or training video’s to learn all the details about new products or features. Still, I don’t always get some of the details or can’t find the info I need. Meeting people at VMUGs or VMworld gives me the changes to ask for those last missing piece of information. But what if you don’t have that chance?

The Doctor is IN

When I blog about stuff I’m sometimes surprised about the comments I get and about how more people than I thought were struggling with the same questions. In responds to the comments I have been able to help quite a number of readers of my blog by e-mail and lately I did a few Google Plus Hangout sessions to help in an even better way. And that is when I came up with the following idea: Why not do a video-chat help session? [Read more...]

Filed Under: esxi, Guides, vCenter, vCloud Director, VMware Tagged With: chat, design, help, helpdesk, support, vCenter, vcloud, VMware, vsphere

[Review] Stormagic SvSAN 5

11 December, 2012 By Gabrie van Zanten 5 Comments

In November 2009 I already did a review on StorMagic’s SvSAN and was then very pleased with the product. Now, three years later I’m again reviewing SvSAN and am anxious to see if in those three years SvSAN has improved.

The Concept

For those not familiar with StorMagic SvSAN I will shortly explain what SvSAN does. With SvSAN you will be able to use the local disks of one or two ESXi hosts and present that local storage as shared storage to your ESXi environment. By mirroring the storage between two ESXi hosts, SvSAN is protected against a single host failure. The following diagram shows how on each ESXi host a SVA (Storage Virtual Appliance) is installed and how the local disks are connected to the SVA and then mirror and presented to the whole vSphere cluster over iSCSI. Should the ESXi host holding the SVA with the primary mirror fail, then the second SVA will present the datastore to the ESXi hosts in the cluster.

SvSAN 5.0 has been certified with vSphere 5.1 and 5.0 hosts, if you’re still on vSphere 4.0 or 4.1 you should use SvSAN 4.5. With that certification comes support for (of course) VMware HA and VMware VMotion, because that is where this was all about in the first place, but now VMware Fault Tolerance is supported as well.

The smallest deployment is an environment with just two ESXi hosts that each run the SvSAN Virtual Appliance and also run VMs on these hosts that use the storage offered by the SvSAN Virtual Appliance (SVA). If needed, more hosts in the environment can connect to the datastores and use them. In my home lab I have five ESXi hosts, two of them offer their local disk through the SvSAN as a datastore, all ESXi hosts are using the datastores offered by SvSAN.

Installation

The installation of SvSAN used to be very simple with version 4. Import the VSA as an OVF to the ESXi host, assign a network config to the VSA, install the vCenter StorMagic plug-in and start configuring your mirrored storage. In version 5, installation is even easier. First step is to install the vCenter Plug-in on the vCenter Server. Next you click on the datacenter and will now see an extra tab named “StorMagic”. From here you can start a wizard to deploy a SVA to an ESXi host.

The wizard will automatically deploy the SVA on the ESXi host in just a few steps. First you select the host on which to deploy the SVA and enter the root password. Next select the RDM or existing datastore which you want to present through the SVA. Next select which VMkernel portgroups you want to use for SvSAN. Per portgroup you can choose if it should be used for Management, iSCSI and/or Mirroring. When the wizard has finished you’ll see the OVF being automatically deployed. Just a few minutes later the SVA is running.

Next wizard is the one that creates a shared datastore. The steps again are very easy, just give the datastore a name and from both SVA’s you’ll see how much space is available and you select how much of that space you want to use for the mirror datastore. Select VMFS5 or VMFS3, select whether or not to use a neutral storage host and you’re done. The mirrored datastore will be created.

What is a neutral storage host?

A neutral storage host is used to avoid a split brain scenario in case there is a network outage. The SVA will use it to determine if it is isolated from the network should the other SVA become unreachable. A neutral storage host is NOT a requirement for a SvSAN deployment. Especially in small branch offices where you only want to deploy two ESXi hosts running SvSAN, it would be too expensive to add a neutral storage host (Windows Server) to the environment if that would be the only function.

Failover

The failover of the datastore works as flawlessly as it did before. I tested it by running iometer on a VM on the datastore presented by SvSAN. The VM was running in memory of a third ESXi host, not running any SVA components. I first ran a few iometer tests without interruption and then ran the same tests again and in the middle I hard shutdown the SVA.

The first test was run without interruption, the second test with interruption:

Counter	Test 1	Test 2
Total IOs per second:	143.08	119.70
Total MBs per second:	1.17	0.98
Average IO Response time:	417.6953 ms	508.2921 ms
Maximum IO Response time:	883.2917 ms	39038.1664ms
%CPU Utilization:	14.70%	11.96%

As you can see there is a Maximum IO Response time of 39038ms (39sec) which happened when I shut down the VSA. In other words, after the first VSA failed, the storage and normal VM function was restored in 39 seconds. Nice result.

Note: The disk performance you see here should not be used to compare performance of the SvSAN with other products since my test setup only contains one 7500 rpm disk per host.

Management

The wizards to help you set up the SvSAN properly already take away a lot of management tasks, but even when there is some extra management needed, the SvSAN is easy to manage. A big improvement has been made in this area. Adding extra hosts to use the datastore is very easy by just selecting extra hosts and then SvSAN will configure the iSCSI connections for you.

If you want to check the health of the shared datastore, you can get a complete view that shows the connected hosts, the active paths and the paths over which IO is running.

Comparison with VMware VSA

VMware now offers a similar product as Stormagic SvSAN, named the VMware VSA (vSphere Storage Appliance). The concept of the VMware VSA is the same: offering local disks as a datastore for your vSphere environment to enable VMware HA and VMotion features. Where SvSAN uses iSCSI to present the datastore to the ESXi hosts, VMware uses the NFS protocol. This post initially would be a comparison between VMware VSA and StorMagic SvSAN, but the hardware requirements for the VMware VSA are more stringent than the StorMagic requirements and I was unable to get the VMware VSA running in my home lab. See: http://www.vmware.com/support/vsa/doc/vsphere-storage-appliance-511-release-notes.html

Summary

With the release of SvSAN 5, StorMagic has proven that deployment and configuration of a cheap SAN solution based on local disks, can be quick and simple. Throughout the testing I often crashed the SVA on purpose and not once was there data corruption or problems with the failover. The remote deployment features that have been added make the SvSAN very easy to deploy in remote offices, a real addition to the previous version of SvSAN. For more info on StorMagic SvSAN visit their website at: http://www.StorMagic.com

SvSAN is available according to the capacity per server, i.e., in 2TB, 4TB, 8TB, 16TB, or unlimited capacity in each server, capacities can be mixed.

Filed Under: esxi, storage, VMware Tagged With: shared storage, StorMagic, sva, SvSAN

Strange DRS behavior during vSphere 5.1 upgrade

16 October, 2012 By Gabrie van Zanten 8 Comments

This week I upgraded a customer running vSphere 4.0 Update 1 to vSphere 5.1 when discovering a strange DRS behavior. My upgrade path was to first install a fresh vCenter 5.1 and then move the ESX 4.0 hosts into vCenter 5.1. Next step was to put the first host into maintenance mode, shutdown, remove from cluster, perform a fresh install with ESXi 5.1 and then add it to the cluster.

After the first host was installed with ESXi 5.1 and added to the cluster, I suddenly saw DRS moving virtual machines to that first host. Not just a few but a lot of VMs. The host got loaded to 96% and then DRS stopped migrating VMs.

Since performance was still good, I decided to put host number two in maintenance mode and continue the upgrade. DRS migrated the VMs from host number two to the remaining hosts and surprisingly enough also managed to add some more VMs to host number one, which had just gone from 96% to 94% memory load. By adding those VMs it went to 96% again. During upgrade of host number two I saw the memory load drop a few percent again and at that point DRS moved some more VMs to the number one host. When host number two was installed with ESXi 5.1 and member of the cluster again, DRS started loading that host too until it hit 96%. In the image below, host number three (vmw15) has just been installed with 5.1 and only just added to the cluster, VMs where starting to move to this host. [Read more...]

Filed Under: esxi, vCenter, VMware Tagged With: drs, upgrade, vsphere 5.1