VMware Cloud Community
blazilla
Enthusiast
Enthusiast
Jump to solution

Secondary VM can't started if more than 4x 2 TB VMDKs are connected

Hi everybody,

a customer is running a small two node vSphere 6 Standard cluster. Each server has three local datastores, two with ~400 GB and one datastore with 18 TB.

ESX1-Datastore1: 400 GB

ESX1-Datastore2: 400 GB

ESX1-Datastore3: 18 TB

ESX2-Datastore1: 400 GB

ESX2-Datastore2: 400 GB

ESX2-Datastore3: 18 TB

Each ESXi runs a HP StoreVirtual VSA, which resides in Datastore2 and each VSA has has a 300 GB VMDK attached. The VSA are used to provide a small 250 GB shared VMFS. All VMFS are version 5.61 and they aren't upgraded from earlier VMFS versions.

Today I tried to protect a VM using VMware FT. The config of this VM, let's call it VM1, is stored in a shared VMFS datastore. Data VMDKs are stored in ESX1-Datastore3. During the FT config dialog of the vSphere Web Client, I chose the shared VMFS datastore for the secondary VMs VMX and the Tie Breaker file. The data VMDKs should be stored in ESX2-Datastore3. I finished the configuration dialog and everything was fine. Some seconds later the VM was protected by VMware FT. I removed the FT protection and added VMDKs to provide 16 TB storage (8x 2 TB VMDKs, SCSI0:3 up to SCSI0:10). I went through the FT config dialog of the vSphere Web Client, I chose again the shared VMFS for the secondary VMs VMX and the Tie Breaker file. The data VMDKs should be stored in ESX2-Datastore3. Some seconds later, an error popped up that ESX2-Datastore3 doesn't have enough disk space, and therefore the secondary VM on ESX2 was unable to start. Just to be clear: 16 TB were allocated in ESX2-Datastore3, and 2TB were free. And only data VMDKs were stored in ESX2-Datastore3, no swap file or similar. All other datastores had also sufficient disk space. I disabled FT, removed one of the 2 TB VMDK and tried it again. And again I was informed that ESX2-Datastore3 doesn't provide enough free disk space, to fulfill my request to start the secondary VM. With 4x 2 TB VMDKs (and two VMDKs for OS and apps, so in sum 6 VMDKs) and in sum 8 TB, the secondary VM was able to start. I added a 5th 2 TB VMDK and again the secondary VM was unable to start.

My question is: Why? I know that I can only use 2 TB VMKDs. No problem. But why can't I add more than 4x 2 TB VMDKs? Configuration maximums for ESXi 6 told me, that I can have up to 16 disks with VMware FT. Is there a limit for max. storage that can be added to a VM (e. g. 8 TB)

Thanks for advice! Smiley Happy

Best regards Patrick https://www.vcloudnine.de
1 Solution

Accepted Solutions
jim12345
VMware Employee
VMware Employee
Jump to solution

You can tell your customer this:

  • This behavior is a defect.
  • VMware has reproduced it in-house, and is currently working on solutions.
  • The only way to get this working in the meantime is that the datastore containing the secondary VMDKs must have at least as much free space as the size of the VMDKs (that is, free space above the space needed to store the secondary VMDKs themselves).  So, in your specific customer scenario, if the datastores were 32 TB or above, then he could add the 16 TB worth of storage to the VM.

View solution in original post

3 Replies
jim12345
VMware Employee
VMware Employee
Jump to solution

You can tell your customer this:

  • This behavior is a defect.
  • VMware has reproduced it in-house, and is currently working on solutions.
  • The only way to get this working in the meantime is that the datastore containing the secondary VMDKs must have at least as much free space as the size of the VMDKs (that is, free space above the space needed to store the secondary VMDKs themselves).  So, in your specific customer scenario, if the datastores were 32 TB or above, then he could add the 16 TB worth of storage to the VM.
blazilla
Enthusiast
Enthusiast
Jump to solution

Hi Jim,

thanks for your reply! Is there any SR number or defect number that I can use as a reference for my customer?

Best regards Patrick https://www.vcloudnine.de
Reply
0 Kudos
jim12345
VMware Employee
VMware Employee
Jump to solution

At this point, all that can be said is that:

  • This behavior is a defect.
  • VMware has reproduced it in-house, and is currently working on solutions.
  • There is a workaround that I described above.
Reply
0 Kudos