SimpliVity Primary and Secondary containers

[jlangmead]

Hi

If I have a VM that has the primary container on host 1 and the secondary container on host 4 is there an easy way to reverse this? I want to keep the containers on the same two hosts but now want the VM to be hosted on host 4. If I migrate the VM to host 4 will the resource balancer simply reverse the replication and make the secondary now the primary or does it need some additional configuration?

many thanks

[DeclanOR]

Hi @jlangmead 

Thanks for your query.

vMotioning the VM where the primary copy is hosted to the hots where the secondary copy is hosted will flip the primary and secondary data copies. No additional configuration is needed. You can confirm by running the dsv-balance-manual command before migration and 5-10 mins post migration to confirm.

Hope this helps.

Thanks,

DeclanOR

[jlangmead]

Thanks Declan

Is that feature in all versions? This is on a 3.7.2 cluster and we're not seeing that. We've tried it on different VMs across different hosts and none of then are being updated in the balance table. It shows the VM on the node that is running the secondary with an * next to it denoting that it's not optimized.

If it should work on a 3.7.2 cluster is there a particular service that manages this process that I can check is running? We're soon going to be upgrading to 3.7.9 

kind regards

Jon

[DeclanOR]

Hi @jlangmead 

Based on what you're saying, the VM's are already running on a node where neither their secondary or primary data copies are ocated. This is what the asterix signafies and results in the "data access not optimized" mesage. This basically means that the VM is proxying IO, as the VM is not running on a node where it's primary or secondary data copies are located.

For any of the VM's showing an asterix, take note of where the P or S copy is. Migrate the VM to that host. Once done for all, you can begin using the method I mentioned earlier.

Thanks,

DeclanOR

[jlangmead]

Thanks - we're aware that some of our VMs aren't on their primary host due to some unrelated current constraints but we do see several VM's that don't seem to comply with what you're saying. Below is an example - VM numbers 1, 27, 28 and 40 (there are others no in the screenshot) indicate that the VM is being hosted on the node containing the secondary (and we've confirmed this using the nodeIP) yet still show the asterix (for example 'Guest VM 1' is on node 6 where the secondary is). When migrated to the node where the Primary is hosted (node 3 for 'Guest VM 1) then the asterix goes but comes back when we move it back to where the secondary container should be.

[DaveOb]

Are the VMs powered off ?

Do they have vmdks on multiple datastores ?

[jlangmead]

Hi Dave

None of them are powered off but I believe many of our VMs have VMDKs across multiple datastores - what are the implications of having VMs configured in this manner when it comes to Primary and Secondary containers?

many thanks

[db13 · Accepted solution]

@jlangmead 

1. Are the VMs with the asterisks those that have vmdks residing in a datastore or folder not containing the VM's vmx file?

2. Are there any ISOs stored in a SimpliVity datastore attached to the VMs in question?

If any of these VMs have nothing attached to cd-rom, and no vmdks outside of the VMs main folder (containing the vmx file), then I would suggest opening a ticket with support to have a deeper look into it.

[jlangmead]

Thanks for the ongoing support

I think I can close this - we actually found some more fundemental communication issues between vCenter and the Simplivity nodes (some VM's were not showing any SimpliVity options in the drop down menu whilst others were) - these have now been remediated and, although I've not checked, I suspect the vm's that were showing the asterisks were those that were being affected by the comm's issues.

thanks very much again