Hi All,

I have a Python code when run it displays the Machines that are currently in Maintenance Mode:

but unsure how to work with getting the Events for when it was placed into Maintenance Mode.

Hi,

i just wanted to remove a CPU limit from a VM and set this to "0", i was thinking "0" is unlimited, i didn't noticed the drop down field whe i can select unilimited.

Now i got a problem!

A VM with a CPU limit to "0" freezes and it can't be modifyed, switched off or something else. Nothing can be done with that VM.

To resolve that issue i killed the VM tasks on the ESXi host.

Now i know this, i'm not doing it again, but perhaps there are others... VMware, please prevent here to enter a "0" in die limit!

Kind regards

Stefan

My host is Ubuntu 19.04. My workstation version is 15.1.2. I attempted to downgrade to 14.x but the modules wouldn't build for some reason.

I am attempting to have VMware use hardware graphics acceleration, but I keep getting a signal 11. Video card is an NVIDIA GTX 980 TI with ubuntu's package maintainers 435 driver installed.     

glxgears works properly on the host.

Any support will be appreciated.

Sorry if this has been asked or answered.

We have recently found that when we migrated our VDI environment to Windows 10 1709 that the Horizon View 7.5.1 Agent will not allow SfB 2016 (desktop client not Store app) Calls (audio and video). The Call screen will appear and it will just sit at "Calling" until you hang up. The person you are calling will not see a toast notification, and no errors appear to be generated (can't enable Full logging in SfB atm). Looking at a ProcMon capture, we see the TCP connection is made, but no UDP connection is attempted (probably due to the call not being connected). The Desktop Sharing/Presenting and IM portions work correctly. We used the Horizon View Agent 7.5.1 version for several months on Windows 10 1607 without issue. We have verified that the Windows Defender firewall has all the necessary ports open. When we install the VMware Horizon Virtualization Pack for Skype for Business (even though we are using Zero Clients) and attempt to place a call it will generate an error (call ended or can't be connected).

We decided to roll back to Horizon View Agent v7.4.0 and Skype for Business calling works without issue now.

We also tried to use Horizon View Agent 7.6.0 and received the same issues with SfB calling that we saw with the 7.5.1 Agent.

Has anyone experienced issues with SfB Calling not connecting/no toast notification (to internal domain customers) using the 7.5.1 and higher View Agent and Win10 1709?

UPDATE:

Updating the above post:

We have now tested Horizon View Agent 7.7 and Horizon View Agent 7.8 and continue to see the issue where everything works on Skype for Business EXCEPT Audio and Video calls. Using the Horizon View Agent 7.4 still works without issues. No one else using Windows 10 1709 is seeing this issue? Again, we are using Teradici Zero Clients, so the SfB Optimization pack Agent option is not installed.

We will be opening a SR here in the coming weeks, but wanted to see if the community has any ideas/thoughts etc...

Hi to all,

it's the first that I write in this forum.

I've two hosts connected to a das with 10gb fiber channel.

In the hosts I've vSphere 6, and the vm with vCenter is inside the system.

From february 2015 this system is ok and without problem.

From about 3 weeks I've frequently errors (about every 4/12 hours) of disconnect host. Sometimes is the first server, sometimes the second and sometimes both.

The virtual machine don't migrate to the other host with HA, and continue to work.

In the logs of vCenter I've this:

2020-04-09T17:32:11.280+02:00 error vpxd[09752] [Originator@6876 sub=HttpConnectionPool-000014] [ConnectComplete] Connect failed to <cs p:0000000009b16310, TCP:192.168.1.205:443>; cnx: (null), error: class Vmacore::SystemException(Connessione interrotta dal software del computer host)

2020-04-09T17:32:11.280+02:00 warning vpxd[02408] [Originator@6876 sub=VpxProfiler opID=LicenseEventQueueProcessPendingEvents-5846cea1] LicenseServiceProxy::QueryAssignedLicensesEx [LicenseServiceProxy::QueryAssignedLicensesEx] took 27724 ms

2020-04-09T17:32:11.280+02:00 warning vpxd[02408] [Originator@6876 sub=VpxProfiler opID=LicenseEventQueueProcessPendingEvents-5846cea1] Base::QueryAssignedLicensesFresh [Base::QueryAssignedLicensesFresh] took 27724 ms

