Virtualization Adapted Adapting Business Processes for Virtual Infrastrcuture (and vice-versa)

2010/03/17

VMFS versions and upgrade paths

Filed under: virtualization — Tags: , , , , — iben @ 12:42

SUMMARY: For best performance be sure to upgrade your VMFS Block Storage when you upgrade your ESX hosts to vSphere.

VMFS 3 versions and upgrade paths

Purpose

It is not possible to upgrade an existing VMFS to a later version. However, all VMFS versions work with any version of ESX 3.0.0 and later. That is, ESX 3.0.0 can run a virtual machine from VMFS 3.33 and ESX 4 can run virtual machines from VMFS 3.21 volumes.

Resolution

VMFS3 which was released initially with ESX 3.0.0 as version 3.21 has since evolved with new minor versions:
  • ESX 3.0.0 is provided with 3.21 (initial release)
  • ESX 3.5.0 is provided with 3.31
  • vSphere (ESX 4.0) is provided with 3.33
If for some reason you must upgrade your VMFS minor version:
Warning: This removes the formatting of the LUN and all the data on the datastore. Relocate your virtual machines and files prior to removing the datastore.
  1. Migrate all the data off the VMFS datastore that you are upgrading.
  2. Delete the datastore from VI Client.
  3. On the VI Client connected to VirtualCenter, choose your ESX 3.5 or 4.0 host. Alternatively connect directly to the ESX host with the VI Client.
  4. Recreate the datastore from that ESX 3.5 or 4.0 host. Click Storage > Add Datastore.
  5. Migrate the data from step 1 to the newly formated datastore.

Additional Information

Features like VMFS grow in ESX 4 work regardless of the minor version.
Reference:
http://kb.vmware.com/kb/1005325
http://www.vfrank.org/2010/01/31/vmfs-3-versions-maybe-you-should-upgrade-your-vmfs/
http://virtualizationreview.com/blogs/everyday-virtualization/2009/06/vstorage-vmfs-version-notes.aspx
http://communities.vmware.com/message/1071323
http://www.onlinetechblog.com/blog/index.php/2009/11/vsphere-4-0-places-service-console-in-local-vmfs-volume/

2010/03/11

vSphere Network Connections and Ports

Filed under: virtualization — Tags: , , , , — iben @ 11:57
esx network ports

esx network ports

The amazing Dudley Smith, from VMware’s Technical Account Manager team has release a larger version of his vSphere Network Connections and Ports for ESX diagram and an accompanying excel spreadsheet listing all the TCP/IP ports for various communication purposes.

Get them directly from the VMware blog site here:

http://communities.vmware.com/blogs/dudleysmith

2010/03/10

HyTrust Appliance 2.0 Released

Filed under: virtualization — Tags: , , , , , — iben @ 09:32

HyTrust Appliance 2.0 is available. Building on the successes of 2009, which included our initial product launch and numerous awards, we’re happy to see the streak continue into 2010 by delivering a major new release that will empower enterprises to capitalize on the wave of datacenter virtualization and accelerate efforts to virtualize tier-one applications. The features available in HyTrust Appliance 2.0 deliver true enterprise-class policy management and access control capabilities to virtual infrastructure. New features include the following:

* Root Password Vault: Locks down privileged host accounts and provides passwords for temporary use to enable time-limited privileged account access. Root accounts on hypervisors are extremely powerful and, as a consequence, can create a significant liability if not kept out of the wrong hands. With the aid of Root Password Vault, all root account access is attributable to an individual and every action is logged, providing far greater visibility and accountability.
* Federated Deployment: Secure distributed system architecture allows for automated replication of policies and templates across multiple HyTrust Appliances as well as geographic boundaries. For larger enterprises with multiple datacenters and collocation facilities, Federated Deployment of HyTrust Appliances ensures consistency of controls across the entire infrastructure.
* Virtual Infrastructure Search: Enables quick and easy accessibility to all virtual infrastructure objects, policies, and logs within HyTrust Appliance.
* Remote API: Interface to remotely access and automate the administration of the HyTrust Appliance. Provides the greater scalability demanded by large, enterprise-wide deployments of virtualization.
* Object Policy Labels: Creates a policy categorization structure, similar to “Web 2.0 tagging” for virtual infrastructure objects, which enables better organization and tighter, more consistent controls. Object Policy Labels enable access, network segment, and zoning policies, which allows administrators to dictate which virtual machines are allowed to connect to which network segments or hosts via RuleSets and Constraints.
* Router-Mode: a deployment option where all VMware management traffic is forced to flow through the HyTrust Appliance. HyTrust Appliance acts as a router for the “protected” management subnet and ESX/ESXi hosts and vCenter Server use HyTrust Appliance as their default gateway. This adds yet another flexible deployment option to the other existing options, ensuring the HyTrust Appliance will easily adapt to any enterprise architecture.

