Hi there.
For future reference, if anyone has a similar issue.
The problem arrived from the FortiGate firewall, onto which the STP (Spanning Tree) option was enabled on the internal interface. Once STP was disabled, the receive length errors stopped immediately.
I am unsure as to why the STP option was enabled in the first place, or why enabling STP caused these errors, but it has fixed the issue.
Kind regards,
Say you have 4 hosts in a cluster, each with a 16-core CPU - you have a total of 64 cores in your cluster.
If you build all your VMs with 2 CPUs each, once you‘ve created 32 VMs you have a total of 64 vCPUs.
At that point your ratio of vCPUs to physical CPU cores is 1:1
If you also account for HA (or maintenance) and 1 host in the cluster is offline, your VMs will then be running across 3 hosts with 48 physical cores between them - your ratio is then 1.33:1
Lose another host and your down to 32 physical CPU cores, at a ratio of 2:1
why did you calculate in cluster ? I think we have to calculate this ration in each host
for example I have 10 esxi host in my cluster with follow info :
DL 580 G10
Processor sockets 4
Processor cores per socket 28
and vcpus that assign to vms on this host1 is 118 vcpus
vcpus that assign to vms on this host2 is 144vcpus
vcpus that assign to vms on this host3 is 129vcpus
vcpus that assign to vms on this host4 is 156vcpus
vcpus that assign to vms on this host5 is 130vcpus
vcpus that assign to vms on this host6 is 110vcpus
vcpus that assign to vms on this host7 is 154vcpus
vcpus that assign to vms on this host8 is 122vcpus
vcpus that assign to vms on this host9 is 129vcpus
vcpus that assign to vms on this host10 is 102vcpus
now how do I had to calculate that ?
Short answer:
Using maths.
Long answer:
You have 112 cores per host, and 10 hosts, so a total of 1120 physical cores.
Add up all your vCPUs, that’s a total of 1294.
Your ratio when all 10 hosts are available is 1294:1120, which if you divide both sides by 1120 is 1.155:1
If you had only 7 hosts available, you would have 784 physical cores, your ratio would then be 1294:784 or 1.65:1
Take half of your cluster out of action and you have 560 cores remaining, your ratio is then 1294:560 or 2.31:1
The issue will be fixed in 7.0 P01. Closing thread.
5 years later and VMware still can't manage to make download links work in HTML.
Got it to work with the link in the HTML source.
would you say please when and where had to notice to this parameter ?
Is there any best practice for this ?
What can understand from this ? Actually how can help me to optimize my infrastructure /
would you say please when and where had to notice to this parameter ?
I don’t understand your question.
Is there any best practice for this ?
There was a link posted earlier in this thread.
What can understand from this ?
I don’t understand your question, but your ratios are low.
Actually how can help me to optimize my infrastructure /
Are you suffering from poor compute performance? If so, this is just one of many things to consider. If not, don’t worry about it.
how can understand my ratio is low and ok ?
By reading through this thread and following the links posted in it.
I see you’ve posted before about vRealize Operations, make use of it.
Newly created VMs do not retain in the inventory list after shutdown or reboot. They show up fine until a host reboot. They're still in the datastore. Re-register brings them back until another reboot. VMs were brought in with converter, newly created from ISO, and created from existing disk. None are retained. Existing VMs in list return to list after unregistering them. Seems like some sort of write access issue. Any ideas?
Welcome to the Community,
does your ESXi host boot from an USB/SD device? It seems that it cannot write the configuration to the bootbank anymore.
I assume it's not only VMs which disappear after a reboot, but also other changes, like newly created vSwitches, or port groups.
What you may try is to see whether /sbin/auto-backup.sh shows any errors, and check whether the boot device shows up in the /dev/disks directory.
If it's indeed and USB/SD device that you are booting from, it may be faster to replace it and reinstall ESXi (with preserving the datastore), than to troubleshoot the issue.
André
Check the event log of your ESX and look for "lost boot device". I have a couple of Hosts whith older SD cards which seems to small for today 6.5 and up.
What i also have seen in the past is than Admin have use passtrough option to bind the USB(Controller) to a VM so ESXi lost the device short after finish booting.
Regards,
Joerg
Hi.
I have 5*300G sas on Hp dl580
I install esxi 6.5 and before creating first machine it showes 1.08T after creating server 2016 and 200G for C drive I only have 580G as rest of storage
i am using raid 5
I would apriciate help about it
Welcome to the Community,
which files (and sizes) do you see in the VM's folder?
Can you confirm that you've only created this VM, i.e. didn't remove one, or modify the VM's virtual disk settings (e.g. remove disk, and add a new one)?
André
How much memory have you assigned to your VM?
Regards
Joerg
My Local ATA Disk is named "t10.ATA_____CT1000MX500SSD1_________________________1914E1F7B0D2________" and I'm also getting the "Not found" error. VadimYakovlev what should I changed my name to like you did with "naa....:1 naa...:1" ??
Hi,
The physical core on ESXi needs to be calculated.
(Physical socket) x (core) = Indicates the total amount of physical CPU, ie pCPU. If HT is not active in the environment, it is the maximum amount of vCPU you can give to the virtual machine.
If HT is active in the environment;
(pCPU) x (2 x core) = Returns the total number of vCPUs.
Now if we proceed with a simple example;
We have a server with 2 physical sockets, each with 16 cores. HT is also active on this server. In this case, if we proceed according to the calculation above;
(2 sockets) x (16 cores) = There are 32 cores in total. If HT is not active, this is the maximum amount of CPU you can give to a virtual server. However, since HT is active, we continue to calculate.
Since (32 core) x (2) = HT is active, our total vCPU amount, that is, the maximum CPU amount we can give to the virtual server is 64.
Now let's come to the real question. We have a server with a capacity of 64 vCPU. How many virtual machines can I host on this server? First of all, as I mentioned above, you can also use resources that you don't have thanks to CPU overcommitment. In this case, you can create 10 virtual servers with 64 vCPUs. A total of 640 vCPUs may have been assigned, but virtual servers cannot use so many resources. Why? Because the physical resource on ESXi is not that much. So if you give this much CPU, it is very likely that you will experience performance problems. For this, VMware proposes the following rates and asks you to calculate accordingly.
According to the account we made above, we have 64 vCPU capacity. According to this account;
1: 1 = If you keep the total number of vCPUs assigned to virtual servers created under ESXi 64 or less, you will not experience any performance problems. I recommend that you use this rate only and only in environments where you have very critical workloads.
2: 1 = You can give a total of 128 vCPU resources to the virtual servers you create on ESXi if you want to use the 2: 1 ratio here. When you choose this rate, you will not experience any performance problems.
3: 1 = If you want to use the middle of 3: 1 here, you can give a total of 192 vCPU resources on the virtual servers you create on ESXi. When you choose this rate, there may be some small or low changes compared to the previous two configurations.
4: 1 = If you want to use the middle of 4: 1 here, you can give a total of 256 vCPU resources to the virtual machines you create on ESXi. This rate is actually the most optimal rate recommended.
If you use the 5: 1 or 6: 1 ratio here, you may experience serious performance problems. If you are using VDI media, you can use 5: 1 or 6: 1 ratios.
On the VMware side, if you absolutely want to follow a rule and wonder how the rates should be, you can use the rates I mentioned above. The rates stated here are actually purely architectural decisions. You may never want to overcommit the CPU side and use it in a 1: 1 ratio. Yes this is possible. If you think of a different scenario, you can use a ratio like 10: 1. Of course, this ratio will cause you various performance problems. However, there is no obstacle in your use. If you do not overcommitment, you cannot use CPU resources more effectively and efficiently.
When you create a virtual machine, the amount of memory you give to the virtual machine is separated from the datastore. Let's give an example as follows;
Let's say you create a virtual machine with 2 vCPU, 4gb memory, 100gb disk features. If you created a thick disk here, it will take up 104 gb in total. If you have created a thin disk, the disk will expand as data arrives.
If the memory size of the virtual machine you created is excessive, this field may be reserved from datastore.
Hi
is this true?
in ESXTOP I can see VM´s with 0% local Numa usage, but actually those VM´s have a RAM Reserversion
Example
NRMEM - NLMEM - N%L
7441.26 - 170.00 - 0
Actually this is a bad situation because the VM is not using lokal ram, almost all ram is located on the remote site.
But i wunder if this can be true if ram reservation is locked..