2020-04-09T17:32:11.280+02:00 error vpxd[02408] [Originator@6876 sub=licenseAssignmentChangeNotifier opID=LicenseEventQueueProcessPendingEvents-5846cea1] Checking for license assignment change failed with class Vmacore::SystemException(Connessione interrotta dal software del computer host)

2020-04-09T17:32:11.281+02:00 warning vpxd[02408] [Originator@6876 sub=VpxProfiler opID=LicenseEventQueueProcessPendingEvents-5846cea1] LicenseEventQueueProcessPendingEvents [TotalTime] took 27725 ms

2020-04-09T17:32:18.942+02:00 error vpxd[10268] [Originator@6876 sub=HttpConnectionPool-000005] [ConnectComplete] Connect failed to <cs p:0000000008b64830, TCP:192.168.1.205:443>; cnx: (null), error: class Vmacore::Ssl::SSLException(SSL Exception: error:140000DB:SSL routines:SSL routines:short read)

2020-04-09T17:32:18.942+02:00 info vpxd[04000] [Originator@6876 sub=licenseServiceProxy] Authenticating to LS for stubAdapter: [class Vmomi::SoapStubAdapterImpl:00000000093835F0]

2020-04-09T17:32:18.942+02:00 info vpxd[04000] [Originator@6876 sub=[SSO][SsoCertificateManagerImpl]] [CreateServiceContent] Try to connect to SSO VMOMI endpoint.

2020-04-09T17:32:31.714+02:00 error vpxd[03840] [Originator@6876 sub=HttpConnectionPool-000000] [ConnectComplete] Connect failed to <cs p:0000000009b80490, TCP:192.168.1.201:443>; cnx: (null), error: class Vmacore::Ssl::SSLException(SSL Exception: error:140000DB:SSL routines:SSL routines:short read)

2020-04-09T17:32:31.714+02:00 error vpxd[04268] [Originator@6876 sub=Vmomi opID=HB-host-10@933-3ea419e2-TaskLoop-7182ec31] [VpxdClientAdapter] Got vmacore exception: SSL Exception: error:140000DB:SSL routines:SSL routines:short read

2020-04-09T17:32:31.715+02:00 error vpxd[04268] [Originator@6876 sub=Vmomi opID=HB-host-10@933-3ea419e2-TaskLoop-7182ec31] [VpxdClientAdapter] Backtrace:

How can I do to resolve the problem?

Thanks to all for help me.

Curious about new reliability improvements in VSAN7.  Understand vmware has introduced a new quick witness replacement feature.  Which is great.  Been wondering if vmware would ever allow for multiple witness.  For example, one onsite + remote.  Active / passive type witness design - but thats another topic.

Asking today if anything has been done to improve disk replacement.

For example.  Replacing hybrid vsan cache disk in maintenance mode.  Never understood why, if all the data is perfectly fine on the capacity tier, does replacing a cache disk require the entire disk group to be wiped?  Ok, if it was online and cache disk crashes.  But if a host is in maintenance mode - why?  All the capacity tier data is just fine - cache was offline (maintenance mode) and replaced.  Seems a cache destaging / mirroring could be implemented to replacement ssd keeping the disk group intact.

.

Always felt 2 node / stretched a bit risky or incomplete that this simple maintenance task requires your all your 2 node / stretch objects to be in a reduced availability state for an extended period of time for entire resync to complete.  Also impacts cluster performance to sync TBs of data because 1 sdd replaced.  Also puts disk strain on source objects disk group that one hopes doesn't have an issue at resync time...similar to infamous RAID5 rebuilds having 2nd failure   Perhaps entire resync not big deal for larger vsan clusters with FFT2 / erasure, but for small cluster it seems relevant.

Does VSAN 7 offer anything new on disk replacement maintenance? 

Appreciate any feedback.

Thanks!

Hello,

Does vCenter 7.0 allow deploying an HTML5 WebClient Plugin (local plugin) developed using vCenter 6.5 SDK? I am trying to find the compatibility matrix chart, but I find any.

Could anyone, please help?

Thanks in advance

Sundar

