VMware vSAN iSCSI use case?

In a previous post I went through a list of my personal favorite features in vSphere 6.5. VMware vSAN is on of them, it’s a storage solution that handles your virtual machines – amongst others as we shall see today.

One of the nicest features introduced for vSAN in vSphere 6.5 is the ability to attach physical servers to the vSAN cluster. By letting the vSAN handle the iSCSI volume, since it’s just another object in the vSAN, you can apply the same policies on that volume as you do on the vSAN datastore used for you virtual machines. And that means you’re able to manage the performance and/or availability, not just when initially setting up the volume but any time the requirements change for the volume you’re able to adapt.

So is it hard setting up vSAN with iSCSI targets and attaching physical servers to it? Not at all, it’s quite easy actually. Let me show you how easy it is. But first we have to create a vSphere cluster with vSAN enabled and configured. Now, I’m a big fan of PowerCLI and automating a lab environment set-up is thanks to William Lam a breeze. I’ve adjusted his script slightly to allow me to select 3 different sizes of the ESXi hosts to choose from: small, medium or large. This allows me within 30 minutes to have a lab consisting of 3 ESXi hosts and a vCenter appliance up and running, configured with a cluster and vSAN enabled. The medium and large size configurations would normally be used for VMware NSX labs and demos.

It might not be the intended use case, but wouldn’t it be fun to host virtual machines from a Hyper-v environment on a vSAN? ”Why?” I hear you say, no reason, just because we can!


So first thing is to execute the PowerCLI script to bring my lab environment online:

Logging on to vCenter will now show the three hosts in a cluster with a new datastore created, a vSAN datastore.

Next, we need to enable the iSCSI functionality, which is a simple process:

Enabling the Virtual SAN iSCSI target service requires some input, specifically

  • Default iSCSI network to use – in a production environment you’d probably want to set up a dedicated VMkernel iSCSI interface for this.
  • Default TCP port – usually no need to change this
  • Default authentication – If you’d like you can set up the connection to use either None, CHAP or Mutual CHAP
  • Storage Policy for the home object – Using the predefined storage policies you can have the home object that stores metadata for the iSCSI target protected for host failures

If you want, you can create a new policy with specific settings for iSCSI Targets and Home object:

The default vSAN storage policy is used.

It protects you against one host failure, to do that it will have the object placed on two different hosts. This means it will use twice the space assigned to an object/VMDK file from the vSAN datastore.

Next up, creating a target and LUN:

You create both the Target IQN (with the desired settings and policies) and a LUN. Depending on the LUN Storage Policy you are using you will consume space from the vSAN datastore accordingly:

Now the set-up of the Target and the LUN is done. It’s that simple! After this point you can attach any physical server using iSCSI to the vSAN datastore and use the resources. In my lab though, I’m going to use a virtual machine from another host to emulate a physical machine.

You probably don’t want just any old server being able to attach to the LUN, so you can configure which initiators are allowed to connect. Either use individual IQNs or create a group of IQNs.

Let’s take a look what has happened on the vSAN Datastore:

We can now clearly see that there’s a new VMDK file that we can handle just as any other VMDK file, inflate it, move it or delete it:

Next up: Creating a Windows Server 2016 VM (emulating a physical machine) that will connect and use the new vSAN LUN we created. 

Setting up the VM is pretty straight forward.

Select the desired OS:

Here’s where we need to make changes, first assign at least two CPUs to the VM and secondly tick the box for hardware virtualization (otherwise the role Hyper-V won’t be able to start or be installed).

The summary page shows us what settings we’ve selected for the VM

We run through the installation of the operating system. Configure everything we need, a static IP address, updating windows and so on:

OK, Windows Server 2016 is ready to be used, let’s configure the iSCSI connection:

Yes, we’d like to start the iSCSI service:

Again, in a production environment you’d probably want to have som fancy stuff set up such as MPIO and so on but for this test we’ll just do a quick connect to the iSCSI target:

Oh, but what IP address should I use? The host that is responsible for the I/O to the LUN can be found on the configuration page of the iSCSI Target:

We connect Windows to the I/O Owner host:

We have a connection, all is well:

Open up the disk management tool and a new disk should be available (if not, try a rescan). Bring the disk online, initialize it and format it:

Give the volume a name:

Now the volume is ready to be used:

Hyper-v will now be installed on the Windows Server 2016 machine:

Add the required features and tools

Configure a virtual switch for Hyper-V

Now we can actually leverage the newly created vSAN volume and use that as the target for our Hyper-V virtual machines:

A simple test to confirm that it actually works, creating a virtual machine for Hyper-V running off of the vSAN volume:

Go through the wizard, give the VM a name and so on.

Choose what generation the VM should be created as:

Select a network connection if needed

Set the size of the virtual hard disk.

Select an iso-file to be used when installing the OS in the Hyper-V virtual machine

Done, just hit finish

The VM is created, start it and connect to it to get the console view

Install the operating system and update it, configure it the way you want it

Now we’re running a virtual machine in Hyper-V with it’s disk being handled by VMware vSAN! Pretty cool.

Now we can go back to see what impact, if any, installing the operating system had on consumed space on the vSAN volume:

As you can see, the VMDK file containing the Hyper-V volume has grown that’s just as we expected.

There you have it! It’s very, very easy to set up vSAN to use iSCSI – why not give it a try yourself?