Along with the new capabilities delivered in 2.0, we’d like to introduce you to the new editions of HyTrust Appliance:

* Community Edition is a free version of the product that supports up to three hosts.
* Standard Edition supports an unlimited number of hosts and offers more flexible deployment options.
* Enterprise Edition supports an unlimited number of hosts, offers more flexible deployment options, supports federation of multiple HyTrust Appliances, enables privileged account management via Root Password Vault, allows two-factor authentication, and offers a remote API for additional management flexibility.

You can download the Community Edition of HyTrust Appliance at http://www.hytrust.com/community.

2010/01/08

VMware Hardware MMU Info

Filed under: virtualization — Tags: , , — iben @ 15:45

VMware Hardware MMU Info

Interesting paper on the nehalem MMU stuff:
http://www.vmware.com/pdf/Perf_ESX_Intel-EPT-eval.pdf

By comparison here’s the tests on AMD hardware:
http://www.vmware.com/pdf/RVI_performance.pdf

Summary, some things AMD is a little faster on; Intel is consistently a little faster on a few more tasks though.

All in all though the difference appears minimal.

2009/10/22

VMware-ESX-versus-ESXi

Filed under: virtualization — Tags: , , , , , , , , — iben @ 12:06

From http://www.vmware.com/pdf/vsphere4/r40/vsp_40_esx_server_config.pdf <— look on page 98 or the VMware ESXi Configuration Guide

Network Attached Storage

ESX supports using NAS through the NFS protocol. The NFS protocol enables communication between an NFS client and an NFS server.

The NFS client built into ESX lets you access the NFS server and use NFS volumes for storage. ESX supports only NFS Version 3 over TCP.

You use the vSphere Client to configure NFS volumes as datastores. Configured NFS datastores appear in the vSphere Client, and you can use them to store virtual disk files in the same way that you use VMFS-based datastores.

*** NOTE: ESXi does not support the delegate user functionality that enables access to NFS volumes using non- root credentials.

Also see these links for more info on read only capabilities for different licenses.

http://partnerweb.vmware.com/comp_guide/docs/vSphere_Comp_Matrix.pdf

On the ViOPs site there is a comparison matrix of ESXi/ESX in case we’re asked ‘which one should I use?’.

VMware ESX and ESXi 4.0 Comparisonhttp://kb.vmware.com/kb/1015000

VMware ESX and ESXi 3.5 Comparison – http://kb.vmware.com/kb/1006543

RCLI is limited to read-only access for the free version of VMware ESXi. To enable full functionality of RCLI on a VMware ESXi host, the host must be licensed with VI Foundation, VI Standard, or VI Enterprise.

http://www.vmware.com/products/vsphere/buy/editions_comparison.html

Comparison of product offerings for vSphere 4.0 and VMware Infrastructure 3.X – http://kb.vmware.com/kb/1010579

2009/08/01

VMware ESX Patch Updates and Release Levels

Filed under: virtualization — Tags: , , , , , , , — iben @ 11:11

VMware makes periodic updates to the ESXi Installable version you can download. This page was created to help track and locate those.

VMware Infrastructure Client
VMware Infrastructure Client

Use these numbers to determine when a system was patched last and to make sure the VMware Infrastructure Client is the right one.

Best Practice:

ESXi: Run the VMware Infrastructure Update tool from a windows management station with the VMware Infrastructure Client every month.

ESX: Use vCenter Update Manager to scan and remediate ESX hosts when new security patches are available.

How to Check the Version Numbers:

  1. Download the VMware Infrastructure Client from the Web User Interface.
    For example: https://ESX-HOST-IP-ADDRESS/client/VMware-viclient.exe
  2. Start the VMware Infrastructure Client
  3. Click the Help Menu
  4. Select “About”
  5. Note the Version and Build for both the Client and Server.
  6. Compare to list below to ensure they are at same release.
  7. If you update the Server you should connect to the Web User Interface and download the latest VMware Infrastructure Client.

Latest Install ISO is VMware ESXi 3.5 Installable Update 4 Build Number: 153875
Released: (2009.03.20)

ESXe350-200907401-O-SG – PATCH Build 176894 (2009.05.28) – VIC 147633 – Tools 176894 <– Latest Patch

ESXe350-200906401-O-BG – PATCH Build 169697 (2009.05.28) – VIC 147633 – Tools 169697

