Application Note. P2V and V2V Concepts for Scale Computing HC³

Size: px

Start display at page:

Download "Application Note. P2V and V2V Concepts for Scale Computing HC³"

Joel Ray
5 years ago
Views:

1 5225 Exploration Drive Indianapolis, IN Phone: 877-SCALE-59 Web: Application Note P2V and V2V Concepts for Scale Computing HC³

2 Table of Contents Introduction... 1 About the Scale HC 3 System... 1 Components of a Physical Server... 1 Booting an OS on a Physical Server... 2 Components of a VM... 2 Booting an OS on a VM... 3 Performance Drivers... 3 Changing the Boot Hard Disk Device... 4 P2V without Performance Drivers... 4 P2V with VIRTIO Performance Drivers... 5 Stop 0x B Blue Screen of Death... 5 Other Disk Structures... 6 Provide Feedback or Contact Support... 6 Resources... 6 Disclaimer... 6 Introduction This application note describes general concepts pertaining to physical to virtual (P2V) and virtual to virtual (V2V) transfers involving a source machine with a Windows based operating system (OS) and a target HC 3 virtual machine (VM). Topics covered include basic virtualization concepts, working with performance drivers, and common problems that arise when conducting a P2V or V2V transfer. Step-by-step instructions and examples for specific tools are provided in separate application notes. About the Scale HC 3 System Scale HC 3 combines the benefits of server virtualization and shared storage into a converged IT infrastructure platform where virtualized workloads have direct access to a distributed, scalable pool of shared storage and compute resources. The cluster eliminates complex virtualization and storage architectures for greater cost savings and management efficiencies from consolidation. Components of a Physical Server This section describes the layers of components running on a typical physical server. If you look at an application and OS running on a physical server, you can split the various components into layers as shown in Figure 1 - Component Layers on a Server.

Figure 1 - Component Layers on a Server Starting from the bottom up, a server has a set of hardware resources such as CPU, RAM, disk drives and various devices such as network interface cards (NICs),

3 Figure 1 - Component Layers on a Server Starting from the bottom up, a server has a set of hardware resources such as CPU, RAM, disk drives and various devices such as network interface cards (NICs), mouse, keyboard, etc. as well as internal system level devices and hardware interfaces like BIOS that are more abstract. On top of the hardware resources, a server has device drivers. These are used to create an interface between the hardware layer, and the installed OS. For example, Windows uses a different driver to communicate with a locally attached SCSI HBA and the disks attached to it vs. an IDE or SATA disk connected to an IDE ATA Disk Controller. Some device drivers are built in and included with the Windows OS while others require a driver disk or CD usually provided by the hardware manufacturer. Booting an OS on a Physical Server To boot an OS on a server, you must have basic hardware components available. The hardware components the server must have are a storage device such as a hard disk, a CPU, and RAM. NICs are not required to boot, but if you choose to boot without NICs you lose the network access they provide. In addition to having basic hardware components available, to boot an OS on a server, the server must also have the right drivers installed. Choosing the appropriate drivers for booting an OS is fairly simple because of Windows plug and play nature, and how generic many drivers are. When you change your system in a way that requires a driver, Windows will attempt to find the right driver for you from a built in repository of drivers, from an attached CD/DVD image, or even from the internet (assuming you choose to boot with a NIC that has network access). Additionally, many device drivers can handle multiple similar devices or changes in devices without driver changes. For example, adding RAM or additional CPU cores would not require changes to driver software. Components of a VM Virtualization products such as HC³ provide software known as a hypervisor to allow multiple VMs to run on a given piece of physical hardware at the same time. The hypervisor is a small, efficient OS that has access to the physical hardware and in turn presents virtual hardware, such as virtual hard disks, network cards, CPU and RAM to individual VMs. Each VM appears to have the host s processor, memory, and resources to itself. Instead, the hypervisor is controlling the host processor

