roland_geiser's Posts

Hello I am trying to find out on which memory metric the 'performance degradiation VMs tolerate' setting in the Admission Control menu is based on. Let's do an example: I have 10 ESXi hosts, each with 512 GB RAM, resulting in total 5 GB of RAM. Used memory in the cluster is 2.87 TB (If I sum up the memory consumed value on all VMs manually, I do get virtually the same amount of memory): Some VMs do have reservations, most VMs don't. The total amount of reservations in the cluster is 1.2 TB. Admission Control is configured like this: Normally, I configure 'Host failures cluster tolerates' to five hosts, so 50 percent of my "stretched over two sites cluster" can fail. In this example let's configure this setting to six hosts. This results in this graphic: OK above we see the gray shaded bar, these are my 60 % failover capacity. I also see the reserved memory in blue. So in this state, every VM with reservations of course receives its reservation and the rest of available memory (for the vms without or partially reservations) is the light gray bar.This is approximately (5TB*0.4 - 1.2 TB)  = 0.8 TB RAM. From this it follows that in the normal state (10 hosts available) the vms are using 2.87 TB (thereof  1.2 TB reserved) --> unreserved capacity occupied by all VMs: 1.67 TB in a failover state (4 hosts available) the vms can only use 2 TB (thereof still 1.2 TB reserved) --> unreserved capacity occupied by all VMs: 0.8 TB So in a failover state (4 hosts running), the vms without reservations do have to move closer together. But it seems, that there is still enough capacity and there is no warning that the running VMs utilization cannot satisfy the configured failover resources on the cluster. Although the vms have less memory available, there is not yet a performance degradiation! OK, lets try with 'Host failures cluster tolerates' set to 7 hosts. Of course, the gray shaded bar is getting longer, the blue bar for reserved memory is the same and gap between - the non reserved memory) is getting very small, only approximately 0.3 TB. So now, after waiting a few minutes, the cluster is complaining about insufficient failover resources... So I am curious which memory metric is used here to do the calculation. I don't think it is only memory active? Because a calculation based only on memory active seems to be a calculation too progressive in my opinion and with only taken memory active in consideration one can expect some performance degradiation. Is it probably memory active and a certain percentage as a buffer? Does anyone know here more how this calculation works? Because I would like to have a feeling how my vms will perform in a failover state (apart from that the algorithm tells me that the vm's don't have memory issues and that "the same performance is guaranteed...") Best regards Roland

Hello Is this statement correct: "When I am cold migrating a (powered off) vm from one ESXi's local storage to another ESXi's local storage via vCenter, the traffic flow goes through the management-traffic-portgroup, not the vmotion-portgroup?" It's because when I do a hot migrate, regardless of its a vmotion or a vmotion with storage vmotion, then the traffic flow goes through the vmotion port group. It's the behavior that I expect. But why does the traffic not flow through the vmotion-portgroup as well when I do a cold migration? Or ist there a misconfiguration? But I have different port groups on different nic's and there are different subnets configured...and every port group has just one traffic type assigned. I am just studying: What if I have a 10GB vmotion network and a 1 GB management network? When doing a cold migration, the traffic will choose the slow 1-GB-connection? Everybody is giving as much bandwidth as possible for vmotion, but in that scenario the traffic goes through the management network? I know - in most cases we are doing a vmotion or svmotion. But I was astonished when I detected, that the traffic choses the management port group and not the vmotion port group... Is this really the default behavior as described? Best regards Roland