ESXe350-200905401-O-BG – PATCH Build 163429 (2009.05.28) – VIC 147633 – Tools 158874
ESXe350-200904401-O-SG – PATCH Build 158874 (2009.04.29) – VIC 147633 – Tools 158874
ESXe350-200904201-O-SG – PATCH Build 158869 (2009.04.10) – VIC 147633 –
ESXe350-200903201-O-UG – UPDATE Build 153875 (2009.03.30) – VIC 147633 <– Update 4
ESXe350-200903411-O-BG – PATCH Build 153840 (2009.03.20) – VIC 119801
ESXe350-200901401-O-SG – PATCH Build 143129 (2009.01.30) – VIC 143129
ESXe350-200811401-O-SG – PATCH Build 130755 (2009.12.02) – VIC 119801
ESXe350-200810401-O-UG – UPDATE Build 123629 (2008.11.17) – VIC 119801 Update 3

The typical way to apply patches to ESXi hosts is through the VMware Update Manager. For details, see the VMware Update Manager Administration Guide.

ESXi hosts can also be updated by downloading the most recent “O” (offline) patch bundle from http://support.vmware.com/selfsupport/download/ and installing the bundle using VMware Infrastructure Update or by using the vihostupdate command through the Remote Command Line Interface (RCLI). For details, see the ESX Server 3i Configuration Guide and the ESX Server 3i Embedded Setup Guide (Chapter 10, Maintaining ESX Server 3i and the VI Client) or the ESX Server 3i Installable Setup Guide (Chapter 11, Maintaining ESX Server 3i and the VI Client).

Note: ESXi hosts do not reboot automatically when you patch with the offline bundle.

Reference:

http://support.vmware.com/selfsupport/s3portal.portal?_nfpb=true&_windowLabel=SearchPatch&SearchPatch_actionOverride=%2Fportlets%2Fpatchupdate%2FfindPatchByProductVersion&_pageLabel=s3portal_pages_downloadPatch_page&version=3.5&product=ESXi%20(Embedded%20and%20Installable)

2009/06/26

VMware ESX High Availability – Tips and Tricks

VMware HA doesn’t work.

  1. Verify that host name is lowercase: hostname; hostname -s
  2. Verify that host name in /etc/hosts is lowercase
  3. Verify that search domain in /etc/resolv.conf is in lowercase
  4. Verify that host name in /etc/sysconfig/network is fqdn, all lowercase
  5. Verify that the host name in esx.conf is fqdn, all lowercase
  6. Verify that host name in DNS is lowercase: nslookup; <short hostname> (should properly resolve fqdn of host, all lowercase)
  7. Verify that all primary service consoles have the same name.
  8. Verify that all primary service consoles are in the same IP subnet.
  9. If VMotion vmkernel port is on same vSwitch as primary service console, use das.allowVmotionNetworks=1
  10. If host has multiple service consoles, use KB 1006541 and the das.allowNetwork0 HA option to ensure that only the primary service console is allowed.
  11. Verify that customer has appropriate licensing for HA, and has available licenses:  In LM Tools, perform a status inquiry, verify that cu is licensed for VC_DAS
  12. Once you have met all of the above criteria, enable HA.
  13. If, after you have verified all the above, and HA still won’t configure:
  1. On the host, stop vpxa: service vmware-vpxa stop
  2. The host will show not responding in VC after a while
  3. Disconnect the host from VC
  4. Re-connect the host to VC
  5. This will force the VPXA package to re-deploy, as well as the HA packages to re-deploy.
  6. Re-configure the hosts for HA.

Many thanks to: Kevin Riley [mailto:kriley@vmware.com]

See also:
http://vmwaretips.com/wp/2008/10/20/advanced-settings-for-vmware-ha/

http://blog.spudz.org/?p=388

http://kb.vmware.com/kb/1006541
As of VirtualCenter 2.5 Update 2 configuration of VMware High Availability fails.
An error similar to the following appears in the Tasks and Events detail:

HA agent on <esxhostname> in cluster <clustername> in <datacenter> has an error Incompatible HA Networks:

Cluster has network(s) missing on host: x.x.x.x

Consider using the Advanced Cluster Settings das.allowNetwork to control network usage.
das.allowVmotionNetworks
– Allows for a NIC that is used for VMotion networks to be considered
for VMware HA usage. This parameter enables a host that has only one
NIC configured for management and VMotion combined to be used in VMware
High Availability communication. By default, any VMotion network is
ignored.
das.allowNetwork[…] – Allows the use of port group names
to control the networks used for VMware HA. The value is set as the
name of the portgroup, for example, Service Console or Management
Network . When configured, the VMware HA cluster only uses the
specified networks for VMware HA communication.

To configure VMware HA to use the new settings:
Log in to VirtualCenter with the VI Client as an administrator.
Edit the settings of the cluster and deselect Enable VMware HA.
Click OK, and wait for the servers to unconfigure for VMware HA.
Click
ESX Server > Configuration > Networking on each of the ESX hosts
in the cluster and note the portgroups that are common between the
servers.
Edit the settings of the cluster, and select Enable VMware HA.
Click VMware HA.
Click Advanced Options.
Add the das.allowNetworkX option with a value of the portgroup name, where X is a number between 1 and 10,

IR: Wednesday, June 24, 2009

2009/06/06

VMware Storage VMotion

Filed under: virtualization — Tags: , , — iben @ 21:10

How Does VMware Storage VMotion Work?

VMware Storage VMotion allows virtual machine storage disks to be relocated to different datastore locations with no downtime, while being completely transparent to the virtual machine or the end user.


Before moving a virtual machines disk file, Storage VMotion moves the “home directory” of the virtual machine to the new location. The home directory contains meta data about the virtual machine (configuration, swap and log files). After relocating the home directory, Storage VMotion copies the contents of the entire virtual machine storage disk file to the destination storage host, leveraging “changed block tracking” to maintain data integrity during the migration process. Next, the software queries the changed block tracking module to determine what regions of the disk were written to during the first iteration, and then performs a second iteration of copy, where those regions that were changed during the first iteration copy (there can be several more iterations).


Once the process is complete, the virtual machine is quickly suspended and resumed so that it can begin using the virtual machine home directory and disk file on the destination datastore location. Before VMware ESX allows the virtual machine to start running again, the final changed regions of the source disk are copied over to the destination and the source home and disks are removed.

This approach guarantees complete transactional integrity and is fast enough to be unnoticeable to the end user.


VMware White Paper on Storage vMotion – http://www.vmware.com/files/pdf/storage_vmotion_datasheet.pdf


Dell video showing how VMware Storage vMotion works – http://www.youtube.com/watch?v=7EfGJaYnQjM


VMware Storage vMotionVI Client Plugin by Andrew Kutzhttp://code.google.com/p/akutz/downloads/detail?name=SVMotionClientSetup-0.4.4.msi


Guide on how to use Storage vMotion – http://www.virtualizationadmin.com/articles-tutorials/vmware-esx-articles/vmotion-drs-high-availability/storage-vmotion-svmotion-vi-plugin.html




Here is another GUI for VMware Storage vMotion – http://communities.vmware.com/thread/122847

VMware Storage vMotion GUI

VMware Storage vMotion GUI


2009/05/20

Spelling – VMware or VMWare or VMWARE or vmware

Filed under: virtualization — Tags: , , , , , , — iben @ 11:20

[NMAP has been corrected! see email replies from Fydor and IEEE at end]

Here are a couple emails I sent off today requesting (suggesting) that the OUI information be corrected for VMware’s MAC addresses.  I first noticed the issue when my friend ran the latest NMAP on his MacBook against our internal work net. So I was all set to submit a bug to the NMAP developers when I realized they just get their information on this from the I triple E standards body and they just get their info from whomever happened to be on duty that day and made the request.

It’s the OCD part of me that can’t stand to see VMware spelled wrong (VMWare).

I’m sure other companies like McAfee and McDonald’s have entire teams dedicated to protecting this sort of brand identity.

All lower case would have been fine (vmware) like Unix style.

So would have all UPPERCASE  (VMWARE) as it adds emphasis or might be a convention for a proper noun in certain types of databases or programming languages.

But if you are going to make the effort to use the shift key for just part of the word the least you could do is learn which letters are supposed to be upper case and which ones are not.

To: ieee-registration-authority@ieee.org

Subject: typo in spelling of company name…

Dear Registration Team,

I noticed a minor typo in the list here:

http://standards.ieee.org/regauth/oui/oui.txt

http://standards.ieee.org/cgi-bin/ouisearch

The word “VMware” is spelled wrong when reporting the company for an OUI. The “w” should be lower case – not upper case.

Also, the company has moved and is no longer located on Porter Drive but around the corner now on Hillview Ave.

Please see the corporate web site for the accurate information and correct the list output.

http://www.vmware.com/company/contact.html

VMware, Inc.
3401 Hillview Ave
Palo Alto, CA 94304 USA

For example: Here is the current output…

00-05-69   (hex)        VMWARE, Inc.
000569     (base 16)        VMWARE, Inc.
3145 Porter Dr., Bldg. F
Palo Alto CA 94304
UNITED STATES

00-0C-29   (hex)        VMware, Inc.
000C29     (base 16)        VMware, Inc.
3145 Porter Dr.
Palo Alto CA 94304
UNITED STATES

00-1C-14   (hex)        VMware, Inc
001C14     (base 16)        VMware, Inc
3145 Porter Drive
Palo Alto CA 94304
UNITED STATES

00-50-56   (hex)        VMWare, Inc.
005056     (base 16)        VMWare, Inc.
44 ENCINA AVENUE
PALO ALTO CA 94301
UNITED STATES

Reference Info:

http://communities.vmware.com/thread/108426

To: nmap-dev@insecure.org

Subject: spelling of company name “VMware” for a given mac address

Dear NMAP Developer Team,

I noticed a minor typo in the OS Detection Output.

The word “VMware” is spelled wrong when reporting the company for an OUI. The “w” should be lower case – not upper case.

For example: Here is the current output…

MAC Address: 00:50:56:01:11:00 (VMWare)

And this is the corrected version…

MAC Address: 00:50:56:01:11:00 (VMware)

Reference Info:

http://communities.vmware.com/thread/108426

http://standards.ieee.org/regauth/oui/oui.txt

00-05-69   (hex)                VMWARE, Inc.
000569     (base 16)            VMWARE, Inc.
3145 Porter Dr., Bldg. F
Palo Alto CA 94304
UNITED STATES

00-0C-29   (hex)                VMware, Inc.
000C29     (base 16)            VMware, Inc.
3145 Porter Dr.
Palo Alto CA 94304
UNITED STATES

00-1C-14   (hex)                VMware, Inc
001C14     (base 16)            VMware, Inc
3145 Porter Drive
Palo Alto CA 94304
UNITED STATES

00-50-56   (hex)                VMWare, Inc.
005056     (base 16)            VMWare, Inc.
44 ENCINA AVENUE
PALO ALTO CA 94301
UNITED STATES

On May 20, 2009, at 5:52 PM, Fyodor wrote:

Hi Iben.  Unfortunately, that is wrong in the official document at
http://standards.ieee.org/regauth/oui/oui.txt.  VMware should really
contact the IEEE and canonicalize their name and addresses in that
file.  As you show in your email, it is even all caps in one case.

So while there is little I can do about the varying VMware
capitalization until they fix it upstream, I took the opportunity to
update the data to correspond with the latest version of
http://standards.ieee.org/regauth/oui/oui.txt.  Looking at the changes
in r13359, it is clear that companies often get minor capitalization
changes put through, so VMware just needs to do that as well.
Instructions are at http://standards.ieee.org/regauth/oui/index.shtml.

Cheers,
-F


From: ieee-registration-authority@ieee.org

Sent: Thursday, May 21, 2009 11:24 AM
To: Iben Rodriguez
Subject: Re: typo in spelling of company name…

Mr. Rodriguez,

The changes have been completed and will reflect on our website within 24 hours.
Please let me know if you have additional questions.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
IEEE Registration Authority
IEEE Standards Department
445 Hoes Lane
Piscataway, NJ 08854 USA
Phone:  +1 732-465-6481
Fax:  +1 732-562-1571
E-mail:  ieee-registration-authority@ieee.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://standards.ieee.org/regauth/index.html

IEEE.  Fostering technological innovation and excellence for the benefit of humanity.

Celebrating 125 Years of Engineering the Future.  www.ieee125.org

—end of email–

Success!

5/25/2009 shows corrected updates.  Still waiting to find out if NMAP will dynamically reflect these changes or if a code rev is needed.

Here are the results of your search through the public section of the IEEE Standards OUI database report for vmware:


00-05-69   (hex)		VMware, Inc.
000569     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES

00-0C-29   (hex)		VMware, Inc.
000C29     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES

00-1C-14   (hex)		VMware, Inc
001C14     (base 16)		VMware, Inc
				3401 Hillview Avenue
				Palo Alto CA 94304
				UNITED STATES

00-50-56   (hex)		VMware, Inc.
005056     (base 16)		VMware, Inc.
				3401 Hillview Avenue
				PALO ALTO CA 94304
				UNITED STATES

Now – need to fix NMAP

Nmap 4.85BETA9

MAC Address: 00:0C:29:11:00:11 (VMware) <– virtual machine guest – correct

MAC Address: 00:50:56:00:11:00 (VMWare) <– ESX host – wrong

As you can see a scan with the latest version of NMAP still shows the wrong spelling.  Now that the OUI is corrected on the public IEEE web site we’ll need to wait for NMAP to get updated.

I’ve emailed Fydor and hopefully he can fix it next week…?

I b e n

Nmap Changelog – fixed

# Nmap Changelog ($Id: CHANGELOG 13432 2009-05-28 

o Updated nmap-mac-prefixes with the latest MAC address prefix data
  from http://standards.ieee.org/regauth/oui/oui.txt as of
  5/20/09. [Fyodor]
Reference: http://nmap.org/changelog.html

2009/05/06

vmxnet3 – features and use information – tips and tricks

Filed under: virtualization — Tags: , , , , , — iben @ 00:01
vmxnet3 – features and use information – tips and tricks
  
UPDATED for Windows 2008 Core

Glad to see this has been posted and we can talk about it now… please share your experiences and let us know if these tips work for you and what sort of performance benefits you’ve noticed when using this new driver.

