Archive for August, 2010


Ever try and startup a virtual machine and got the following xc_dom_do_gunzip error?


Start - /OVS/running_pool/30_owi2
PowerOn Failed : Result - failed:failed: Error: (1, 'Internal error', 'xc_dom_do_gunzip: inflate failed (rc=-5)\n')>

StackTrace:
File "/opt/ovs-agent-2.3/OVSXXenVM.py", line 57, in xen_start_vm
run_cmd(args=cmd)
File "/opt/ovs-agent-2.3/OVSCommons.py", line 85, in run_cmd
raise Exception('%s => %s' % (cmdlist, p.childerr.read()))>

StackTrace:
File "/opt/ovs-agent-2.3/OVSSiteVM.py", line 131, in start_vm
raise e

A colleague of mine ran into this issue a few days ago, and I decided to post about what was causing the problem. At first glance, I thought it had to deal with xen memory ballooning in the OVM environment (since it mentioned the word inflate), but I was wrong. The root cause of the problem is that the root directory “/” under /dev/sda2 (default OVM storage layout) was full. Since the root directory diskspace was at capacity it wasn’t able to start up the VM.

The fix is to free up some space from your root directory in order to get rid of the problem. While the solution is an easy one, it can be tricky to see how your root directory could cause your VM not to start since all your VM files are located in the /OVS directory. For that reason, I decided to post about it anyway since the error message is not very clear on what could be causing the problem.

Hope this helps someone out and feel free to comment! 🙂

Advertisements

Ever had your virtual machine show an incorrect status such as ‘Shutting Down’ and just stay in that status indefinately? Well there is some good news, it’s an easy fix. There are a couple reasons this can occur. First, if you stopped your virtual machine from the OVM server instead of the OVM Manager this could cause the OVM Manager and OVM server to be out of  ‘sync’ when reporting the status of your virtual machine. In other cases, it could be a bug between the communication of the OVM Manager and Oracle VM server. In either case there are a few options in solving your issue.

In OVM Manager 2.1.*, you will need to manually update the Oracle VM Manager database status of your guest virtual machine.
Login as ‘oracle’ into your OVM Manager and follow the steps below.

$ export ORACLE_HOME='/usr/lib/oracle/xe/app/oracle/product/10.2.0/server'
$ export ORACLE_SID=XE
$ ${ORACLE_HOME}/bin/sqlplus system/oracle@XE
$ SQL> update ovs.ovs_vm_img t set t.status='Powered Off' where t.img_name like '<MY_VM_NAME>';
$ SQL> commit;
$ SQL> quit;

In Oracle VM Manager 2.2 and above, the process is quite simple. Oracle has introduced the ‘Reset’ option which will set the virtual macine guest to its correct state.
The steps are as follows:
1) Click on the Virtual Machines tab found on the top left corner.
2) Select the radio button of the appropriate virtual machine that has the incorrect status displayed.
3) Click on the ‘More Actions:’ drop down box and select the option ‘Reset’
4) Click the ‘Go’ button for the reset to take place.

Once the ‘Go’ button is selected, the virtual machine will reset and display the appropriate virtual machine status.

Hope you enjoyed this article and feel free to post any comments our questions.

Thanks,
Roger.