Configuring vSwitch or vNetwork Distributed Switch from the command line in ESX/ESXi 4.x

To restore the Service Console connection to the proper VMNIC connecting to the correct network subnet:

Note: In ESX 4.0 Update 2, a new command-line tool, console-setup, was included to simplify the process of creating or restoring networking in the ESX service console. For more information, see Configuring or restoring networking from the ESX service console using console-setup (1022078).

• Apply these commands to regular vSwitches:
  
  esxcfg-vswitch -U #unlink an uplink
  esxcfg-vswitch -L # add an uplink
  
  Note: Unlink and relinking from or to a distributed switch depending on the scenario.
  
  
• Apply these commands to vNetwork Distributed Switches:
  
  esxcfg-vswitch -Q -V #unlink a DVS uplink
  esxcfg-vswitch -P -V #add a DVS uplink
  
  
• To create the vswif and uplink it to the DVS port:
  
  esxcfg-vswif -a -i -n -V -P vswif0
  
  For example:
  
  esxcfg-vswif -a -i 192.168.76.1 -n 255.255.255.0 -V dvSwitch -P 8 vswif0

For ESXi 4.x commands, see the vSphere Command-Line Interface Installation and Scripting Guide.

Note: The command-line tool provides limited functionality when running the esxcfg-vswitch command with vNetwork Distributed Switch. For example, you cannot create a dvportgroup or assign VLAN IDs to dvportgroups using this command.

Lost access to VM Network and Service Console when Playing with dvSwitch?