We’ve been switching our Windows and Linux VMs to use “VMXNET Enhanced” for some time now and see public information on the new VMXNET3 NIC for guests…
This Thread has been started to help with procedures on the conversion of existing machines from older NIC to newer NIC as it is not 100% straightforward and there are some tricks to remove old hardware and change to new hardware. This would be similar in the physical world to changing from a 100 BaseT PCI Card to a GigE card. The old drivers need to be removed, new drivers installed, and IP Addresses moved over. If you just remove the old NIC and install the new one you may end up with a IP Address Conflict error saying the Address you are trying to use is already in use on another Network Interface. The problem is that when you open Device Manager the old NIC is hidden. See below for steps on how to overcome this.
Question: What is VMXNET3?
Answer: VMXNET3 builds upon VMXNET and Enhanced VMXNET as the third generation paravirtualized virtual networking NIC for guest operating systems.
New VMXNET3 features over previous version of Enhanced VMXNET include:
• MSI/MSI-X support (subject to guest operating system kernel support)
• Receive Side Scaling (supported in Windows 2008 when explicitly enabled through the device’s Advanced configuration tab)
• IPv6 checksum and TCP Segmentation Offloading (TSO) over IPv6
• VLAN off-loading
• Large TX/RX ring sizes (configured from within the virtual machine)

What’s New in vSphere 4.0

http://communities.vmware.com/viewwebdoc.jspa?documentID=DOC-9225&communityID=2701
http://www.vmware.com/files/pdf/VMW_09Q1_WP_vSphereNetworking_P8_R1.pdf

From the Cisco document:VMware vSphere 4 and Cisco Nexus 1000V Series

VMware vNetwork module that encompasses the vDS and VMXNET-3 enables inline monitoring and centralized firewall services and maintains the virtualmachine’s network run-time characteristics.

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/solution_overview_c22-529767-00.pdf

Tech Notes

Flexible shows up in Windows Device Manager as an “VMware
Accelerated AMD PCNet Adapter” and Enhanced vmxnet show up as “VMware
PCI Ethernet Adapter”.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805
Flexible — The Flexible network adapter
identifies itself as a Vlance adapter when a virtual machine boots, but
initializes itself and functions as either a Vlance or a vmxnet
adapter, depending which driver initializes it. VMware Tools versions
recent enough to know about the Flexible network adapter include the
vmxnet driver but identify it as an updated Vlance driver, so the guest
operating system uses that driver. When using the Flexible network
adapter, you can have vmxnet performance when sufficiently recent
VMware tools are installed. When an older version of VMware Tools is
installed, the Flexible adapter uses the Vlance adapter (with Vlance
performance) rather than giving no network capability at all when it
can’t find the vmxnet adapter.
Enhanced vmxnet — The enhanced vmxnet adapter is
based on the vmxnet adapter but provides some high-performance features
commonly used on modern networks, such as jumbo frames. This virtual
network adapter is the current state-of-the-art device in virtual
network adapter performance, but it is available only for some guest
operating systems on ESX Server 3.5. This network adapter will become
available for additional guest operating systems in the future.

Networking Error, IP Address Already Assigned to Another Adapter
KB Article 1179
Updated Jan. 07, 2009
Why do I see an error message that “The IP address XXX.XXX.XXX.XXX…” is already assigned to another adapter?

Solution
Under certain conditions, you may see the following error message from a Windows guest operating system:
The IP address XXX.XXX.XXX.XXX you have entered for this network
adapter is already assigned to another adapter Name of adapter. Name of
adapter is hidden from the network and Dial-up Connections folder
because it is not physically in the computer or is a legacy adapter
that is not working. If the same address is assigned to both adapters
and they become active, only one of them will use this address. This
may result in incorrect system configuration. Do you want to enter a
different IP address for this adapter in the list of IP addresses in
the advanced dialog box?
In this message, XXX.XXX.XXX.XXX is an IP address that you are
trying to set and Name of adapter is the name of a network adapter that
is present in the registry but hidden in Device Manager.
This can occur when you change a network connection’s TCP/IP configuration from DHCP to a static IP address if:

  • You have upgraded VMware virtual network adapters (for example

when you migrate a virtual machine from an older to a new version of
VMware software.)

  • You have added and removed network adapters multiple times.

The cause of the error is that a network adapter with the same IP
address is in the Windows registry but is hidden in the Device Manager
(My Computer > Properties > Hardware > Device Manager). This
hidden adapter is called a ghosted network adapter.

Using the Show hidden devices option in the Device Manager (View

Show hidden devices) does not always show the old virtual NIC

(ghosted adapter) to which that IP Address is assigned

Microsoft addresses this issue in their Knowledge Base article
269155, which is available at the time of this writing at
http://support.microsoft.com/?kbid=269155.

