Solved

Storage Snapshots for an extremely isolated server. Am I breaking the rules?


Userlevel 7
Badge +3

Interesting Scenario here.  I have a VERY isolated environment separate from my production environment.  The SAN is the only thing that shared between environments. No networking at all.

 

Is there any license wizards in here who could tell me if this is supported, or if the following would be against the Veeam license rules?

 

 

In this isolated environment we don’t have Veeam.  We are in the process migrating all of those servers to our production environment , but I’d like to archive one to tape before hand to free up 50TB


If I were to do a storage snapshot of the VM’s volume from within Veeam (Same SAN) , I could then run an instant recovery to our production environment. While its running from the Storage Snapshot in our production environment, I’d like to do a VeeamZip, then export it to tape from the VeeamZip.

 

It should be no different than exporting to OVF and importing it into production from vCenter which wouldn’t be against any license rules and it does save me moving 50TB 2 times.

 

I feel like this is a grey area and just wanted to make sure I wasn’t breaking the rules as the host the VM runs on isn’t licensed for Veeam, but technically I’m not touching that host in the process. It’s just a obscure way of moving it to production, then getting rid of the VM. 

 

As stated earlier, these hosts are being decommissioned and all of the VM’s will be migrated to our fully supported environment. I just like to be fully compliant at all times when it comes to licenses. 

 

 

 

icon

Best answer by Mildur 3 October 2022, 19:35

View original

15 comments

Userlevel 7
Badge +8

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.

Userlevel 7
Badge +8

Simple question:

VUL or socket license?

Userlevel 7
Badge +3

Sockets for my entire production 

Userlevel 7
Badge +3

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.

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 🤣

Userlevel 7
Badge +8

Sockets for my entire production 

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...

Userlevel 7
Badge +5

VeeamZIP does not consume licenses.

So you should be safe from a licensing perspective.

 

Thanks

Fabian

Userlevel 7
Badge +3

Sockets for my entire production 

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...

 

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. 

 

 

 

Userlevel 7
Badge +6

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.

Userlevel 7
Badge +3

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.  

 

 

 

 

 

 

 

 

 

Userlevel 7
Badge +3

Sockets for my entire production 

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...

 

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.

Userlevel 7
Badge +3

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.

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.

Userlevel 7
Badge +3

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.  

 

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.

Userlevel 7
Badge +6

Sockets for my entire production 

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...

 

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.

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

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. 

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.

 

Userlevel 7
Badge +3

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.  

 

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.

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. 

 

 

Userlevel 7
Badge +3

Sockets for my entire production 

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...

 

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.

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

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. 

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.

 

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. 

 

 

 

 

Comment