4 and resources, distributing what is needed to each operating system in turn and ensuring that the guest OSes/VMs are unable to disrupt each other. Booting an OS on a VM As with physical machines, Windows plug and play nature helps when booting up a VM, particularly if you are booting up after migrating a full workload from a source machine to a target VM. The vast majority of hardware devices and drivers are detected automatically and work with little or no reconfiguration, while other non-critical devices may prompt for drivers to be installed when they are first detected. The only difficulty arises at the start of boot up from a hard disk. Because the driver to allow the operating system to access the hard disk is stored on the hard disk itself, changes that impact the driver required to access the boot disk have to be made very carefully to allow the operating system to continue to boot. In addition, unlike other devices where Windows can search for a driver for a new device it does not have, this cannot be done for the boot device. For example, if you did a sector/block level copy of IDE/ATA/SATA boot disk to a SAS/SCSI disk and then tried to boot a system from that SAS/SCSI disk, it would fail to boot with a BSOD that displays the message STOP 0x B INACCESSIBLE_BOOT_DEVICE because the Windows image does not contain the proper drivers for the SAS/SCSI HBA required to access the copied boot image. Even for simple devices like ATA/SATA disks that Windows normally installs to using built-in drivers, once Windows configures itself to boot from a particular kind of device, it no longer attempts to boot from other kinds of storage devices. The only exception is if you configure Windows to attempt to boot from other kinds of devices, such as tools that make specific changes to the windows registry to alter the boot storage device. Most workload migration tasks such as physical to virtual (P2V) or virtual to virtual (V2V) involve changing the boot hard disk type and driver that Windows uses to boot. Care must be taken to ensure that you have the right boot hard disk type, and essential drivers or your VM will not boot at all. Performance Drivers HC³ can expose two different types of virtual disk hardware to Windows VMs, depending on whether you create a VM with Use Performance Drivers turned on or off. When an HC³ VM is created with Use Performance Drivers turned off, the HC³ hypervisor provides virtual disks by emulating a standard IDE/ATA hard disk for the guest VM. Windows has built-in drivers to boot from this type of hard disk. This is why Windows can be installed without having to load any additional drivers; Windows can use the disk directly. The tradeoff is that the hypervisor has to use software and CPU cycles to mimic that hardware device in software, which can have an impact on performance. When an HC³ VM is created with Use Performance Drivers turned on, the guest OS must include or install special software device drivers that allow them to communicate directly with the hypervisor and the virtual hard disk. These are referred to as VIRTIO drivers, which is a standard for I/O virtualization used by HC³. For Windows VMs, HC³ provides these VIRTIO performance drivers to the guest OS on a virtual CD-ROM or floppy disk device which is automatically created when creating a virtual machine with performance drivers. At the appropriate stage in the OS install, Windows will not find a hard disk to install to using its built in drivers and will provide an option to load additional drivers as would be done if you were using a specialized hardware RAID controller. At this time you would browse to the appropriate Scale provided drivers for the OS you are

5 installing and continue the OS install as usual. These drivers provide improved performance because the hypervisor does not need to emulate the function of a hard disk. The VIRTIO drivers are aware they are running in a virtual machine and are able to communicate with the hypervisor layer in an optimal way. For VMs on the HC 3, performance drivers are used for both virtual hard disks and virtual NICs when Use Performance Drivers is turned on. Changing the Boot Hard Disk Device Unlike the initial OS install where you can specify a driver CD / floppy disk and load a driver, there is no standard way to tell Windows to change the boot storage device or even to force it to load a driver for a new storage device that is not actually present. As a result, a number of 3 rd party tools have been developed to allow this to occur in conjunction with P2V migration or restoring full system backup images to different hardware. These often go by names such as hardware independent restore or system independent recovery. The way these products work is by booting a different OS instance, usually off a CD/DVD image, and then using that OS instance to detect the hardware available. After the hardware is detected, the appropriate device drivers for that hardware are added into the restored OS instance, making it bootable on the new hardware. For example, you backup the c:\ drive of a physical machine with an SCSI HBA and SCSI disks and stored that backup in a file called cbackup.img. Hardware independent restore tools would allow you to create a VM with an empty c:\ drive, boot that VM off a recovery CD/DVD image such as recovery.iso, and restore the blocks from cbackup.img into the virtual hard disk exposed by the VM. At that point, the contents of the hard drive would exactly match the contents of the original physical disk. However, that VM would not be able to boot the OS yet using that virtual disk. This is because that image is expecting to boot from a SCSI HBA and disk and does not have the correct driver files or registry settings to allow the OS to boot from a different type of disk. You would need to change the restored OS image to provide it the correct driver files for boot storage device as well as change the registry to tell Windows to boot from that new device instead of the old boot device. P2V without Performance Drivers If you are not using performance drivers, the HC³ emulates a standard IDE disk type for the operating system which uses a built in Windows driver and therefore can simplify the migration options. To prepare an OS to boot off that type of disk, the driver files are already there, you simply need to change the Windows registry to specify that the OS should attempt to boot off IDE disks using it s built in driver. In this case, you can and must actually do this BEFORE you attempt to do the P2V migration or take the initial system backup by creating and running the mergeide.reg file that Microsoft describes in The process would be to run mergeide.reg on the physical machine and then take the full image backup at that point. When the image is restored to a VM without performance drivers and an emulated standard IDE disk, it will boot successfully. Without running mergeide.reg, the VM would boot and give a Stop 0x B blue screen of death error that indicates windows is not configured to boot the current boot disk. NOTE: If you do not run mergeide.reg before taking the backup image, it is too late to boot directly off that backup image. You would require the use of 3 rd party tools that can boot into an alternate recovery OS environment and make these kinds of registry and driver changes through that alternate environment. Or, go back to the original physical machine and start over, run mergeide.reg, take a new backup, and restore that new backup.