The VMware VMmark team previously identified an issue with Weathervane in VMmark 3.1 and addressed the issue by releasing a patch in the initial offering of VMmark 3.1.1 on March 5, 2020.  This fix has been incorporated into a new downloadable VMmark OVA (vmmark3.1.1-template-031420.ova) which, as of April 7, 2020, can be found on the VMmark download page.

There are a number of ways to make sure you're running VMmark 3.1.1:

• VMmark environments that have been updated to version 3.1.1 using the March 5, 2020 patch don't need any changes; a patched VMmark environment fully implements version 3.1.1.
• VMmark environments running unpatched version 3.1 must be updated to 3.1.1, as described in the VMmark 3.1.1 Release Notes, available on the VMmark download page.
• VMmark environments running version 3.0 or earlier need a complete installation of VMmark 3.1.1, accomplished by following the instructions in the VMmark User's Guide and using the VMmark 3.1.1 OVA file (vmmark3.1.1-template-031420.ova) available on the VMmark download page.

For additional information, please contact the VMmark team atvmmark-info@vmware.com.

As title says

I've tried linked clone floating Pool , linked clone with  Persistent disk, Linked clone app volume over a couple of years now and there is always some kind of problem ,

Apparently there is an App volume update coming soon to fix this

Does it work well for anyone here at the moment and if so what is your setup?

Hello,

  i think i do not understand how clustering works in vRO 7.6, or i am doing something wrong with configuring , i read the manual couple of times and still nothing.

I have 3 nodes : vro761,vro762,vro763,  in which the vro761 is the lead. The load balancer is configured with : vrocluster7.greg.labs

If i open the vrocluster7.greg.labs webiste, i can be served via vro763.greg.labs for example, but the link on the page to the client shows always the lead i have chosen at the setup stage. So it points to vro761. This works as long as the vro761 is up and running.

If the vro761 goes down, then i can't open the html5 client since the 761 is down. If i would type url myself and type: vro762.greg.labs:8281, the link to the client still points to 761 the leader.

It is not like in the vro8, where the actual link always points to the LoadBalancer FQDN.

Are we supposed to change the FQDN of the host in the control center on the leader before joining the other nodes to the leader ? In 8.0.1 documentation there is a step like this, but not in 7.6 documentation.

I don't know, maybe i think of the clustering here in the wrong way. Why do we need in this case the load balancer ?

I also noticed that if i would use the old java client, i can always use vro762,vro763,vro761 how i want to connect, will always works. Also, i can use there the LoadBalancer FQDN , and LB will always forward the java client to the working node, and that works ok.

At the above screenshot, the cluster in sync mode has noticed that node 761 is down, and he moved master role to 762. But all the links are pointing to the 761 node. So when i open the website vrocluster7.greg.labs and click the client html5 link i get : website not reachable.

So is there some explanation for this behavior  ? Is it by design that it is not possible to use any other html5 client besides the leader after cluster is formed , or i am doing something wrong here?

For the control center this is not happening, everything there is working using LB FQDN: vrocluster7.greg.labs is being served via vro762, while vro761 is actually down. I can still click the link to control center i will be served website content.

One other question, have you noticed that the VAMI certificate has doubled domain strings ?

IF you will check the main website, its certificate is in correct format. I have installed it using the OVA import. The normal / the beggining website for client or at 8281, has properly CN value.

Thank you

I have scoured the Internet looking for examples of how to resolve my issue. I have enabled passthrough for my graphics card on my ESXi host, rebooted, then added it to a Windows 10 VM as a new PCI device, dedicated 4GB of RAM, and changed svga.present to FALSE. Upon reboot of the host and starting up the VM, I do see the graphics card added as a display adapter in the Device Manager. I can update the driver successfully as well. No matter what I do, the monitor shows no signal or just solid black. I have tried to adjust the pciHole.start option and that did not seem to do anything. Any suggestions on how to debug or try other options would be greatly appreciated.

Hello guys, is it possible to get a report of those events using script?

Thanks much.

I'm trying to get a better sense of the connection path between a vCenter user and a VM's web console in order to diagnose why users can open some web consoles but not others.

When you're connected to to the web client of [VC1] and you open the web console of a VM on [VC2] (which is in the same SSO domain and shows up on the same web client), does the path go like this:

