Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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
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.
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.