Generating Random Data in Linux

I’ve been fleshing out a proper Veeam Backup & Replication Demo lab at work, but doing demos on static VMs isn’t all that much fun and doesn’t really give us much. Doing scheduled backups of non-changing data is really boring.

So, in order to get some changes done on the file system on a few Linux VMs running in the environment, I came up with the following solution:

I set up a crontab entry that generates a file with random data in it a couple of times a day, just to make sure that there are some changes made to the VM. The crontab entry looks like this:

0 03,09,13,22 * * * head -c 1G </dev/urandom >/tmp/randomdata

This generates a 1 GB file called randomdata in /tmp filled with content from /dev/urandom at a couple of different times a day. This ensures that there are at least 1GB of changes for each backup cycle, and gives Veeam Backup & Replication something to work with.

#vDM30in30 progress:

VMware Update Manager: Unsupported Configuration

During an upgrade from vSphere 5.1 to 5.5, I ran into a rather strange issue when trying to utilize VMware Update Manager to perform the ESXi upgrade.

During scanning, VUM reported the ESXi host as “Incompatible”, without offering any other explanation. I spent ages looking through VUM logs, trying to find the culprit, suspecting it was an incompatible VIB. Without finding anything that gave me any indication on what the problem might be, I moved on to looking at the ESXi image I had imported into VUM.

As this was on a Dell PowerEdge R710, I was utilizing the Dell Customized Image of VMware ESXi 5.5 Update 2, which got an updated A02 version last night (27th of August) – I downloaded my image, VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64-Dell_Customized-A00.iso on the 27th, but before the VMware-VMvisor-Installer-5.5.0.update02-2068190.x86_64-Dell_Customized-A02.iso image was available. Thinking this would resolve the issue, I imported the new image into VUM, and created a new Upgrade Baseline. Sadly, I was still greeted by the non-gracious “Incompatible” warning after performing a new scan.

After some more digging, I found the following entry in the Events pane, for the given host, in vCenter:

Error in ESX configuration file (esx.conf).
error
28.08.2015 11:51:25
Scan entity
[hostname]
[username]

Naturally I go digging into the  /etc/vmware/esx.conf file, and found the following entries:

/nas/[oldserver]/readOnly = "false"
/nas/[oldserver]/enabled = "true"
/nas/[oldserver]/host = "[oldserver.fqdn]"
/nas/[oldserver]/share = "/VeeamBackup_[oldserver]/"

 

These references to [oldserver] pointed to an old Veeam Backup & Replication server that was decommissioned ages ago. Veeam B&R adds these to a host if vPowerNFS has been used to mount a backup share, and the entries had not been removed when removing the old Veeam B&R server. DNS resolution for the old server failed, as it has been completely removed from the infrastructure, thus causing the VUM update to fail.

Manually removing these lines from /etc/vmware/esx.conf fixed the problem, and VUM was able to scan and remediate without issues.

Update:

After writing this, I saw Jim Jones had the same experience, for more details read his post:
Unsupported Configuration when using VUM for a Major Upgrade

Preserve your Veeam B&R Backups Jobs when Moving vCenter

This week I´m working at a client site, upgrading their entire existing vSphere 4.1 infrastructure to vSphere 5.1. The customer engagement also includes upgrading Veeam Backup and Replication 6.0 to 6.5, and usually an isolated upgrade of Veeam B&R is a no-brainer next, next, next, done install.

To complicate things in this particular environment, I also had to migrate the vCenter SQL DB from a local MS SQL Server 2005 Express instance to a full-fledged MS SQL Server 2008 R2 instance.

Of course, it was also decided to move the vCenter installation from a physical server, to a VM in the same operation.

To be able to have an exit path, until the vSphere 4.1 hosts management agents, were reconfigured, a new vCenter VM was created with a new IP-adress and server name.

After the migration from vCenter 4.1 to 5.1, and from physical to virtual was completed, the existing Veeam B&R server was upgraded to the latest 6.5 release.

Now, this is where things started to get a bit interesting with regards to the existing Veeam B&R backup jobs.  As far as it was concerned, the new vCenter was unknown and the old one was no longer anywhere to be found on the network.

If you add the new vCenter to the Veeam B&R server, you will need to either redefine all the existing backup jobs by adding the same VM from the new vCenter to the existing job, and keep the old one around until your retention period has passed (and have it fail on the existing VM object until it´s removed) or you will have to recreate all the jobs pointing to the new vCenter instance and start new “first time backups” for all the VMs.

For some reason you simply can not rename/redefine your vCenter connection inside of the Veeam B&R GUI.

Thankfully there is an easy way to work around this issue, without having to mess about with the Veeam B&R database: Create a DNS alias!

That´s right, the solution was that simple. I created a DNS CNAME  alias pointing the old vCenter network name to the new vCenter network name. After doing that, I had to re-enter the credentials for the vCenter connection in Veeam B&R to force a reconnect, and all of a sudden all existing backups jobs where present again and working as intended.

The reason this works, is that when you change the vCenter name and/or IP address (or even move it to a new server) it does not change the VM identification number (vmid) or Managed Object Reference (MoRef), in essence the VMs stay the same and Veeam B&R can continue managing them as before.

Now, can we please get an option to update the registered vCenter name in Veeam Backup & Replication v7.0?

Update:

Check out Veeam vCenter Migration Utility for a small utility to help you move Veeam B&R jobs after replacing your vCenter.