Post P2V Cleanup Procedures

[edmundlp]

Does anyone have a "Best Practices" doc for post P2V cleanup procedures after migrating a physical machine to virtual?

ex. View Event Log, Remove drivers no longer needed, etc..

[admin]

A little dated (covers P2V Assistant) but there are a few slides here that talk about it and still apply to P2V'ed VMs. There will be a new session this year at VMworld on Converter best practices

http://download3.vmware.com/vmworld/2006/tac9886.pdf

[theanykey]

this may not be what your looking for but this is useful if you need to rid the application entirely from a machine that was converted (with converter installed directly to that machine)

1. uninstall

2. reboot

3. clean registry

Manual cleanup required of some Converter Agent files from remote source physical machine

**********

In some cases, the automatic cleanup of Converter Agent files from the system on which it ran is incomplete. If there are vmware-ufad-p2v-XXXXX subdirectories remaining under %SystemRoot% on the remote source physical machine after completion of the import (either successful or failed), automatic cleanup was not totally successful, and might cause future import attempts to fail. To clean up manually (recommended), follow these steps:

1. Launch regedit and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

2. Remove the stcp2v30 key

3. Remove the vstor2-p2v30 key

4. Remove all vmware-ufad-p2v-XXXXX keys

5. Remove all courier-XXXXX keys

6. Reboot

7. Under %SystemRoot%\system32, remove all vmware-ufad-p2v-XXXXX subdirectories

[esiebert7625]

What should I do after I successfully convert my virtual machine?

If you change from a multi-processor system to a uni-processor system you need to manually change the HAL on the Windows server after the conversion. To do this go into Device Manager after the machine first boots and discovers it's new hardware and then click on Computer then right-click on the processor and select Update Driver. Then select Install from specific location and then Don't search I will choose the driver to install. Then select show All compatible hardware and select the appropriate processor. For example, if you went from a dual cpu to a single cpu then select ACPI uni-processor PC instead of ACPI multi-processor PC. You will need to reboot once you change this. To verify what HAL you are using you right-click your hal.dll in c:\windows\system32 and select the Version tab and select Internal Name and it should say halmacpi.dll for multi-processor acpi and halacpi.dll for uni-processor acpi.

Next clean up all the non-present hardware after the P2V conversion. To do this go to a CMD prompt and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 and then DEVMGMT.MSC and then select Show Hidden Devices. Delete any old grayed out hardware.

Next remove any vendor specific applications/drivers. For example on a HP server you should go to Add/Remove programs and remove any HP management agents, survey utility, array config utility, version control agent, etc. Also check your NIC and make sure there are no vendor specific drivers there (ie. teaming). Check the Services to see if all there is anything vendor specific related there and disable any services that are.

[edmundlp]

I was looking for a list:

Ex.

Synchronize time with host

Remove vendor specific software. Ex. Dell OpenManage, Array Manager

etc...

[theanykey]

The list you are looking for would go on for miles as there are way to many variables to assess such as "is this a domain controller?" or "do you have citrix installed" .... But I'll give it my best shot...

Best practices regardless of your environment for converting physical to ESX:

\- install converter 3.0.1 directly to the physical machine as the LOCAL administrator

\- power cycle the physical machine if NT4 or win2k

\- run converter as the LOCAL administrator and choose "this local machine" upon authentication step in the wizard

\- unselect diagnostic partition (if exists)

\- do not alter the size of the disk unless greater then 256gb - then you need to make it less then 256gb (this is a total size of the physical disk - not the partitions within)

\- ignore pagefile

\- choose ESX by IP (not virtualcenter as this adds another point of failure to the task) unless you have ESX 2.x (then you require VirtualCenter or the workaround using scp+vmkfstools)

Check basic network

• ping from source system to VC host

• ping from VC to ESX target system

• ping from source system to ESX target system

• ping from ESX target system to VC host

• ping from ESX target to source system

Check the port usage

• telnet from source system to VC host port 902

• telnet from source system to ESX target system port 902

• telnet from VC to ESX server target system port 902

• telnet from VC to source system ports 902, 445, 139

• Note the Virtual Center or ESX server may be configured to listen on port 905. If so, check that all systems are configured consistently and that you can telnet to the appropriate ports.

Check credentials and privileges

• Ensure that each username can login to all systems (you may want to create one admin account on all systems to simply the testing)

• Ensure the user has permission to create a VM on the target system

• Ensure the user has access to LUNs on the target system

• Ensure the user has write privilege on target system storage devices

• Verify that the user can create a new VM on each target system from VirtualCenter

Verify space requirements

• Check available file space on all systems (Depending on your method you will either need space equal to the selected drive or to the space used on the source drive.)

• Verify that the Target VMname does not exist on target system

• Optionally, turn firewall off on 3.0.1 ESX servers

In some cases the files/volumes are unreadable/locked. This could be due to anti-virus, live backupagents and/or services (file server, web server, etc). To ensure you are in the best environment to avoid these sort of issues, we recommend to msconfig the box. For OSs such as win2k, you can use a 3rd party tool (google is your friend):

To do so:

Click Start --> enter "msconfig" (without quotes)

Click on the "services" tab

Check the box for "hide all Microsoft services"

Select "disable all", then re-check the VMware services

Select the "startup" tab

Select "disable all" then re-check the VMware startup items

Reboot and test if the virtual machine reproduces this issue

If this shows better performance, run the msconfig again and start enabling services one at a time to narrow down which service is causing the issue.

edit*

the deal behind the max filesize is due to limitations of the "default" install of a VMFS partition. This may not be the case if you have made the blocksize larger.

Message was edited by:

theanykey

[pasoboble]

Hi,

Is it the 902 or 443 between VC and the source, I heard that this port change between converter 3.0.0 and converter 3.0.1, thus could you provide us the control protocol (tcp or udp frames).

Regards

Paso

[theanykey]

I need to correct myself - the ports have changed in 3.0.1

Check the port usage (use telnet to verify)

• Converter application to remote physical machine - 445 and 139

• Converter application to VirtualCenter Server - 443

• Converter application to ESX Server 3.x - 443

• Physical machine to VirtualCenter Server - 443

• Physical machine to ESX Server 3.x – 443 and 902

\*** When you select VirtualCenter as a destination and then choose an ESX host, Converter will first make a connection to VirtualCenter and then the ESX host, so you will need to make sure these ports are not being blocked for both the VirtualCenter server and ESX server

[pasoboble]

Could you tel me if the protocol is udp or tcp and thus if it is a bidirectional stream between source and destination (VC to ESX, Physical bax to VMconverter...etc)

regards

paso

[theanykey]

I can confirm it is both TCP and UDP, as for bidirectional, not quite sure - maybe somebody else can comment