VMware recommends using a snapshot for a maximum of three days. The main reason for justifying this recommendation is related to disk space: snapshots can grow quickly on disk-intensive virtual machines.
But if you read carefully you can also find some performance-related risks. Interesting! We all know more or less that disk performance can be impacted by snapshots. But in which proportions? In order to get some clues, we are going to run some tests and evaluate the performance impact of snapshots by ourselves.
You might be surprised!
Today we are going to install a custom, CA-signed certificate for our new instance of vROps.
VMware published information about the certificate requirements (in short: .pem file, full certificate chain required), as well as a procedure to update the certificate. However this procedure is limited (it does not configure the certificate, for instance), so we are going to develop this part a little bit. As in previous articles, we are using a Microsoft-based certificate authority.
From time to time, the UPS fails with the following symptoms:
- The event viewer (application log) displays the events 6801, 6803 and 6110, in this order.
- The Forefront Identity Manager (found here: C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe) shows failed synchronizations with the status: stopped-extension-dll-exception.
- And of course, updates between SharePoint and Active Directory are not sent anymore.
The best clue is found in the details of the eventID 6801.
In our article series about vSphere Replication, we configured new replications and checked the possibilities for monitoring these replications.
These monitoring possibilities are interesting when you create a new replication, or when you’re in a troubleshooting session. But on the long run, this is not an efficient way to monitor ongoing replications. In this article we will create an alarm to send us an email when the RPO of a replication is violated.
Easy? We’ll see!
In part 4, we configured replications and learned to monitor them. Now it’s time to test a virtual machine recovery!
We will connect to the disaster recovery vCenter and recover a replicated virtual machine. After the recovery test, we will reconfigure the replication by using the existing virtual machine files at destination. This will avoid a new, complete initial replication by replicating only changed blocks.