To resolve this problem, follow these steps to make the ghosted
network adapter visible in the Device Manager and uninstall the ghosted
network adapter from the registry:
1. Select Start > Run.
2. Enter cmd.exe and press Enter.
3. At the command prompt, run this command:
set devmgr_show_nonpresent_devices=1
4. Enter Start DEVMGMT.MSC and press Enter to start Device Manager.
5. Select View > Show Hidden Devices.
6. Expand the Network Adapters tree (select the plus sign next to the Network adapters entry).
7. Right-click the dimmed network adapter, and then select Uninstall.
8. Close Device Manager.

How to remove these “phantom” NICs from Windows 2008 Server Core

  1. Copy devcon.exe over to the server core server (extract devcon.exe from \SUPPORT\TOOLS\SUPPORT.CAB on a Windows 2003 R2 x64 disc).
  2. Run devcon.exe findall =net (this should list all NICs on the system, including the phantoms). Example output:
    PCI\VEN_15AD&DEV_0720&SUBSYS_072015AD&REV_10\4&B70F118&0&0088: VMware PCI Ethernet Adapter #2
    PCI\VEN_15AD&DEV_0720&SUBSYS_072015AD&REV_10\3&18D45AA6&0&88: VMware PCI Ethernet Adapter
    PCI\VEN_15AD&DEV_07B0&SUBSYS_07B015AD&REV_01\FF565000EB16A3FE00: vmxnet3 Ethernet Adapter
    3 matching device(s) found.
    Observe that vmxnet3 was the active NIC and the others needed to be removed.
  3. devcon -r remove “@PCI\VEN_15AD&DEV_0720&SUBSYS_072015AD&REV_10\3&18D45AA6&0&88″ removed the first one.
  4. Repeat for the remaining unwanted NICs
  5. Reboot the machine to restart all services

Reference: http://vmtoday.com/2009/11/vsphere-upgrade-breaks-active-directory/

Performance

http://blogs.vmware.com/networking/2009/04/considerations-for-maximum-network-performance.html

For UDP, use vmxnet3 to be able to configure a larger vNIC Rx ring size.  Because UDP can be a lot more bursty (due to lack of flow-control), having a larger Rx ring size helps to provide buffering/elasticity to better absorb the bursts.  The new vmxnet3 allows resizing the vNIC’s Rx ring size, up to around 1 to 2 thousand buffers.  As a side note, there is some negative performance impact with larger ring size due to larger memory foot print. The new vxmnet3 vNIC is more efficient than the e1000 vNIC.  Also in general, ESX 4 has some performance improvements over ESX 3.5.

Line Rate 10GigE

Howie Xu, Director of R&D for VMkernel IO remarked recently that after talking with a few customers, many are still unaware we can achieve line rate 10GigE performance on ESX 3.5. Read “10Gbps Networking Performance on ESX 3.5u1” posted on VMware’s network technology resources page.

The story only gets better with vSphere 4 and ESX 4 with the new Intel Nehalem processors. Initial tests from engineering show a staggering 30Gbps throughput.

Choosing a Network Adapter for Your Virtual Machine

KB Article 1001805
Updated May 05, 2009
 
 
Details
 
The Virtual Machine wizard’s Choose Networks window allows you to specify a network and a network adapter. The network adapter choices available depend on these factors:
  • The version of the virtual machine, which depends on what host created it or most recently updated it
  • Whether or not the virtual machine has been updated to the latest version for the current host
  • The guest operating system

The Choose Networks window makes available only those network adapters that make sense for the virtual machine you are creating. Each adapter type is discussed in some detail in “Available Network Adapters,” below. Here is an overview of what Choose Networks might offer you:

  • For virtual machines native to VMware Workstation 4x, VMware GSX Server 3, or VMware ESX Server 2.x, you can explicitly choose between Vlance and vmxnet
  • For most 32bit virtual machines native to VMware Workstation 5 or 6, VMware Server 2, or VMware ESX Server 3, only the Flexible adapter is available
  • For most 64bit virtual machines and for 32bit Microsoft Windows Vista virtual machines, only the e1000 adapter is available
  • For certain guest operating systems on VMware ESX Server 3.5 and later, you can choose the Enhanced vmxnet adapter in addition to the Flexible or e1000 adapter mentioned for that guest type in the previous bullets
Solution
 
Available Network Adapters
 
