Cleaning up View Composer VMs

We've had frequent issues where our VMware View desktops will get into a state of Provisioning Error (missing) with a popup box that a "Virtual Machine with Input Specification already exists"

This symptom is described pretty well in http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1008658, but here's some more info:

At least in the version of Composer 4.5 that I'm running, the sviconfig command doesn't know the RemoveSviClone that they reference in the KB. So it's the manual way for me.

This seems to happen if the Composer database bits get out of sync with what's in the ADAM database that View uses (Can we please pick ONE database).

This weekend's problems came when the Oracle DB that supports our VirtualCenter, View Composer, and Update Manager environments had a corrupted file. I had to roll back to a previous Oracle state, which naturally meant that it wasn't quite the same as ADAM.

The manual cleanup (besides being MSSQL-specific in table names and interface reference) requires a significant amount of C&P to run through in SQL/Plus. So I declared an Oracle procedure that, given a VM name, cleans up the data automatically:

create or replace procedure cleanup_clone
( p_vmname in varchar )
delete from SVI_VM_NAME where NAME = p_vmname;
delete from SVI_COMPUTER_NAME where NAME = p_vmname;
delete from SVI_SC_PDISK_INFO where PARENT_ID in
(select id from SVI_SIM_CLONE where VM_NAME = p_vmname);
delete from SVI_SC_BASE_DISK_KEYS where PARENT_ID in
(select id from SVI_SIM_CLONE where VM_NAME = p_vmname);
delete from SVI_SIM_CLONE where VM_NAME = p_vmname;


end cleanup_clone;

With this in place, I can "execute cleanup_clone('uscimposer-99');" at the SQL/Plus prompt (having logged in as the Composer user) and it nicely wipes out the input specification for that VM, and a new one can be provisioned. The only other manual step then, is to remove the provisioning-error'd VM from the View Admin interface.


No comments: