Hyper-V Server 2012 R2 X64 PT BR Original MSDN Free Download
Irmgard Verzi
I'm having some problems running on HyperV (machine stops responding for a while, etc.), that for the most part I've seen are greatly improved on Gen2 (we follow all Microsoft recommended practices for running Linux on Hyper-V but it's still not there, at least on Gen1).
The original VM was running on a Windows Server 2008 host. We have upgraded to a 2012 R2 host and can run Gen2 now, but every source I've found says you have to reinstall linux for it (I haven't been able to figure out why, but I'm sure there should be a reason).
Since this was top result when I tried to find an answer, I'm posting my own solution, even though it's 6+ years since question. (btw fercasas.com in old comments is no longer available so couldn't say if it was helpful or not)
Note #2: As always, your partitioning scheme and disk names will probably be different than in my examples, PLEASE modify accordingly, I am in no way responsible for data loss if you format wrong partition! You can check partitions while in your original OS using fdisk -l and/or cat /etc/fstab
This is for Ubuntu 16.04. It is similar, practically same, but I modified it to fit the workflow of "Rescue" mode available from stock 16.04 boot ISO image. "Rescue" mode puts you in chroot, so I had to modify paths and removed few steps that aren't needed.
On future kernel update you may get prompted by grub installer if you want to keep your config or few other options. Pick first one - installing "package maintainers" version (assuming you did not do manual changes to grub.cfg, which would be unusual in a server VM). Since Ubuntu is package maintainer, it should set all the "safe defaults" properly for you.
This should give you working Gen2 / EFI CentOS 7 VM. As with Ubuntu, I did kernel update after this procedure, and while I did manually run grub2-mkconfig command, everything else worked fine, and on reboot I could pick a new entry in grub and booted correctly to new kernel.
If anyone stumbles upon even better way, let me know in comments below. I have a whole environment of production servers of assorted Ubuntu/CentOS/Debian VMs to convert from Gen1 to Gen2 in 2021. so any additions are welcome!
To optimize performance of AhsayOBM on Windows, and to avoid conflict with your antivirus software, refer to the list of processes and directory paths that should be added to all antivirus software white-list / exclusion list.
The default Java heap size setting on AhsayOBM is 2048MB, for Hyper-V backups it is highly recommended to increase the Java heap size setting to improve backup and restore performance. (The actual heap size is dependent on amount of free memory available on your Hyper-V server).
Delta generation of large VHD files is a memory intensive process; therefore, it is recommended that the Java heap size to be at least 2048MB - 4096MB. The actual required Java heap size is subject to various factors including files size, delta mode, backup frequency, etc.
For stand-alone Hyper-V server, AhsayOBM uses the temporary folder for storing backup set index files and any incremental or differential delta files generated during a backup job. To ensure optimal backup / restore performance, it should be located on a local drive with plenty of free disk space. It should not be on the Windows system C:\ drive.
For local, mapped drive, or removable drive storage destinations with Run Direct enabled, the compression type will always be set to No Compression and data encryption is disabled to ensure optimal backup and restore performance. The backup set compression type and data encryption settings will only be applied to CBS, SFTP/FTP, or Cloud storage destinations.
The VM snapshot method is the preferred backup option, as it supports live guest VM backups. This means guest VM will not be put into a saved state when a VSS snapshot is taken during a backup job. So it will not affect the availability of any applications or services running on the guest VM every time a backup job is performed.
3. The Hyper-V Volume Shadow Copy Requestor service is running on the guest VM installed with Windows operating system. Please refer to the following article for further details: -us/virtualization/hyper-v-on-windows/reference/integration-services#hyper-v-volume-shadow-copy-requestor
4. For guest VMs installed with Linux / FreeBSD operating systems, the VSS Snapshot daemon is required for live backups, not all Linux / FreeBSD versions support live backup on Hyper-V. For example, only FreeBSD 11.1 supports live backup while for Ubuntu, version 14.04 LTS to 17.04 LTS supports live backups. Please refer to the following article for further details: -us/windows-server/virtualization/hyper-v/supported-linux-and-freebsd-virtual-machines-for-hyper-v-on-windows
Some older Windows operating systems installed on guest VM's which do not support either Integration Services or the Hyper-V Volume Shadow Copy Requestor Service, will not support VM snapshot method, for example, Microsoft Windows 2000, Windows XP, or older Linux/FreeBSD versions.
If any of the VM Snapshot method requirements cannot be fulfilled, AhsayOBM will automatically use the Save State method. When the Saved State method is used, the guest VM is placed into a saved state while the VSS snapshot is created (effectively shut down), and the duration is dependent on the size of VM and performance of Hyper-V host. The downside is it may affect the availability of any applications or services running on the guest VM every time a backup job is performed.
1. CBT (Changed Block Tracking) is used to optimize incremental backups of virtual machines by keeping a log of the blocks of data that have changed since the previous snapshot making incremental backups much faster. When AhsayOBM performs a backup, CBT feature can request transmissions of only the blocks that changed since the last backup, or the blocks in use.
4. CBT Cluster Service and CBTFilter will NOT be installed on Windows Server 2016 where a built-in system called Resilient Change Tracking (RCT) will be used instead. For details of RCT, please refer to Windows Server 2016 and 2019 RCT Requirement.
Please refer to the following link of Microsoft for details about virtual machine version: -us/windows-server/virtualization/hyper-v/deploy/Upgrade-virtual-machine-version-in-Hyper-V-on-Windows-or-Windows-Server
To get full use of Hyper-V, install the appropriate linux-tools and linux-cloud-tools packages to install tools and daemons, e.g. VSS Snapshot Daemon, for use with virtual machines. Please refer to the following link for the details of requirements for Ubuntu relating to Hyper-V daemons: -us/windows-server/virtualization/hyper-v/supported-ubuntu-virtual-machines-on-hyper-v
3. For backup of individual virtual disks, the restored virtual machine does not support the reversion of previous snapshots, if the snapshot contains disks which are not previously backed up by AhsayOBM.
4. A guest virtual machine can only be restored to the Hyper-V server with the same version, e.g. backup of a guest on Hyper-V 2012 R2 server cannot be restored to Hyper-V 2008 R2 Server or vice versa.
This will require modification of Hyper-V guest configuration files, and this only should be done if you have in-depth knowledge and understanding of Hyper-V, otherwise the guest virtual machine may not startup properly.
Unlike normal recovery procedures where the guest virtual machine(s) are restored from the backup destination and copied to production storage, which can take hours to complete. Restore with Run Direct can instantly boot up a guest virtual machine by running it directly from the backup file in the backup destination; this process can be completed in minutes.
4. Start Up Virtual Machine - The guest virtual machine is started up. To finalize recovery of the guest virtual machine, you will still need to migrate it from the backup destination to the designated permanent location on the Hyper-V server.
The restored virtual machine, at this stage (e.g. before the restore is finalized) is in a read-only state to avoid unexpected changes. All changes made to the virtual disks (e.g. operation within the guest virtual machine) are stored in a VSS snapshot created for the Run Direct restore. These changes are discarded when Run Direct is stopped, where the restored guest virtual machine will be removed and all changes will be discarded, or the changes will be consolidated with the original virtual machine data when the restore is finalized.
AhsayOBM granular restore technology enables the recovery of individual files from a guest VM without booting up or restoring the whole guest VM first.Granular restore is one of the available restore options for Hyper-V backup sets. AhsayOBM makes use of granular restore technology to enable a file level restore from a virtual disk file (VHD) of guest VM backup possible. It is particularly useful if you only need to restore individual file(s) from a guest VM which would normally take a long time to restore and then startup before you can gain access to the files on the virtual disks. Granular restore gives you a fast and convenient way to recover individual files from a guest VM.During the granular restore process, the virtual disks of the guest VM can be mounted on the Windows machine as a local drive. This will allow the individual files on the virtual disks to be viewed via the file explorer within AhsayOBM or from the Windows File Explorer on the Windows machine you are performing the restore on, without having to restore the entire virtual machine. Granular restore can only mount virtual disks if the guest VM is running on a Windows Platform and it is supported for all backup destinations, e.g. AhsayCBS, Cloud storage, or Local/Network drives. The mounting of Linux/Unix file systems from virtual disk file is currently not available due to limitations of the file system drivers.
As compression is not enabled for Granular backup sets, to optimize restore performance, the storage quota required will be higher than non-Granular backup sets. Contact your backup service provider for details.
b1e95dc632