When you enable Virtual SAN on a cluster, you must assign the cluster an appropriate Virtual SAN license before the 60-day evaluation period expires.
License capacity and usage for Virtual SAN
Similar to vSphere licenses, Virtual SAN licenses also have per CPU capacity. When you assign a Virtual SAN license to a cluster, the amount of license capacity that is used equals the total number of CPUs in the hosts that participate in the cluster. For example, if you have a Virtual SAN cluster that contains 4 hosts with 8 CPUs each, you need to assign the cluster a Virtual SAN license with a minimum capacity of 32 CPUs.
The license usage of the Virtual SAN cluster is recalculated and updated when:
You must maintain the Virtual SAN clusters in compliance with the Virtual SAN licensing model. The total number of CPUs of all hosts in the cluster must not exceed the capacity of the Virtual SAN license that is assigned to the cluster.
As per me, you need to purchase vCenter/ESXi licenses separately.
Welcome to the Community,
VSAN is an Add-On/Feature, and has to be license in addition to the vSphere licenses (i.e. vCenter Server and CPU licenses). It however contains a "vSphere Distribute Switch" license, so you don't need to purchase Enterprise Plus licenses for the ESXi hosts. see e.g. http://www.virten.net/2014/03/vmware-virtual-san-licensing-and-pricing/
We've went through and purchased and applied our VSAN license but when we try to apply our Vsphere license (bring it out of evaluation mode), it won't let us because we are using VDS. Since it is included with VSAN, why are we receiving this error?
Do you receive an error message complaining about features being used which are not included in the vSphere license? I'd actually consider this a bug, and suggest that you open a support case with VMware.
Yes we are receiving an error message complaining about features. We have opened several tickets but so far it has been 4 frustrating hours of the Licensing and Technical team telling us that VDS isn't included in VSAN. :smileyangry: We are waiting to hear back from the VSAN Sales Lead to confirm that VDS is included with VSAN. Maybe then we can make some progress.
Thanks for the reply and hope.
Did you send them the link to VMware Virtual SAN Now Available with shows the VDS in the Pricing an Packing table and also states:
"... All editions feature the complete set of Virtual SAN capabilities – data persistency, read/write caching, storage policy based management, etc. – and include the vSphere Distributed Switch..."
Well I'm glad you asked because I wasn't going to bring it up. We were actually told on the phone by a licensing department supervisor that this blog post and another we had found were incorrect. Our jaws dropped trying to comprehend this response.
I just heard back from VMWare and they are still denying that VSAN comes with VDS even though its very clear from their website that "All editions feature the complete set of Virtual SAN capabilities – data persistency, read/write caching, storage policy based management, etc. – and include the vSphere Distributed Switch. This means that customers can take advantage of simplified network management of vSphere Distributed Switch for their Virtual SAN storage regardless of the underlying vSphere edition they use."
I'm not sure how far up the food chain I am going to have to fight to get this taken care of but if there is a better (easier) route to take, I would really appreciate hearing it. I am open to any suggestions.
We had the same problem.VSAN definitely includes the distributed vSwitch (we use Essentials Pluslicense + VSAN + distributed vSwitch).
Solution: you have to delete the distributed vSwitch, add the vSphere license (without deleting the distributed vSwitch this would fail if using any other license than Enterprise+),
add the VSAN license and reconfigure the distributed vSwitch.
It looks like VMWare has finally came to its senses but we aren't quite through the mess yet. In order to comply with VMWare licensing, we had been migrating all of our servers over to the new Vhosts while in the evaluation mode. So now we have all of our production servers on this cluster that is using VSAN + VDS. I'm crossing my fingers that there is a bug fix being worked on OR a way for an engineer to do some magic through the CLI to get this corrected. How disrupting and risky is it going to be to our VSAN Datastore to remove the VDS that our VSAN uses?
We had to migrate the VMkernel adapters and portgroups from the distributed to a standard vSwitch on each host.
Then we deleted the dvSwitch, added the vSphere license, then added the VSAN license and finally recreated the distributed vSwitch.
I know this is painful but at the moment I have no other workaround. Open for ideas...
Did you have to take down the whole cluster to do this? If so, could we just put all 3 hosts in maintenance mode, remove the VDS then re-license and recreate the VDS without having to create the standard vSwitches? Our managment network is on a standard vSwitch.
If you didn't have to take the whole cluster down, were you able to put 1 host at a time into maintenance mode and remove it from the portgroup and place them onto a vSwitch, and then rinse and repeat for the others?
Thank you for your help. You have been the one person I have found that has actually ran into this same issue. Hopefully this thread can help prevent some of this pain from happening to others. Who would have thought something as innocuous as the order you apply your licensing could become such a burden.
If you have the possibility to shutdown the whole VSAN cluster, then I would do so (depends if your vCenter is running on VSAN).
If not, then put each host after the other into maintenance mode ("ensure access" mode) and change the VSAN - VMkernel to the Standard vSwitch.
You could also do a live migration of the VSAN VMKernel from the distributed to the standard vswitch - I think there will be only a short network outage when migrating a VMKernel.
Yes I fully agree - this is a stupid bug. It happened once to us, now we know to activate the vSphere license before creating a distributed switch in combination with VSAN.
We also leave the Mgmt and VSAN VMkernels on seperate NICs/vSwitches and not on the distributed vSwitch - but we use 1G NICs.
The workaround in this case is to remove the host from the switch (the VDS shouldn't be in use), assign the license which edition doesn't include the feature VDS e.g. Essential or Essential Plus and add again in the virtual switch - the feature is allowed because of the vSAN configuration. We’re working to fix this behavior and improve the user experience.
Please, let me know if any questions.
Yes, exactly. I tested using the following steps:
1. vSAN is created and licensed, the host is moved to the vSAN cluster and it's in evaluation, the vDS is configured and the host is added in it - it's your setup, isn't it?
2. Go to the DSwitch ->Related objects -> Hosts and remove the host from the current distributed switch
3. Assign the license to the host - the edition is Essential
4. Return to DSwitch and open Add and Manage Hosts wizard -> Add a host
5. The licensed host is added in DSwitch
But if the VSAN Kernel is on the dvSwitch (like in this case), you cannot just delete the dvSwitch.
Would it be save to migrate the VSAN Kernel to the standard vSwitch without putting the host into maintenance mode?
Well we are finally licensed! We had some serious issues one night because of some recommendations we received that included creating a second vmk for VSAN traffic.
We did have to migrate the VMKernel for VSAN off of the VDS before we were able to license the host. We may have ran into a bug while doing this step. We used the webclient to migrate the VMK with VSAN Traffic from our VDS to a VSS while in maintenance mode. Then we migrated back to the VDS and tried to delete our VSS. We received a message that we were about to delete a VSS with a VMK on it although we had already migrated the VMK back to the VDS. We proceeded with the deletion but the host had no VSAN access when we brought it out of maintenance mode. We had to recreate the VSS and migrate the VMK back in order to regain VSAN access. Then everything was successful when we re-migrated it back to the VDS and deleted the VSS.
So the procedure that worked best for us in the end was to:
1. Migrate all VMs off the host
2. Migrate the VSAN Traffic VMK to a VSS that uses a Physical Adapter connected to the same Layer 2 network as the VDS
3. Remove the host from the VDS
4. License the Host
5. Re-add the host to the VDS
6. Migrate the VSAN Traffic VMK back to the VDS
7. Migrate all the VMs back
We did migrate the VMK for VSAN Traffic while both in and out maintenance mode. We did not experience any difference although maintenance mode may be best practice.
Hi, this is a message from the far future. The year is 2020, in the month of November. *** The issue encountered by CL4PTP still exists here in this time. VSAN licensing certainly enables vSphere Distributed Switch capability but the VSAN license key does not list vSphere Distributed Switch as a Feature. Do not create that VDS using that Eval license you intend to downgrade later - it's a trap!!! You will find difficulties in the process of applying your permanent license that doesn't include VDS as a feature, and messages will appear like "Assignment Validation Details" and "The selected license does not support some of the features that are currently available to the licensed assets". Wishing you well, and make good life choices. Sincerely, (not) lcuky