Me -> [TCP 443] -> VC1 -> [TCP/UDP 902] -> VC2 -> [TCP/UDP 902] -> VC2Host -> VM

Or is it this:

Me -> [TCP 443] -> VC1 -> [TCP/UDP 902] -> VC2Host -> VM

And are those ports accurate? Are there any other ports needed for the web console to work (whether from one VC directly or from a linked VC)?

-----

Here's the actual problem I'm having:

I have these two vCenter appliances (both v6.7):

• vc-toronto
• vc-portland

If I log in to vc-toronto from our corporate LAN, I can open web consoles for VMs in that vCenter, but if I try to open a console for a VM on vc-portland, it hangs and then times out. The opposite is also true if I log in to vc-portland. However, if I use the VMRC, I can open the consoles of any of the VMs regardless of which of the two vCenters I'm logged in to.

Meanwhile, I have one user working from home, connecting via VPN1, who reports the same behavior as me, and a second user, connecting via VPN2, who can open web consoles on either vCenter, regardless of which one he's logged in to.

So the implication is that this is a firewall/routing issue. I just need to figure out which ports need to be open and from where to where.

We recently upgraded to Horizon 7.8 and are trying to implement HTML access for the first time. We're an F5 shop for load balancing, and seem to be running into a problem when going through the load balanced address. In a nutshell:

We have two 3.6 UAGs in our DMZ. They are under a load balancer. The UAGs are each pointed at a secure network load ba;ancer address that has our connection servers behind it. In terms of brokering with the Horizon client, we have no issues. Works fine. However, when we point our browsers (tried Chrome and Firefox) at the UAG load balancer, we get to this page fine:

However, as soon as we click "VMware Horizon HTML Access", we progress to a page that is all white. That's it. No error, nothing, just a blank white web page. If I point my browser directly at each UAG, I get the same behavior. If I bypass the UAG, point directly at the brokers, I get expected behavior: I can login and get a VM.

The UAG radio button for allowing HTML access is indeed set. We also modified the Locked.Properties file a bunch of different ways using these 2 KBs, but, without luck. We're a bit stuck for now. Hoping someone has seen something similar.

Allow HTML Access Through a Load Balancer

Allow HTML Access Through a Gateway

Anyone seen this yet on ESXi7?  Clean install of esxi7 all on native VLAN with management network, same computer on network pinging all 4 at the same time and only one responds while others drop sequentially.https://youtu.be/77dfXJQuLHo

I am looking for some help with a script that I can periodically run that would verify that an SNMP read community is set on a ESXi 6.7 host and if it is not set, set the read community to a predefined string.

Thank you,

Tim

The consolidation action it was stooped suddenly with error failed

And then the VM was thinner ie: it was 140GB ,before it was about 400gb

my vm crashed ...all the sites of my son (he dye one and half mounth ago) , i wanted this site for him

and i noticed there is no vmdk (flat) file

There is a delta fvmdk of 125gb (some think like this) left and more smaller file

see the picture

Can i do some thing and revert to my vm , it seems that it is a dangerous software!

The following issue is in a ROBO Stretched Cluster connected by 10Gb Crossover Cable in a 2 Node vSAN with Witness.

So a vSphere 7 ESXi w/vSAN upgrade went south.

- ESXi 7 was reinstalled on two host servers with a new ESXi 7 vSAN witness appliance.

- vCenter was still intact and a new Cluster was made. New vmkernel ports. Added to existing vDS.

The problem I am having, is the vsandatastore was recovered. However when I add any VM back to inventory the virtual disks are 0\blank\missing. However, the VSANDATASTORE used space appears that all the data is still there.

VMs added will say errors like:

"Some of the disks of the virtual machine ___ failed to load. The information present for them in the virtual machine configuration may be incomplete"

Power On - Operation Failed - "Unable to enumerate all disks."

When I browse a host in WinSCP, under volumes I see:

/vmfs/volumes/vsan:52e8a7a1b473de38-2dc9078322a3e571 - This is active datastore and has all the VM's but no big disk files.

vsanDatastore - Appears to be a shortcut that does not work which I think is pointing to the original old vsan volume. /vmfs/volumes/vsan:52aceefd58033ced-e6d380dbb3a4e95a