VMware vSAN rapporterar att kapacitet saknas

Förra veckan lanserade VMware vSAN – Ett SAN, det vill säga gemensam disklagring för flera hostar, utan att det krävs någon speciell extra disklåda som ska installeras i ditt datacenter. Ett virtuellt SAN helt enkelt. VMware vSAN gör det möjligt att använda funktioner som High Availability, vMotion och DRS på dina virtuella maskiner genom att utnyttja de diskar som sitter lokalt i servrarna. Det behövs inga speciella virtuella appliances som ska installeras på hostarna heller – vSAN är integrerat i hypervisor så det enda man behöver göra för att komma igång är att klicka i en bockruta.

Det går utmärkt att test i en virtuell miljö, man behöver tillgång till senaste versionerna av ESXi och vCenter som släpptes förra veckan (åtminstone om man vill testa GA versionen). För att testet ska gå att genomföra i en virtuell miljö kan man ”emulera” en SSD disk, vSAN kräver nämligen att det finns en SSD disk i hosten samt ytterligare SAS/SATA diskar som kan nyttjas. SSD disken används för prestanda accelerering. När man sätter upp vSAN genom att bocka i vSAN rutan i clusterkonfigurationen så skapas automatiskt en ny datastore ”vsanDatastore” som utnyttjar de lokala diskarna i hostarna, men man kan råka ut för att man får en varning på clustret som säger:

vsan datastore datastore1 in cluster **** in datacenter **** does not have capacity

Tittar man i release-noten för vCenter 5.5 Update 1 så hittar man felet och dessutom ganska nedslående workaround som beskrivs:

The error message continues to persist even after disabling Virtual SAN on the cluster. The issue does not occur if there are one or more disk groups created for a Virtual SAN cluster before disabling Virtual SAN on the cluster.

Workaround: None.

Oavsett om man använder automatisk eller manuell konfiguration får man samma fel. Detta är möjligtvis ett legitimt fel i vissa scenarier och miljöer men det kan också vara en felkonfiguration man råkat göra som administratör där man förbisett några krav för vSAN. Kravet är att det ska finnas minst en SSD disk (som man i en virtuell miljö kan emuleras genom att lägga till scsi0:1.virtualSSD=1 i konfigurationen för den virtuella ESXi hostens disk som ska användas för SSD emulering). Och det ska även finnas en vanlig disk utan någon ytterligare konfiguration. Hosten har alltså 3 diskar: 1 för vSphere installation, en för SSD emulering (prestanda) och ytterligare en som vSAN använder (kapacitet).

Nästa krav är att diskarna ska vara oanvända, d.v.s. de ska inte ha en aktiv datastore redan. Och det är just detta kravet som kan ställa till problem. Om diskarna redan har formaterats och är tillgängliga som datastores för hosten kan man få ovanstående fel, som ju egentligen inte är ett fel utan helt enkelt betyder att du har redan använt dina lokala diskar till annat så vSAN får ingen diskyta kan användas.


  1. Disabla vSAN
  2. Kontrollera att ingen information ligger på de datastores som ska användas till vSAN – se till att det inte är disken du använder för vSphere installationen.
  3. Välj delete och frigör diskarna så vSAN kan claima dom. (Görs på samtliga hostar i clustret som ska användas för vSAN)
  4. Aktivera vSAN igen

Sen bör du ha en vsanDatastore volym som du kan använda och vSAN har claimat tillgängliga diskar i clustret.

VMware lanserar vSAN

Idag har VMware lanserat vSAN, virtual SAN, som är deras lösning för att förenkla och förbättra lagringshantering. VMware vSAN gör det möjligt att lagring dina virtuella maskiner på lokal disk som sitter i servern, vSAN ser därefter till att göra kopior av alla inblandade filer och flytta dom till andra hostar och därigenom tillhandahålla redundans om den ursprungliga hostar fallerar.

Med andra ord, dina virtuella maskiner kan flyttas med vMotion, de kan skyddas med High Availability, lastbalanseras med Distributed Resource Scheduler utan att ha en fysisk gemensam lagringsmiljö, SAN. Det räcker alltså med de diskarna som sitter i servrarna. Och vSAN är en integrerad del av vSphere plattformen, för att aktivera och börja använda vSAN räcker det med ett par musklick för att vara igång – eller som VMware uttrycker det ”Two-Click Storage Provisioning”.

Vid lanseringen idag offentliggjorde man 2 väldigt intressanta saker:

  • VMware vSAN kommer att finnas tillgängligt i nästa vecka i GA version, d.v.s. produktionsfärdig
  • Man kommer redan från start att stödja 32 hostar i ett vSAN kluster

En av funktionerna man får med vSAN är möjligheten att specificera hur många kopior man vill ha av sina VMs, vill man ha 4 kopior av en VM är det bara att ändra policy och då skapar vSAN själv fler kopior av de virtuella maskinerna och flyttar dessa kopior till olika hostar. Man har i policyn även möjlighet att ange vilka prestanda man önskar på de virtuella maskinerna – hur många diskar den virtuella maskinen ska stripas över.

Utökning av vSAN kan göras på olika sätt: Scale-up eller Scale-out. Antingen kan man addera fler diskar i hostarna eller så kan man addera fler hostar till clustret.

Låter det bra och vill du veta mer? Kontakta mig.