VM Manager Alert: Addressing Unsupported Virtual Machine Configurations

Table of Contents

Virtual machine environments, particularly those managed by VMware vSphere, occasionally flag configurations as ‘unsupported’. A common scenario leading to such alerts involves guest operating systems configured to boot from virtual disks attached via an IDE controller. While IDE controllers were standard for legacy systems, modern operating systems and VMware best practices strongly recommend using SCSI controllers for primary boot disks due to performance improvements, broader device support, and advanced features like hot-add capabilities. This guide provides a detailed procedure to address an unsupported configuration stemming from an IDE boot disk by migrating it to a supported SCSI controller type.

Unsupported configurations can arise from various factors, often originating from virtual machines created with older hardware compatibility versions or converted from physical machines using certain tools. The VM Manager flags these issues to alert administrators to potential problems, including performance bottlenecks, compatibility issues with future VMware updates, or lack of support from VMware Global Support Services should a problem occur with that specific configuration. Resolving these alerts ensures the stability, performance, and long-term compatibility of your virtual infrastructure.

Before attempting any changes to a virtual machine’s configuration, especially direct edits to configuration files, it is paramount to ensure you have adequate safeguards in place. Creating a snapshot of the virtual machine is the first and most crucial step. This allows you to revert the VM to its previous state if any issues arise during the modification process, preventing data loss or irreversible damage. Additionally, ensuring you have a recent backup of the virtual machine further enhances your ability to recover from unexpected problems.

This procedure requires direct access to the underlying ESXi host’s file system, typically via SSH or the ESXi Shell. Ensure that SSH service is enabled on the host hosting the virtual machine in question and that you have the necessary credentials and permissions to log in and navigate the file system. Familiarity with basic command-line text editors like vi or nano is also necessary for modifying configuration files. Always exercise caution when making direct edits to system files on the ESXi host.

Locating the Virtual Machine Files¶

The first step in modifying the virtual disk configuration is to locate the specific files associated with the virtual machine on the datastore. Virtual machines are stored within dedicated folders on the datastore, containing all relevant configuration files, virtual disks, snapshots, and log files. The datastore path is essential for accessing and editing the virtual disk descriptor file.

You can typically find the datastore path using the VMware vSphere Client or vSphere Web Client. Navigate to the virtual machine, right-click it, and look for an option like “Browse Datastore” or examine the VM’s properties which often display the datastore location. The path will follow a standard format, indicating the datastore volume and the VM’s folder name. For example, /vmfs/volumes/<datastore_name>/<vm_name>/. Note down this exact path, as you will need it to navigate the file system on the ESXi host.

Accessing the ESXi Shell via SSH is required for the subsequent steps. Use an SSH client like PuTTY (on Windows) or the built-in ssh command (on Linux/macOS) to connect to the IP address or hostname of the ESXi host where the VM resides. Once connected, you will navigate the directory structure to reach the virtual machine’s folder on the datastore using the path you identified in the previous step. The command cd /vmfs/volumes/<datastore_name>/<vm_name>/ will take you to the correct directory.

Identifying and Modifying the Virtual Disk Adapter Type¶

Within the virtual machine’s folder, you will find several files. The main virtual disk consists of two files: a small descriptor file (e.g., myvm.vmdk) and a large data file (e.g., myvm-flat.vmdk). The descriptor file contains configuration parameters for the virtual disk, including its size, geometry, and importantly, the virtual controller it is attached to. This is the file we need to edit.

Open the descriptor .vmdk file using a text editor available in the ESXi Shell, such as vi or nano. For example, vi myvm.vmdk. Once the file is open, you need to locate the line that specifies the adapter type. In the case of an unsupported IDE configuration, this line will typically appear as ddb.adapterType = "ide". This line indicates that the virtual disk is currently configured to use an IDE controller, which is causing the unsupported status.

The goal is to change this line to specify a supported SCSI controller type. The choice between controller types like LSI Logic Parallel, LSI Logic SAS, Bus Logic Parallel, or VMware Paravirtual SCSI (PVSCSI) depends on the guest operating system and the desired performance characteristics. LSI Logic SAS and PVSCSI are generally recommended for newer operating systems due to better performance, but compatibility should always be verified against VMware’s compatibility guide for the specific guest OS version.

