Ein Schritt für Schritt walkthrough durch einen Case, bei dem die VM und vApp auf unresovled stand.
Jeder der mit VMware Cloud Director arbeitet, kennt ein wenig das Thema mit den unresolved VMs und vApps. Wer MSSQL nutzt, der wird das irgendwie mit den Management Tools irgendwann nachvollzgogen haben. Für die, welche aber auf der Konsole arbeiten und nicht pgAdmin im Einsatz haben, die können sich mal an dem hier versuchen.
Warnung
arbeiten an der Db können dazu führen, dass der vmware cloud director zerstört wird. wenn du nicht mit Datenbanken vertraut bist, dann ist das hier nichts für dich. Für alle anderen, denkt bitte an den fallback wie snapshot, db Backup und backup überhaupt.
Zuerst verbinden wir uns auf die Appliance via ssh, auf der die Primary DB läuft. Anschliessend wechseln wir in den postgres Kontext und verbinden uns mit der vcloud DB. Der Syntax \x aktiviert die Extendend View für Querys
sudo su - postgres
psql vcloud
\x
Mein Fall beschäftigt sich darum, die vApp steht auf unresolved, lässt sich nicht löschen, ebenfalls darin enthaltene VM steht auf undresolved, lässt sich ebenfalls nicht löschen.
Die erste Abfrage soll mal aufzeigen, ist in der Tabelle vapp_vm ein Eintrag verfügbar, der auf “DELETING_CONTENTS” gesetzt wurde, während dem die Kindobjekte gelöscht werden sollten. Hier ging dann irgendwas schief, dass es nicht mehr zum Löschen des VM Eintrags kam.
select * from vapp_vm where creation_status like 'DELETING_CONTENTS';
-[ RECORD 1 ]-----------------+-------------------------------------
id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
vapp_scoped_vm_id | 6a70753e-8cd0-49a7-be9a-357c4ab722a0
vapp_id | 02dd7f92-a494-4344-85e7-e2d11e7f96b6
creation_status | DELETING_CONTENTS
name | UNRESOVLED-VM
descr |
is_autoconfig | f
boot_order | 0
boot_delay | 0
boot_action | 1
stop_delay | 0
stop_action | 2
version_number | 12
storage_class_lr_id | 6877b8b3-7684-475c-b96d-baeab2dfd9db
cvm_id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
nvm_id | 07666301-63b0-4dfb-b7a5-5864b488e902
svm_id | 64ffb2e0-b0ee-4bdb-9eb8-a35a93ec3a45
ovf_env |
ovf_env_transports |
needs_customization | f
computer_name | UNRESOVLED-VM
default_storage_class_name |
last_marker |
date_created | 2019-09-07 07:56:35.79
memory_configured_mb | 2048
check_post_gc_status | f
vdc_compute_policy_id | 22650375-41d5-4e8c-8531-3f0494f69fb5
vcpu_speed_mhz |
vm_sizing_policy_id |
is_compute_policy_compliant | t
is_compute_policy_immutable | f
is_vm_sizing_policy_immutable | f
Der Eintrag zeigt: ja da ist ein Eintrag. Von diesem Eintrag nehmen wir nun die ID mit und erstellen den Query zum Entfernen des Eintrags in der Tabelle vapp_vm.
delete from vapp_vm where id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
ERROR: update or delete on table "vapp_vm" violates foreign key constraint "guest_pers_info_vapp_vm_fk" on table "guest_personalization_info"
DETAIL: Key (id)=(9fa850ad-5b3f-4f0d-91e7-282c333565a1) is still referenced from table "guest_personalization_info".
Das schlug nun aber entsprechend fehl mit der Bemerkung: Achtung da sind noch Fremdschlüssel vorhanden, die müssen zuerst weg. Sprich die Relations wurden hier vom VMware wunderbar eingehalten und leitet und jetzt eigentlich Schritt für Schritt zum Ziel
Wir nehmen nun die genannte Tabelle, mit der gleichen id wie vorhin, jedoch nun als vapp_vm_id und suchen den entsprechenden Eintrag.
select * from guest_personalization_info where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
-[ RECORD 1 ]------------+-------------------------------------
id | 15e977d6-bdc3-431c-9753-22cd3c86749d
domain_name |
user_name |
domain_user_password | KkgS3ITJN8i/YCmLoIHFcA==
domain_machine_ou |
reset_password | f
change_sid | f
domain_join_enabled | f
use_org_settings | f
custom_script |
admin_password_enabled | f
admin_password | f4eQfeDcf7gDOTU5z3+T5w==
admin_password_auto | t
vapp_vm_id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
admin_auto_logon_enabled | f
admin_auto_logon_count | 0
Da haben wir tatsächlich einen Eintrag, nun wird der Query zum Löschen umgebaut und der Eintrag ins Nirvana geschickt.
delete from guest_personalization_info where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
DELETE 1
Nun versuche ich wieder, den VM Eintrag zu löschen, in der Hoffnung, dass dieser nun gelöscht wird.
delete from vapp_vm where id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
ERROR: update or delete on table "vapp_vm" violates foreign key constraint "fk_va_vm_di_st_c2vapp_vm" on table "vapp_vm_disk_storage_class"
DETAIL: Key (id)=(9fa850ad-5b3f-4f0d-91e7-282c333565a1) is still referenced from table "vapp_vm_disk_storage_class".
Und schon wird die nächste Relation angezeigt, die lasse ich mir wieder bestätigen, genau gleich wie oben.
select * from vapp_vm_disk_storage_class where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
-[ RECORD 1 ]-------+-------------------------------------
bus_type | 4
bus_number | 0
unit_number | 0
vapp_vm_id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
storage_class_lr_id | 6877b8b3-7684-475c-b96d-baeab2dfd9db
version_number | 1
-[ RECORD 2 ]-------+-------------------------------------
bus_type | 4
bus_number | 0
unit_number | 1
vapp_vm_id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
storage_class_lr_id | 6877b8b3-7684-475c-b96d-baeab2dfd9db
version_number | 1
Ganz interessant, hier haben wir nun 2 Einträge, sprich die VM hatte 2 Disks, die Einträge werden nun auch entsprechend gelöscht.
delete from vapp_vm_disk_storage_class where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
DELETE 2
Die beiden Einträge sind nun weg, also gehen wir weiter und versuchen wieder, den VM Eintrag zu entfernen.
delete from vapp_vm where id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
ERROR: update or delete on table "vapp_vm" violates foreign key constraint "fk_vap_vm_scl_me2vapp_vm" on table "vapp_vm_sclass_metrics"
DETAIL: Key (id)=(9fa850ad-5b3f-4f0d-91e7-282c333565a1) is still referenced from table "vapp_vm_sclass_metrics".
Schlägt erneut fehl, wenn wir aber bei der vapp_vm_sclass_metrics angekommen sind, ist das in der Regel die letzte Referenz, die weg muss, sprich du bist bald am Ziel.
select * from vapp_vm_sclass_metrics where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
-[ RECORD 1 ]-------+-------------------------------------
vapp_vm_id | 9fa850ad-5b3f-4f0d-91e7-282c333565a1
storage_class_lr_id | 6877b8b3-7684-475c-b96d-baeab2dfd9db
storage_used_mb | 122880
Wieder prüfen, der Eintrag ist bestätigt, also den Query zum Löschen abändern auf die Tabelle und weg damit.
delete from vapp_vm_sclass_metrics where vapp_vm_id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
DELETE 1
So und dann beginnen wir wieder von vorne, der Eintrag der VM löschen.
delete from vapp_vm where id = '9fa850ad-5b3f-4f0d-91e7-282c333565a1';
DELETE 1
Perfekt, der Eintrag ist weg, die VM ist jetzt nicht mehr in der vApp vorhanden, dass können wir im VMware Cloud Director auch prüfen.
Nun damit wir nicht noch weiter in der Datenbank herumdrücken müssen, lösen wir nun das Problem der vApp, damit diese wieder auf resolved steht.
select * from vm_container where name like 'vApp';
-[ RECORD 1 ]-------------+----------------------------------------------
sg_id | 02dd7f92-a494-4344-85e7-e2d11e7f96b6
name | vApp
descr |
user_id | 6d352d6c-a1f2-4777-bd5b-cec43fd18c5c
sg_type | 1
shared_count | 0
is_enabled | t
date_created | 2020-09-08 16:39:52.73
honor_boot_order | f
vmfolder_moref | group-v86966
vmfolder_vc_id | 76a08c28-31a9-4fc9-90b9-4e6139ffcd27
auto_undeploy_ticks |
auto_undeploy_date |
auto_delete_ticks |
auto_delete_date |
is_auto_undeploy_notified | f
is_auto_delete_notified | f
org_id | 7c76d8c7-a16d-4c54-aaf5-2e2ca257950e
org_vdc_id | 9741cb96-5e9c-4452-9d65-2ea4bf97d0fc
is_gold_master | f
fence_must_be | f
version_number | 5
creation_status | DELETING_CONTENTS
transfer_session_id |
is_manifest_required | f
uniquename | 7c76d8c7-a16d-4c54-aaf5-2e2ca257950e|DummyApp
customize_on_instantiate | f
is_deployed | f
in_maintenance_mode | f
auto_nature | f
linked_vapp_id |
is_generated_by_move | f
Dazu überschreiben wir einfach den creation_status von DELETING_CONTENTS auf RESOLVED.
update vm_container set creation_status = 'RESOLVED' where sg_id = '02dd7f92-a494-4344-85e7-e2d11e7f96b6';
UPDATE 1
Nun hat sich auch der Zustand im vCloud Director geändert, Aber wie es sein muss, kann der Eintrag nicht gelöscht, nun sagt der Cloud Director aber auch klar, woran das ganze liegt. im vCenter ist noch die VM vorhanden, sprich die muss zuerst weg.
[ f482f766-6a2d-4c48-88d4-364f49318729 ] Failed to delete folder [vcId=76a08c28-31a9-4fc9-90b9-4e6139ffcd27, moref=group-v86966] from vCenter Server. - Could not delete folder "vApp(02dd7f92-a494-4344-85e7-e2d11e7f96b6)" because it contains: child "vm-14702"Ab uns vCenter und die entsprechende VM entfernen. Dann ein erneuter Versuch, die vApp im Cloud Director zu entfernen und die Hartnäckigket hat sich gelohnt, Die vApp wurde entfernt.
thanks, just what I was looking for. worked perfectly