similar to: [PATCH] Fix optimistic locking during vm migration

This fix db-omatic that cannot recover the node on wich the vm run for example. We have not investigate far away but that can be due to a change on the ruby-qmf API. Signed-off-by: Michel Loiseleur <mloiseleur at linagora.com> --- src/db-omatic/db_omatic.rb | 10 ++++++---- src/libvirt-list.rb | 6 +++--- src/matahari-list.rb | 4 ++-- 3 files changed, 11

--- src/db-omatic/db_omatic.rb | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/db-omatic/db_omatic.rb b/src/db-omatic/db_omatic.rb index 155ff5e..b5b7b81 100755 --- a/src/db-omatic/db_omatic.rb +++ b/src/db-omatic/db_omatic.rb @@ -270,10 +270,10 @@ class DbOmatic < Qpid::Qmf::Console end def object_props(broker, obj) - target =

The error is caused by the save! method updating an object that another thread (most likely in taskomatic) already updated. In the case of this race condition, we retry saving. However, a proper fix would involve fixing the locking. --- src/db-omatic/db_omatic.rb | 23 ++++++++++++++++++++--- 1 files changed, 20 insertions(+), 3 deletions(-) diff --git a/src/db-omatic/db_omatic.rb

This patch fixes state changes in dbomatic so that there is no intermediate 'stopped' state after being unreachable or on startup of dbomatic etc. Also fixes a number of smaller bugs around host associations, state changes, etc. Signed-off-by: Ian Main <imain at redhat.com> --- src/db-omatic/db_omatic.rb | 85 +++++++++++++++++++++++++++++++------------- 1 files changed, 60

Hi all, I've got some problems to make work oVirt. I've installed a Fedora 10 VM the lightest possible (nothing checked, even based) and installed after some packages (wget, sudo, acpid,...) and updated the system. By the way, acpid should be a dependency of ovirt-installer because the installation fails if it's not available. I've then installed ovirt (ovirt-server-installer

This fixes a bug where if db-omatic restarted, any running vm lost the association with the host it is running on in the db. --- src/db-omatic/db_omatic.rb | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/src/db-omatic/db_omatic.rb b/src/db-omatic/db_omatic.rb index b5b7b81..d2540e1 100755 --- a/src/db-omatic/db_omatic.rb +++ b/src/db-omatic/db_omatic.rb @@

Live migration is an operation which can takes times, like 2 or 3 minutes for heavy vms. Fixing this timeout work around another bug of db-o-matic: the infinite loop where node A has a defined & stopped vm X and node B has a defined & running vm X. I encountered this bug because the live migration has hit the timeout limit. Signed-off-by: Loiseleur Michel <mloiseleur at

Since Ruby::Qmf moves, the .key() method does not work anymore. It forces to use a .get_attr('key') in order to get the good value. Signed-off-by: Loiseleur Michel <mloiseleur at linagora.com> --- src/task-omatic/taskomatic.rb | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-) diff --git a/src/task-omatic/taskomatic.rb b/src/task-omatic/taskomatic.rb index

The underlying issue has to do with optimistic locking for active record, and contention between db-omatic and task-omatic. That still needs to be fixed, especially since contention issues might get worse when the two daemons are made multithreaded. --- src/db-omatic/db_omatic.rb | 22 +++++++++++++++++++--- 1 files changed, 19 insertions(+), 3 deletions(-) diff --git

This patch updates dbomatic, taskomatic and host-register to use the new C++ wrapped ruby QMF bindings. It also fixes a couple of bugs along the way including the 0 cpu bug for host-register. This is a compilation of work done by myself and Arjun Roy. Signed-off-by: Ian Main <imain at redhat.com> --- src/db-omatic/db_omatic.rb | 111 ++++++-------

Also includes a couple minor model changes to support better error reporting. This method was added so that a client could submit multiple vms to the service layer in one call and get back appropriate messages showing any failures without those failures also causing the entire call to fail, or forcing the client to implement handling (begin/rescue blocks) of these errors to continue through the

Signed-off-by: Loiseleur Michel <mloiseleur at linagora.com> --- app/models/vm.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/app/models/vm.rb b/app/models/vm.rb index 88e0aef..0be3f89 100644 --- a/app/models/vm.rb +++ b/app/models/vm.rb @@ -27,7 +27,7 @@ class Vm < ActiveRecord::Base find(:all, :conditions=>{:state=>Task::STATE_QUEUED})

After running for a while the node becomes "unavailable" in the server UI. All VMs running on that node also become unavailable. The node is still running fine as are all the VMs, they're just no longer manageable. I looked on the node and everything appeared to be running fine. Looked on the server and ovirt-taskomatic was stopped (this seems to happen quite a bit).

since the introduction of ovirt-vnc-proxy and the updating of ovirt-viewer to user it the forward vnc functionality is no longer necessary / and incompatable w/ the current system. --- src/app/controllers/vm_controller.rb | 2 - src/app/models/host.rb | 9 - src/app/models/vm.rb | 36 ----

It can be quite hard to manage a pool of 40-50 VMs without informations about the OS running, the contact (which is the only one to know when the vm can really be destroyed) or an End Of Life date. This patch add those fields, and rework a little the VM list view, in order to show gracefully those new fields. It has been made at the expense of UUID, Total Run Time & Load fields. Since those

This patch changes taskomatic so it only sets the VM to shutdown if the undefine succeeds. Otherwise it's possible a shutdown event could not succeed, or take a while as it often does, giving confusing messages to the user. Basically we're just letting dbomatic handle it now. Signed-off-by: Ian Main <imain at redhat.com> --- src/task-omatic/taskomatic.rb | 1 - 1 files

Signed-off-by: Loiseleur Michel <mloiseleur at linagora.com> --- app/models/smart_pool.rb | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/app/models/smart_pool.rb b/app/models/smart_pool.rb index 1f718a8..9afc354 100644 --- a/app/models/smart_pool.rb +++ b/app/models/smart_pool.rb @@ -62,18 +62,16 @@ class SmartPool < Pool if nested_pools

This sets up ovirt-agent to start as a daemon along with dbomatic, taskomatic etc. While this is not ready for prime time I think it should be ok as you still require a valid, authenticated, connection to qpidd to access it. Signed-off-by: Ian Main <imain at redhat.com> --- installer/modules/ovirt/manifests/ovirt.pp | 6 +++ ovirt-server.spec.in | 5 ++

Hi all, Recently i built development version from the repo. After installing rpms and basic installation procedures. I ended up with "500 internal server error" on my webpage for " http://management.ovirt.priv/ovirt" . I have some relevant logs from db-omatic.log and taskomatic.log which seem to indicate some problem the "AMQP" connection, but i am

I've been playing with ovirt built from source. When I try to start my first VM, I get this error in taskomatic.log: INFO Wed Aug 26 14:33:28 -0600 2009 (12750) starting task_start_vm INFO Wed Aug 26 14:33:29 -0600 2009 (12750) VM will be started on node node94.ovirt.priv DEBUG Wed Aug 26 14:33:29 -0600 2009 (12750) Connecting volumes: DEBUG Wed Aug 26 14:33:29 -0600 2009 (12750) XML Domain