1. Support
  2. Knowledge base
  3. 100010856

Performing Physical to Virtual (manual P2V) restores using Bare Metal Restore (BMR)

Article: 100010856
Last Published: 2019-12-18
Ratings: 1 0
Product(s): NetBackup

 

 

Problem

This article gives specific guidance for doing client image restores to a VMWare Virtual Machine (VM). The information is VMware centric but can act as a template for other supported virtual environments.  It builds on existing documentation for doing Dissimilar Systems Restores (DSR) using BMR.  This article does not cover the auto P2V conversion option that is new to NBU/BMR 7.6 releases.

Solution

The related articles noted for this article are for DSR activities in general. across all supported platforms. This article is additional information when the recovery is to a virtual instance.

1. To BMR, the VMWare virtual hardware is invisible to BMR. It is not cognizant that it is virtual. The VMWare Hypervisor presents this all as physical hardware and BMR acts upon in the same manner.
 
2. You MUST always use a copied version the client’s original restore configuration (“current”). Use the instructions in the related TECH articles on how to make the proper changes.
 
3. When choosing a MSD adapter, the recommended action is to specify the LSI Logic SAS (lsi_sas) MSD adapter versus the LSI Logic Parallel (lsi_scsi) or VMware Paravirtual (pvscsi) SCSI adapter. The driver sets for the LSI cards are already resident in the BMR SRT at all NBU 7.X releases and should be a Windows native driver for restore purposes.
 
4. When choosing a NIC adapter, the recommendation is to use the Intel E1000 as the working adapter. This is an emulated version of the Intel 82545EM Gigabit Ethernet NIC (Intel PRO/1000 MT desktop adapter). Most current supported OS versions have a driver set native to it. It is not native to the BMR SRT for NBU Version 7.5 and earlier so must be added. The Windows 2008 driver file set is "e1g6032" (32 bit) or "e1g6032e" (64 bit). For a BMR SRT created on NBU version 7.6 and later, the working WinPE image is version 3.0 which is based on Windows 2008 R2.  This version has an "in the box" driver set to support the NIC.  No driver import is required. If specifying the VMXNET/VMXNET2/VMXNET3 NIC adapters, you will need to ensure driver sets are in place in the BMRDB and the SRT. They can be found in the VMWare Tools software depository.
 
When creating the Virtual Machine shell  for the restore within the Vsphere application, note the MAC address that is assigned for the NIC by VMWare. It is important. It must be specified in the restore configuration. The related Dissimilar System Restore (DSR) technical articles describes this.
 
5. Windows Only. If driver sets are not resident in the BMRDB or the SRT, they must be added ahead of any restore actions.  Information on what drivers to have and how to add them to the BMR environment, see the following article:
Windows Device Driver Requirements for Bare Metal Restore (BMR) 
 
6. For disk size, it is best (but not totally required) to allocate target disk sizes as large as the original disk sizes. If this is a burden, specify a disk size that is as large or larger than the used disk space of the original system. You can view this value in the "Volume" section of the client configuration.
 
For Windows BMR client recoveries:
In client environments where the entire disk is allocated (no free space left on the disk), as a safety measure, allocate a target disk size slightly larger than the original disk size. The Windows API call that creates the drive letter partitioning allocates space on a disk on a disk cylinder boundary. This is normal Windows processing. The disk geometry of individual disks (bytes per sector, sectors per cylinder) varies per OEM vendor. The "bmrsavecfg" process on the client actually captures these values into the configuration. If an allocation value used crosses a cylinder boundary, the value is rounded up to the next cylinder boundary value. This effect is cumulative on a single drive and can cause the allocation request to fail for lack of free space.
 
As an example, assume that the original system had a 300 GB disk, with a 300 GB “C:\” partition allocated. However, only 50 GB of disk space was actually in use. When doing the “Change” of the restore configuration, you can reduce the size of the allocated “C:\” partition to be 55 GB and create (in the VMWare instance) a logical disk size of 60 GB. During the BMR restore, the system will most likely push out to a Automatic Disk Mapping Wizard at run time. However, the system/boot partition will already be pre-allocated on the disk seen, so one only needs to either map the data partitions, or just hit “OK” to continue.
 
For Linux (all supported 64 bit variants)  and Solaris x86 (all supported 64 bit variants) recoveries: 
Size and number of defined disks is more important and needs to match that of the original server. Should there be disk problems at recovery time, the restore will drop into a "Discovery" mode and ask for a name of a discovered configuration to provide the disk/disk sizes it saw at the time of the failure. Specify a unique name and allow the system to write this data to the Master server. On the Master Server you can use it to initialize the data disks and partition layouts to properly match what BMR saw at actual restore time. With the updated values you can restart the recovery process using the newly updated configuration.
 
7. Booting a VMWare guest OS instance to initiate the BMR recovery procedure:
For boot purposes, the easiest (and fastest) boot method is to use a media SRT (an ISO image of the network based SRT) and load it into the datastore of the VMware server. In creating the VMDK, allocate a virtual CD, set to be powered on and attached when the virtual machine is powered on. Have this bootable ISO image attached to the virtual CD-ROM drive and have the system boot from the CD. The boot image loads extremely quickly and the process moves long much faster. After the BMR process completes and the system reboots, either detach the ISO from the CD drive or allow it to boot from disk, as normal.
Because this mechanism is very fast and straight forward, the use of PXE to boot the virtual guest instance is not recommended.
 

Applies To

All supported Windows, Linux, and Solaris x86 (non-SPARC) OS environments that are supported by NBU and BMR as a client.

Actual OS variant support is dependent on the version of NBU/BMR is use for the process. See the NetBackup (tm) 7.X Operating System Compatibility List article noted in the related articles filed.

Was this content helpful?

Article Languages