Continuing from my previous post on using vMA as a local vSphere patch repository, I wanted to explore further how to utilize rsync to ensure that all vMA instances have the same set of patches. As mentioned earlier, rsync is a great tool for this purpose due to its ability to handle fast incremental file transfers, which is particularly useful in my scenario where bandwidth and latency can be an issue.

To get started, we need to install rsync on our vMA instances. Unfortunately, rsync is not included in vMA by default, so we need to edit some files inside of vMA to enable its installation. Since vMA is based on CentOS, we need to configure yum repositories to install official packages directly from CentOS. Thankfully, William Lam at virtuallyGhetto has already provided the necessary instructions for creating a valid repository configuration.

To create the file, navigate to the correct directory and run the following command:

“`

sudo vi /etc/yum.repos.d/central.repo

“`

Once the editor opens, add the following lines to the file:

“`

[rsync]

name=RSYNC

baseurl=https://download.opensuse.org/repositories/sysadmin:/tools/CentOS/$releasever/$basearch/

gpgcheck=1

gpgkey=https://download.opensuse.org/repositories/sysadmin:/tools/CentOS/$releasever/$basearch/openSUSE-LEASE-signing.key

enabled=1

“`

Exit the editor by hitting esc and entering `:wq` and hit enter. This saves the file and enables the rsync repository.

Now that we have rsync installed, we need to configure it to fetch updates from a central vMA instance. Since both ends of the pipe (client and master vMA) need to have rsync installed, make sure to follow the same steps on both instances.

On the client vMA instance, run the following command to start the rsync process:

“`

sudo rsync -avz –delete /vmfs/volumes/patches/ /vmfs/volumes/patches/client/

“`

This command pulls down all the files currently in the repository on the “master vMA” and places them in the “client vMA” repository. The `-a` option tells rsync to preserve file attributes, while `-v` increases verbosity and `-z` compresses the data. The `–delete` option deletes any files that no longer exist in the source repository.

Once the rsync process finishes, you should see that the current contents of the “master vMA” repository is now located in the “client vMA” repository as well. This means that all vMA instances now have the same set of patches, and any new updates can be pushed to the central instance and automatically replicated to remote instances using rsync.

There are many more advanced use cases for rsync that can help admins centrally manage distribution of vSphere patches to remote locations. Some examples include replication files both ways, controlling bandwidth usage, and using ssh keys to avoid username/password prompts. For more information on these features and more, head over to the rsync site for documentation.

In conclusion, using rsync with vMA instances provides a reliable and efficient way to ensure that all vMA instances have the same set of patches. With rsync installed, admins can centrally manage distribution of vSphere patches to remote locations, even in low-bandwidth or high-latency environments. While this post only scratches the surface of what rsync can do, it’s clear that this tool is a valuable addition to any vAdmins toolset.