The following network adapters might be available for your virtual machine, depending on the factors discussed above:
  • Vlance — Vlance (also called PCNet32) is a faithful virtual implementation of a common, if now somewhat aging, physical network adapter. Most 32bit guest operating systems, except for Windows Vista, have built-in support for this card so a virtual machine configured with this network adapter can use its network immediately.
  • vmxnet — The vmxnet virtual network adapter has no physical counterpart. VMware makes vmxnet available because Vlance, a faithful implementation of a physical card, is far from optimal for network performance in a virtual machine. Vmxnet is highly optimized for performance in a virtual machine. Because there is no physical card of type vmxnet, operating system vendors do not provide built-in drivers for this card. You must install VMware Tools to have a driver for the vmxnet network adapter available.
  • Flexible — The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a vmxnet adapter, depending which driver initializes it. VMware Tools versions recent enough to know about the Flexible network adapter include the vmxnet driver but identify it as an updated Vlance driver, so the guest operating system uses that driver. When using the Flexible network adapter, you can have vmxnet performance when sufficiently recent VMware tools are installed. When an older version of VMware Tools is installed, the Flexible adapter uses the Vlance adapter (with Vlance performance) rather than giving no network capability at all when it cannot find the vmxnet adapter.
  • e1000 — e1000 is a faithful virtual implementation of a physical network adapter that is broadly supported by newer operating systems, specifically most 64bit operating systems and both 32 and 64bit Windows Vista. e1000 performance is intermediate between Vlance and vmxnet.
  • Enhanced vmxnet — The enhanced vmxnet adapter is based on the vmxnet adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames. This virtual network adapter is the current state-of-the-art device in virtual network adapter performance, but it is available only for some guest operating systems on ESX Server 3.5. This network adapter will become available for additional guest operating systems in the future.

    • 32/64bit versions of Microsoft Windows 2003 (Enterprise and Datacenter Editions). You can use enhanced vmxnet adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in the VI Client. For more information, see Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003.
    • 32bit version Microsoft Windows XP Professional
    • 32/64bit versions Red Hat Enterprise Linux 5.0
    • 32/64bit versions SUSE Linux Enterprise Server 10
    • 64bit versions Red Hat Enterprise Linux 4.0

    Enhanced VMXNET is supported only for a limited set of guest operating systems:

Adapter Caveats
  
This section discusses some potential issues you might have.
 

 

Migrating virtual machines that use enhanced vmxnet. Enhanced vmxnet is new with ESX Server 3.5. Virtual machines configured to have enhanced vmxnet adapters cannot migrate to older ESX Server hosts, even though virtual machines can usually migrate freely between ESX Server 3.0 and ESX Server 3.0.1.

Upgrading from ESX Server 2.x to ESX Server 3.x. When a virtual hardware upgrade operation transforms a virtual machine created on an ESX Server 2.x host to an ESX Server 3.x host, Vlance adapters are automatically upgraded to Flexible. In contrast, vmxnet adapters are not upgraded automatically because certain guest operating systems — specifically most or all Linux versions — do not reliably preserve network settings when a network adapter is replaced. Because the guest operating system thinks a Flexible adapter is still Vlance, it retains the settings in that case. If the upgrade were to replace a vmxnet adapter with a Flexible adapter, the guest operating system would erroneously discard the settings.
 
After the virtual hardware upgrade, the network adapter is still vmxnet, without the fallback compatibility of the Flexible adapter. Just as on the original older host, if VMware Tools is uninstalled on the virtual machine, it is unable to access its network adapters.

 

Network adapters on multi-boot Linux. The Virtual Machine Settings dialog box and New Virtual Machine wizard allow creation of only those virtual network adapters that are supported for the selected guest operating system. If you change the guest operating system, the existing network adapters are not affected. When you switch a multi-boot Linux system between 32bit mode and 64bit mode, a problem arises because most 32bit Linux versions do not support e1000 adapters while most 64bit Linux versions support only e1000 adapters. Consider configuring your virtual machine with one of each type of network adapter (e1000 and Flexible). You can then set up your guest operating system to use only the network adapter for which it has a driver in each mode.
 
You can add the second adapter any time the virtual machine is powered off, but you need to change the configured guest operating system type from 32bit to 64bit or vice-versa in order to be offered the other network adapter. Since changing that setting before rebooting into the other bit depth can potentially improve the efficiency of virtual machine scheduling, plan to change the guest operating system type setting before your first reboot into the other bit depth.

Adding virtual disks. Adding an existing older (ESX Server 2.x) virtual disk to an ESX Server 3.x virtual machine results in a de-facto downgrade of that virtual machine to ESX Server 2.x. If you are using ESX Server 3.x features, such as enhanced vmxnet or Flexible network adapters, the virtual machine becomes inconsistent. When you add an existing ESX Server 2.x virtual disk to an ESX Server 3.x machine, you should immediately use the Upgrade Virtual Hardware command to restore the virtual machine to the ESX Server 3 version.
Note: Executing Upgrade Virtual Hardware changes the ESX Server 2 virtual disk so it is no longer usable on an ESX Server 2 virtual machine. Consider making a copy of the disk before you upgrade one of the two copies to ESX Server 3 format.

If you must migrate a virtual machine between newer and older hosts, do not choose enhanced vmxnet but instead one of the older adapter types. Flexible or e1000 are offered whenever enhanced vmxnet is offered.

« Newer PostsOlder Posts »

Powered by WordPress