I cannot see how you are breaking the licensing rule since you are just doing a one time backup of the VMs and then they will not be used again which then shifts the licenses back to PROD for use there.

Simple question:

VUL or socket license?

Sockets for my entire production 

I agree with this.  If I were to export the OVF from VMware, and import it to production, that is allowed as well.   I’m basically just using Veeam to do this task. 

It just seems weird, because I’m also technically taking a backup of a VM, where Veeam hasn’t been licensed to the environment, so for a very brief portion of this process, perhaps that wasn’t how it was supposed to be designed.

I actually have extra sockets I could attach, however, that environment is so isolated my Veeam server can’t talk to it haha

Socket licenses could be an issue, because the sockets of the isolated environment are not licences then…

With VUL I think it is not a problem...

This is a good question for your Veeam sales person...

VeeamZIP does not consume licenses.

So you should be safe from a licensing perspective.

Thanks

Fabian

VUL makes sense, however, my production environment is licensed, and the ability to do a storage snapshot on the SAN is allowed.    What’s to stop me from moving that volume to my production environment and doing the same thing? or doing a cross vCenter vMotion before backing up the VM? or exporting and importing it.

This is why it’s a grey area. Obviously adding a host to Veeam and backing up requires a license, restoring from a storage snapshot that is not mounted to production to production has not come up before.  It’s a tricky one.

Due to how much we pay Veeam , how many sockets we have, and the fact that these WILL be moved to production, I’m going to go out on a limb and say they will most likely allow it. I would like to hear from Veeam their perspective though. 

I’m not trying to bend the rules even, this isolated environment is just so difficult to work with, I’m not sad to see it go!.

It took explaining how storage and VLANS work to some very not technical people to understand we can make their lives easier without this silo. 

If your about to migrate the VMs to your production hosts, and if those hosts already see/access the same storage, why don't you just re-register the VMs in your production environment? You can still take a backup/VeeamZIP afterwards.

The volumes are mapped to a different host cluster on the SAN.

Totally separate environment.

I recall something about separate clusters can not see a VMFS datastore created on another cluster / vCenter. I tested to see and I was able to map the volumes but it looked like an empty fresh volume with no VMFS datastore in it.  

To be fair….you could be using a complimentary VUL included with perpetual licensing, which would be a likely loophole where I’d say this would be okay.

I was wondering this as well.  If you have two hosts (or clusers) that all see the same storage, I’m not sure why you wouldn’t be able to unregister the VM from the old host, and reregister it on the new host.  We’ve done migrations like that before.  Obviously, there’d be a new level-0 backup happening on the new cluster, but since nothing is shared, I’m sure that’d be the case anyway.  Unless I’m not understanding the infrastructure configuration here.

Edit:  Nevermind…..the volumes aren’t presented to both clusters...some volumes to on cluster, others to the other.  In that case, you could still unregister, remove the volumes from the old hosts, present to the new hosts, mount the volumes (but don’t overwrite/format them) and then register the VM’s.  A bit more messy, more room for error, and may or may not be possible if there are other VM’s on the datastore and if they can or cannot be taken offline at the same time.

Okay, yeah, that’d be an issue if the volumes aren’t presented to both clusters.  And since the clusters don’t talk to each other, that could be an issue as the second cluster to connect to the volume is going to see those as foreign datastores.  I’m not sure off the top of my head if it’s going to like that…..you can probably mount the datastore without resignaturing, but I think you’re really opening up yourself to datastore corruption.

This won't work unfortunately. When using socket licenses, the free/gifted instances can't be used for VMs.

Well it's not a good idea for production use to mix datastores between independent clusters. But for migration it would be OK. Unregister the VMs at the source hosts, shutdown the hosts and then present the datastores to your production environment.

What makes me wonder is, why would you see an empty datastore. If the VMFS versions are compatible and supported, the production hosts should see the datastore. If it shows empty then don't try to format them as this would wipe the data/VMs!

Talking about storage snapshots, you could present that one to your production host and register the VMs just for the backup. That way you don't mess anything in the source environment.

Just to test, I spun up a test volume on the the isolated cluster, created a VMFS datastore, created a VM, then unmounted it, attached it to production and as suspected, it showed up as a blank empty datastore.   

 I figured it would be like attaching a windows LUN to a new server and importing.  After a rescan it didn’t see the VMFS partition and looked like a raw LUN. 

Due to the fact there is about 50TB of data on this VM I don’t want to risk it either. It is pretty serious data I have to keep for 60-100 years of retention due to the insane policies I deal with. 

I tried taking a storage snap and presenting it as well :)

Perhaps it’s the change from 6.7 to 7.3 VMware giving me grief, but they are both VMFS6. 

I can’t upgrade this environment from 6.7 due to the old hosts.  My “work around” solved my problems, and is my reason for doing it the way I did.