Impact of stopping VCD Cells to clear qrtz tables..

[lsemple]

Hi,

I'm relatively new new to VCD, and recently discovered our environment (VCD 5.5 - 2 cell environment) has the " Unable to find the cell running this listener" error message; so cant perform multiple actions on VM's.  

I came across this post below, and see I have to clear the qrtz tables to see if it sorts the issue. The post indicates I have to cleanly stop both cells to clear the tables, but wondered if that will cause a service outage to the customers VM's running within VCD?.

http://www.boche.net/blog/2011/12/16/vcloud-director-and-vcenter-proxy-service-failure/

I assume the portal will be unavailable to them until the services are restarted, but struggling to find any information on what else would be effected by shutting down both cells. I need to raise a CAB change to get this done, so looking for some solid information if any customer outrages would be experienced while the cells are down?

Thanks in advance

Lee

[LordofVxRail]

Clearing quarts table does not affect running workload // vms in the cloud. When you stop vcd service, it's the management layer you are losing access to; all the vms are still running as normal in the hosting vcenter.
When vcd services are stopped for the quartz cleaning, your users will not have access to the tenant portal, but all vms will still be accessible over IP.
I had to do that a few times on a dev environment; db was a mess with several hundred vms, only took a few minutes to tidy up the quartz tables.

[lsemple]

Cheers LordofVxRail,

I've restarted the cells a couple of times, but never shut down both at once, so good to confirm the extent of the outage. I've found a couple of versions of the script, so need to review them, raise a change and give it a whirl 🙂 

Thanks again

Lee

[LordofVxRail]

yeah, you'll need to stop all cells otherwise changes may be pushed to DB.

The last time I did this was in 2016, and I modified these tables: (take a snap!)

USE [vcloud]

GO

delete from QRTZ_SCHEDULER_STATE

delete from QRTZ_FIRED_TRIGGERS

delete from QRTZ_PAUSED_TRIGGER_GRPS

delete from QRTZ_CALENDARS

delete from QRTZ_TRIGGER_LISTENERS

delete from QRTZ_BLOB_TRIGGERS

delete from QRTZ_CRON_TRIGGERS

delete from QRTZ_SIMPLE_TRIGGERS

delete from QRTZ_TRIGGERS

delete from QRTZ_JOB_LISTENERS

delete from QRTZ_JOB_DETAILS

go

delete from QRTZ_SCHEDULER_STATE;

delete from QRTZ_FIRED_TRIGGERS;

delete from QRTZ_PAUSED_TRIGGER_GRPS;

delete from QRTZ_CALENDARS;

delete from QRTZ_TRIGGER_LISTENERS;

delete from QRTZ_BLOB_TRIGGERS;

delete from QRTZ_CRON_TRIGGERS;

delete from QRTZ_SIMPLE_TRIGGERS;

delete from QRTZ_TRIGGERS;

delete from QRTZ_JOB_LISTENERS;

delete from QRTZ_JOB_DETAILS;

delete from compute_resource_inv;

delete from custom_field_manager_inv;

delete from cluster_compute_resource_inv;

delete from datacenter_inv;

delete from datacenter_network_inv;

delete from datastore_inv;

delete from datastore_profile_inv;

delete from dv_portgroup_inv;

delete from dv_switch_inv;

delete from folder_inv;

delete from managed_server_inv;

delete from managed_server_datastore_inv;

delete from managed_server_network_inv;

delete from network_inv;

delete from resource_pool_inv;

delete from storage_pod_inv;

delete from storage_profile_inv;

delete from task_inv;

delete from vm_inv;

delete from property_map;