ivivanov's Posts

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.
It depends on the source server, if it is a Windows machine - then you can use the so called "proxy mode" and it redirects the traffic through the Converter server, i. e. exactly the use case you are... See more...
It depends on the source server, if it is a Windows machine - then you can use the so called "proxy mode" and it redirects the traffic through the Converter server, i. e. exactly the use case you are describing. However, keep in mind that proxy mode is... well, sllowww, and especially on faster networks the difference can be in orders of magnitude.
No, VMware Converter does not officially support that. Yes, you can try that and see whether it is working, given you satisfy the required networking prerequisites (that are listed in the User's Guid... See more...
No, VMware Converter does not officially support that. Yes, you can try that and see whether it is working, given you satisfy the required networking prerequisites (that are listed in the User's Guide). IMO if you convert the Azure VM as a physical machines it has good chances to work on the destination.
There is Converter 6.4 already where this issue should have been fixed.
Hm, this is quite surprising, I have used this setting and it worked as expected. Will try to reproduce it locally and will get back to you. BTW it would be useful if you can share the log bundle of ... See more...
Hm, this is quite surprising, I have used this setting and it worked as expected. Will try to reproduce it locally and will get back to you. BTW it would be useful if you can share the log bundle of the failed conversion task for analysis. You can send them to me as a private message if you do not want to post them publicly.
Hi To your questions: 1. For the disk options it is best to include all volumes listed - some of them are system volumes used by Windows and if missing the target might be unbootable 2. For the ne... See more...
Hi To your questions: 1. For the disk options it is best to include all volumes listed - some of them are system volumes used by Windows and if missing the target might be unbootable 2. For the network options - by default Converter lists all network cards detected on the source and creates the same number of network cards on the destination. There is not much to preserve for the networkinc expect the count of the NICs on the destination. You can modify that number to as much network cards as you want to have on the destination. 3. For the Advanced/other options - it is best if you leave everything to default unless you want to make use of any of them. The screenshot you have provided looks OK. That said, historically there have been issues reported by some customers that converting a DC is not always successful, meaning the machine is converted and boots, but the domain controller starts acting odd. Probably it is related to the IP/network change on the destination, but this is just a speculation. Anyway, be warned and better do some testing before switching over to the migrated one. Probably it would make sense to try to demote it and then promote it to a domain controller again, but I personally have not tried that workflow. Hope it helps, Ivan
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
Have you tried to specify the source machine in host:port format, e. g. if you are using an IP address - then it should look like x.y.z.t:222
In general yes, it is possible and should work in most of the cases. Given that the guest OS-es are supported by Converter I think the chances are pretty good. There is a possibility that there is so... See more...
In general yes, it is possible and should work in most of the cases. Given that the guest OS-es are supported by Converter I think the chances are pretty good. There is a possibility that there is some software installed in the source VM by the 3rd-party hypervisor (e. g. similar to VMware Tools) that does not work well within VMware environment and in theory could prevent the destination OS from booting, but we cannot tell in advance whether this would be the case. The best option is to give it a try.
Hi, I believe your analysis is correct and this is indeed the cause for the failure. I have double-checked the log bundle and found the corresponding location for the error in the source code. ... See more...
Hi, I believe your analysis is correct and this is indeed the cause for the failure. I have double-checked the log bundle and found the corresponding location for the error in the source code. There is however something I do not understand. When setting up the conversion job in Converter Client, at the destination select step you need to connect to the vCenter sever and enter username and password. At this point Converter Client should display a prompt stating the server certificate is not trusted, display the thumbprint and ask for confirmation whether to proceed with the connection or not. If you select to ignore the error then the certificate thumbprint is saved in the job spec and then passed to the Converter Agent. The agent in turn connects to vCenter server and checks whether the saved certificate from the UI matches the actual server certificate. If this is the case it proceeds with the connection. In your case obviously it did not happen as confirmed by the error you have posted: 2022-11-08T10:41:41.564-06:00 warning vmware-converter-agent[08940] [Originator@6876 sub=task-1] CreateVimConnection has SSL certificate error while trying to connect, Error: SSL Exception: Verification parameters: --> PeerThumbprint: DF:65:E8:9E:F9:95:C8:81:A7:2A:BC:66:63:F5:EB:19:75:44:60:54 --> ExpectedThumbprint:   <<<<<<<<<!!!!!!!!!!!!!!!!!!!! --> ExpectedPeerName: xxx.xxx.xxx Indeed the ExpectedThumbprint field is empty and it does not match the actual server thumbprint, which ultimately aborts the connection. I have also checked the GUI log, where the expected thumbprint should be populated by the client and indeed we can see the following: -->          vimConnect = (converter.VimConnectionSpec) { -->             hostname = "vcenter.server.name", -->             port = <unset>, -->             credentials = (converter.VimConnectionSpec.LoginVimCredentials) { -->                username = "<domain>\<user>", -->                password = (not shown) -->             }, -->             verifyPeer = <unset>, -->             sslThumbprint = <unset> -->          }, We can see the sslThumbprint property is unset in the client and that is the reason for passing an empty value to the agent. For a reference if we look at another conversion in the GUI log we see something different: -->          vimConnect = (converter.VimConnectionSpec) { -->             hostname = "10.x.y.z", -->             port = <unset>, -->             credentials = (converter.VimConnectionSpec.LoginVimCredentials) { -->                username = "<user>", -->                password = (not shown) -->             }, -->             verifyPeer = <unset>, -->             sslThumbprint = "2F:86:39:75:FB:8D:9F:03:45:1E:84:0A:9F:D3:08:50:FE:53:DE:8C" -->          }, In this case the thumbprint is populated properly in the client and should be propagated to the agent. I am not sure what could be the reason for this behavior, what comes to my mind is that the client machine (where Converter Client is running) trusts the vCenter certificate and the connection proceeds without an exception, which does not generate a prompt in the UI and as a result the vCenter certificate thumbprint does not get passed to the agent. On the other hand on the Hyper-V machine the vCenter certificate is not trusted, but since the thumbprint is not saved by the client (ExpectedThumbprint is empty), it cannot be confirmed and the connection to vCenter fails. I think the easiest workaround would be to configure the Hyper-V server to trust the vCenter certificate (note it should be configured for the local machine root, but not for the current user), however this is just a suggestion, I have not verified it locally since I have not reproduced the issue.
Hi, Thanks for posting to the community. It is not obvious where exactly the SSL fault is happening. Converter has multiple components (Client/Server/Agent) possibly at different machines, it also c... See more...
Hi, Thanks for posting to the community. It is not obvious where exactly the SSL fault is happening. Converter has multiple components (Client/Server/Agent) possibly at different machines, it also communicates with vCenter server and ESX server where the source/destination VM lives. It is not clear which of all connections is experincing issues. It also includes management traffic and data traffic. I am not sure what changes you have done to the XML files, but you cannot turn off the SSL communication on the management connections, just on the data connection for copying actual data (the reason for enabling turning it off is to mitigate some performance issues if SSL-encrypted traffic is much slower and it is clear that the network is secure). Given that you are converting a Hyper-V VM and you have got to 1% into the progress indicates the error most likely is in the Converter Agent log file which is on the Hyper-V server. Alternatively you can try to export a log bundle from the UI by right-clicking on the failed task and it should contain all related log files for further investigation.
"\\.\pipe\vmware-converter-worker-soap" indicates this is the communication between the Server and Worker services. "Closed connection" means the other end of the named pipe was closed, which can hap... See more...
"\\.\pipe\vmware-converter-worker-soap" indicates this is the communication between the Server and Worker services. "Closed connection" means the other end of the named pipe was closed, which can happen when Worker service exited - either on service stop (manually, or e. g. by windows update manager), or more likely - if the service crashed. Can you please check in Services Control UI if the Worker service is still running, if there are any events related to the VMware vCenter Converter Worker service in the Windows Event log (e. g. crash, restart) and also look in the worker log for some more detailed errors, and specifically - for a backtrace (it should be along with the server log).
Seems like Converter and vCenter cannot negotiate a common version. If your vCenter is new and Converter is old (and 6.2 IS old) then it is possible to happen. Have you tried with Converter 6.3? It c... See more...
Seems like Converter and vCenter cannot negotiate a common version. If your vCenter is new and Converter is old (and 6.2 IS old) then it is possible to happen. Have you tried with Converter 6.3? It can be downloaded at https://customerconnect.vmware.com/en/downloads/details?downloadGroup=VCENTER_STANDALONE_630_GA&productId=1355&rPId=95099
If it is a x86-based system and the guest OS inside the AIX VM is one from the Supported Operating Systems list for Powered-On conversions, then there are good chances that you can convert the AIX VM... See more...
If it is a x86-based system and the guest OS inside the AIX VM is one from the Supported Operating Systems list for Powered-On conversions, then there are good chances that you can convert the AIX VM treating it as a physical machine. Of course we have never tried that.
I looked at the log bundle and the "grub-install" error is not the issue. Converter tries to detect the grub version, so it runs multiple commands, trying to get successful execution. Since this mach... See more...
I looked at the log bundle and the "grub-install" error is not the issue. Converter tries to detect the grub version, so it runs multiple commands, trying to get successful execution. Since this machine seems to have a GRUB1 bootloader, it is expected that grub2-related commands fail. IMO the reason for the failure is at the volume layout: --> <volume mountPoint="/" blockSizeInBytes="4096" capacityInBlocks="36915830" blocksFree="29946550" blocksUsed="6969280" devicePath="/dev/wally/root" fileSystemType="ext3" isBootVolume="false" label=""> --> <extfsFeatures dirIndex="true" filetype="true" hasJournal="true" journalDev="false" resizeInode="true" sparseSuper="true" extent="false" flexBg="false" uninitBg="false" inodesCount="9388032"/> --> </volume> --> <volume mountPoint="/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines" blockSizeInBytes="4096" capacityInBlocks="36915830" blocksFree="29946549" blocksUsed="6969281" devicePath="/dev/wally/root" fileSystemType="ext3" isBootVolume="false" label=""> --> <extfsFeatures dirIndex="true" filetype="true" hasJournal="true" journalDev="false" resizeInode="true" sparseSuper="true" extent="false" flexBg="false" uninitBg="false" inodesCount="9388032"/> --> </volume>  We can see that "/dev/wally/root" is mounted at two locations - at "/" (root filesystem) and also at "/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines". Converter has issues with this type of layout. The solution would be to unmount the device temporarily from "/var/lib/named/usr/lib/i386-linux-gnu/openssl-1.0.0/engines" until the conversion completes. However given that Ubuntu-18 has kernel 4.15 and Converter is using 2.6.XX, I think it is quite likely for the conversion to fail after the data is copied while trying to reconfigure the guest OS in the destination VM and make it bootable in virtual environment.
Hi Paul, Sorry to hear that you are having issues with accessing Converter Beta program. I have forwarded your email address to the corresponding team to have a look and hopefully the issue will be ... See more...
Hi Paul, Sorry to hear that you are having issues with accessing Converter Beta program. I have forwarded your email address to the corresponding team to have a look and hopefully the issue will be resolved soon. BTW there is already an official Converter Beta sign-up page (alternative to the email alias posted in the beginning) so you can try to self-register for the Converter Beta at https://www.vmware.com/learn/1645300_REG.html and hopefully it can be processed faster. Appologies for the inconveniences that you have experienced so far. Regards, Ivan
In terms of features it is the same product, this first re-release mostly focused on security improvements, so most likely the existing issues would be still there. And yes, Linux is much more versat... See more...
In terms of features it is the same product, this first re-release mostly focused on security improvements, so most likely the existing issues would be still there. And yes, Linux is much more versatile and customizable than Windows and it is much harder to capture all differences into a single workflow, so we are trying to focus at least on the standard installations.
You should get an email invitation to the Beta program and after you complete your registration you should be able to access the Beta page.
Converter Server machine needs to be able to connect to the destination ESX HOST (not vCenter server) on port 902 (check firewall and routing). Also the Converter Server machine needs to be able ... See more...
Converter Server machine needs to be able to connect to the destination ESX HOST (not vCenter server) on port 902 (check firewall and routing). Also the Converter Server machine needs to be able to resolve the destination ESX HOST name through DNS (the name that is registered in vCenter server) (check DNS). The actual error should be visible in the converter-worker log file, which should be located under "%PROGRAMDATA%\VMware\VMware vCenter Converter Standalone\logs".
A couple of things that came to my mind 1. You can try to find an older Converter version in Google - even if it is not available for download on vmware.com, it can be found on 3rd-party sites.... See more...
A couple of things that came to my mind 1. You can try to find an older Converter version in Google - even if it is not available for download on vmware.com, it can be found on 3rd-party sites. You could try with 4.3 or even 4.0.x. I am not sure what version of glibc they use, but the chances are better. 2. You can try to manually rebuild vmware-sysinfo on that source machine with the local glibc version and use the custom built with Converter. vmware-sysinfo is open-source and its source tarball can be found on vmware.com, however the process most likely will not go smoothly, especially on an unsupported platform. With both approaches keep in mind that this is an unsupported scenario and even after a successful query it is possible to hit some other issues later in the conversion process.