Conververter 3.0 – slow speed, requested feature, windows re-activation

[tom_e_reynolds]

Vmware Conververter 3.0 issues – slow speed, requested feature, windows re-activation.

Slow Speed

One of the things I've noticed is that I get better response when I run the Converter on the source machine, not the destination server as I had been trying all day. Sounds odd, but it worked when previous attempts of running it from the destination server failed.

Also, I am noticing speed issues, that are directly related to network issues, not Converter issues. I am not sure why, but on some of my servers, I am only getting 10-20% NIC utilization when generating the-VMDK files and attempting to copy them to the destination server.

This amounts to average 10-20Mbit/sec, which is quite poor on our 100 MB Switched network. It would have taken 5 hours to image a 4 GB Hard Drive. On some occasions, the entire file copy failed (timed out), and I had to start over and try to create the VMDK files on a different destination server with better network performance.

Keep this in mind. Keep your eye on the network bandwidth when creating the VMDK file on the destination server. If you are using Windows 2003, this is easy since task manager now includes a network bandwidth utilization tab. You should be able to get 50%-75% network utilization when copying the file to the destination server. If its lower than that, consider copying the image file to a different destination server with better network performance. It would be worth your time.

Requested feature:

It would be nice, if in future versions, if we could have the option to just create the VMDK file locally, as on a USB external drive, and allow us to just move it ourselves.

Windows Re-Activation

Also...keep this in mind...I just got hit with this. When moving Windows 2003 Server from Physical to Virtual, it now prompted me to re-activate my license when booted in the VM. Since we were using MSDN, and had already used our allocated amount, I can't re-activate. Windows Activation tells me the license count is too high for my subscription. Windows will NOT let me login to the box at all until I reactivate. Since I have no spare licensing, this now concludes my test, as I can't re-activate, since we are still using the original source box. Bummer, I really wanted to test the P2V migration!

Also, if you do need to re-activate, make sure your IP addressing and Networking is setup, since you won't be able to login to the box to set any addressing. In the end I had to enable NAT on the host NIC to allow me to even access the Internet from the host I was on.

-TomR

[Jasemccarty]

I'll have to agree with the points you made about the nic settings. I completely agree.

Regarding MS Activation, this is a limitation of the Windows OS, and does not pertain to VMware or any other virtualization technology.

I will say, some have seen success, at least on HP boxes, where if you P2V a HP box, and if the host that will be running the resulting VM on is an HP, can sometimes be tricked by using the following code in the .vmx file:[code]smBIOS.reflecthost="TRUE"[/code]

That will pass some of the host's bios information to the VM, and sometimes won't trigger a reactivation. I haven't seen any success on Dell boxes, only HP.

[APlant]

Hello,

In response to a couple of points:

Slow speed: I have done quite a few migrations now in various environments and speed seems OK. I am able to transfer a 15Gb disk in around 30-45 mins on a 100Mb network and quicker on 1 Gbps network (30Gb in around 1 hour). I have found that things take slightly longer if the Windows disk has 2 partitions on the same disk (i.e. one logical drive). If the physical server has 2 logical drives (e.g. with a c drive on one and d on the other) the process is faster.

Regarding slow networks or wanting to copy locally, this is the approach I take. Take the option to convert from physical to VMware Server/Workstation (i.e. not to ESX). This will create the files locally on the converter machine. Then take this machine to the site with the slower link and convert from 'Standalone Virtual Machine' with the destination as the ESX host. Works well, obviously it is a two step process but could still be quicker then converting over a WAN or slow link.

Hope this helps

[pharmacare]

I am having this same slowness issue. They are 10GB partitions with about 7GB used. It is taking a little over an hour on a 1gbs network and I am not resizing the partition.

I am running converter from a Physical server and migrating my esx 2.5 guest to esx 3.0. I have run Converter from a different physical server on 1gbs with the same result.

[bretti]

Please forgive me if you've already checked this.

Are you getting any collissions or errors on the switch ports of the machines being used in this process?

It really sounds like some speed duplex mismatch.

[APlant]

Hello,

Just to follow on from my earlier post, although all the migrations I have done so far have been Ok with respect to speed I have had a 'slow' migration today. I was running another migration at the same time (but to 2 different ESX hosts) and 30Gb went over in around 45 mins. Another server took hours (5 at the last count!) yet it only has a 10Gb disk to take over. All this is happening on the same network so I don't think the issue is network related.

The difference is in hardware, the slow server is a HP DL360, but it's not as if it's a 'really' old and low spec machine.

On both migrations I have used the boot CD.

I'm wondering what physical hardware other people who are having slow migrations are migrating from?

[schnj65]

same thing happened to me over the weekend during a P2V - P2V's have been running at 23 - 27 GB per hour over a Gigabit Cisco link with just about any scenario (resizing, not resizing, one disk w/ multi Win partitions, 2 phy disks each w/ a Windows partition).

The only thing that changed is that one of the Dell 6850 servers in my cluster locked while trying to re-scan the SCSI bus for a new SAN LUN - HA kicked in and thankfully worked as advertised. The server right before it in the cluster re-scanned fine; however this is the server that all new VM's seem to land on when the Cold P2V -Boot CD creates the new VM (we have Emulex HBA's and I see that VMware released a critical patch for 3.0.1 related to detecting new storage)

The servers that I am trying to P2V are Dell 2850's; only a generation old. Dual 3.6 GHz proc's and 2 GB of RAM.

I am thinking about rebooting the Virtual Center server and the server that did not crash during the re-scan, as this was the last thing changed - it could be unrelated; however with VMotion it is easy to try

[vmwareguru]

Slow speed is probably due to the speed duplex mismatch. The converter is really for volume licensed products. You might be able to hack your way to get around the activation problem. you can google your way to finding alternate method of re-activating your windows.