Recently had a OVS root file system fill up due to a run away iSCSI process (and I don’t even use iSCSI…). This had a side affect of affecting almost any task that needed to interact with the Xen hypervisor (status, start, stop, etc). Once I had worked this out and cleaned up the logs to gain space back, I had one VM which was in a very upset state and couldn’t be started, shutdown, anything. I was getting a “Error: Acquire running lock failed: 256”. Read more

I recently had a clustered OVM 2.2 system that had suffered from a catastrophic power failure across all nodes. This ended up corrupting several of the BerkelyDBs that ovs-agent keeps in /etc/ovs-agent/db and /OVS/.ovs-agent/db. On starting ovs-agent, I was getting errors like: “2012-02-15 21:56:24” INFO=> ha_set_shutdown_mode: inform master agent, leave shutdown mode. “2012-02-15 21:56:54” ERROR=> ha_set_shutdown_mode: failed. =>errcode=00001, errmsg=CDS accquire lock /etc/ovs-agent/db/ataskaux.lock timeout. locker process is 16953. StackTrace: File “/opt/ovs-agent-2.3/OVSXHA.py”, line 488, in ha_set_shutdown_mode rs = sp.set_shutdown_mode(“,”.join(my_ips), False) File “/opt/ovs-agent-2.3/OVSServerProxy.py”, line 65, in __getattr__ if not OVSAsyncTaskAux.in_asyncenv(): File “/opt/ovs-agent-2.3/OVSAsyncTaskAux.py”, line 143, in in_asyncenv taskid = get_asynctaskid() File “/opt/ovs-agent-2.3/OVSAsyncTaskAux.py”, line 151, in get_asynctaskid cds = CDS(‘ataskaux’) File “/opt/ovs-agent-2.3/OVSCDS.py”, line 119, in __init__ raise CDSLockTimeout(ERR_CDS_LOCK_TIMOUT, { Also when trying to start virtual machines, I would get the following error: Read more

One of our clients had been running OVM 2.2 for several months after we set them up. They are running a database VM and a couple of application VMs. After they heard of the release of OVM 3.0 they were really keen on getting that installed. I put them off for as long as I could to ensure stability, but I couldn’t hold them off any longer, and I have just completed the migration. Read more