I just checked internally, and right now there doesn't appear to be a way to create an exception of some kind, it is listed as something to be fixed in the future. I have added your question to the t...
See more...
I just checked internally, and right now there doesn't appear to be a way to create an exception of some kind, it is listed as something to be fixed in the future. I have added your question to the ticket so that it hopefully will get fixed asap.
@leslier wrote:
So we just onboarded to vSphere+, yes the documentation says that any host is automagically applied the vSphere+ license, is there NO way to make an exception for a VSAN witness ...
See more...
@leslier wrote:
So we just onboarded to vSphere+, yes the documentation says that any host is automagically applied the vSphere+ license, is there NO way to make an exception for a VSAN witness appliance that had an embedded license?! Do I have to move the witness appliance to vCenter not exposed to the vSphere+ all seeing eye?
I never tested this myself, that is a good one, I can see if I can find out internally...
I wrote a lengthy paper on the topic years ago: https://core.vmware.com/resource/vmware-vsphere-metro-storage-cluster-vmsc
What happens from a VMware perspective depends on where the VMs are locate...
See more...
I wrote a lengthy paper on the topic years ago: https://core.vmware.com/resource/vmware-vsphere-metro-storage-cluster-vmsc
What happens from a VMware perspective depends on where the VMs are located. Assuming the VMs align from a compute stance with the ownership from a storage point of view then NONE of the VMs will need to be restarted. If however your VMs are all over the place then VMs will be restarted as soon as VMware can acquire a lock on the datastore.
In other words, FOLLOW the guidance provided by NetApp and VMware to prevent ending up in a situation where VMs need to be restarted in this scenario. (https://kb.vmware.com/s/article/2031038)
@Peymansh wrote:
The problem has nothing to do with the hardware. In general, the power went out once and when we turned on the servers, this was the problem and it has not been solved until now...
See more...
@Peymansh wrote:
The problem has nothing to do with the hardware. In general, the power went out once and when we turned on the servers, this was the problem and it has not been solved until now.
It could have everything to do with the hardware, the 980 Pro doesn't have power loss protection, which means that if power goes out you can end up in a weird state. I think the best way forward now is to recover from a backup! Assuming you have a backup?
But disabling HA and Admission Control doesn't prevent what is going to happen in this situation.
Your VMs are replicated between locations, and you have VMs in both preferred and the secondary. Wh...
See more...
But disabling HA and Admission Control doesn't prevent what is going to happen in this situation.
Your VMs are replicated between locations, and you have VMs in both preferred and the secondary. When the ISL goes down, the Preferred location will bind itself with the witness, the secondary will lose access to the witness. Which means that ALL virtual machines in the secondary instantly lose access to storage and will be marked inaccessible and killed by vSAN.
NORMALLY they would be restarted by HA in the preferred location, but in this case if you disable HA then nothing would happen.
I would highly recommend moving ALL the virtual machines to the preferred location before doing the maintenance.
that feature is called VM Monitoring, and you will still need a cluster for that to work as you enable it on a cluster level. but if it helps, you could create a cluster with a single host
You do not need vSAN to achieve this, there's a free replication solution called vSphere Replication which you can use to replicate your VMs in Site A to Site B. This is asynchronous replication. If ...
See more...
You do not need vSAN to achieve this, there's a free replication solution called vSphere Replication which you can use to replicate your VMs in Site A to Site B. This is asynchronous replication. If you need sync replication then you could talk to the storage team to see what the SANs in both locations support (if they are a similar make and model that is of course)
@zoomprofile wrote:
VMware vCenter Server 8.0.2 is broken as hell... not just MAC addresses, but also user without admin permissions is not able to edit settings and connect ISO, or it's not pos...
See more...
@zoomprofile wrote:
VMware vCenter Server 8.0.2 is broken as hell... not just MAC addresses, but also user without admin permissions is not able to edit settings and connect ISO, or it's not possible to do storage vmotion or import OVA... vCenter from version 7 is **bleep** product, not usable, always broken, unsecure, etc... that's how it looks when VMware started saving money and delegated all work to India...
Did you file SRs for these issues?
It is pretty straight forward:
Disable the performance service
Make sure all VMs are migrated
Delete diskgroups 1 by 1
Disable vSAN Service
Remove VMkernel interfaces
Yes you should be able to use it, a vTPM requires a key provider, the native key provider is part of vCenter Server at all license levels, VM Encryption is what requires Enterprise Plus, but if you o...
See more...
Yes you should be able to use it, a vTPM requires a key provider, the native key provider is part of vCenter Server at all license levels, VM Encryption is what requires Enterprise Plus, but if you only do vTPM and the Native Key Provider you don't need that.
https://core.vmware.com/vtpm-questions-answers
From a vSAN point of view, checksums are enabled by default, unless explicitly disabled, guessing this is indeed an Aria issue, so no need to worry about the vSAN aspect. (But indeed, this needs to b...
See more...
From a vSAN point of view, checksums are enabled by default, unless explicitly disabled, guessing this is indeed an Aria issue, so no need to worry about the vSAN aspect. (But indeed, this needs to be fixed)
