Mastering VMware Infrastructure 3 (VI3) intricacies can make a system administrator's management job easier. This...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
article outlines several quick fixes for nagging VI3 problems: errant snapshots that prevent a virtual machine (VM) from starting, virtual switches that don't have network interface cards (NICs) assigned, how to renumber NICs after assigning them and what to do if you've forgotten the root password to an ESX server.
Sometimes snapshots become separated from their parent disk files and VMs will no longer power up when this occurs. When this happens you will get an error message stating "Cannot open the disk vmname-000001.vmdk or one of the snapshot disks it depends on. Reason: the parent virtual disk has been modified since the child was created." This can occur when you cold migrate a VM with snapshots from one ESX server to another. While the snapshot files are also migrated with the VM, the CID numbers in the VMDK descriptor file can change. Fortunately there is an easy fix.
Every virtual disk has two VMDK files associated with it. The larger one will have –flat at the end of the name and is the actual raw data of the virtual disk. The smaller one is the descriptor file that contains some basic information about the configuration of the virtual disk. If you open the descriptor file for your original disk (which will usually named the same as your VM, i.e. myvm.vmdk) with a text editor such as Nano, you will see a CID and a parentCID listed. The parentCID of the first disk is always "ffffffff", notice in the example below that the snapshot parentCID does not match the CID of the original disk.
Original disk file:
Snapshot disk file:
To rejoin the child to the parent edit the descriptor VMDK file of the snapshot, take the CID of the original disk file and change the parentCID of the snapshot disk file so they are the same, as below.
Original disk file:
Snapshot disk file:
Then power on the VM. It should boot without any problems.
Virtual switches without NICs
Having virtual switches (vSwitches) that have no network interface cards (NICs) assigned to them is like having isolated, internal-only switches that are completely isolated from the network and any other vSwitches on an ESX host. These types of vSwitches are very useful for isolating virtual machines that you do not want communicating on your regular network. Some examples where you may use this are:
- Building a new VM and wanting to isolate it until you get it fully patched and its security tightened
- Penetration testing or running security scans on a VM
- Cloning an existing VM to troubleshoot it so the original server and clone can be running at the same time and be isolated from one another
- "P2Ving" a physical server so the physical server and VM can be running with the identical IP address at the same time until the VM is ready and the physical server can be shut down
- Building an isolated test environment that has no network connectivity to other servers
It's always a good idea to have one on every ESX server. They support port groups and VLAN tagging so you can set up an isolated environment with multiple servers. It's simple to switch a VM back and forth from one network to another by editing the VM's settings; there is no need to power off the VM to do this.
To create an internal vSwitch, first select your ESX host in the VMware Infrastructure Client (VI Client). On the Configuration tab, select Networking. Click the Add Networking link. Select Virtual Machine as the connection type. Select Create a vSwitch, and do not select any network adapters. Finally, you can optionally assign a VLAN ID. If you need additional VLANs, create more port groups.
When adding, changing or removing hardware such as NICs or fiber cards to your ESX host, you may come across a situation where ESX renumbers your NICs which can cause your networking to malfunction. This can also happen by simply replacing a defective card with the same model card. This happens on occasion when the BIOS in your server changes the physical topology of its hardware devices which can subsequently change the order in which devices are discovered. When this occurs ESX will see the NICs as new devices and assign them new NIC numbers (i.e. vmnic#).
An example of this is if you replace a two port NIC with a four port NIC. The original NIC numbering is typically vmnic0 and vmnic1. Once ESX is started after the NIC has been changed, ESX will see the new NIC and number them as vmnic2 through vmnic5. This happens because even though vmnic0 and vmnic1 are no longer physically present they still exist in the ESX configuration. Since your current virtual switch configuration relies on vmnic0 and vmnic1, your networking will no longer work when the ESX host starts up. You will also not be able to connect to the Service Console remotely via SSH or the VI Client.
There are two ways to recover from this when it happens, the first method is easier and saves you from changing your vSwitch configuration, but involves editing the esx.conf file so you need to be careful. In addition the first method preserves your NIC numbering if you do not want your NICs starting at vmnic2.
Method one – Editing the esx.conf file
- First, log in to the service console.
- Type esxcfg-nics –l to check your existing NIC numbering.
- Type cd /etc/vmware to change to the correct directory
- Type cp esx.conf esx.con.bak' to make a backup of this file as it is a critical configuration file for ESX.
- Type nano esx.conf to open the file for editing.
- Hold the CTRL key and type W, then enter vmnic2 to search for the first new NIC.
- Change vmnic2vmnic0.
- Change the subsequent NICs from vmnic3 to vmnic1, vmnic4 to vmnic2 and vmnic5 to vmnic3.
- Hold down the CTRL key and type O to save the file.
- Press CTRL – X to exit the Nano editor.
- Shut down and restart the ESX server.
When the server comes back up the NICs will be numbered vmnic0 – vmnic3. You cann verify this by typing esxcfg-nics –l.
Method two – Modify your virtual switch configuration
- Log in to the service console.
- Check your existing NIC numbering by typing esxcfg-nics –l.
- Check your current vSwitch configuration by typing esxcfg-vswitch –l , note which NICs are assigned to which vSwitches (uplink column).
- Remove the old NICs that have been renamed by typing esxcfg-vswitch –U <vmnic#> <vswitch name>', i.e. esxcfg-vswitch –U vmnic0 vSwitch1.
- Add the new NICs with the correct names by typing esxcfg-vswitch –L <vmnic#> <vswitch name>, i.e. esxcfg-vswitch –L vmnic2 vSwitch1.
- Repeat this process for any additional NICs. Once you have the vSwitch that contains the service console corrected you can also log in via the VI Client and correct the other vswitches that way.
Your newly renamed NICs should now be assigned to the original vswitches and your networking should now work again.
Forgotten root password
If you have forgotten the root password of an ESX server and have no other way to change it, there is a way to change it if you have physical access to the ESX server.
- First, shut down the ESX server and restart it. At the first menu type a.
- At the next prompt type single.
- ESX will now go through the boot process and you will end up at a "#" prompt .
- Type passwd, enter a new password for root and retype it when prompted.
- Type reboot and you're done.
ABOUT THE AUTHOR: Eric Siebert is a 25-year IT veteran with experience in programming, networking, telecom and systems administration. He is a guru-status moderator on the VMware community VMTN forums and maintains VMware-land.com, a VI3 information site.