If I open up a VMDK from a VM I see, for example:

# Disk DescriptorFile version=4 encoding="UTF-8" CID=ee6267c9 parentCID=d6a51678 createType="vsanSparse" parentFileNameHint="OPNSense Firewall.vmdk" # Extent description RW 67108864 VSANSPARSE "vsan://a439555e-6e08-833c-e1a0-000e1e7254b0"  # The Disk Data Base #DDB  ddb.longContentID = "e34cf36849d729a254145eb2ee6267c9" ddb.toolsInstallType = "0" ddb.toolsVersion = "2147483647" 

Digging a little deeper and it looks like the disk objects are showing in vSAN as " Unknown object type". There are Unknown object type objects with matching vSAN GUID's mentioned in VM vmdk files. Such as the one mentioned above...

RW 67108864 VSANSPARSE "vsan://a439555e-6e08-833c-e1a0-000e1e7254b0"

Unknown object type Healthy vSAN Default Storage Policy a439555e-6e08-833c-e1a0-000e1e7254b0

esxcli vsan storage list - on Host 1

naa.5000cca258d82813 Device: naa.5000cca258d82813 Display Name: naa.5000cca258d82813 Is SSD: false VSAN UUID: 520645fa-a797-38d4-5e68-22b2171861dc VSAN Disk Group UUID: 520d0603-6e38-a207-1f2b-b6472f57d6f9 VSAN Disk Group Name: naa.55cd2e404c18cb88 Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 4179814668856239213 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:45:56 2019  naa.55cd2e404c18cb88 Device: naa.55cd2e404c18cb88 Display Name: naa.55cd2e404c18cb88 Is SSD: true VSAN UUID: 520d0603-6e38-a207-1f2b-b6472f57d6f9 VSAN Disk Group UUID: 520d0603-6e38-a207-1f2b-b6472f57d6f9 VSAN Disk Group Name: naa.55cd2e404c18cb88 Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 6518366817165333701 Checksum OK: true Is Capacity Tier: false Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:45:56 2019  naa.5000cca252cdeadd Device: naa.5000cca252cdeadd Display Name: naa.5000cca252cdeadd Is SSD: false VSAN UUID: 5242f42c-474e-1c1a-9016-927431e9713d VSAN Disk Group UUID: 52782092-2deb-db53-aaa1-cc71b1679b43 VSAN Disk Group Name: naa.55cd2e404c2055aa Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 12173014117720582296 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Tue Jan 21 12:40:33 2020  naa.55cd2e404c2055aa Device: naa.55cd2e404c2055aa Display Name: naa.55cd2e404c2055aa Is SSD: true VSAN UUID: 52782092-2deb-db53-aaa1-cc71b1679b43 VSAN Disk Group UUID: 52782092-2deb-db53-aaa1-cc71b1679b43 VSAN Disk Group Name: naa.55cd2e404c2055aa Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 5367773553359825337 Checksum OK: true Is Capacity Tier: false Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:45:45 2019  naa.5000cca23b7ee4e4 Device: naa.5000cca23b7ee4e4 Display Name: naa.5000cca23b7ee4e4 Is SSD: false VSAN UUID: 52e46a8d-cdb8-1159-38d5-cfbde318e15f VSAN Disk Group UUID: 520d0603-6e38-a207-1f2b-b6472f57d6f9 VSAN Disk Group Name: naa.55cd2e404c18cb88 Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 4127245025532564424 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:45:56 2019  naa.5000cca23b834064 Device: naa.5000cca23b834064 Display Name: naa.5000cca23b834064 Is SSD: false VSAN UUID: 52f4d6fa-0c8f-603d-453c-3da1646496ce VSAN Disk Group UUID: 52782092-2deb-db53-aaa1-cc71b1679b43 VSAN Disk Group Name: naa.55cd2e404c2055aa Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 6169125189223970042 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:45:45 2019 

esxcli vsan storage list - on Host 2