I tried adding the physical host to the dvSwitch and it blew up and I lost access to my vCenter VM (VM being the key issue here) because the box only has a single NIC (I also probably ignored a couple of warning dialog boxes as I was distracted doing something else (! pay attention to these things !)

The vCenter node was communicating over the VM Network to my client. which now couldn’t connect into the dvSwitch as I had moved the uplink to the dvSwitch there were no physical NICs to connect with so I was kind of stuck. Connecting directly to the physical ESX host using the VI client worked so I had service console access but it wouldn’t let me remove the pNIC from the dvSwitch and add it back to the traditional vSwitch as I only had a single pNIC. So in the end I had to break out the command line to get access back.

Unlink the pNIC from the dvSwitch: (your vmnic/PortID and dvSwitch names may be different)

esxcfg-vswitch –Q vmnic0 –V 265 dvSwitch

(note there is no -Q=vmnic as the help file would suggest on 1st glance, use a space and not an ‘=’ my esxcfg-* command line-fu was a bit rusty so that caught me out for a while )

Re-link it to a normal vSwitch

esxcfg-vswitch –L vmnic0 vSwitch0

within about 30 seconda all the VM networking came back so I could connect to the vCenter box again.

I then removed the dvSwitch entirely from the host; to do this I had to connect directly to the ESX host using the VI client as there are no options to do it via the UI when connected to vCenter.

vNetwork Distributed PortGroup (dvPortGroup) configuration

dvPortGroup represents a group of dvPorts that share the same configuration template. The configuration is inherited from dvSwitch to dvPortgroup.

Before configuring a dvPortGroup, make sure dvSwitch is present. For more information, see Configuring vNetwork Distributed Virtual Switch using vCenter (1010557).

To modify and add dvPortGroups:

1. In vCenter, go to Home > Inventory > Networking.
2. Right-click on dvPortGroup and click Edit Settings.
3. Under dvPortGroup Settings, specify:
   
   • General
   • Policies
   • Security
   • Traffic Shaping
   • VLAN
   • Teaming and Failover
   • Miscellaneous
   • Advanced
     
4. Define the following under the General Settings:
   
   
   • The name of the portgroup
   • A description
   • The number of ports available
   • The type of Port Binding:
     
     
     • Static Static Binding (Default): means that the dvPort is assigned to the virtual machine at configuration time. When all the ports are booked by virtual machines, it is not possible to connect to any more virtual machines, regardless of whether the connected virtual machines are powered up or not, and an error message is displayed.
     • Dynamic Dynamic Binding: means that the dvPort is assigned at the moment of powering the virtual machine up. This option allows for over committing the number of dvPorts.
     • None (Ephemeral ports): (Ephemeral Ports or No Binding) this behavior resembles the behavior in the standard vSwitch. If you select this option, the number of ports are automatically set to 0, and the Portgroup allocates one port for each connected virtual machine, up to the maximum number of ports available in the Switch.
       
       
5. Setting Security:
   • Promiscuous mode: Allows machines to see the traffic of all the other machines in the vDS.
   • Mac address changes: Allows virtual machines to receive frames with a Mac Address that is different from the one configured in the VMX.
   • Forged Transmits: Allows virtual machines to send frames with a Mac Address that is different from the one specified in the VMX.
     
     
6. Traffic Shaping policies:
   
   Notes: Allows you to define ingress and egress traffic shaping.
   
   Ingress shaping is a new feature, and available only with dvSwitch (not on vSwitch).
   
   Traffic Shaping concepts:
   • Average Bandwidth: Target traffic rate cap that the switch tries to enforce. Every time a client uses less than the defined Average Bandwidth, credit builds up.
   • Peak Bandwidth: Extra bandwidth available, above the Average Bandwidth, for a short burst. The availability of the burst depends on credit accumulated so far.
   • Burst Size: Amount of traffic that can be transmitted or received at Peak speed (Combining Peak Bandwidth and Burst Size you can calculate the maximum allowed time for the burst.
     
     
7. VLAN EST Policies:
   
   Note: Allows you to specify the VLAN behavior of only the dvSwitch.
   
   
   • EST – External Switch Tagging
   • NONE: Physical equivalent to: No VLAN Tagging
   • Standard vSwitch equivalent to: VLAN ID option set to 0
     
     
8. VLAN VST Policies:
   • VST – Virtual Switch Tagging
   • VLAN: Physical equivalent to: VLAN in Access/Untagged mode
   • Standard vSwitch equivalent to: VLAN ID option
   • VLAN ID 4095 is not allowed here
     
     
9. VGT Policies:
   • VGT – VLAN Guest Tagging
   • VLAN Trunking: Physical equivalent to: VLAN in Trunk/Tagged mode
   • Standard vSwitch equivalent to: VLAN ID set to 4095
   • vDS Only: option to specify the range of VLANs to trunk, to improve security
     
     
10. PVLAN Policies:
    • PVLAN Physical equivalent to: PVLAN
    • Standard vSwitch equivalent to: Does not exist
    • PVLAN option to specify which Primary and Secondary VLAN to use (Selecting from the list defined in the Switch)
      
      
11. Teaming and Failover Policies:
    • Load Balancing
    • Failover detection
    • Notify Switches
    • Failback
    • Failover order
    • Specific Uplink usage
      
      
12. Miscellaneous Policies:
    • Allows you to block all the dvPorts of the dvPortgroup.
      
      
13. The dvPortgroup Advanced subcategory is different from dvSwitch:
    • It allows each single dvPort to override the settings of the dvPortgroup.
    • Clicking Edit Override Setting the VI Admin can also specify which properties to allow/not allow to be overridden at lower levels.

Enabling SSH on ESXi 3.5 or 4 (VSphere)

I ran into this issue last night as I was trying to transfer over files with WinSCP. First off, if you are familiar with ESXi, you know there is no service console by default and you are given the bare bones version of ESX unless you purchase the upgrade for ESXi. If you are using this for home use then ESXi (free) is more than enough. Personally I run ESXi 3.5 Update 4 (free) and for firewall issues I just have a VM running pfSense with no problems. If you ever want to transfer over files or VMDKs to a VMFS lun/disk you need to enable SSH to use WinSCP.

Here is how its done:
1. At the start up screen (Management Console) press ALT+F1 and a console screen will come up
2. Type unsupported (you will not see the text) and press Enter
3. You'll see "Technical Support Mode" and a prompt for a password; simply type in your root password
4. If everything is successful you will be given a shell "#"
5. Type in vi /etc/inetd.conf
6. The config file will come up on the screen and now just scroll down until you see "#SSH"
7. Press the "Insert" button on your keyboard and remove the # (This will uncomment the function)
8. Now press "ESC" button and type :wq (this will write and quit your editing session)
9. Now type in ps -a | grep inetd (this will find the process for inetd)
10. You should see the PID for "busybox"/"inetd" (the number will be different for everyone)
11. Type kill (and the PID number from the last step) and this will stop the inetd process
12. Type cd /etc
13. Type ./services.sh restart (this will restart the management services)
14. Now perform a clean reboot of your ESXi machine by typing ALT+F2 to get back to the management screen
15. Press F12 to shutdown/restart and restart (wait for you machine to come back up)
16. Now you should be able to log in with SSH (putty) and SCP (WinSCP)

Vmotion is Disabled after upgrade

Here is a quick fix for those experiencing a problem using VMotion after upgrading from ESX Server 2.5 to ESX Server 3.5

In some cases after this upgrade is done VMotion is disabled and warm migrations are not possible. The solution is to re-enable VMotion on the host.

Re-enable VMotion on the host:

1. Select the host in VI Client and navigate to the Networking section of its Configuration tab.
2. Click the Properties link for the switch associated with the VMkernel port.
3. In the switch Properties dialog box, select the appropriate network label and click Edit.
4. Select the VMotion Enabled checkbox and click OK.

Search for VM Snapshots from the Service Console

It may not be the fanciest of methods, but probably the quickest way to find VM snapshots is to use the ls command from the ESX Service Console. By piping the output with grep to find files with the snapshot extension, .vmsn, and using the recursive switch you can scan all the VMFS LUNs visible to an ESX host. That’s so simple it hurts!

To use the ls command to find snapshots do the following:

1. Log in to the service console (use putty or mRemote for remote log in)
2. Query for the snap shot files in the VMFS volumes

#ls -Ral /vmfs/volumes/* |grep .vmsn

Create USB Drive to Install VMware ESX Server

Steps to be followed : (NOTE : I is my USB drive)

1. Plug in your USB flash disk and format it in dos using the following command: FORMAT I: /FS:FAT
   
2. From Windows Explorer, find the boot.iso file in the /images directory on the ESX 3.x CD-ROM. Copy boot.iso into a temporary directory on your hard drive.
   
   
3. Using your ISO extraction or mount program, extract the contents of the boot.iso file to your USB flash drive.
   
4. Delete the isolinux.bin and updatecd.cfg files from the USB disk.
   
5. Rename the isolinux.cfg file on the USB flash disk to syslinux.cfg
   
6. Using WordPad (not Notepad), open the syslinux.cfg file and add the keyword usb to the end of every line that begins with append. Here's what the file should look like when you're done:
   
   • default esx
     
   • prompt 1
     
   • timeout 600
     
   • display boot.msg
     
   • F1 boot.msg
     
   • F7 snake.msg
     
   • label debug
     
     • kernel vmlinuz
       
     • append initrd=initrd.img noapic nomediacheck debug usb
   • label esx
     
     • kernel vmlinuz
       
     • append initrd=initrd.img usb
   • label text
     
     • kernel vmlinuz
       
     • append initrd=initrd.img text usb
   • label expert
     
     • kernel vmlinuz
       
     • append expert initrd=initrd.img usb
   • label ks
     
     • kernel vmlinuz
       
     • append ks initrd=initrd.img usb
   • label lowres
     
     • kernel vmlinuz
       
     • append initrd=initrd.img lowres usb
7. Extract the syslinux.zip file into another temporary directory on your hard drive.
   
8. Open up a command prompt and navigate into the win32 directory. For example: C:\temp\syslinux-3.36\win32
   
9. Now, run the syslinux program to apply the boot loader and boot sector to the USB flash drive: syslinux -s –ma I:
   
10. Copy the ESX 3.x ISO image onto the USB drive root
11. Confirm that your USB flash drive contains the following files:
    
    • boot.cat
      
    • boot.msg
      
    • initrd.img
      
    • snake.msg
      
    • splash.lss
      
    • vmlinuz
      
    • syslinux.cfg
      
    • esx-X.iso
    
    
12. Your ready to go, ensure your bios on the server you want to install too is setup to boot from USB or select USB from the alternate boot menu.
    
13. The ESX installer will detect the USB device and whatever SCSI / disk controllers you have. When the installer asks you what the installation source will be, choose Hard Disk.
    
    
14. You will need to choose the right disk device (ie. /dev/sda, /dev/sdb) that corresponds to your USB disk. Chances are it will be /dev/sdb.
    
    
15. Finally, the installer will ask you what directory to find the ESX installation CD image in. Just use / and it will find the .ISO image for you.

VMware ESX storage: How to get local storage to act as a raw disk for VMs

VMTN Communities forum users have recently been asking how to make use of a LUN or partition on your local host within a virtual machine (VM) the same way you would if you had a SAN available. This is a more difficult task than some, and not every RAID controller allows this when using the VMware Infrastructure Client. We have to resort to command-line methods to make this happen.

A VM with a raw disk or raw disk map (RDM) allows the guest OS to write directly to the LUN or disk partition within a LUN assigned to it, utilizing a pass-through mechanism. Using a raw disk or RDP won’t result in a noticeable performance gain, but there is often an improvement in management. In general, when a VMDK grows past a certain size set by the administrator, the administrator will opt to use a raw disk or RDM.

With VMware ESX v2.5 and ESX v3.0 it took a few simple VM configuration file edits to enable a raw disk when using local storage. Unfortunately, those methods no longer work on VMware ESX v3.5. There is, however, a solution. It is not very elegant, but it will work.

The solution is to use vmkfstools to import or copy a virtual machine disk file to the LUN or partition to use for the raw device. Here is an example that I just tested and seems to work. First, I needed to find out which device held the LUN I was going to assign to my VM.

1. Run fdisk -l to find the LUN.

# fdisk -l

Disk /dev/cciss/c0d0: 146.8 GB, 146807930880 bytes 255 heads, 63 sectors/track, 17848 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot    Start       End    Blocks   Id  System /dev/cciss/c0d0p1   *         1        13    104391   83  Linux /dev/cciss/c0d0p2            14       650   5116702+  83  Linux /dev/cciss/c0d0p3           651      1287   5116702+  83  Linux /dev/cciss/c0d0p4          1288     17848 133026232+   f  Win95 Ext'd (LBA) /dev/cciss/c0d0p5          1288      1924   5116671   83  Linux /dev/cciss/c0d0p6          1925      2561   5116671   83  Linux /dev/cciss/c0d0p7          2562      3198   5116671   83  Linux /dev/cciss/c0d0p8          3199      3453   2048256   82  Linux swap /dev/cciss/c0d0p9          3454     17835 115523383+  fb  Unknown /dev/cciss/c0d0p10        17836     17848    104391   fc  Unknown

Disk /dev/cciss/c0d1: 440.4 GB, 440430842880 bytes 255 heads, 63 sectors/track, 53546 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/cciss/c0d1 doesn't contain a valid partition table

2. Run esxcfg-vmhbadevs to find the vmhba device associated with the LUN.

# esxcfg-vmhbadevs vmhba0:0:0     /dev/cciss/c0d0 vmhba0:1:0     /dev/cciss/c0d1

3. Create the VM with a standard virtual disk (VMDK).

4. Use vmkfstools from the command-line interface to import the VMDK into the vmhba device associated with the LUN using a disk target of RAW. Kill the import after you hit 1%.

# vmkfstools -i OpenFiler.vmdk -d raw:/vmfs/devices/disks/vmhba0:1:0:0 OpenFiler_1.vmdk Destination disk format: raw disk out of '/vmfs/devices/disks/vmhba0:1:0:0' Cloning disk 'OpenFiler.vmdk'... Clone: 1% done.

5. Review the resultant VMDK metadata file. Note that the size of the LUN is references. For size take 860216490 and multiply by 512 for 410 GBs.

# cat OpenFiler_1.vmdk # Disk DescriptorFile version=1 CID=c0699ec2 parentCID=ffffffff createType="vmfsRaw"

# Extent description RW 860216490 VMFSRAW "/vmfs/devices/disks/vmhba0:1:0:0"

# The Disk Data Base #DDB

ddb.virtualHWVersion = "4" ddb.uuid = "60 00 C2 97 5c a6 e9 59-f3 de ba f6 83 ed 15 73" ddb.geometry.cylinders = "1044" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.adapterType = "lsilogic"

5. Using the VMware Infrastructure Client (VIC), add an existing disk into the VM or add the following lines to the VMX file. (Note that you want to use a virtual SCSI controller not already in use. Also, the VM you make these changes to should be powered off and perhaps even unregistered if you are doing this from the CLI. If you use the VIC add the device following the red arrow path in the diagram below.)

scsi1.present = "true" scsi1.sharedBus = "none" scsi1.virtualDev = "lsilogic" scsi1:0.present = "true" scsi1:0.fileName = "OpenFiler_1.vmdk" scsi1:0.deviceType = "scsi-hardDisk"

Now you have a VM that can directly access the local LUN on your VMware ESX host. I imagine this will work the same way for ESXi.

Create a NFS share for VM ISO files with Windows 2003 Server R2

If your ESX servers are not connected to network storage or if you do not have enough available space on your SAN to dedicate a sub folder of a VMFS volume for ISO files, then you can use a NFS network share to centrally store these images. Creating the NFS share can be done with many server operating systems, but did you know that Windows Server 2003 R2 has native NFS?

VMware-land.com has many “how to” VMware Tips for ESX, and the following is the instructions found there for creating a Windows 2003 R2 NFS share:

1. On the Windows 2003 Server make sure “Microsoft Services for NFS” in installed. If not you need to add it under Add/Remove Programs, Windows
   Components, Other Network File and Print Services
2. Next go to folder you want to share and right-click on it and select Properties
3. Click on the NFS Sharing tab and select “Share this Folder”
4. Enter a Share Name, check “Anonymous Access” and make sure the UID and GID are both -2
5. In VirtualCenter, select your ESX server and click the “Configuration” tab and then select “Storage”
6. Click on “Add Storage” and select “Network File System” as the storage type
7. Enter the Windows Server name, the folder (share) name and a descriptive Datastore Name
8. Once it finishes the configuration you can now map your VM’s CD-ROM devices to this new VMFS volume

Repeat steps 5 through 8 for each of your ESX servers to make the same ISO files available to all ESX hosts.

These instructions assume that you have already configured the VMkernel port group on a vSwitch for each ESX host. For instructions and information about configuring the VMKernel for NAS/NFS storage check the Storage Chapter of the ESX Server 3 Configuration Guide.

Of course, you can use the NFS share for more than just ISO file storage too. This is a good repository for patches and scripts that need to be used on all hosts. NFS also makes a good target for VM image backups too. Use some imagination and install the free VMware server on your 2003 R2 box and you have a low budget DR platform. Oh yeah, I shouldn’t forget to mention you can even run ESX VMs from NFS!

Script for VMware HA Feature without VirtualCenter

So, who wants free VMware High Availability? That’s the title of a post created by Leo Raikhman on his Leo’s Ramblings blog. In this post, Leo has published the steps and scripting necessary to simulate VMware’s VI3 High Availability (HA) feature. Leo’s script works without VirtualCenter (VC), so VMware customer’s who have not implemented VC can manually create “HA -like” awareness between 2 ESX hosts. If one of the ESX servers goes offline then the virtual machines (VMs) are auto restarted on the other host. Of course, the VMs must be created on shared storage for this to work.

Before considering this script as a replacement understand the major differences between VirtualCenter HA and Leo’s HA:

• Leo’s script only works between 2 ESX hosts while VC HA can be configured with up to 32 ESX hosts as of VI 3.5 (actually using 32 host HA clusters is another topic, but it can be done)
• Leo’s script needs the ESX Service Console as written. It would need to be ported for the RCLI to work with ESXi. VC HA works with both ESX and ESXi
• VC provides a visual status for the health of your HA cluster via the VI Client
• VC HA provides HA fail over capacity for more than 1 ESX host at a time

I’ve held this post in my drafts because I wanted to try this configuration myself, but alas, I have never gotten around to it. For those that can benefit from VC -less HA and give this script a test, let me (and Leo) know your results.

Leo’s post says:

“First of all lets talk about the basics of what HA actually does: if your ESX server doesn’t respond to a heartbeat for 14 seconds, the other host registers all machines and starts them up. “

Here’s the process from Leo’s Ramblings with the scripts, commands and instructions:

Create a list of the VMs on each host and copy to the other host

But there’s a few other tricks. How do you generate that other_host file? Here’s how. On each host run the following command:

vmware-cmd -l | sed ’s/\ /\\ /g’ > /root/other_host

What you’ve done is just dumped all registered machines on each host to the /root directory.

Now, scp each /root/other_host file to the other ESX server’s /etc directory.

In each /etc/other_host file, re-organize the VM order if you want them to start up differently and delete VMs that you don’t want to start up.

Create the HA script and make it executable

#!/bin/bash
if ! ping -c 14 10.8.0.1 > /dev/null; then
for $i in `cat /etc/other_host` ; do vmware-cmd -s register $i && vmware-cmd $i start ; done
fi
sleep 16
if ! ping -c 14 10.8.0.1 > /dev/null; then
for $i in `cat /etc/other_host` ; do vmware-cmd -s register $i && vmware-cmd $i start ; done
fi

Then I made it executable:

chmod a+x /usr/bin/esx_ha.sh

Here’s what the script does:

If for 14 pings, an ESX server with Service Console IP 10.8.0.1 does not reply, then, browse the contents of the file /etc/other_host, register every listed machine there on the current host (10.8.0.2) an start them up, one by one. Then it sleeps for 16 seconds, and executes the same thing again.

Seems easy enough.

Create a cron entry to start auto HA

Now we need to create a cron entry as root by running crontab -e as the root user. The screen that opens works like vi, input the following text:

MAILTO=”youremail@yourcomapny.com”
* * * * * /usr/bin/esx_ha.sh

This means, that on the minute, every minute of the day, the script (which runs twice a minute) will execute and provide HA for you.

Regenerate SSL Certificate for ESX 3.5/4.0

Ever had to rename a ESX 3.5 host? You've done all the proper procedures of renaming network, hosts files, and changing your rc.conf file but now your storage doesn't recognize your new host. You've checked everything and then we you go to sign in you find out that your ssl certificate still has the old name and won't connect with the SAN array. I've recently run into that problem and here is how I fixed it.

1. Backup your ssl file to be safe.

- cp -r /etc/vmware/ssl /etc/vmware/ssl.bckp

2. After checking that the backup was indeed created, delete the rui.* files

- cd /etc/vmware/ssl

- rm rui.crt

- rm rui.key

3. Now restart hostd and ESX will regenerate the SSL cert and key using your new name.

- service mgmt-vmware restart

4. Easiest way to test if it worked is to use IE and go to https://"yourhost" and view the certificate. You should now see the new name in your issued to and issued by section of the cert.

Thats it. Any comments or question please post. Thanks.

Failed to install the VirtualCenter Agent Service

A number of customers have been reporting the message: “Failed to install the VirtualCenter Agent Service“, when trying to connect an ESX host to virtual center, often after upgrading to ESX 3.0.2 and VC 2.0.2. In all the cases I have come across these reason seems to be that /tmp/vmware-root does not exist. This directory has to exist for the agent install process. To remedy this you can-

1. Login to ESX Server via ssh client as root user
2. cd /tmp
3. mkdir vmware-root
4. Try re-connecting the host to Virtual Center

Apparently there is a cron job that is removing this directory whenever it runs.Here is another method:

1. Disable HA. Otherwise, the virtual machines might be forcibly powered down by step 2.
2. At the service console, issue
   service mgmt-vmware restart
3. At the service console, issue
   service vmware-vpxa restart
4. Reconnect the virtual machines to VirtualCenter.
5. Attempt to re-enable HA within VirtualCenter. If this doesn’t work, this means that vpxa did not install properly.
6. At the service console, issue
   rpm -qa | grep vpxa
7. At the service console, issue “rpm -e” on the rpm file that displayed in the previous command.
   rpm -e
8. Reconnect the virtual machines in the usual manner within VirtualCenter.
9. Re-enable HA.