Issue


Hot migration fails for VSs with the following 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
CODE


Environment


KVM compute resources with the enabled Ballooning option

Linux OS

 

Resolution


Set the available memory in the system to be of the same value as the current memory. This can be done via configuring ram_ratio in the /onapp/interface/config/info_hub.yml file. 

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]#
CODE


Cause


It is caused by the VS ballooning and is related to memory configuration. In KVM systems, there are two values you can set:

  • Current memory - memory configured for the VS in WEB-UI (current memory Unit)
  • Available memory - maximum allocation of memory for the guest at a boot time

The OnApp daemon calculates the 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.