naa.5000cca252cc5f25 Device: naa.5000cca252cc5f25 Display Name: naa.5000cca252cc5f25 Is SSD: false VSAN UUID: 5234687a-c379-e17e-a53d-4cf9e9fc8e7c VSAN Disk Group UUID: 52be0b83-8590-9e78-3d27-ad7926eb9ad0 VSAN Disk Group Name: naa.55cd2e404c18cc1f Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 5370575494238580185 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Wed Jan 22 02:29:14 2020  naa.55cd2e404c2055af Device: naa.55cd2e404c2055af Display Name: naa.55cd2e404c2055af Is SSD: true VSAN UUID: 524971da-1c92-f80e-9199-0fa74a253354 VSAN Disk Group UUID: 524971da-1c92-f80e-9199-0fa74a253354 VSAN Disk Group Name: naa.55cd2e404c2055af Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 18423783201084117590 Checksum OK: true Is Capacity Tier: false Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Fri Nov  8 12:46:06 2019  naa.5000cca23b437b3c Device: naa.5000cca23b437b3c Display Name: naa.5000cca23b437b3c Is SSD: false VSAN UUID: 5255b6bb-5de1-49c7-67af-aee865cde07a VSAN Disk Group UUID: 524971da-1c92-f80e-9199-0fa74a253354 VSAN Disk Group Name: naa.55cd2e404c2055af Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 7220870063380886230 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Thu Jan 16 03:16:23 2020  naa.55cd2e404c18cc1f Device: naa.55cd2e404c18cc1f Display Name: naa.55cd2e404c18cc1f Is SSD: true VSAN UUID: 52be0b83-8590-9e78-3d27-ad7926eb9ad0 VSAN Disk Group UUID: 52be0b83-8590-9e78-3d27-ad7926eb9ad0 VSAN Disk Group Name: naa.55cd2e404c18cc1f Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 9858777924305020986 Checksum OK: true Is Capacity Tier: false Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Sun Jan 19 03:42:32 2020  naa.5000cca258d81d2c Device: naa.5000cca258d81d2c Display Name: naa.5000cca258d81d2c Is SSD: false VSAN UUID: 52c41e3e-e943-1a1a-d001-5fcb6de4997b VSAN Disk Group UUID: 524971da-1c92-f80e-9199-0fa74a253354 VSAN Disk Group Name: naa.55cd2e404c2055af Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 3826993888305396649 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Tue Jan 21 12:42:14 2020  naa.5000cca23b0bce74 Device: naa.5000cca23b0bce74 Display Name: naa.5000cca23b0bce74 Is SSD: false VSAN UUID: 52cb0133-f1c4-b3e1-dd47-fd9f5a786437 VSAN Disk Group UUID: 52be0b83-8590-9e78-3d27-ad7926eb9ad0 VSAN Disk Group Name: naa.55cd2e404c18cc1f Used by this host: true In CMMDS: true On-disk format version: 10 Deduplication: false Compression: false Checksum: 4710347119789749474 Checksum OK: true Is Capacity Tier: true Encryption Metadata Checksum OK: true Encryption: false DiskKeyLoaded: false Is Mounted: true Creation Time: Sun Jan 19 03:42:32 2020 

Is there any way to make these VM's usable again or is all my data lost?

Example: In picture below - this highlighted unknown object is the parent disk vmdk to one of my VMs

I have attempted a graceful shutdown by following the standard instructions of shutting down all VMs in the cluster (excluding V-Ctr), going to see if any tasks were outstanding on the vSAN, shutting down the V-Ctr VM) and then logging into the individual hosts to enter maintenance mode and shutdown the hosts.  Unfortunately once all of the VMs were shutdown and after confirming no tasks were outstanding on the vSAN things went for the worse.  The V-Ctr wouldn't shutdown and then errors occurred I simply shut it down as it was being non-responsive.  I placed all the hosts in maintenance mode and 3 hosts were displaying their list of VMs that were previously hosted under that host.  The 4th host which also contained the V-Ctr currently shows no VMs in its list which makes no sense as those VMs are listed on the other 3 hosts as being unknown due to the fact they physically reside on this 4th problematic host.  The entire cluster is around 40TB and 3 of those hosts are showing around 30TB and the 4th is showing around 10TB under the vSAN.  It seems like this 4th hosts isn't connected to the 3 other hosts yet no network/config changes were done.  What can I start with in order to get these missing VMs back up and running.  Keep in mind that the V-Ctr appliance is also missing.  The entire environment is not connected to the internet.