Physical to Virtual migration (P2V) is a common task for achieving consolidation goals through virtualization. System Center Virtual Machine Manager (SCVMM) is by far the best tool from Microsoft to facilitate P2V migrations (as well as V2V conversions from VMware to Hyper-V). The FAQ for SCVMM is a worthwhile read to best understand automated migration to Hyper-V, and it can be found here.
While I believe that SCVMM is the best option for P2V migrations, it isn’t practical in all situations. Sometimes a light weight, standalone solution is necessary to accomplish Windows migrations.
There are other 3rd party options for P2V migration include Novell’s Platespin, DoubleTake Move, Acronis, and even tools from VMware, but I prefer not to use them if I don’t have to, since they add cost and (non-Microsoft) complexity to the migration process. They are some instances, appropriate tools, but I prefer to go with Microsoft tools that may cost less (like free!).
When I want to migrate a physical machine to a VM without using SCVMM, I will either use WinPE and ImageX (detailed in our books on Hyper-V), or I will use Disk2VHD.
I’m still amazed how many administrators haven’t heard about or tried Disk2VHD! It’s a wonderful tool for capturing Windows-base system images and converting them to VMs. With either Disk2VHD or other manual efforts, you still need to install the Integration Services and perhaps take other remediation / migration steps (fixing storage drivers / HAL issues), but it’s a great tool, and you can’t beat the price!
One limitation of Disk2VHD, is that it relies on VSS to capture an image of a running system. Older versions of Windows (NT / 95 / 98 / Windows 2000) don’t include VSS, so it will not work to capture an image of these operating systems. ImageX works well for me for older NTFS-based systems, so I use that as my low priced fallback.
As you know, I’ve been doing a good amount of work virtualizing Linux on Hyper-V. Neither of these two “free” migration tools work with Linux, since Linux systems don’t use NTFS or VSS. In my next post, I’ll dive into some of the challenges of P2V for Linux as well as solutions.
-John
Tony had a question about automating the installation of the Integration Services (aka Integration Components) for Hyper-V.
You can copy the contents of the Integration Services ISO onto a physical system before performing a manual P2V (say, into a new C:\IS_install directory).
Running setup in the AMD64 setup directory (C:\IS_install\AMD64\support\setup.exe /quiet) will install the ISs and reboot the system. Automating the install is something I used to do via RIS (for the Windows Server 2003 Compute Cluster Edition), as it used RIS for deployment. Back then it was a bit of a complicated process, as I would stick the ISs into the D:\RemoteInstall\Setup\English\Images\WINDOWS\$OEM$\$1\IC_Install directory and then call a script to invoke the install that could also close the installer (back when Hyper-V was in beta). The script I used “back in the day” is below, but you shouldn’t need it any more, as the installer for the ISs is much better.
dim delay set WshShell = CreateObject("WScript.Shell") delay = 800 'call setup set objShell = WScript.CreateObject("WScript.Shell") objShell.Run("c:\IC_install\x86\setup.exe /quiet"),1,False 'Wait for window - This was the special sauce While WshShell.AppActivate("Installation Complete") = FALSE wscript.sleep delay Wend WshShell.AppActivate("Installation Complete") wscript.sleep delay WshShell.SendKeys "{ENTER}"
dim delay set WshShell = CreateObject("WScript.Shell") delay = 800
'call setup set objShell = WScript.CreateObject("WScript.Shell") objShell.Run("c:\IC_install\x86\setup.exe /quiet"),1,False
'Wait for window - This was the special sauce While WshShell.AppActivate("Installation Complete") = FALSE wscript.sleep delay Wend WshShell.AppActivate("Installation Complete") wscript.sleep delay WshShell.SendKeys "{ENTER}"
All your have to figure out is how you want to invoke setup as part of your automated installation.
I mentioned in a post last week that I would go over some options to perform a Linux Physical to Virtual (P2V) migration on Hyper-V. Before showing you the easy way, I wanted to go over a manual approach that a coworker worked out for me a while back. Even before that, I wanted to review why some common P2V methods don’t work that well for capturing a Linux physical machine.
That’s something to keep in mind – all those tools you’ve used for Windows P2V migrations including SCVMM, Disk2VHD, ImageX and others all work great because they know how to work with NTFS well. NTFS is a known quantity, and systems that are based on Windows XP / Windows Server 2003 or newer also have VSS to enable live, running snapshots and easier migration. Common P2V tools can leverage VSS and NTFS to make migration and backup easier.
You have multiple file system choices in the 300+ Linux distributions available to you, but you won’t see writable NTFS (I never have). The common file systems I run into are ext2 and ext3 – not file systems that most Windows systems or tools can access (all though it is possible). Without NTFS, there also is no VSS support, so tools like Disk2VHD cannot do their work.
The process for manually moving a Linux system into a Hyper-V VM is similar to the process I have used with WinPE and ImageX:
I asked a “Linux Veteran” for help with a generic, manual process. The Linux veteran (I’ll call him Mr.Z) used Ubuntu successfully for a quick test of this process. I tried it with CentOS and Ubuntu with not quite optimal results, but my failure highlights some of the challenges of the process. Mr. Z gave me a great writeup of the manual process he used (using commands oyu may / may not know as a Windows admin like tar or cpio, mkfs, mkswap, mount, fdisk, scp, Sudo, and by editing all sorts of files).
What did I find out? Each distribution of Linux (and separate installation) required different manual handling – depending on all sorts of variables including the file system used (ext3 or ext4, or other), shadow password files, and available commands (not all distros have all the same tools!).
Manual P2V of Linux systems is not the easiest thing in the world to accomplish without a good understanding of the Linux distribution employed, the file system used, and other implementation specifics including security practices. Yes, manual P2V of Linux hosts to Hyper-V can be accomplished (similar to what I’ve done in the past with ImageX and WinPE), but it may not be practical. I’ll try in the next few weeks to go over some automated solutions for Linux P2V migrations to Hyper-V, as well as some “semi-homemade” approaches that can take the edge of of the manual process.
I mentioned in my last post how challenging manual Physical to Virtual migrations (P2V) of Linux systems can be. There are a number of great automated tools that make Linux P2V simpler that I’ll try to run through in the coming weeks.
The tools I’m showing fill a need – to migrate a Linux host to a Hyper-V-based virtual machine. I’m not endorsing these products, simply showing how they can be used to migrate to Hyper-V.
The first one I’ll cover is Novell’s PlateSpin Migrate. Migrate is part of the PlateSpin Portability Suite which can be downloaded from Novell. The Portability Suite allows you to capture and protect “workloads” (servers) over the network for DR and other purposes. I’m only interested in a tiny subset of functionality – easily converting Linux servers to Hyper-V VMs.
The architecture relies on a PlateSpin server in the middle of the process to orchestrate and control protection activities (image capture and deployment). The server monitors and controls the P2V process between the source and target machines/
I started by downloading the latest version from the Novell site. The version of the suite I used relies on an older version of the .NET Framework and 32-bit IIS (does not install on Windows Server 2008 R2 at this time), so using a 32-bit Windows Serve 2003 R2 VM was the path of least resistance for me. The PlateSpin folks have a decent article on the installation requirements for the server here.
Once the server was installed, I could use it to discover “protection” eligible systems (P2V sources) in my environment. It found lots of Windows systems on my network, but I already have a slew of low-cost, easy to use tools for Windows P2V.
To find my Linux migration targets, I discovered new hosts by entering their IP address (or DNS name). To properly discover systems, you will need valid credentials for Linux / Unix hosts, and they require that SSH be installed (SSH is part of the secret sauce). A complete list of source system requirements can be found here.
After I found my source Linux host, I configured my “target” VM in Hyper-V. I created a new virtual machine with all the proper bells and whistles including a Legacy Network Adapter for network support before the Integration Services are installed. I then booted the VM using the PlateSpin Linux boot ISO image, to bring the blank system under the control of the PlateSpin Server.
Once both the physical host and target VM were accessible to the PlateSpin server, I could step through the migration process.
The migration was painless compared to a manual migration, where I would have had to prepare my volumes and file systems. After selecting my source and target systems, I used the GUI in the server to basically point and click through migration options.
The process alters the boot configuration of the source Linux system (modifies grub) to start the system using a Linux “Take Control” ISO to capture an image of the system cleanly.
Depending on your environment, you may want to take note of the “Temporary Take Control Network Settings” (like if you don’t have DHCP in your data center…otherwise you can select DHCP as an option).
Yes, there is MUCH MORE to the migration process than I’m letting on.
PlateSpin Portability Suite allows you to deal with lots of other migration details, including volume and disk configuration (maybe you don’t want to migrate all the mounts on a server, alter the start-up mode of some daemons after migration, or run a post migration command). After confirming your migration options, you can kick off the process.
After the migration began, the source host was rebooted into the “Take Control” ISO I mentioned previously, and the system was migrated into VM I booted earlier. The migration job can be monitored via the “Jobs” view in the server. The job console shows (in great detail) the migration progress for the entire process until it is complete.
That’s about it. I’ve used PlateSpin in my environment to move Red Hat Enterprise Linux 5.1 and CentOS 5.4 to Hyper-V, and the process went well. PlateSpin of course works with SUSE (they are owned by Novell after all!).
Novell has a guidance document for using the Portability Suite (Migrate) with Hyper-V which can be found here.
The cost per migration (protected workload) seems reasonable to me when compared to other products and the pain of a manual migration.
If you are interested in using PlateSpin to migrate your Linux to Hyper-V, check with Novell for pricing and options.
As time permits over the next few weeks, I want to walk through some other Linux P2V options for Hyper-V.
Let me know if you have any suggestions.
I received an e-mail from someone looking for an electronic version of the VMCPU PowerShell reporting script I wrote for our book on Hyper-V, so I thought I would post it here (FYI the updated, 2nd edition is due out in a month or two!).
I wrote to script to address CPU performance monitoring requirements I had in citations where I didn’t have SCVMM or SCOM. When we wrote the first edition of the book, James O’Neill’s PowerShell library for Hyper-V didn’t include any functions to check VM CPU load.
James (a 5 star rated PowerShell expert, as far as I’m concerned) has since added Get-VMProcessor to the library, but I like my little function, because the output is more colorful (yes, the code is uglier than James’, but it’s my ugly baby!).
Let me know if you have any questions (or just check out the end of Chapter 10 in either edition of the book!).
function Report-VMCPU {Param ($server=".") $LoadSum = 0 $PCores = 0 $VProcs= GWMI -computerName $server –Namespace root\virtualization -Class MSVM_Processor write-host " " write-host " CPU Load" write-host "VM Name # %" write-host "-------------------------------------- ---- -----" foreach ($VProc in $VProcs) { $VM = GWMI -computerName $server -Namespace root\virtualization -Query "Select * From MSVM_ComputerSystem Where Name = '$($VProc.SystemName)'" $VMname = $VM.Elementname.PadRight(39," ") $VMCPU = $VProc.deviceid.split("\")[-1] $VMCPULOAD = $VProc.LoadPercentage Write-Host "$VMname $VMCPU " -nonewline if ($VMCPULOAD -lt 30) {write-host $VMCPULOAD -backgroundcolor green} elseif ($VMCPULOAD -gt 80) {write-host $VMCPULOAD -backgroundcolor red} else {write-host $VMCPULOAD} $LoadSum = $LoadSum + $VMCPULOAD } $PProcs= GWMI -computerName $server –Namespace root\CIMV2 -Class Win32_Processor foreach ($PProc in $PProcs) { $PCores = $PCores + $PProc.NumberOfCores } $VLoad = $LoadSum / $PCores write-host " " write-host "-----------------------------------------------------------" Write-Host "Physical Host Virtual CPU Performance Summary" -nonewline if($Server -ne ".") {write-host " for $Server"} else {write-host " "} write-host " " Write-Host " Total Physical Cores: " $PCores Write-Host "Approx. Virt. CPU Utilization: " -nonewline if ($VLoad -lt 30) {write-host $VLoad -backgroundcolor green} elseif ($VLoad -gt 80) {write-host $VLoad -backgroundcolor red} else {write-host $VLoad} write-host "-----------------------------------------------------------" write-host " " }
I’m back from lots of traveling (why I’ve had time to post a few things).
I got a great question about my last post…how best to call a custom PowerShell function.
I’m not a PowerShell expert by any stretch of the imagination, but I do use it a good amount and I find it useful to save code that I’ve optimized (gotten to actually run!) so can use it over again – like the VMCPU code from my last post.
Sometimes I’ll simply copy and past a function directly into PowerShell – that way I don’t have to worry about loading the script file (execution policy). Here’s what it looked like when I copied the Report-VMCPU function into PowerShell and called it.
It’s not a convenient way to manage your functions, but you don’t encounter all the security “challenges”. you might otherwise encounter.
You can of course simply load a “.PS1” which contains your pre-defined functions (like say, a file called Report-VMCPU.PS1 that contains , but the default execution policy may block your ability to load a script file. To allow the execution of scripts, you may need to run:
set-executionpolicy –executionpolicy unrestricted
To then load the script file, type a period followed by a space and the full path to the script file (if it’s in the current directory, then you would enter:
. .\Report-VMCPU.ps1
You may receive another warning about “Running scripts you trust”. Some files may be “blocked” based on their security status. To “unblock” your script file, hop into Explorer and access file properties. Click the “Unblock” button and “Apply” for your script.
If you’ve set your execution policy and unblock your script, loading your file full of functions is much cleaner.
Depending on where I’m working, or what I’m doing, calling a PowerShell function (from my bag of tricks) could look like any of the examples screens above.
As always, keep the comments and questions coming!
I mentioned in my last post that Microsoft now has multi-processor support for Linux VMs on top of Hyper-V (yeah!). The beta updates to the Linux Integration Services (aka Integration Components / ICs) was big enough new to be picked up by big time Microsoft watchers.
There are three enhancements in the beta release of the Integration Service for Linux:
Mike Sterling posted to the Virtualization team blog with details, and Brett Shoemaker blogged on Port 25 with a link to to the download. I know both of them really well if you have any questions (I wrote a Hyper-V book with Mike, and Brett and I are on the same team).
Yes, everyone thinks SMP is a big deal for Linux on Hyper-V. I agree, but I’m more excited about the other two feature (why? that’ll be in a future post – I promise).
Just to get the SMP piece out of the way, let me say that the installation of the Integration Services (ISs / ICs) is via the same process. Mount the ISO image in the VM, copy the contents to a directory (/opt/linux_ISs) and run perl setup.pl drivers, and reboot.
What do you get? Reliable multi-processor support for Linux on Hyper-V – up to 4 virtual CPUs!
So why do I think TimeSync is more important than SMP for Linux on Hyper-V?
First, let me recap… last week Microsoft released a beta version of updates to the Linux Integration Services (ISs / Integration Components / ICs).
This release of the ISs includes three new features customers have been asking for:
Most enterprise have lots of Windows – on the desktop as well as on servers in the data center and branch offices. I understand that some times (gasp) a few Linux servers may sneak into an enterprise because of business requirements (application only ships on Linux, for example). For primarily Windows enterprises, there may be a requirement to support a few Linux servers here and there (yes there are organizations with more Linux than that…they should look at Hyper-V too!). Typically, these are not high-performance systems, often just one-offs. The question I often ask administrators about those Linux systems is, “do you back them up?” Often the answer is, “I don’t know” (that answer means no to me!).
Encapsulating Linux in a VM on Hyper-V makes backup and recovery a snap…literally. I’ve detailed it in earlier posts… you can use DPM, Windows Server Backup (WSB), or the diskshadow command to easily backup and restore Hyper-V virtual machines INCLUDING Linux!
One challenge with Linux had been the lost seconds on in the Linux VM clock when the VM is “frozen” for backup (not an issue for most Windows VMs because of VSS backup integration). When a host backup was invoked for a Linux (or non-backup aware) VM, the virtual machines state would be saved to disk to facilitate a host-based snapshot. During the seconds it would take to create the snap, the VM would not be able to track time (count ticks), and the clock would typically be slow equal to the down time. This could be corrected with NTP and the proper slew settings, but it was a hassle (the picture to the right). Why couldn’t Linux just get the time from Hyper-V like Windows VMs? With the new Integration Services, Linux virtual machines can!
TimeSync means that you don’t have to hassle with configure network-based time sync for your Linux VMs on Hyper-V…they can get the correct time from the host! Time is automatically updated (if you install the new Integration Services) on your Linux VMs even if they are “saved” for a while. I just did this in my lab a bunch of times with a bunch of Linux VMs, and it worked great!
The new TimeSync Integration Service for Linux makes it ever easier for administrators to backup and restore non-Windows VMs on Hyper-V without impacting business applications.