HIT for Windows under vmware?

So all the utilities in HIT for windows can be run safety inside a Windows VM under vSphere environment? Does ASM/ME support SQL Server running under vmware too? The manual only mention support for physical and under hyper-v, not vmware.

An EQL Volume should be protected by an ACL so only a specific Hosts can get access. When speaking about VMware multible Hosts connecting to the same volume but not an foreign Host!.

The NTFS Volume you will created is dedicated to the given Guest VM. The VMware Hosts would never see or use this volume.

Regards,

Joerg

Yes, they can run safety within a VM. We use this setup for more than 4 years now for VMs with special requirements. It doesnt matter if its a VM or phys. system.

No, the Hit KIT VE does not support SQL or any other Application "directly" or in the same way as ME. Part of Hit Kit VW is MEM and VSM (Virtual Storage Manager formaly known as ASM) and the later one acts with VMs. Together with VMware Tools and their VSS integration you will get an consistent state for Backup/Cloning but no tight integration for enterprise application like exchange or sql.

Regards,

Joerg

My main concern is having Windows attempt to write NTFS entry into Equallogic volume that has been formatted as VMFS for the Windows VM host and end up corrupting the whole volume, which we have previously experienced when using a software SAN solution. Thus, we want to ensure that this won't happen if we let Windows see the VMFS volumes thru Microsoft iSCSI, which I believe is required for HIT utilities to function inside Windows right?

To be clear, the OP should note that the HIT/ME is only useful when the VM has additional volumes that are connected to the SAN array via iSCSI guest attached volumes.  So the benefits that it does add (great integration with the OS's VSS) also comes at a cost.  Guest attached volumes are not visible from the perspective of vCenter.  Thus, if you are using a commercial backup application, etc that leverages the vCenter API, it can't protect it because it can't see it.

I have implemented a number of systems with guest attached volumes in Windows and Linux.  (I've written about it quite a bit at http://vmpete.com) It was a great way to help mitigate the shortcomings I had with my environment at the time.  However, I will say that there is significant administrative overhead especially in terms of looking at your big picture protection strategy.  For that (and many other reasons), I've been in the process of moving these guest attached volumes back to native VMDKs.  

Could I conclude that to ease management of my vSphere VMs, I should avoid direct connection of EQL volumes into them? Thus, making HIT/ME for Windows useless?

Or does HIT/ME for Windows has any other use without a direct connect to EQL volumes that are VMFS formatted?

Application and/or file quiescing is a bit of a sliding scale.  A lot of factors come in to play.  Most significant are the version of the Windows OS, and the version of the hypervisor you are on.  It’s also important to distinguish the difference between file level quiescing, and application level quiescing.  With that said, you have full application aware processing of backups with Veeam.  Any old discussions around that usually related to much older versions of the OS, the hypervisor, or the backup software.  It’s easy enough to test and validate - something I did before moving away from guest volumes and HIT/ME.

One of the main reasons is that I am not able to use veeam to backup some of our SQL servers due to VMware Tools unable to quiesce the guest file system. Was hoping that EQL snapshot for SQL server can fulfill this backup instead. But it appears that this is only supported if we map the EQL volume directly into our SQL server?

The short answer is that yes, that is a correct statement.  I think it is deserving of a longer explanation.  Let me preface that a lot of what I say comes not only from knowing the capabilities of the product well, but using those capabilities in a production environment for many years.  I know what it does well, but I know the shortcomings also.  I’m simply sharing my experiences.  

We all love virtualization in part because it abstracts out any understanding the OS has on the underlying hardware it lives on.  When you start using guest attached volumes, you are moving away from hypervisor and vCenter centric functionality and moving toward in-guest functionality.  It doesn’t seem like it at the time, but you are creating an indelible tie between where the data is located, and the system serving up the data.  So the shortcoming of guest attached volumes are not directly related to a feature lacking, or not being provided for by Dell EqualLogic, but rather, the increase in complexity of your own workflows when it comes to protecting your data.  (see vmpete.com/.../hunting-down-unnecessary-io-before-you-buy-that-next-storage-solution )

For instance.  HIT/ME does a superb job of quiescing applications and the flow of data, since it has VSS writers for Exchange, SQL, and NTFS.  It is wickedly fast, and east to restore, clone, etc.  So with that said, you create a fully application aware snapshot, which is fantastic, yet you still have to deal with how you will just protect these volumes off your group of arrays (whether it be to tape, offsite, etc.).  This typically results in doing trickery with a backup media server.  Mounting snapshots and doing file level backups, etc.  But again, it complicated the workflow, because it was only protecting the guest volumes, and nothing else.

I’m also uncertain as to the future usefulness that guest attached volumes once had over native VMDKs.  Back in the day, they were really helpful for a number of reasons:

1.  Multipathing for improved performance

2.  Good application/filesystem quiescing courtesy of working with the guest OS’s VSS writers.

3.  Large (greater than 2TB) volume support

But times have changed, and so has the hypervisor.  Multipathed vmkernel connections have been around for a while.  And each newer version of Windows with each newer version of vSphere offers better and better OS and application quiescing support.  Lastly, while the ~2TB limit for a VMDK is still around, don’t expect this to be the case for too much longer.  The demand is way too high for this to be overlooked by VMware.

Don’t get me wrong.  I’m a big fan of the Dell EqualLogic portfolio of solutions, and will continue to buy more as needed.  However, when it comes to coming up with a sustainable/manageable protection strategy for your virtualized environment, I say, let something that hooks into the vSphere API take care of it, and call it a day.  Have your protection live on some affordable storage outside of a failure domain.

Crescendas,

Yes, in order for ASM/ME to work and provide all the quiescing the MS iSCSI initiator will have to connect to the volume.  You can't use it on a VMFS/VMDK, or RDM.  

Yes, using HIT means a little more work on a DR scenario.  I would counter and say what do you do more often?  Restore a mailbox or want to protect a database, create a test copy of your SQL data and mount it on another SQL server, or failover to you DR site?    DR failover for most people is a once in a lifetime process.  Recovering data from your DR site is much more common.   At least in my experience.  

Also guest connected volumes can levearge transportable snapshots, where the backup server will run back from a EQL snapshot, completely bypassing the ESX server.   Providing a faster backup, and something that can be done at anytime during the day without impacting the ESX host.