Since Microsoft introduced VSS libraries, it’s a smart way of doing backup using them, in order to guarantee a consistent backup of applications supporting them.
Veeam can do backups without the help of permanent agents inside the virtual machines, anyway if you want to do a VSS-based backup, Veeam deployes (and removes when the backup is completed) a small agent in the Windows VM in order to cohordinate VSS tasks. Usually, this is done by connecting to the target VM via network.
But, what happens when for any reason Veeam is in another network of the one used by the virtual machine, or they cannot communicate to each other? For example an IIS webserver in a DMZ network that cannot be reached from the network where Veeam server is connected to?
In these situations we can really appreciate VMware VIX libraries, and the way Veeam decided to use them. I found this quite old article , dated 2008, they noentheless explains in an awesome way what those libraries can do. Basically, they allow for direct interaction between the guest operating system inside a VM using the hypervisor running it, without any need for network connectivity. Among the several activities you can do, you can copy files, start and stop services, and run programs inside the guest VM.
Veeam has taken advantage of these libraries to allow VSS-based backups, even when the VM cannot be reached via network. To show you this, I created a small test in my lab, by deploying a Windows 2008 R2 VM with no network connection at all:
I then configured a quick backup job in Veeam, without any custom parameter other than the use of VSS libraries, just to see what was going to happen:
The backup was “simply” complteted successfully. To be honest, Veeam first tries to connect as usual via RPC, but right because the VM does not have any IP address, it fails and it then tries to use VIX libraries. You can appreciate the intimate procedure by looking at the relevant log parts:
[24.06.2013 14:00:20] <01> Info [VssGAConn('vix-test')] Initializing VSS guest agent connection.
[24.06.2013 14:00:20] <01> Error Failed to connect to guest agent: unable to obtain guest IP address. at Veeam.Backup.VssProvider.CVssGAConnection.ConnectViaRpc
[24.06.2013 14:00:20] <01> Error at Veeam.Backup.VssProvider.CVssGAConnection.CreateEx
[24.06.2013 14:00:20] <01> Info [VssGAConn] Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKSadministrator', vmVmx '[qnap259] vix-test/vix-test.vmx', vmUser 'vix-testadministrator'
[24.06.2013 14:00:20] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKSadministrator].
[24.06.2013 14:00:26] Info Temporary file [C:UsersADMINI~1AppDataLocalTempvmware161] created.
[24.06.2013 14:00:26] Info Copying files form host [C:Program FilesVeeamBackup and ReplicationVSSVeeamGuestAgentsVeeamVixProxy.exe] to guest [C:UsersADMINI~1AppDataLocalTempvmware161].
[24.06.2013 14:00:27] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKSadministrator].. Ok.
[24.06.2013 14:00:27] Info Enter CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:00:28] Info Temporary file [C:UsersADMINI~1AppDataLocalTempvmware185] created.
[24.06.2013 14:00:28] Info Running program [C:UsersADMINI~1AppDataLocalTempvmware161 -func GetServiceState -out "C:UsersADMINI~1AppDataLocalTempvmware185" -svcname "VeeamVssSupport"].
[24.06.2013 14:00:30] Info Copying files form guest [C:UsersADMINI~1AppDataLocalTempvmware185] to host [C:WindowsTEMPifd4720.tmp].
[24.06.2013 14:00:31] Info Deleting file [C:UsersADMINI~1AppDataLocalTempvmware185] in guest.
[24.06.2013 14:00:32] Info Leave CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:00:32] <01> Info VssGAConn('vix-test')] Agent state: 'EVeeamVssNotInstalled'.
[24.06.2013 14:00:32] <01> Info [VssGAConn('vix-test')] Installing agent.
[24.06.2013 14:00:32] Info Enter CVeeamVssGAInstaller::Install
[24.06.2013 14:00:32] Info Installing agent.
As you can see, since the RPC connection has failed, Veeam connects to vCenter (10.2.50.111) and from here to the VM via VIX, using the same credentials I specified in the job (vix-testadministrator), since the VM is not joined to my lab domain “SKUNKWORKS”. VIX connection is successful, and Veeam is able to install the temporary agent into the VM.
How cool is that?
If you also want to remove the initial error, and save some seconds in the job execution, since Veeam Backup & Replication v6.1 patch 1 (build 6.1.0.205) you can switch the VSS connection order, telling Veeam to try VIX connection first. You can see how to do it in the release notes of that build:
Added new registry value that reverses the sequence of application-aware processing, making jobs try network-less processing mode before network one. HKEY_LOCAL_MACHINESOFTWAREVeeaMVeeam Backup and Replication DWORD: InverseVssProtocolOrder Value = 1 To disable (default behavior), value is 0 (false)
So, after I configured the new registry key as described, I run again the same backup job:
First thing you can see, “Preparing guest for hot backup” now lasted 15 seconds instead of 21, meaning something has really changed. But, as before, the detailed log is where you can appreciate the configuration change:
[24.06.2013 14:39:16] <01> Info [VssGAConn('vix-test')] Initializing VSS guest agent connection.
[24.06.2013 14:39:17] <01> Info [VssGAConn] Connecting to guest via vix, hostIp '10.2.50.111', postPort '443', hostUser 'SKUNKWORKSadministrator', vmVmx '[qnap259] vix-test/vix-test.vmx', vmUser 'vix-testadministrator'
[24.06.2013 14:39:17] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKSadministrator].
[24.06.2013 14:39:24] Info Temporary file [C:UsersADMINI~1AppDataLocalTempvmware175] created.
[24.06.2013 14:39:24] Info Copying files form host [C:Program FilesVeeamBackup and ReplicationVSSVeeamGuestAgentsVeeamVixProxy.exe] to guest [C:UsersADMINI~1AppDataLocalTempvmware175].
[24.06.2013 14:39:25] Info Connecting to host [10.2.50.111] over VIX library. Login: [SKUNKWORKSadministrator].. Ok.
[24.06.2013 14:39:26] Info Temporary file [C:UsersADMINI~1AppDataLocalTempvmware215] created.
[24.06.2013 14:39:26] Info Running program [C:UsersADMINI~1AppDataLocalTempvmware175 -func GetServiceState -out "C:UsersADMINI~1AppDataLocalTempvmware215" -svcname "VeeamVssSupport"].
[24.06.2013 14:39:28] Info Copying files form guest [C:UsersADMINI~1AppDataLocalTempvmware215] to host [C:WindowsTEMPifd6AC3.tmp].
[24.06.2013 14:39:29] Info Deleting file [C:UsersADMINI~1AppDataLocalTempvmware215] in guest.
[24.06.2013 14:39:30] Info Leave CVeeamVssGAInstaller::GetGateState
[24.06.2013 14:39:30] <01> Info VssGAConn('vix-test')] Agent state: 'EVeeamVssNotInstalled'.
[24.06.2013 14:39:30] <01> Info [VssGAConn('vix-test')] Installing agent.
You can see as now Veeam has started first to connect via VIX libraries, without trying first a connection via network.
So, if you have several virtual machines you cannot reach via network, maybe you can configure Veeam to use VIX libraries as its primary backup mode for VSS.