No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


VRM unable to power on due to reserved frequency band greater than maximum value

Publication Date:  2017-08-30 Views:  264 Downloads:  0

Issue Description

The VRM (FusionCompute) is set up in standalone environment.The VRM and CNA were properly shutdown by using command through putty.

After a while, the CNA is successfully powered on but without VRM.

Client is unable to access the portal of VRM (FusionCompute) and unable to ping the VRM's IP through putty of CNA.

By running xl list in CNA, there is no extra VM found except for CNA itself:

Two commands are tried in the CNA but fail to force start up the VRM:

/opt/galax/NCclientncRebootVM i-00000001 1  and /opt/galax/NCclient ncStartInstances i-00000001

Handling Process

Then, we checked on the log named nc.log under the directory of /var/log/galaxenginelog/vna.

In the log, we can see that the CNA is failed to call uvp.



Root Cause

Based on the clue in nc.log, we check on the uvp log which named as libvirtd.log.l under the directory of /var/log/libvirt.

In this log, we found the root cause: internal error domain limit or reserve is greater than max value 13964


Based on the error message: internal error domain limit or reserve is greater than max value 13964, we understand that the reservation value for reserved (mhz) cpus are invalid.

We direct to the VRM configuration file: /etc/galax/eycalyptus/i-00000001.xml and change the reservation value back to 13964.

After the reservation value is changed, run the command: /opt/galax/NCclient ncStartInstances i-00000001 to force start up of the VRM.

The Result: VRM is able to powered on without issue.


To avoid this incident is to ensure not to change the value of reserved (mhz) for cpus accidentally on the FusionCompute portal.