• For LSI Logic controllers (a common choice for many modern Windows and Linux distributions), change the line to: ddb.adapterType = "lsilogic".
• For Bus Logic controllers (often used for older operating systems like Windows NT or NetWare), change the line to: ddb.adapterType = "buslogic".

After making the necessary change to the ddb.adapterType line, save the .vmdk descriptor file. In vi, you would press Esc, type :wq, and press Enter. If using nano, press Ctrl+X, then Y to confirm saving, and Enter to confirm the filename. Ensure you have edited the correct file and saved it correctly before proceeding. An incorrect edit can prevent the VM from booting.

Reconfiguring the Virtual Machine in vSphere¶

Modifying the .vmdk descriptor file updates the configuration at the disk level, but the virtual machine’s .vmx configuration file, which is read by the hypervisor, still reflects the old IDE configuration. To synchronize the VM’s configuration with the changes made to the disk file, you must remove and then re-add the virtual disk through the vSphere client interface.

Access the virtual machine’s settings by selecting the VM in the VMware vSphere Client or vSphere Web Client and choosing the “Edit Settings” option. In the list of hardware devices, locate the virtual disk that is currently configured as an IDE disk. It will likely be listed as “Hard disk [IDE 0:0]” or similar, connected to an IDE controller.

Select the IDE virtual disk you intend to migrate. Once selected, locate the option to remove the disk. This option is usually represented by a red “X” or a “Remove” button. Crucially, ensure you select the option to remove the disk from the virtual machine configuration only, and DO NOT select any option that suggests deleting the files from disk. Removing the disk from the VM’s settings removes the entry from the .vmx file but leaves the .vmdk and -flat.vmdk files intact on the datastore, which is exactly what we want as we have already modified the .vmdk file. Confirm the removal by clicking “OK” or “Save”.

After removing the disk, the virtual machine’s configuration is updated to no longer include the IDE disk. Now, you need to add the same virtual disk back to the VM, but this time configuring it to use the desired SCSI controller type. In the virtual machine’s “Edit Settings” dialog, click the “Add New Device” or “Add” button. From the list of device types, select “Hard Disk” and then choose the option “Use an existing virtual disk”.

A dialog will appear, prompting you to browse for the existing virtual disk file. Navigate through the datastore browser to the virtual machine’s folder where the .vmdk and -flat.vmdk files are located. Select the descriptor .vmdk file (e.g., myvm.vmdk). By selecting the descriptor file, vSphere reads the updated ddb.adapterType parameter you modified earlier and will propose the corresponding controller type.

Ensure that the virtual device node for the re-added disk is set to the desired SCSI controller type (e.g., SCSI Controller 0) and the appropriate SCSI ID, typically SCSI 0:0 for the boot disk. Confirm that the controller type displayed in the vSphere client matches the ddb.adapterType you configured in the .vmdk file (e.g., LSI Logic Parallel, Bus Logic Parallel, etc.). This step links the virtual machine’s configuration (.vmx) to the modified virtual disk file (.vmdk) using the correct controller type.

Addressing Potential CD-ROM Controller Conflicts¶

Virtual machines often have a CD-ROM device configured, and these devices are typically attached to an IDE controller. When you remove the primary boot disk from the IDE controller (IDE 0:0), the CD-ROM might still be configured on IDE 0:1. After adding the boot disk back on a SCSI controller, having a CD-ROM on the first IDE channel (IDE 0:0) can sometimes cause boot order issues or conflicts, especially if the guest OS expects the boot device to be on the primary controller.

If the virtual machine has a CD-ROM device and it is configured on IDE 0:1, it’s good practice to move it to IDE 0:0 or remove and re-add it to ensure it’s on a non-conflicting channel after the boot disk has been moved to SCSI. In the VM’s “Edit Settings,” select the CD/DVD Drive. Examine its configuration to see which IDE channel it is using.

If the channel is IDE 0:1, you might be able to change it directly to IDE 0:0 from the dropdown options under the device settings. However, this option is sometimes greyed out or unavailable depending on the VMware version and the VM’s configuration state. If you cannot change the channel directly, the simplest solution is to remove the CD-ROM device from the virtual machine’s configuration entirely.

