| We moved this page to our Documentation Portal. You can find the latest updates here. |
Issue
Hot migration fails for VSs with an error message:
Running: virsh migrate --live --unsafe vfztrsbidhyeij qemu+ssh://10.50.34.10:22/system?no_verify=1 tcp:10.50.34.10 error: internal error: process exited while connecting to monitor: 2018-05-18T15:50:33.344807Z qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory Fatal: Execution of virsh migrate --live --unsafe vfztrsbidhyeij qemu+ssh://10.50.34.10:22/system?no_verify=1 tcp:10.50.34.10 failed
Environment
KVM compute resources with Ballooning enabled
Linux OS
Resolution
Set the available memory on the system to be of the same value as the current memory. This can be done via configuring ram_ratio value in the /onapp/interface/config/info_hub.yml file.
For example:
[root@panel1 tmp]# grep ram_ratio /onapp/interface/config/info_hub.yml -B3
hypervisor:
kvm:
default_memory_overhead: 1536
ram_ratio: 0.1
[root@panel1 tmp]#Cause
This is caused by the VS ballooning and is related to memory configuration. On KVM systems, there are two values you can set.
- The current memory - memory configured for the VS in WEB-UI (current memory Unit)
- The available memory - maximum allocation of memory for the guest at boot time
OnApp daemon calculates memory value for the VS based on the max memory value and free memory on the compute resource. The problem is that the max memory value is static and doesn't depend on the amount of free memory value on the compute resource. When a KVM VS boots up, it starts with the maximum allotment of memory possible to be given (the available memory). Gradually, during the boot phase of the system KVM claws back this memory using its ballooning, leaving you instead with the current memory setting you have.