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..
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
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
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.
I was looking for a list:
Ex.
Synchronize time with host
Remove vendor specific software. Ex. Dell OpenManage, Array Manager
etc...
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
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
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
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
I can confirm it is both TCP and UDP, as for bidirectional, not quite sure - maybe somebody else can comment