After removing the CD-ROM, save the settings. Then, go back into “Edit Settings,” click “Add New Device,” select “CD/DVD Drive,” and add it back. When adding a new CD-ROM device, vSphere typically assigns it to the first available IDE channel, which should now be IDE 0:0 if no other device is using it. This ensures the CD-ROM is on the primary IDE channel, leaving the SCSI controllers free for hard disks.

Finalizing and Verifying the Configuration¶

Once all the necessary configuration changes have been made – the .vmdk file edited, the original IDE disk removed, the disk re-added as a SCSI disk, and the CD-ROM controller adjusted if necessary – save the virtual machine settings in the vSphere Client. The virtual machine’s hardware configuration is now updated.

Before powering on the virtual machine, it is highly recommended to review the VM’s settings one final time to confirm that the hard disk is indeed attached to the correct SCSI controller type and ID (e.g., SCSI 0:0) and that the CD-ROM is on IDE 0:0 or removed if preferred. Power on the virtual machine. The guest operating system should now boot using the newly configured SCSI controller.

It is possible that the guest operating system may require drivers for the new SCSI controller type upon first boot, especially if it was previously exclusively using an IDE driver. For Windows operating systems, this often involves installing the appropriate VMware Tools version, which includes the necessary storage controller drivers. If the OS fails to boot, you might need to attach an ISO image of the operating system installation media or the VMware Tools ISO to the VM’s CD-ROM drive, boot into recovery mode, and load the drivers manually.

For Linux distributions, support for common SCSI controllers like LSI Logic is often built into the kernel. However, for PVSCSI, VMware Tools or open-vm-tools are usually required to load the driver. If the Linux VM fails to boot, you may need to boot from a rescue environment or live CD to install the necessary kernel modules or update the initramfs.

After the virtual machine boots successfully, log in to the guest operating system and verify that the disk is recognized and accessible. Check the device manager (on Windows) or run commands like lsscsi or fdisk -l (on Linux) to confirm that the disk is now seen as a SCSI device. Finally, check the VM Manager or vSphere Client for any remaining alerts related to unsupported configurations. The original alert about the IDE boot disk should now be cleared.

Summary of Controller Types¶

Understanding the different virtual SCSI controller options in VMware can help in choosing the most appropriate one for your guest operating system.

Controller Type	Description	Typical Use Cases	Notes
IDE	Legacy controller, only supported for compatibility with older OS versions.	Limited, often flagged as unsupported for boot disks.	Poorest performance, limited device support. Avoid for new VMs.
Bus Logic Parallel	Older SCSI controller, good compatibility with older operating systems.	Windows NT 4.0, Windows 2000, NetWare.	Supported but generally superseded by LSI Logic.
LSI Logic Parallel	Common SCSI controller, widely supported by many operating systems.	Windows 2003/XP, many Linux distributions.	Good balance of compatibility and performance.
LSI Logic SAS	Newer LSI Logic controller, improved performance over Parallel.	Windows Server 2008/7 and later, recent Linux versions.	Recommended for modern OS where PVSCSI is not applicable.
VMware Paravirtual SCSI (PVSCSI)	High-performance SCSI controller designed for throughput.	I/O-intensive workloads, modern OS (W2k8+/RHEL5+/SLES10+).	Requires specific guest OS drivers (via VMware Tools) for optimal use.

Selecting the correct controller type is crucial for performance and stability. Consult the VMware Compatibility Guide for specific recommendations based on your guest operating system and VMware version.

Conclusion¶

Addressing unsupported virtual machine configurations, such as migrating an IDE boot disk to a SCSI controller, is a vital task for maintaining a healthy and performant virtual environment. While the process involves direct file editing and careful configuration in the vSphere client, following these steps diligently ensures a smooth transition. Always remember the importance of creating snapshots and backups before making significant changes.

By successfully resolving these configuration alerts, you enhance the stability, performance, and supportability of your virtual machines, paving the way for future updates and improvements to your VMware infrastructure.

Have you encountered similar unsupported configuration issues in your VMware environment? How did you resolve them? Share your experiences and tips in the comments below!