Accepted Solutions
Graph 1 shows the "Consumed" memory by the VMs. It's essentially the memory that's been claimed by the guest OSes and not released afterwards.
Graph 2 shows the "Active" memory of the VMs. This represents the memory pages actively "accessed" by the guest read/write in real time. Be careful with this metric it shouldn't be used for capacity management. It can be very misleading especially if the guest caches data in memory (db).
So in you case it would probably be wise to add more memory to the host or reduce the memory allocation to the VMs.
Seeing your hosts, the CPUs are doing nothing, it might be worth having a look and see if you need to allocate this much memory to the VMs? (depends on their workloads, one can't tell just now).
If you overcommit your host too much, when the consumed memory (graph 1) reaches close to 100% the memory reclamation mechanisms will kick off (TPS, compression, then ballooning and Swap).
Ram is pretty cheap so if you can avoid it it's for the best 
Graph 1 shows the "Consumed" memory by the VMs. It's essentially the memory that's been claimed by the guest OSes and not released afterwards.
Graph 2 shows the "Active" memory of the VMs. This represents the memory pages actively "accessed" by the guest read/write in real time. Be careful with this metric it shouldn't be used for capacity management. It can be very misleading especially if the guest caches data in memory (db).
So in you case it would probably be wise to add more memory to the host or reduce the memory allocation to the VMs.
Seeing your hosts, the CPUs are doing nothing, it might be worth having a look and see if you need to allocate this much memory to the VMs? (depends on their workloads, one can't tell just now).
If you overcommit your host too much, when the consumed memory (graph 1) reaches close to 100% the memory reclamation mechanisms will kick off (TPS, compression, then ballooning and Swap).
Ram is pretty cheap so if you can avoid it it's for the best