Cloudtidings.com

Hotfix needed to move R2 differencing disk to Windows Server 2008

In Windows Server 2008 R2 there was a minor change to the format of differencing virtual hard disks.  As a result you will need to apply an update to Windows Server 2008 if you want to move differencing disks from Windows Server 2008 R2 to Windows Server 2008.

You can download this update from here:

http://support.microsoft.com/kb/971677

Note that this applies to Windows Server 2008 and Windows Server 2008 SP2 (not to Windows Server 2008 R2).  If you do not have this update installed and you try to use a differencing disk created with Windows Server 2008 R2 you will receive an error message that states that the virtual hard disk is corrupted or unreadable.

Posted by Ben ( Virtual PC Guy )
http://blogs.msdn.com/virtual_pc_guy/archive/2009/10/16/hotfix-needed-to-move-r2-differencing-disk-to-windows-server-2008.aspx

• Virtual PC supports a maximum virtual disk size of 127GB. If you create a VHD from a larger disk it will not be accessible from a Virtual PC VM.
• Do not attach to VHDs on the same system on which you created them if you plan on booting from them. If you do so, Windows will assign the VHD a new disk signature to avoid a collision with the signature of the VHD’s source disk. Windows references disks in the boot configuration database (BCD) by disk signature, so when that happens Windows booted in a VM will fail to locate the boot disk.

If the Directory Service event log reports Event ID 2095. Here is how to fix the issue:

1. Shut down the domain controller virtual machine that recorded the error, and ensure that it does not restart.

2. Determine whether a snapshot of the domain controller was recently used as a restore mechanism. If so, this is most probably the source of the error.

3. Attempt to determine whether any changes originated from this domain controller and propagated to other domain controllers. If the event was a result of a snapshot or copy of a virtual machine being started, try to determine the time the USN rollback occurred. You can then check the replication partners of that domain controller to determine whether replication occurred since then.

   You can use the Repadmin tool to make this determination. For information about how to use Repadmin, see Monitoring and Troubleshooting Active Directory Replication Using Repadmin (http://go.microsoft.com/fwlink/?LinkId=122830). If you are not able to determine this yourself, contact Microsoft Customer Service and Support (http://go.microsoft.com/fwlink/?LinkID=102491) for assistance.

4. Forcefully demote the domain controller. This involves cleaning up the domain controller’s metadata and seizing the operations master (also known as flexible single master operations or FSMO) roles. For more information, see the “Recovering from USN rollback” section of article 875495 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=137182).

5. Delete all former VHD files for the domain controller.

When a running virtual machine is moved to a server running different processor, the virtualization platform needs to provide necessary support to ensure applications running inside virtual machines continue to run on the destination processor. 

The Processor Compatibility new feature of Windows 2008 R2, enables Live Migration to occur between processors at different versions/generations/steppings.

A particular Intel or AMD class of processors exists in a family. That family has multiple generations, or steppings, that define one set of processors from another. While these differences are relatively unnoticeable for most of us during our usual use of the OS, they can be enough to prevent a Live Migration from successfully occurring. The "differences" actually arrive as different processor capabilities that are baked into the chip itself.

This new feature enables the masking of these features so that a running virtual machine can successfully Live Migrate from one host to another. The result is that you must no longer be exactly equal in processor capabilities between multiple hosts. The best part is that the majority of this functionality is kept underneath the covers.

You only need to check if the box "Migrate to a physical computer with a different processor version" is marked for each VM. That’s it. The Live Migration process will eliminates concerns and conflicts and process the migration sucessfully

Scenarios

1. You have a virtual machine running on a host A and would like to be able to move it to another host B   

2. You buy another server and add to the cluster.  The newly added server is most likely has newly added processor features than other hosts in the cluster.  You would like to be able to move running virtual machines freely from any node of the cluster. 

3. You have a virtual machine running on host A, You save the VM with active memory state and would like to restore the same at a later date on any Hyper-V enabled host which may not be the same host.

How it works:

With processor compatibility mode enabled, Hyper-V only exposes the guest VM to processor features that are available across all processors of the same processor architecture, i.e. AMD-to-AMD or Intel-to-Intel. This allows the VM to be migrated to any hardware platform of the same processor architecture. Processor features are “hidden” by the Hypervisor by intercepting a VM’s CPUID instruction and clearing the returned bits corresponding to the hidden features.

When a VM in a processor compatibility mode is started following processor features are hidden from the VM:

Host running AMD based processor
 SSSE3, SSE4.1, SSE4.A, SSE5, POPCNT,
LZCNT, Misaligned SSE, AMD 3DNow!,

Host running Intel based processor
 SSSE3, SSE4.1, SSE4.2, POPCNT, Misaligned
SSE, XSAVE, AVX
 
Also, VM’s cache line flush size is set to 8 bytes on AMD and Intel based hosts when in processor compatibility mode.

Important : Windows Server 2008 R2 Hyper-V will not allow migrating a VM (with or without in processor compatibility mode) from AMD based hosts to Intel based hosts, and vice versa.

VM’s processor compatibility mode is OFF by default.  It can be turned on by one of the two ways:

1. Using Hyper-V Manager: from Hyper-V Manager, select CPU setting wizard of the VM. 
Check a check-box labeled “Migrate to physical computer with a different processor version.  You can only change this setting when VM is not running.

2. Using System Center Virtual Machine Manager 2008 R2

Notes :

1. Moving down to older processer versions consider potential performance reduction due to loss of processor features which might accelerate applications performance. It’s recommended that you properly test these scenarios.   
 
2. An application may use non-recommended methods for processor feature detection, such as instruction probing, i.e. using an exception handler and attempting to execute a feature’s instruction to determine the presence of a feature. Or, basing feature presence on the type of processor, i.e. family, model and stepping. 

3. Applications may fail to launch because of the lack of a specific a processor feature It is recommended that before deploy