Bug #567

Vmm polling error - Error monitoring VM, Error executing sudo /usr/sbin/xentop -bi2

Added by Tuomo Varis almost 10 years ago. Updated over 9 years ago.

Status:ClosedStart date:04/08/2011
Priority:NormalDue date:
Assignee:Javi Fontan% Done:

0%

Category:Drivers - Auth
Target version:Release 3.0
Resolution:fixed Pull request:
Affected Versions:

Description

Hi,
I have been playing around with OpenNebula 2.2 and Xen 4.0 hypervisors. The problem is that execution of the VMM polling script (/var/tmp/one/vmm/xen/poll) fails to return any relevant information when only a couple of VMs are deployed and a Nil object is returned from get_all_vm_info.

I have attached a VM log of the issue and a patch that seems to fix the problem.

vm.log (4.98 KB) Tuomo Varis, 04/08/2011 03:20 PM

poll_xen_kvm.rb.diff Magnifier (394 Bytes) Tuomo Varis, 04/08/2011 03:20 PM

xentop.output (2.55 KB) Tuomo Varis, 04/15/2011 09:17 AM

xen_poll_error_handling.patch Magnifier - Return [] rather than nil when polling fails. (242 Bytes) Vivien Bernet-Rollande, 04/15/2011 12:05 PM

one_xen_4.0_poll.patch Magnifier - Check for xen version and use different polling strategy (2.15 KB) Vivien Bernet-Rollande, 05/17/2011 12:05 PM

poll_xen_kvm.patch Magnifier (2.08 KB) Luis M Carril Rodriguez, 07/18/2011 11:45 AM


Related issues

Related to Bug #656: Xen poll script fails for some Xen versions Closed 05/20/2011

Associated revisions

Revision a841f0db
Added by Abel Coronado about 3 years ago

Solved bug in Selenium tests (off('change')) (#567)

Revision e167aaad
Added by Abel Coronado about 3 years ago

Solved bug in Selenium tests (off('change')) (#567)

(cherry picked from commit a841f0db4bf33aed1f030416526d014cfa826204)

History

#1 Updated by Tuomo Varis almost 10 years ago

Is anyone else encountering similar problems? Or is just my setup giving different output from xentop and causing parsing failures with the non-patched poller?

One symptom of this same bug seems to be that some VMs get "lost" - OpenNebula decides they are in UNKNOWN state while still running in the hypervisor and thus attempting to recover them by restart action causes them to FAIL.

#2 Updated by Javi Fontan almost 10 years ago

  • Category set to Drivers - Auth
  • Status changed from New to Assigned
  • Assignee set to Javi Fontan
  • Target version set to Release 3.0

OpenNebula was tested with 3.x series of Xen so there could be some problems with Xen 4.0. Could you send use the output of /usr/sbin/xentop -bi2? Then I can take a look into the differences and your patch and check the best way to make it work in both versions.

#3 Updated by Tuomo Varis almost 10 years ago

Attached.

#4 Updated by Vivien Bernet-Rollande almost 10 years ago

I have the same issue with Xen 4 on debian. The proposed fix works for me.

There's another small issue : if an exception is raised while parsing this output, the function get_all_vm_info() will return nil. It's caller expect to recieve an array. I believe it should either be returning an empty array (patch attached), or, even better, propagate the exception.

#5 Updated by Vivien Bernet-Rollande over 9 years ago

The attached patch checks for the xen version used. If the version is > 3.X, it will use a slightly modified polling method., to cope with the xentop output format change.

I have no means of testing this code on 3.X, but it should work, since the code is pretty much the same.

#6 Updated by Luis M Carril Rodriguez over 9 years ago

The patch has worked for in a mixed infrastructure of Xen 4, Xen 3 and KVM.

But I needed to apply a fix (the attached file is an updated patch). As the commands to detect the Xen version needed to be executed with sudo. So I added '/usr/sbin/sudo' to the 'xm info' commands.

#7 Updated by Luis M Carril Rodriguez over 9 years ago

Luis M Carril Rodriguez wrote:

The patch has worked for in a mixed infrastructure of Xen 4, Xen 3 and KVM.

But I needed to apply a fix (the attached file is an updated patch). As the commands to detect the Xen version needed to be executed with sudo. So I added '/usr/sbin/sudo' to the 'xm info' commands.

I meant: I added 'sudo /usr/sbin/xm info' for the 'xm info' commands.

#8 Updated by Javi Fontan over 9 years ago

A patch was added to #656 so it detects the header instead of the xen version. That would make the probe work even if they add lines before the header (like 3.x version)

#9 Updated by Javi Fontan over 9 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Also available in: Atom PDF