Tuesday, March 25, 2014

You wanted to P2V?

Went to convert an old physical server to a virtual machine and I discovered that the latest version of System Center Virtual Machine Manager, 2012 R2, removed the P2V (physical to virtual) conversion tool.

What's recommended by the Microsoft Virtual Machine Engineering blog is to use an older version of VMM - 2012 SP1 or older - to complete your P2V needs.
http://blogs.technet.com/b/scvmm/archive/2013/10/03/how-to-perform-a-p2v-in-a-scvmm-2012-r2-environment.aspx

Alternatively, you can use the SysInternals Disk2vhd tool to manually P2V.
http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

I ended up using the Disk2vhd tool and was successful in converting my server to a virtual machine.

Before I began converting the physical disks to virtual:
  • Stopped any programs or services that may have been running (as memory is not going to be captured)
  • Disabled any services running from automatically starting. Once you boot it up and reconfigure your network adapters and drive letters, set the services back to boot Manual or Automatic.
Then, I launched the Disk2vhd tool and captured the disks (one VHD disk with both the system reserve and the C: system volumes, and another VHD disk with the D: data volume).
    Note: The Disk2vhd tool default converts disks to VHDX, but that's only compatible in Server 2012 and above. I had to uncheck the [Use VHDX] check box, since the virtual machine was going on a Windows Server 2008 R2 Hyper-V host.
The only left to do after converting the system's disks where:
  • Write down the system's network information (easiest with ipconfig /all in the command prompt)
  • Convert the VHD files created from 'Dynamically Size' vhd disks to 'Fixed Size' vhd disks
  • Attach the VHD disk files to a blank virtual machine with the necessary specifications (Processors, Memory, Network Adapters, etc) The disk containing the system volume needs to be connected to the Virtual Machine's IDE 0 or 1 Controller
  • Shutdown the phsyical machine
  • Boot up the virtual machine
  • Loaded the Hyper-V Guest OS Utilities (Hyper-V Integration Services)
  • Set the network adapters back to the correct configuration
  • Set the drive letters back to the proper designations (in my case D: became E:)
  • Re-enable the Services that were disabled 
  • Re-activate Windows Operating System

Thursday, March 13, 2014

Remotely Running PowerShell

Very simple.


To enter a remote PowerShell session:

 enter-pssession servename


To exit the remote session:

 exit-pssession



Commands I like to run remotely:

-Listing and killing an active process:
  (*Particularly any starting with the name "note" and then stopping it)

 get-process -name note*
 stop-process -name note*



-Pulling a system's serial number:
  (*Particularly great for support calls)

 gwmi win32_bios



 This eliminates the need to connect via Remote Desktop in order to perform these simple tasks.


  • [Note] In order to use PowerShell commands on a remote machine: You need to have permission to connect and run these commands remotely; You need to have ran enable-psremoting; You need to have direct communication with the machine; and have opened the firewall in order to connect to the WS Management service. There's more details about of this and these commands listed below.

References:
about_Remote_Requirements, http://technet.microsoft.com/en-us/library/dd315349.aspx
Running Remote Commands, http://technet.microsoft.com/en-us/library/dd819505.aspx
Using the Get-Process Cmdlet, http://technet.microsoft.com/en-us/library/ee176855.aspx
Using the Stop-Process Cmdlet, http://technet.microsoft.com/en-us/library/ee177004.aspx

Wednesday, March 12, 2014

DPM 2012 and Beyond Frustration

All of our Hyper-V Clusters, Server 2008 R2 hosts, started having failed backups inside our two independent Data Protection Managers. The problem initially progressed from one node consistently fail backups for virtual machines and the other hosts kept performing backups, until all of our nodes could no longer could make successfully backups of any virtual machines. Our standalone backups via DPM had no issue. These hosts had been configured and unchanged for well over a year - only Windows patches months prior and anti-virus updates were continuously loading.

DPM kept stating for the failed backups that "The VSS application writer or the VSS provider is in a bad state ... ID 30111: VssError:A function call was made when the object was in an incorrect state for that function(0x80042301)) and the local nodes wrote VSS 12362 Application Log Event Errors "A Shadow Copy LUN was not detected in the system and did not arrive" and VSS 12363 Application Log Event Errors "An expected hidden volume arrival did not complete because this LUN was not detected" whenever we attempted to run full virtual machine backup via a Consistency check.

We had tried and didn't work...
  • Power cycling all of the equipment involved: Hyper-V Servers (PowerEdge R710's), the iSCSI SAN (EqualLogic PS4000vx's), the switches connecting them (Catalyst 3750X's), and our DPM server
  • Unregistering and Registering the EqualLogic VSS provider (eqlvss /unregserver and eqlvss /regserver)
  • Removing virtual machines from a protection group (deleting disk data) and adding them back
  • Moving virtual machines to a new protection group
  • Upgrading the EqualLogic Windows Host Integration Toolkits (HIT kits) on the Hyper-V nodes - upgraded from 4.0 to 4.6
  • Installing the EqualLogic HIT kit on one of the virtual machines
  • Patching the Hyper-V nodes to all of the latest Windows Updates - even yesterdays released kb 2908783 which resolves issues with corruption of iSCSI LUNs in Windows Server 2008 R2 and 2012
... and still no success.

After much time wasted on what seemed to be magic potions and DPM's hatred of backing up critical data, a random thought of trying to disable our anti-virus on the cluster nodes resolved the issue! Yeah, I know they say to disable anti-virus on everything and everywhere you read, but we have had Microsoft Forefront Client Security on these systems configured and running since we setup these servers 2+ years ago. Apparently, some change in the definitions or just its mood decided to start messing with the iSCSI VSS Hardware process... and messing with my sleep over the last two days.

Good luck!