6 P2V with VIRTIO Performance Drivers Since there is currently no fully tested / supported way to pre-install or activate VIRTIO drivers on a physical machine that is not currently running inside a VIRTIO VM, you need to use 3 rd party tools that are able to add the VIRTIO drivers into a recovered disk image before attempting to boot it for the first time. For these tools, the process is the same as the process for recovering an image backup using P2V with the backup tools of your choice, however the destination is a VM that uses a Scale VIRTIO SCSI Host Adapter. Because Scale expects most customers want to use VIRTIO performance drivers, Scale has developed a series of application notes that provide step by step examples using popular full system backup and recovery tools from companies like Storagecraft, Acronis, and Symantec. Using the application notes for these tools, you can learn how to backup workloads running on physical machines (or 3 rd party virtualization platforms as well) and restore them to HC³ VMs using performance VIRTIO drivers. The general steps for P2V with an HC 3 VM as the target machine are: 1. Create the destination HC³ VM with an empty hard disk to restore data to. The hard disk must be the same size, or slightly bigger than what you are restoring from. 2. Set the VM to boot from the tools recovery CD/DVD ISO image. 3. Boot the VM and restore the full disk image including partition tables, master boot record (MBR), etc. (in most cases this requires pointing the recovery process to the Scale VIRTIO driver CD so it can load network and storage drivers). 4. Run the process to change the restored image to boot using the Scale VIRTIO storage driver. 5. Reboot the VM and perform post migration cleanup. Stop 0x B Blue Screen of Death If you receive a Stop 0x B error (also called Blue Screen of Death or BSOD) when booting a VM after a migration, the error always indicates that the migrated OS image is not configured to boot from the type of hard disk that is available. The disk driver for the target VM environment is not properly configured in Windows. It is normal to see the boot process begin and look like it is going to start before displaying this error (and possibly quickly rebooting and trying again in a loop often making it difficult to see the actual error being displayed). In this state, none of the built in Microsoft recovery tools, such as safemode will help. Only tools that boot into an alternative recovery environment and that have the ability to inject new storage device drivers and manipulate the recovered registry files offline will be able to make the image boot correctly. Most tools allow you to re-run this process again manually without performing the data restore all over again. Common errors to look for include selecting 32-bit drivers from the CD (which are often required early in the recovery process for the recovery ISO to access the disk if it is based on a 32-bit OS) instead of selecting 64-bit drivers to add when recovering a 64-bit OS. For example, when recovering with Symantec System Recovery you first have to tell it to LOAD 32-bit drivers for Windows 2003 since that is the OS its recovery environment is based on to give it access to the disk, but later when specifying the drivers to add into the image you need to specify the correct drivers for the environment being recovered, for example Windows bit. You may need to make other changes to the source machine such as running mergeide.reg and do another backup and restore if you are not using 3 rd party tools that can correct the drivers in the image offline). Beyond minor additional boot time while Windows attempts to boot from devices that are not present, there does not appear to be any downside to making changes such as running mergeide.reg on a source machine to make any subsequent full image backups of that system more

7 portable and recoverable without requiring 3 rd party tools. This could also be done inside a VIRTIO VM to make the qcow2 image file bootable inside a non VIRTIO VM, if you were to experience issues with the VIRTIO drivers. Other Disk Structures There are other disk structures and settings that must be backed up and restored properly to allow the migrated OS to boot. These include partition tables, MBR, and more. In most cases, it is safest to include all partitions of all disk in the backup and recovery process but advanced users may be able to exclude certain items such as vendor specific recovery partitions. Follow the instructions provided by your 3 rd party tool vendor for more information. Provide Feedback or Contact Support If you have comments or suggestions regarding this document or other Scale Computing documentation, you can send them to documentation@scalecomputing.com. If you need help, call SCALE-59 ( ), and someone from the Scale Computing Technical Support Team will be happy to help you. You can also Scale Computing Technical Support at support@scalecomputing.com or find them on the web at Resources A Microsoft article about how to troubleshoot a Stop 0x B error, which can occur on the target machine after a transfer. Disclaimer This document is meant to filter the information around P2V as it relates to the Scale Computing HC 3 product. Scale Computing is not responsible for, and expressly disclaims all liability for, any issues or damages of any kind arising out of use of 3rd party tools.

Application Note: P2V/V2V with Clonezilla and the Scale HC3 Cluster (non Performance Driver VMs Only)

5225 Exploration Drive Indianapolis, IN 46241 Phone: 877-SCALE-59 E-Mail: info@scaleomputing.com Web: www.scalecomputing.com Application Note: P2V/V2V with Clonezilla and the Scale HC3 Cluster (non Performance