Archive for March, 2011

eql_modifyvolume

Shrinking Equallogic Volumes

Mar 28th

Posted by eeg3 in Storage

Shrinking a volume is not available via the Equallogic GUI.

To do so, it must be done via the CLI. Telnet into the group, and select the volume that is to be shrinked.

You must then put the volume offline (in this case, I put the volume offline via the GUI already). To shrink the volume, simply execute:

shrink 1234G

The size to put here is the total size you want the volume to be after the shrink, it is NOT the size you want to shrink the volume by. Additionally, put a G or M after the size to specify the unit.

A snapshot is automatically created prior to the shrink, and can be deleted after testing. This obviously doesn’t cover the necessary steps to shrink the partition residing on the volume, which can vary depending on the format.

,
adamreplicate_failure

VMware View ADAM Database Replication

Mar 20th

Posted by eeg3 in Virtualization

When using multiple Connection Servers in View, things can get wonky if replication of the ADAM database stops occurring. The ADAM database stores the majority of the configuration for View, and as such is very important. When replication stops occurring, if users log in to connection servers that have stopped getting replication information then they could receive improper pool listings. Also, obviously, configuration changes will not be pushed out. We ran into this recently with our main connection server not wanting to replicate to our replica server, and we saw both of the issues above (as well as some other oddities).

To see the status of replication on each of your connection servers, you can console them and bring up a command line and run:

C:\WINDOWS\adam\repadmin.exe /showrepl localhost:389 DC=vdi,DC=vmware,DC=int

This should show results similar to the following if you’re having replication failures:

From this you can see that your connection server is unable to replicate to the specific replica (in this case, VIEWCS). In this particular case, this was caused by the replica server being turned off but not removed. Many other errors can show up, and this is great information to use when troubleshooting what is causing the failure. Some other issues that can cause replication failures (this is not an exhaustive list, but just a few of many):

  • Firewall blocking connectivity between the two servers
  • Ambiguous DNS (pointing to multiple IPs)
  • Kerberos issues

When trying to resolve these issues, you can manually force replication both-ways by executing the following:

C:\WINDOWS\adam\repadmin.exe /replicate local-host.fqdn.com:389 remote-host.fqdn.com:389 dc=vdi,dc=vmware,dc=int

C:\WINDOWS\adam\repadmin.exe /replicate remote-host.fqdn.com:389 local-host.fqdn.com:389 dc=vdi,dc=vmware,dc=int

If all goes well, you should see the following:

It seems when things really go wrong in View, administrators can end up needing to get their hands dirty with the ADAM database. Some other VMware KB articles requiring ADAM tinkering:

, , ,