VM roles are described in .xml files stored in the SbRoles subfolder in the product installation folder. To add a new role, you should create a new .xml file and save it to the SbRoles subfolder.
.xml files describing VM roles have the following structure:
<SbRoleOptions> <Role>
<SbRole>
<Id>4CDC7CC4-A906-4de2-979B-E5F74C44832F</Id>
<Name>Web Server</Name> </SbRole> </Role> <Options> <SbVerificationOptions> <ActualMemoryPercent>100</ActualMemoryPercent> <MaxBootTimeoutSec>300</MaxBootTimeoutSec> <AppInitDelaySec>120</AppInitDelaySec> <TestScripts> <TestScripts> <TestScript>
<Name>Web Server</Name> <Type>Predefined</Type>
<TestScriptFilePath>VmConnectionTester.exe</TestScriptFilePath> <Arguments>%vm_ip% 80</Arguments>
</TestScript>
</TestScripts> </TestScripts>
<HeartbeatEnabled>True</HeartbeatEnabled> <PingEnabled>True</PingEnabled>
</SbVerificationOptions> </Options>
</SbRoleOptions>
Available XML tags are described in the table below.
Tag Required/
Optional Description
<SbRoleOptions> Required Encapsulates the VM role file.
<Role> Required Parent tag for a role assigned to a VM. <SbRole>, <Id> and <Name> are children of this tag.
<SbRole> Required Encapsulates basic information for a VM role – ID and name.
the roles list on the Role tab. <Options> Required Parent tag for startup and test script
options to be used for the defined role. <SbVerificationOptions>,
<ActualMemoryPercent>, <MaxBootTimeoutSec>,
<AppInitDelaySec>, <TestScripts>, <Name>, <Type>, <TestScriptFilePath>, <Arguments>,<HeartbeatEnabled>, <PingEnabled> are children of this tag. <SbVerificationOptions> Required Encapsulates options data for a VM role. <ActualMemoryPercent> Optional Percent of the original memory level set for a production VM that should be pre- allocated to a verified VM on the system boot.
<MaxBootTimeoutSec> Optional Maximum allowed time to boot a VM. <AppInitDelaySec> Optional Maximum allowed time to initialize an
application inside the VM.
<TestScripts> Optional Encapsulates test script data for a VM role.
<Name> Optional Name of a VM role to be displayed on the Test Scripts tab.
<Type> Optional Type of the test script – Predefined or Custom
<TestScriptFilePath> Optional Path to an executable file with a test script to be performed. Can be absolute or relative.
<Arguments> Optional Arguments to be passed to the script. You can use two variables here: - %vm_ip% - IP address of a virtual
lab VM
- %vm_fqdn% — a fully qualified domain name of a virtual lab VM <HeartbeatEnabled> Required Should the heartbeat test be enabled for
this VM role: True or False.
<PingEnabled> Required Should the ping test be enabled for this VM role: True or False.
Performing Universal Application Item-Level Restore
Veeam Backup & Replication 5.0 offers a new technology — U-AIR, or Universal ApplicationItem-Level Restore, that allows you to restore individual items from any virtualized application – Active Directory, Microsoft SQL, Microsoft Exchange and many others. U-AIR does not require any special backups or additional tools – it starts an application and all components required for its proper work in the isolated virtual lab, and connects to the application using its native tools so that users can restore items they need.
For such applications as Active Directory, Microsoft SQL and Microsoft Exchange, U-AIR is a wizard-driven process — that is, you can restore necessary items from applications using Veeam’s wizards. For other applications, U-AIR is user-driven — that is, Veeam Backup & Replication 5.0 starts the application and all required components in the virtual lab so that users can connect to that application and restore items themselves.
U-AIR wizards are not tied to Veeam Backup & Replication 5.0 — these are standalone components that can be downloaded, installed and updated independent of the product release. You can install U-AIR wizards on any machine in the production environment. As a restore procedure requires specific knowledge and is commonly performed by application administrators or users working with these applications, the U-AIR process is distributed between two roles:
• Application administrators or users submit requests for virtual labs in which the required application should run, wait for the request to be approved, and perform the application item-level restore itself when the lab is ready.
• All submitted requests are registered at the Veeam Backup Enterprise Manager server. Portal administrators working with Veeam Backup Enterprise Manager make sure that users who submitted requests are eligible to access the corresponding application’s data backup. After that, they approve or reject lab requests, and select necessary backups and virtual labs where restore should be performed.
To help users who requested virtual labs monitor the state of their request, Veeam Backup & Replication 5.0 offers a special tool — Virtual Lab Manager. Virtual Lab Manager runs on the machine from which the request has been sent and connects to Veeam Backup Enterprise Manager to notify users about the state of their requests. When the request is approved or rejected, a virtual lab is ready or its time elapses, Virtual Lab Manager displays a message hovering over its icon in the system tray.
Virtual Lab Manager is launched once the virtual lab request is submitted and continues running in the background even when the New Virtual Lab Request wizard is closed. Beside monitoring the state of your requests, you can Virtual Lab Manager it to create new virtual lab requests, open ready virtual labs and dismiss unnecessary requests.