Converter Standalone for Windows runs as 64-bit, but it tries to deploy the appropriate agent (32-bit vs 64-bit) based on the source machine’s uname -m. If the source reports i686 but actually has a 64-bit kernel, or vice versa, the agent may crash.
Check:
uname -m on source Linux.
If x86_64, agent should be 64-bit. If i386/i686, agent should be 32-bit. In mixed environments, force the agent architecture by editing the Converter XML job file (advanced).
If the Linux source uses a filesystem that the Converter version does not recognize (such as Btrfs, ZFS, or newer versions of XFS/ext4 features), it may fail to "query" the disk layout and throw a generic error.
If all else fails, consider:
Would you like a one-page checklist or a script to run on the Linux source to auto-fix common issues?
Troubleshooting VMware Converter: "Unable to Query the Live Linux Source Machine"
Running into the dreaded "Unable to query the live Linux source machine" error while attempting a Physical-to-Virtual (P2V) or Virtual-to-Virtual (V2V) migration using VMware vCenter Converter Standalone can bring your migration project to a screeching halt.
This specific error triggers when the Converter fails to properly gather hardware and volume configuration details from your powered-on Linux system.
Let's break down the most common culprits and how to bypass them. 🔍 The Big Three Causes
When this error pops up, the logs usually point to one of these three architectural or security bottlenecks: 1. The Multi-Mount Conflict
This is arguably the most common cause documented in the Broadcom Knowledge Base.
The Problem: VMware Converter expects every source file system to map to a single, unique mount point. If you have a single disk device mounted in multiple directories (like a disk bound to / and at the same time to a directory under /var), the partition analysis logic breaks.
The Clue: Look at your vmware-converter-worker.log for a line saying: No disks for volume with id '/dev/...' and label.
The Fix: Temporarily umount the secondary mount points on your Linux machine until the initial query and cloning task completes. 2. Sudo Without Password Prompting
To pull raw hardware and disk layouts, the Converter executes commands via SSH using administrative permissions.
The Problem: If you aren't logging directly in as root and are instead using a standard user with sudo privileges, Converter will fail if sudo asks for an interactive password prompt.
The Fix: Grant your conversion user passwordless sudo access. Run visudo on the Linux source and append:your_username ALL=(ALL) NOPASSWD: ALL 3. Blocked Executables in /tmp
VMware Converter executes its helper queries by deploying a sysinfo tarball package to the source system's /tmp directory and executing a script.
The Problem: Many security-hardened Linux environments mount the /tmp directory with the noexec permission flag. This hardens the server but stops the script right in its tracks with a "Permission denied" error.
The Fix: You can either temporarily remount /tmp with execution rights using mount -o remount,rw,exec /tmp or change the target path by editing the converter-worker.xml file on the Windows machine hosting the Converter software to point to another writable directory. 🛠 Quick Troubleshooting Checklist
If none of those big three solved your issue, check off these foundational basics: Converter Standalone for Windows runs as 64-bit, but
🔐 Check .bashrc for echoes: If the user profile logs in and returns an interactive text string (like a welcome banner or an echo command in .bashrc), it confuses the SFTP transfer mechanism used by the tool. Move echoes to .bash_profile.
🔌 Network & SSH Ports: Ensure that ports 9089 and 443 are reachable, and verify that standard SSH port 22 is fully accepting connections from your Converter machine.
🔢 SSHD Ciphers/HMACs: Older versions of Converter rely on standard, sometimes deprecated algorithms like hmac-sha1. If your Linux server strictly demands newer SHA2 algorithms, Converter may fail to authenticate.
💿 Unsupported RAID: Remember that the standalone converter does not support native Software RAID (MDRAID) setups.
Are you still getting blocked by hardware queries on your specific Linux distro? Drop your log snippet below and let's figure it out!
The error "Unable to query the live Linux source machine" in VMware vCenter Converter Standalone typically occurs when the application fails to gather essential system information from the source Linux machine. This failure is often rooted in environment-specific configurations rather than a software bug, frequently involving SSH restrictions, permission issues, or non-standard filesystem layouts. Common Causes & Troubleshooting
Based on technical support data and expert reviews, here are the primary reasons for this error: VMware P2V Linux Conversion – The Essential Methods
The VMware vCenter Converter Standalone is a powerful tool, but it often hits a wall when dealing with Linux distributions. One of the most frustrating errors is the "Unable to query the live Linux source machine" message. This error usually triggers during the initial source selection phase, preventing you from even starting the conversion process. Essential Prerequisites
Before diving into deep troubleshooting, ensure these basic requirements are met. Most "unable to query" errors stem from simple configuration oversights. SSH Access: Port 22 must be open on the source machine.
Root Access: You must use the root account or a user with full NOPASSWD sudo privileges.
Network Path: The Converter server must reach the Linux source directly over the network.
Supported OS: Ensure your Linux kernel and distribution version are compatible with your Converter version. 1. Verify SSH Server Configuration
The Converter relies on SSH to communicate with the Linux source. If the SSH daemon is restricted, the query will fail immediately. Permit Root Login
By default, many modern Linux distributions disable root login via SSH. To fix this: Open /etc/ssh/sshd_config. Find PermitRootLogin and set it to yes. Restart the service: sudo systemctl restart sshd. Check SFTP Subsystem
The Converter uses SFTP to transfer helper files. Ensure the SFTP subsystem is enabled in your sshd_config file. Look for a line like:Subsystem sftp /usr/libexec/openssh/sftp-server 2. Resolve DNS and Hostname Issues
VMware Converter is notoriously sensitive to name resolution. If the Converter server cannot resolve the Linux machine's hostname (or vice versa), the handshake will fail.
Use IP Addresses: Try connecting using the static IP of the Linux source instead of the hostname.
Update Hosts File: Add the source machine's IP and hostname to the C:\Windows\System32\drivers\etc\hosts file on the machine running the Converter.
Check Source Hostname: Ensure the Linux source has a valid hostname set in /etc/hostname and /etc/hosts. 3. Disable Sudo Password Prompts
If you are not using the "root" account, the Converter must be able to execute commands via sudo without a password prompt. Run sudo visudo. Would you like a one-page checklist or a
Add the following line for your user: username ALL=(ALL) NOPASSWD: ALL.
Ensure Default requiretty is commented out if it exists, as it prevents non-interactive shells from using sudo. 4. Check for Disk and Filesystem Errors
The "query" process involves the Converter scanning the source machine's partition table and filesystem. If there are inconsistencies, the process will hang.
LVM Issues: Ensure your Logical Volume Manager (LVM) is healthy. Run vgs and lvs to check for errors.
Mount Points: Unmount any stale network drives (NFS/SMB) before starting. The Converter may attempt to query these and timeout.
Disk Space: Ensure the /tmp directory on the Linux source has at least 500MB of free space for the Converter’s helper scripts. 5. Security and Firewalls
Even if Port 22 is open, internal security modules can block the Converter's automated scripts.
SELinux: Temporarily set SELinux to permissive mode using setenforce 0.
IPtables/Firewalld: Temporarily disable the firewall (systemctl stop firewalld) to rule out port blocking.
TCP Wrappers: Check /etc/hosts.allow and /etc/hosts.deny to ensure the Converter’s IP isn't being restricted. 6. Analyze the Logs for Specific Triggers
If the error persists, the GUI won't tell you why, but the logs will.
On the machine running Converter, go to: %ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone\logs.
Open vmware-converter-server.log or vmware-converter-worker.log.
Search for the string "error" or "failed" near the timestamp of your connection attempt.
Look for specific Linux exit codes or SSH "Permission Denied" markers.
Troubleshooting: VMware Standalone Converter "Unable to Query the Live Linux Source Machine"
Migrating physical Linux servers or virtual machines from other platforms to VMware vSphere is a common task, but it’s rarely without hurdles. One of the most frustrating errors you might encounter in VMware vCenter Converter Standalone is the dreaded: "Unable to query the live Linux source machine."
This error usually pops up immediately after you enter the credentials for your source Linux machine. It indicates that the Converter worker cannot gather the necessary hardware and configuration data from the source to build the destination VM.
Here is a comprehensive guide to diagnosing and fixing the root causes of this issue. 1. Verify SSH and Root Access
VMware Converter relies heavily on SSH to communicate with the Linux source. Before diving into complex logs, ensure you have
SSH Status: Ensure the SSH service (sshd) is running on the source machine.
Direct Root Login: By default, many modern Linux distributions (like Ubuntu or newer RHEL) disable direct root login via SSH.
Check /etc/ssh/sshd_config for the line PermitRootLogin yes.
If you are using a non-root user with sudo privileges, ensure the user is part of the sudoers file and that "Allow password-based authentication" is enabled.
The Shell Factor: The source user must use the Bash shell. If the user’s default shell is set to something else (like Csh or Zsh), the query process often fails. 2. Network and Firewall Constraints
Even if you can manually SSH into the box, the Converter needs specific ports open to perform its "query" and subsequent "cloning."
Port 22: Must be open from the machine running the Converter Standalone server to the source Linux machine.
Port 443: Must be open between the Converter server and the vCenter/ESXi host.
DNS Resolution: Ensure the Converter server can resolve the hostname of the Linux source. If DNS is shaky, use the IP address instead of the FQDN when defining the source. 3. Missing System Requirements (The "Hidden" Culprits)
The Converter executes several commands on the source to map out the disk layout. If certain system utilities are missing, the query fails.
Tar, Gzip, and Rsync: These are essential for the data transfer. Ensure they are installed (yum install rsync or apt-get install rsync).
SFTP Server: VMware Converter uses SFTP to move helper files to the source. Ensure the SFTP subsystem is enabled in sshd_config. Look for:Subsystem sftp /usr/libexec/openssh/sftp-server
LVM & Disk Tools: If you are using Logical Volume Management, ensure lvm2 is installed. The converter also frequently uses fdisk, parted, and df. 4. Temporary Directory Permissions
During the query phase, the Converter attempts to write a small script/binary to the /tmp directory on the Linux source and execute it.
Noexec Mount: If your /tmp partition is mounted with the noexec flag (a common security hardening practice), the Converter will fail to run its discovery scripts. Fix: Temporarily remount it: mount -o remount,exec /tmp. Disk Space: Ensure /tmp and /var aren't at 100% capacity. 5. Check the "Converter-Worker" Logs If the UI doesn't give you enough detail, the logs will.
On the machine where VMware Converter is installed, go to:C:\ProgramData\VMware\VMware vCenter Converter Standalone\logs Open the vmware-converter-worker-#.log.
Search for "error" or "failed." Often, you’ll see the exact Linux command that failed (e.g., failed to execute 'uname -m'). This tells you exactly what the source machine is rejecting. 6. SSL/TLS Compatibility
If you are using an older version of VMware Converter (like 6.2) to query a very new Linux distro (like Ubuntu 22.04 or RHEL 9), the handshake might fail due to deprecated SSL protocols or ciphers.
Update: Always use the latest version (VMware vCenter Converter Standalone 6.4 or 6.6+), which restored support for modern Linux distributions and updated encryption standards. Summary Checklist Can you SSH into the source using the same credentials? Is PermitRootLogin set to yes? Is the /tmp directory writable and executable? Are rsync and tar installed? Are you using the IP address instead of the hostname?
By methodically checking these points, you can move past the "Unable to query" stage and begin the actual conversion process.
Before diving into complex logs, ensure you have these basics covered. Do not skip these.
Posts
Comments
