VMware Converter - P2V process stuck at 1% 10 days...

[SouthSeaPirate]

Hello again all!

Having a bit of an issue here with my first P2V; the conversion process is taking ages. Each time Ive tried, the conversion starts at 1 hour and 6 minutes, then drops to 41min, 16min, 6min. This is over a 2 hour plus time frame.

Once it hits that 6min mark, it will finally move to 2% and 6 DAYS 5 hours. After waiting a little longer, it goes to 10+ hours. I didnt let it get any further than this.

Converter 5.0.1
Physical machine 380 G5

[DigitalZeroOne]

Are you converting it and saving it across the network? If possible, you could connect a USB drive to the physical machine, and convert it directly to the drive.

[ptilsen]

How big is the system you're converting? What is its workload? What's the destination hardware?

There are many performance considerations for conversions. Knowing it's a 380 G5 really only tells us what generation of processors it could be using, which is to say almost nothing. Storage and network are going to be your most likely bottlenecks.

[azjag]

What is your network speed? Are you running at half or full duplex? How much data are you migrating? Can you stop unnecessary services while the conversion is in progress. Have you disabled SSL for the worker process? Are the ports blocked?

[blargoe]

What is the destination environment?

[slinuxuzer]

Hello again all!

Having a bit of an issue here with my first P2V; the conversion process is taking ages. Each time Ive tried, the conversion starts at 1 hour and 6 minutes, then drops to 41min, 16min, 6min. This is over a 2 hour plus time frame.

Once it hits that 6min mark, it will finally move to 2% and 6 DAYS 5 hours. After waiting a little longer, it goes to 10+ hours. I didnt let it get any further than this.

Converter 5.0.1
Physical machine 380 G5

The last time I saw an issue like this it was because Vcenter and the source machine were in different Vlans, If I remember right I moved the source into the same Vlan as Vcenter and it started working, a few other notes on P2v's. Sorry if you already know these things, I thought I'd include them anyway.

1. Technically P2'ving is only supported for the OS, not the data files.

2. Since this is a HP server set the proliant support pack application services to disabled on the destination VM (this can be done in the vmware converter tool) particuarly the sysdown.exe service, this service had me pulling my hair out, it will peg the CPU on the destination VM at 100% and make it really hard for you to do anything. (make sure you remove all the PSP apps on the new vm, they are no longer needed since the server is no longer going to run on HP hardware)

3. If this is a windows 2000 server you will need to use version 4.x of vmware converter (I forget the exact version) for it to work on a 2000 server.

4. If the workload for this server is oracle, sql, or exchange or something transactional, I.E. uses a database, stop the application/database services and change the service to disabled, don't set to manual cause I've seen them get auto-restarted, this will make sure the "transactional" datasets on the server doesn't change during the p2v causing consistency problems. If this is AD forget the P2v and build a whole new VM, you can't stop AD, cold clone would be your only option, and its so easy to build a DC its just not worth it.

5. If you keep having issues with this, perhaps try the cold clone CD from Vsphere 4, I haven't used this to go to a Vpshere 5 environment yet, but I should think it would work, this was an awesome tool that allowed me to P2v alot of machines that just wouldn't work any other way.

6. Make sure to do yourself a favor and review VM alignment recommendations for your storage array (if using shared storage) with version 5 converter you can change the block alignment during the p2V process, mis-aligned vm's are a HUGE performance concern and I've seen more issues spawn from this than any other issue.

7. Make sure to clean up Ghost / non-present hardware on the new VM, there is a process out there to remove this after you p2v, this is basically the removal of hardware drivers, things like the SCSI controller for your 380 G5, since its no longer needed, this will greatly increase VM stability.

8. Generally you'll change the CPU count from x down to 1, most Vm's only need one Vcpu, so make sure you change the servers HAL driver to match whatever you assign, I generally use ACPI uniprocessor/multiprocessor depending on the processor count, if this isn't set right you'll see lots of issues.

9. Finally take this chance to resize your C: and other drives with the Converter if they need it.

[SouthSeaPirate]

Are you converting it and saving it across the network? If possible, you could connect a USB drive to the physical machine, and convert it directly to the drive.

Never heard of this. It may have to be an option at this point.

[SouthSeaPirate]

How big is the system you're converting? What is its workload? What's the destination hardware?

