ivivanov's Accepted Solutions

The error you have seen is happening in the initial stages of the conversion process and it does not matter whether the source is a KVM vm or any other running Linux machine. The problem is the helpe... See more...
The error you have seen is happening in the initial stages of the conversion process and it does not matter whether the source is a KVM vm or any other running Linux machine. The problem is the helper ISO file cannot be attached to the virtual CD-ROM device and as a result the destination VM cannot boot (as you have already identified). The helper ISO is attached to the destination VM using the remoteDeviceConnect.exe tool. It accepts as a command-line argument a ticket (generated by vCenter) in order to authenticate to the destination ESX server and proceed later with connecting the ISO image to the virtual CD-ROM. Looking at the log bundle there is the following line in vmware-converter-worker-2.log: 2023-05-23T13:21:30.661+08:00 info vmware-converter-worker[07464] [Originator@6876 sub=Default] SysCommand invoking command C:\Program Files (x86)\VMware\VMware vCenter Converter Standalone\remoteDeviceConnect.exe -t cd-iso -d ide0:0 -W -u wss://localhost.localdomain:443/ticket/3adcd0329bdc737 -V /vmfs/volumes/vsan:5271497197c4aef5-73578a6868426934/4d4d6c64-900d-5a61-be3e-d47c44d2278f/192.168.1.83.vmx -T 26:6F:69:E0:F5:4A:08:98:92:76:9B:5C:C9:44:5D:7F:51:BC:E0:33 C:\Program Files (x86)\VMware\VMware vCenter Converter Standalone\converter-helper-vm-x64.iso The ticket used is wss://localhost.localdomain:443/ticket/3adcd0329bdc737. You can see the ESX host name is reported as localhost.localdomain and this obviously prevents the connection to the ESX host and thus successfully attaching the helper ISO.  You can try to change the following setting in the converter-worker.xml file:     UseHostIPForWebSocketTicket to true, and restart the Converter Worker service, then you can retry the conversion.   Let me know if this works.
Hello, If you open the product download page at this URL, it will look like this: If you click on the "Read More" link it opens an additional pane with the binary checksums: BTW there is a... See more...
Hello, If you open the product download page at this URL, it will look like this: If you click on the "Read More" link it opens an additional pane with the binary checksums: BTW there is already a 6.4 Beta version available. Regards, Ivan
You have to make sure you have network connectivity on port 902 both from Converter Server machine and the source machine to the destination ESX server (note it is not the vCenter server). If you... See more...
You have to make sure you have network connectivity on port 902 both from Converter Server machine and the source machine to the destination ESX server (note it is not the vCenter server). If your ESX server is registered in vCenter with hostname, but not with IP address, then both Converter Server machine and the source machine should be able to resolve the ESX server DNS name.
Hi Javier, Unfortunately this is a long-standing problem in Converter, but it has never been highly prioritized in order to be addressed and fixed. I guess the assumption was that "it doesn't ... See more...
Hi Javier, Unfortunately this is a long-standing problem in Converter, but it has never been highly prioritized in order to be addressed and fixed. I guess the assumption was that "it doesn't hurt" to have logical partitions. It is the first time I hear this is causing actual problems - added free space at the end cannot be used unless switching to dynamic disks. We should need to revisit this bug again and prioritize it accordingly. As a workaround I would suggest that you can resize volumes as a part of the conversion process - you can add free space to each volume in the conversion wizard and would not need additional resizing after that. I know it is not a real fix but it might be enough for your case. Regards, Ivan
Hm, looking again at the offending partition, it is actually a SWAP volume. It should be pretty harmless to call swapoff, delete the partition, re-create it again with the correct size and call s... See more...
Hm, looking again at the offending partition, it is actually a SWAP volume. It should be pretty harmless to call swapoff, delete the partition, re-create it again with the correct size and call swapon. However, again as this is a change in the disk partition information, a backup is a good idea...
Yes, in theory you can. /boot directory under / is OK, however this error message is a bit misleading - I would say that Converter could not recognize your *disks* and thus no mounted partitions,... See more...
Yes, in theory you can. /boot directory under / is OK, however this error message is a bit misleading - I would say that Converter could not recognize your *disks* and thus no mounted partitions, so it could not find /boot neither as a separate partition nor as a directory under /. Are you using some software RAID (md) on your source server?
Yes, this is correct. In addition you have the option to stop some services on the source before the synchronization step (e. g. a database server) so no data loss occurs, only downtime.
You may want to have a look at Re: An error occurred while opening a virtual disk. Verify that the converter server and the running source machines hav… and let me know whether it works for you.
The error is pretty clear - the destination ESX server does not support running of 64-bit operating systems, and obviously the source guest OS is 64-bit. This could mean the hardware virtualizati... See more...
The error is pretty clear - the destination ESX server does not support running of 64-bit operating systems, and obviously the source guest OS is 64-bit. This could mean the hardware virtualization feature in ESX server BIOS is not enabled. You can try to enable it and retry the conversion.
The problem is at 2014-03-10T18:52:38.022+01:00 [05852 info 'Default'] GetManagedDiskName: Get virtual disk filebacking [WTVNX1_VMFS_15_L] PDC_JNC-DoNotPowerOn/PDC_JNC-DoNotPowerOn.vmdk 2014-03-... See more...
The problem is at 2014-03-10T18:52:38.022+01:00 [05852 info 'Default'] GetManagedDiskName: Get virtual disk filebacking [WTVNX1_VMFS_15_L] PDC_JNC-DoNotPowerOn/PDC_JNC-DoNotPowerOn.vmdk 2014-03-10T18:52:38.022+01:00 [05852 info 'Default'] GetManagedDiskName: updating nfc port as 902 2014-03-10T18:52:38.022+01:00 [05852 info 'Default'] GetManagedDiskName: get protocol as vpxa-nfcssl 2014-03-10T18:52:38.022+01:00 [05852 warning 'Default'] [Converter::Util::PopulateSslIdDb] Empty thumbprint for host wtesx6.intra.wolftheiss.com 2014-03-10T18:52:38.022+01:00 [05852 info 'Default'] GetManagedDiskName: Get disklib file name as vpxa-nfcssl://[WTVNX1_VMFS_15_L] PDC_JNC-DoNotPowerOn/PDC_JNC-DoNotPowerOn.vmdk@wtesx6.intra.wolftheiss.com:902!52 d5 76 8c 7c 91 fa 29-e4 f7 ed 11 cd e4 1e 81 When trying to open the virtual disk Converter server should provide the SSL thumbprint of the ESX server where the virtual disk file is located, however it provides an empty thumbprint and the opening of the virtual disk file later fails because of SSL errors. Converter server is providing an empty ESX Server thumbprint because it is reading an empty thumbprint from vCenter Server. The reason why vCenter Server is providing empty thumbprints for ESX hosts is a setting on the vCenter Server. It can be found in vCenter Client under Administration/vCenter Server Settings/SSL settings (in the list on the left). There is a checkbox “vCenter requires verified host SSL certificates”. By default this option is turned on, however most likely in your case it is turned off. When deselected, in general this option means all host in the list below are NOT trusted. As a result when a ticket is issued for such a host, the thumbprint field in the ticket (needed for opening the virtual disk) is not populated. On each line in the list along each not-verified host and thumbprint on the right there is a checkbox for “verifying” the specific host thumbprint. After a host’s thumbprint is “verified” then vCenter starts returning a thumbprint for that host along with the ticket information and conversion should be able to proceed. You need to either select the global option, or "verify" each specific ESX server you plan to use as a source or destination of a conversion process. HTH
It seems there is some problem with your volume K:. What is it? Is there a chance to detach it or make it offline and try again?
Hi, We were able to identify the issue and it is not in Converter itself, but rather related to the physical infrastructure. The problem is in the ARP cache on the target network gateway. Afte... See more...
Hi, We were able to identify the issue and it is not in Converter itself, but rather related to the physical infrastructure. The problem is in the ARP cache on the target network gateway. After the first conversion it has cached an ARP entry for the helper IP address. When you start the second conversion, the new VM that is created has a new network card with a new MAC address, but the gateway is not aware of this change and when Converter Server tries to connect to the helper, the gateway sends the IP packets to the wrong MAC address and eventually they are dropped. When the ARP cache on the gateway expires - the problem is fixed automatically (in our environment by default it was about 15 minutes, but it depends on the specifc hardware and configuration). A possible workaround is to generate some network traffic from within the helper VM (e. g. a ping to the default gateway IP address) that would generate some ARP traffic and refresh the gateway ARP cache. Instructions how to logon to the helper VM are available at http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1036746. Once you login you can ping anything (even an invalid target IP address does the job) and the conversion should proceed immediately. HTH, Ivan
You need to somehow get access to the target disks. You can use VMware Workstation to mount the target VMDK or you can temporarily attach the disk with the Windows directory to another Windows VM... See more...
You need to somehow get access to the target disks. You can use VMware Workstation to mount the target VMDK or you can temporarily attach the disk with the Windows directory to another Windows VM (in this case you should open Disk Manager and select Rescan Disks command from the Actions menu and the new virtual disk from the converted Amazon VM should become visible). After that: * run regedit on that machine * select HKLM hive * from the File menu select 'Load Hive' command * navigate to the target SYSTEM registry hive (it is under WINDOWS\system32\config\system *on the target disk* that was attached to the VM, but *not* the currently running Windows directory) * pick a name for the new key (e. g. ec2-system) * navigate to  ec2-system\ControlSet001\Services * search for the three drivers and delete the whole keys * then select again the ec2-system key under HKLM * from File menu select 'Unload Hive' command and close Regedit * unmount the mounted VMDK or detach the target virtual disk from the "temporary" VM Power on the converted VM HTH
i dont think P2V over the WAN will be nice idea. Nope, it is not, besides Converter needs direct connectivity from the physical source to the target ESX box. Can we Convert the physical m... See more...
i dont think P2V over the WAN will be nice idea. Nope, it is not, besides Converter needs direct connectivity from the physical source to the target ESX box. Can we Convert the physical machine into virtual machine with the help of VMware Workstation converter and than ship the Vdisk to central DC and than import into VMware Environemnt. Yes, if your physical source is Windows. For Linux physical sources you cannot create a Workstation image, but you need to convert it to an ESX. However after performing Linux P2V to an ESX box, then you can perform V2V conversion of the result to a Workstation image and import it back on the target site.
You need to be able to access \\localmachine\sharedname from the *SOURCE* machine. The way Windows P2V conversions work is to install an agent on the source, then the agent connects to the target... See more...
You need to be able to access \\localmachine\sharedname from the *SOURCE* machine. The way Windows P2V conversions work is to install an agent on the source, then the agent connects to the target (that's why it has to be on a network share) and transfers the data. Can you browse \\localmachine\sharedname from the source (but not from where Converter is installed)?
If you have a Windows machine, you could try using Converter 5.0.1.
To answer the second part of your question, you can try to create a new target VM with blank disks large enough to hold the source image, restore the image in the new VM using the Acronis provide... See more...
To answer the second part of your question, you can try to create a new target VM with blank disks large enough to hold the source image, restore the image in the new VM using the Acronis provided software (bood CD?) and then run Converter on the newly created VM selecting the "Reconfiguration" option (hopefully it will make the result boot in Workstation).
Hm, the SWAP partition is recognized properly -->    <partition number="2" type="primary" isActive="false" fileSystemType="linux-swap"> -->     <device path="/dev/cciss/c0d0p2" major="104" minor... See more...
Hm, the SWAP partition is recognized properly -->    <partition number="2" type="primary" isActive="false" fileSystemType="linux-swap"> -->     <device path="/dev/cciss/c0d0p2" major="104" minor="2"/> -->     <lba start="212160" length="8388480" end="8600639"/> -->    </partition> However, there is no volume that is corresponding to this partition. The only recognized volumes are "/" and "/boot" (no swap). Is this swap partition activated? Converter is detecting the active SWAP partitions through iterating /proc/swaps file. What is the output of # cat /proc/swaps on the source? Message was edited by: ivivanov Updated the partition info pasted from the log with the "right" wrong partition
This is really strange. The log definitely shows network errors. It is either a problem of the ESX host or... I don't know, some networking issue that shows up now and then. A couple of wild gues... See more...
This is really strange. The log definitely shows network errors. It is either a problem of the ESX host or... I don't know, some networking issue that shows up now and then. A couple of wild guesses 1. Try to turn off the SSL encryption on the data traffic - look at http://communities.vmware.com/thread/333786 for details how to do it. 2. Is there a chance for an IP conflict in your network?
Yeah, it seems the output has changed in the newer versions so we need to update Converter accordingly... but still the workaround with the older LVM version on the source (how older?) should wor... See more...
Yeah, it seems the output has changed in the newer versions so we need to update Converter accordingly... but still the workaround with the older LVM version on the source (how older?) should work...