iSCSI software initiators inside your Windows VM’s

[heybuzzz]

Do any of you guys use iSCSI software initiators inside your Windows VM’s to connect say a local d:\ to your NAS?

I keep my VM’s on the San, but sometimes get requests to add huge data drives. I really don’t like/want to add another huge drive and keep it in the same .vmdk on the SAN and I don’t want to RDM the drive as a new LUN. So one of my local support guys said to just load an iSCSI software initiator inside the VM and have it connect to my NAS for say a 200 gig D:\. I mean it’s defiantly cheaper then using up SAN space and it seems a lot easier then having lots of RDM LUNs I would need to keep up with. Do any of you guys run this kind of setup for additional drives? Also, I assume it’s all VMotion aware?

My setup is: Enterprise 3.0.1 HA/DRS/VMotion enabled.

Thanks Guys!!!

[lamw]

I've worked with both having an RDM for your external drives and also having additional storage drives as a large .vmdk (there's a tradeoff/benefits in doing either setup). If you're looking at Windows's base iSCSI Initiator, you can look at Microsoft's free version, there's other versions but it works just fine. As long as the target's are presented and seen by your VM, you should be able to connect to your external storage.

[heybuzzz]

Yeah, I'm looking at Microsofts free version.

So basically, I would then have my 10 or 15 gig Windows Server OS and App in a .vmdk on my SAN. Then inside I use software iSCSI from microsoft that points to my NAS and allocate out say 200 gigs. Also need it to work with my HA/DRS cluster.

Defiantly NOT try to RDM the additional drive...

[lamw]

Yep, just setup an iSCSI target for that 200gb drive, export it out and make it visible to your VM. HA/DRS will function, that functionality is more for your VM ... doesn't deal with your iSCSI target unless you lose connectivity to your network. The only caveat to using iSCSI sw initiator is that it chews on more CPU and if it's in a VM, you might need to allocate an extra vCPU unless the traffic is not too high. Usually if you have a large iSCSI requests, you usually offload that to a hw initiator HBA that has TOE built in, to offload that processsing from your CPU to card. Depending on the number of VMs you have on your host and how much processing this individual VM will require, will let you know through the long run if it'll run efficently. If it's a small setup of VMs, you should be fine but testing will determine that.

[heybuzzz]

Thanks, those are some things to consider.

Anyone else doing anything similar?

[5474]

Yes, we doing exactly that.

The OS itself is connected over the ESX 3.5 software initator, but if the server needs any addtional

LUNS then we carve that out of from our Equallogic and connect to it inside the VM using the MS

initiator. It works really well, one of the things I really like is in an emergency I can connect to that

LUN from anyware using the software, inside ESX or not. Seems to work really well.

[heybuzzz]

"The OS itself is connected over the ESX 3.5 software initator" Little confused, so you mean that your .vmdk's are hosted on the equalogic device? Thanks

[lamw]

It mean's he's hosting his Virtual Machine on a SAN that's being connected via iSCSI using ESX built in Software iSCSI Initiator (again caveat, high load or many VMs will tax your CPU cores to provide reduced resources for allocating additional VMs without using a dedicated iSCSI HBA w/TOE). On top of that, the Windows machine that's going over iSCSI also can connect to external storage within the VM by using the Microsoft SW iSCSI Initiator, this external storage can be from any setup that can present the iSCSI Targets. We have the exact same test setup and it works great.

[heybuzzz]

Gotcha....

[happyhammer]

and dont forget if you are using EQL then you can use the auto snap manager with this setup to VSS SQL and Exchange Databases and replicate them

[Cotay]

One important thing to remember: If you format this volume NTFS, you cannot connect to it with multiple iSCSI initiators at the same time. Unlike VMFS, NTFS has no filesystem locking mechanism that can support this. Equallogic is support to have new documentation that makes this a lot more clear.

We had this same setup and tried to bypass LAN for our backups. We added another iSCSI initiator on our backup server and we ended up with major data corruption on the MFT of the volume. As long as you stay away from this, it works great.

[heybuzzz]

Yes, I plan on formating it NTFS so it'll basicall just be a large data drive instead of using the same amount of space on the SAN. And since it will just be for that Windows server instance I think it should be ok in regards to your post.

I assume you can still map to it and copy data back and forth just like if it was local storage on a physical box or the primary .vmdk on a VM?

[happyhammer]

Cotay

you should snapshot the volume and mount the snapshot to the backup server, i believe most backup software will do this automatically and then unmount and remove the snapshot

[Cotay]

happy - I would love to do this. Our backup server currently runs vRanger/VCB for image level and Symantec BE 12d for file/brick level restores. This server is zoned to our Equallogic arrarys via the MS iSCSI initiator. Is this possible to backup a mounted snap with this setup?

[5474]

Your BE12 should have open file options including using VSS. That will basically snap the volume and then use that for the backups.