There are many performance considerations for conversions. Knowing it's a 380 G5 really only tells us what generation of processors it could be using, which is to say almost nothing. Storage and network are going to be your most likely bottlenecks.

This only for data retention (policy). Ive now went to another server that needs converting;

This one will get to 85% in only a few minutes, but eventually slows down to a crawl. Starts off running somewhere around 10MBps, then slowly and now down to 86KBps... Been sitting at 95% for a day now.

Server Stats;
CPU Xeon 3Ghz
Mem 2GB
HD 47GB

VM Stats;
Total CPU 134GHz
Total Memory 383.96GB
Total Storage 2.46TB

Everything is ran through an HP Brocade to a 3Par SAN; all fibered to the hosts.

What is your network speed? Are you running at half or full duplex? How much data are you migrating? Can you stop unnecessary services while the conversion is in progress. Have you disabled SSL for the worker process? Are the ports blocked?

1000Mbps (original was through a 2950; obvious bottleneck).
Full Duplex (orginally forced, but changed to auto).
Firewall is off.
I know nothing of SSL, please advise.
Migrating 47GB.

The last time I saw an issue like this it was because Vcenter and the source machine were in different Vlans, If I remember right I moved the source into the same Vlan as Vcenter and it started working, a few other notes on P2v's. Sorry if you already know these things, I thought I'd include them anyway.

1. Technically P2'ving is only supported for the OS, not the data files.

2. Since this is a HP server set the proliant support pack application services to disabled on the destination VM (this can be done in the vmware converter tool) particuarly the sysdown.exe service, this service had me pulling my hair out, it will peg the CPU on the destination VM at 100% and make it really hard for you to do anything. (make sure you remove all the PSP apps on the new vm, they are no longer needed since the server is no longer going to run on HP hardware)

3. If this is a windows 2000 server you will need to use version 4.x of vmware converter (I forget the exact version) for it to work on a 2000 server.

4. If the workload for this server is oracle, sql, or exchange or something transactional, I.E. uses a database, stop the application/database services and change the service to disabled, don't set to manual cause I've seen them get auto-restarted, this will make sure the "transactional" datasets on the server doesn't change during the p2v causing consistency problems. If this is AD forget the P2v and build a whole new VM, you can't stop AD, cold clone would be your only option, and its so easy to build a DC its just not worth it.

5. If you keep having issues with this, perhaps try the cold clone CD from Vsphere 4, I haven't used this to go to a Vpshere 5 environment yet, but I should think it would work, this was an awesome tool that allowed me to P2v alot of machines that just wouldn't work any other way.

6. Make sure to do yourself a favor and review VM alignment recommendations for your storage array (if using shared storage) with version 5 converter you can change the block alignment during the p2V process, mis-aligned vm's are a HUGE performance concern and I've seen more issues spawn from this than any other issue.

7. Make sure to clean up Ghost / non-present hardware on the new VM, there is a process out there to remove this after you p2v, this is basically the removal of hardware drivers, things like the SCSI controller for your 380 G5, since its no longer needed, this will greatly increase VM stability.

8. Generally you'll change the CPU count from x down to 1, most Vm's only need one Vcpu, so make sure you change the servers HAL driver to match whatever you assign, I generally use ACPI uniprocessor/multiprocessor depending on the processor count, if this isn't set right you'll see lots of issues.

9. Finally take this chance to resize your C: and other drives with the Converter if they need it.

1. I thought this was the whole point of P2Ving. It does not copy any of the data?

2. I can never get this far. P2V never finishes.

3. Running Server 2003 and using Converter 5.0

4. Does have a DB; all related services stopped (that I know of).

5. That may be an option, however, there is obviously another underlying issue; especially seeing how Im on another server and still having issues.

6. Ill have to research this. Know that I am running the same way as five other arrays in our organization.

7. Again, a cannot get this far; great info for when I finally get there.

8. I followed the recommended; which was the same as the currect proc. Single CPU, 2 Thread, 2 Core. Should I still drop this to 1?

9. I have been doing the minimal. These are not production, just needed for data retention. Once the cenversion is complete, the plan is to back up the VM file (cannot remember the name at the moment) to tape. Then delete the VM from the array. Restore the VM when needed...

Thank you for all the great advice!