Posts tagged vsphere
With the release of vSphere 5.1, VMware has retired VMware Data Recovery (VDR) and replaced it with vSphere Data Protection (VDP). From my experience, there were not a lot of fans of the old VMware Data Recovery product, so this is a welcomed change. I decided to give it a spin, and see how it stacks up and what quirks there are in the first release.
The virtual appliance comes in three options that correspond to the size of the storage available to store backups: .5TB, 1TB, and 2TB. This sizing is a drawback as there is no way to increase the capacity of the appliance’s attached storage after installation other than adding another appliance.
The appliance can only backup to the attached VMDK, and it cannot backup directly to CIFS, etc. Of course, the CIFS space could be presented as an NFS share to the ESXi host(s) and then the VMDK stored on top, but this is rather kludgy.
Each vCenter can support up to 10 VDP appliances and up to 100 VMs per appliance (1000 total). It’s worth noting that this is the supported limit and not a hard limitation; VMware has not done testing beyond the aforementioned number and will not support more. vCenter 5.1 and the Web Client are required, but will work with ESX >=4.0 hosts.
There are some interesting aspects of the configuration:
- Password requirements: It requires an exactly nine character (no less, no more) password.
- DNS: Both forward AND reverse lookups must work.
Management is done through the vSphere Web Client, and is not possible through the classic Windows client. The interface is rather straight to the point with not a lot of flare or advanced features.
Deduplication is built-in, but only works within each appliance; for example, data backed up on appliance[n] will not be deduped against data on appliance[n+1].
When creating backup jobs, there is no built-in way to exclude certain VMDKs: it is all or nothing. Six concurrent backups can occur at a time. There is also no way to tell the job not to quiesce the guest, etc.
Only one backup per virtual machine can run each day, as there is no granularity for multiple backups per day. This may be a problem for some.
File-level recovery requires logging in to the appliance from the guest VM that needs the file restored. Individual files cannot be restored from the appliance in the same manner a full virtual machine can be restored. Compared to other products, this is a very different way to restore individuals files, and is rather inconvenient especially for Linux guests that don’t have a GUI. There is no way to restore from the command-line currently.
The actual functionality of VDP is solid on a great base with EMC Avamar’s engine, and it’s a good product despite the aforementioned. It is limited in what it can do in this release, lacking many simple features that are available in other products (selecting only certain VMDKs, multiple backups scheduled per day, better file level recovery, more granular options on jobs,etc). It is also missing the advanced functionality in other products (running from backup, catalogue of files, etc). It’s likely a great fit for many SMB environments that just need no-frills VM backups, but until it matures in certain areas it is probably best to stick with Veeam, PHD Virtual, or others for more advanced needs.
- VMware KB: VMware Data Protection (VDP) FAQ
- VMware KB: Required ports for vSphere Data Protection 5.1
- VMware vSphere Blog: Setting the record straight on VMware vSphere Data Protection
- Document: vSphere Data Protection 5.1 Release Notes
- Document: vSphere Data Protection 5.1 Administration Guide
I ran into this error when upgrading one of our hosts to ESXi 5.0 from 4.1u1 via format and re-install. Everything joined back normally, I was able to vMotion machines back onto the new host, etc.; however, once I tried to open the console I was greeted with: Unable to connect to the MKS: The remote host certificate has these problems: *unable to get local issuer certificate * Host name does not match the DNS name in certificate.
After some tinkering (and googling to no avail), my solution was to reboot the host, remove the host from vCenter, and then re-add the host back. I believe the issue was compounded by a couple of unique issues, but I’ll spare the boring details on reproducing. Simple fix, but since I wasn’t able to find a solution when googling the error message, I figured it would be worth tossing this blog post up to hopefully expedite someone else’s troubleshooting.
Update (8/23/12): A reader sent me an email saying they ran into the issue due to the following as well: “In my case in turned out to be a local hosts file had an entry for one of the esxi hosts that was pointing at the wrong IP.”