WilliamLam.com

How to evaluate vSphere Data Protection without DNS?

by // 15 Comments

A fellow colleague of mine was looking to deploy the latest vSphere Data Protection Advanced (VDP[A]) 5.5 in his lab this past week to check out some of the new enhancements made to VDP and interoperability between other VMware solutions. However, he was unable to move forward with his evaluation due to the mandatory DNS requirement for VDP. I can understand the need for having proper DNS in a production or even a POC environment but for a quick evaluation or home lab it is a bit much. In my opinion I think it is a nice to have but it should not be a mandatory requirement.

As part of the networking settings, VDP assumes that configured IP Address is fully resolvable both forward/reverse lookups and manually adding an entry into /etc/hosts will not work. If you try to move forward in the wizard, you will receive this nice error message.

I decided to look into this as I faced a similar challenge in my personal home lab which does not have a DNS Server due to limited resources unlike my remote home lab which has a proper DNS server running. Though we can not get rid of the DNS requirement since it is part of the VDP code, we can however leverage an application found within VDP to help us. This nifty little application is called dnsmasq which is a lightweight server that provides basic DNS, DHCP & TFTP services for a small network which works great for an evaluation or home lab.

Disclaimer: I have been able to verify basic VDP functionality including a complete VM image backup/restore using the method below. However, it is still recommended that you still have proper DNS configured in your environment for in-depth testing of VDP, especially when evaluating for a production environment.

Step 1 - Deploy the VDP OVA as you normally would and when you specify the network configurations, ensure you set the DNS entry to 127.0.0.1 (loop back address) and then you can power on the VM after deployment.

Step 2 - Once VDP is up and running, SSH into the system using root as username and changeme as the password. We will then need to update /etc/hosts to reflect the IP Address/Hostname of our VDP appliance as well as any others you may want VDP to be able to resolve. In my environment I have the following:

192.168.1.104 vdp.primp-industries.com vdp
192.168.1.103 vcenter.primp-industries.com vcenter
192.168.1.200 mini.primp-industries.com mini

Note: I would also recommend adding your "search" domain into /etc/resolv.conf (e.g. search primp-industries.com)

Step 3 - Next we need to edit the dnsmasq configuration file located in /etc/dnsmasq.conf and add the following entry (replace it with the IP Address you have assigned your VDP appliance):

server=192.168.1.104

Step 4 - Finally we just need to start the dnsmasq service as well as enable it to automatically startup on boot by running the following two commands:

/etc/init.d/dnsmasq start
chkconfig dnsmasq on

Step 5 - To confirm that everything has been configured correctly, we will perform both a forward and reverse lookup of our VDP hostname and IP Address. You can do so by using "nslookup" command or any others such as dig or host. In this example, I will be using nslookup and you will need to run the following two commands (ensure to replace it with your hostname/IP Address):

nslookup vdp.primp-industries.com
nslookup 192.168.1.104

Once you have confirmed both forward and reverse lookups are successful, you can then proceed to configuring your VDP appliance by opening a browser to https://[VDP-ADDRESS]:8543/vdp-configure and proceed with moving forward with the VDP configuration wizard.

Note: Ensure that 127.0.0.1 is shown in the VDP configuration UI for the DNS entry. For hostname, you will need to use the short hostname even though a hostname is officially defined as specifying the FQDN

One of the cool new features that I personally wanted to check out is the new emergency Direct-to-Host Emergency Restore functionality. This feature allows you to restore VM backups in the scenario that vCenter Server is not available and one such use case is when you are using VDP to backup vCenter Server itself which I have been able to successfully test in my home lab.

Can You Backup & Restore Apple Mac OS X Guests Using vSphere Data Protection (VDP)?

by // 1 Comment

It is really cool to see more and more customers show interest in running Apple Mac OS X on vSphere. Just the other day there was another interesting question that was raised from a customer asking whether vSphere Data Protection (VDP) would be able to backup and restore Mac OS X guests.  Apparently there is still an assumption that VMware Tools do not exist for Mac OS X guests? Perhaps virtualizing Mac OS X is still relatively new for some folks, but it is just like any other guest operating system that is supported on vSphere.

I think the following two statements should help clarify any confusion that may exist:

  • To virtualize an Apple Mac OS X guest, you need to be running vSphere on Apple hardware. This is due to a requirement in Apple's EULA and is also enforced within the vSphere platform. You can get more details in this article. 
  • VMware Tools does exist for Apple Mac OS X guests, take a look at this article for more details.

Now, if we take a look at VDP's evaluation guide on page 4 we will see the prerequisite for backing up a guest OS is pretty straight forward:

At least one virtual machine running a supported guest operating system (OS) with VMware Tools installed

Since Apple Mac OS X (10.8, 10.7, 10.6 and 10.5) is a supported guest operating system and we have VMware Tools for this operating system, then yes VDP can be used to backup and restore an Apple Mac OS X guest. To demonstrate that this actually works, I have a Mac OS X 10.7 VM running in my home lab (Apple Mac Mini which is not officially supported) and I have deployed the latest version of VDP.

I then setup the backup job for the Mac OS X guests using the super simple VDP backup wizard and then initiate a backup.

Now, let's say I accidentally fat fingered an operation and deleted this VM. Uh oh!? What am I to do? Well don't worry, VDP is there to the rescue!

To restore the VM, it is simply going through the VDP restore wizard and in just a few minutes, I  have now recovered my Mac OS X guest and it is up and running again!

I have said this many times, but it still amazes me on the number of guest operating systems vSphere supports! There really is no workload that vSphere can not virtualize! So if you have any use cases for Mac OS X workloads, rest assure you can safely virtualize it and back it up on vSphere.

Note: Though I showed using VMware VDP as the backup/recovery solution, you should also be able to leverage both VMware vSphere Replication as well as VMware Site Recovery Manager.

number of guest OSes the vSphere platform supports