Introduction
In this blog we will show to fix the error “Index:0, Size: 0” issue in VMware Cloud Director. This issue will prevent users to make changes on the Organization Tenant VM’s.
Issue
If we go to a organization within VMware Cloud Director and we want to make changes (cpu, ram, hard disks or anything else) to a VM we will receive a error “[ f14cfa58-9afa-4730-98ce-0f69347775f9 ] Index 0 out of bounds for length 0”.
Solution
Warning! Before starting with the solution, always make sure to make a snapshot of all the VMware Cloud Director Cells!
Obtaining "dstore_moref" information from impacted VM's
First we need to obtain all the impacted vm’s. We can do this by accessing the Cloud Director database tables. Impacted vm’s will have a empty “dstore_moref” column.
1. Start a SSH session to the Primary Cloud Director Cell.
2. Switch to the “Postgres” user by running:
su - postgres
3. Start Postgres and open the “vcloud” table by running:
psql vcloud
4. Obtain all the vm’s that have a empty “dstore_moref” value by running:
You will get a list of all the vm’s with there associated id.
select vm.id,vm.name,datastore_inv.moref FROM vm
inner join vapp_vm on vapp_vm.svm_id = vm.id
inner join vm_inv on vm_inv.moref = vm.moref
inner join datastore_inv on datastore_inv.vc_display_name = (substring(vm.location_path,2,(POSITION(']' in vm.location_path))-2))
where vm.dstore_moref is NULL and vm_inv.is_deleted is false;
5. Now we have a complete list of all the impacted vm’s with their id, name and moref datastore.
Here is a output example:
id | name | moref
--------------------------------------+--------------------------------------------------+-----------------
d6259566a-9826-8845-98b9-9a0b445b803c | dash-demovm-m6g4 | datastore-1935
Fixing the issue on a per-VM basis.
In this part we will fix the issue on a per-vm basis. This can be useful in cases where a faulty outcome is not tolerated or if you want to test the results for the first time.
1. Start a SSH session to the Primary Cloud Director Cell.
2. Switch to the “Postgres” user by running:
su - postgres
3. Start Postgres and open the “vcloud” table by running:
psql vcloud
4. If your list of impacted vm’s from the previous step is to big to find your vm, you can filter one specific vm by running:
Replace the ‘%dash-demo%’ with your vm name.
select 'update vm set dstore_moref = ' || '''' || datastore_inv.moref || '''' || ' where id = ' || '''' || vm.id || '''' || ';' from vm
inner join vapp_vm on vapp_vm.svm_id = vm.id
inner join vm_inv on vm_inv.moref = vm.moref
inner join datastore_inv on datastore_inv.vc_display_name = (substring(vm.location_path,2,(POSITION(']' in vm.location_path))-2))
where vm.dstore_moref is NULL and vm_inv.is_deleted is false and vm.name like '%dash-demo%';
5. Now we receive the command to implement the fix.
It should look something like this:
update vm set dstore_moref = 'datastore-1935' where id = 'd6259566a-9826-8845-98b9-9a0b445b803c';
An alternative method is to run the following command:
This will allow you to create the command manually.
Replace the ‘%dash-demo%’ with your vm name.
select vm.id,vm.name,datastore_inv.moref FROM vm
inner join vapp_vm on vapp_vm.svm_id = vm.id
inner join vm_inv on vm_inv.moref = vm.moref
inner join datastore_inv on datastore_inv.vc_display_name = (substring(vm.location_path,2,(POSITION(']' in vm.location_path))-2))
where vm.dstore_moref is NULL and vm_inv.is_deleted is false and vm.name like '%dash-demo%';
Now we have all the information we can create the fix command:
Copy the datastore name from the previous result and replace the ‘datastore-1935’ below.
Copy the id from the previous result and replace the ‘d6259566a-9826-8845-98b9-9a0b445b803c’ below.
update vm set dstore_moref = 'datastore-1935' where id = 'd6259566a-9826-8845-98b9-9a0b445b803c';
6. Copy the command and paste it in the command line.
7. Run this command.
8. You will get a response like “UPDATE 1”. This means there is 1 update performed in the database.
9. Go back to Cloud Director Organization and try to change cpu, ram or hard disk settings on the vm.
10. Everything should update fine now without any errors.
Fixing the issue for all VM's at once.
In this part we will fix the issue for all vm’s at once. After you have tested one vm and it is safe to perform this on all the vm’s you can use this guide.
1. Start a SSH session to the Primary Cloud Director Cell.
2. Switch to the “Postgres” user by running:
su - postgres
3. Start Postgres and open the “vcloud” table by running:
psql vcloud
4. Get all the commands at once by running:
select 'update vm set dstore_moref = ' || '''' || datastore_inv.moref || '''' || ' where id = ' || '''' || vm.id || '''' || ';' from vm
inner join vapp_vm on vapp_vm.svm_id = vm.id
inner join vm_inv on vm_inv.moref = vm.moref
inner join datastore_inv on datastore_inv.vc_display_name = (substring(vm.location_path,2,(POSITION(']' in vm.location_path))-2))
where vm.dstore_moref is NULL and vm_inv.is_deleted is false;
5. Now we receive all the commands to implement the fix for all vm’s at once.
update vm set dstore_moref = 'datastore-1935' where id = 'd6259566a-9826-8845-98b9-9a0b445b803c';
update vm set dstore_moref = 'datastore-1935' where id = 'd6259566a-9826-8845-98b9-9a0b445b803c';
update vm set dstore_moref = 'datastore-1935' where id = 'd6259566a-9826-8845-98b9-9a0b445b803c';
6. Copy the complete output.
7. Run this commands.
8. You will get a response like “UPDATE” with a number behind it. The number represents the number of updates, that have been performed in the database.
9. Go back to Cloud Director Organization and try to change cpu, ram or hard disk settings on one of the vm’s.
10. Everything should update fine now without any errors.
