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

2011/08/11

ESX vSwitch L2 Security

Filed under: it,security,virtualization — Tags: , , , , , , — iben @ 11:58

VMware vSphere ESX Host Virtual Switch Layer 2 Security Features

The virtual switch has the ability to enforce security policies to prevent virtual machines from impersonating other nodes on the network. There are three components to this feature. These should all be set to “REJECT” to enable the security feature.

•Promiscuous mode is disabled by default for all virtual machines. This prevents them from seeing unicast traffic to other nodes on the network.

•MAC address change lockdown prevents virtual machines from changing their own unicast addresses. This also prevents them from seeing unicast traffic to other nodes on the network, blocking a potential security vulnerability that is similar to but narrower than promiscuous mode.

•Forged transmit blocking, when you enable it, prevents virtual machines from sending traffic that appears to come from nodes on the network other than themselves.

Cisco Nexus 1000v Switch Layer 2 Security

MAC ACLs

MAC ACLs are ACLs that filter traffic using information in the Layer 2 header of each packet.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_9mac_acls.html

Port Security

Port security lets you configure Layer 2 interfaces permitting inbound traffic from a restricted set of MAC addresses called secure MAC addresses. In addition, traffic from these MAC addresses is not allowed on another interface within the same VLAN. The number of MAC addresses that can be secured is configurable per interface.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0/security/configuration/guide/security_10port.html#wp1210839

DHCP Snooping

DHCP snooping acts like a firewall between untrusted hosts and trusted DHCP servers by doing the following:

•Validates DHCP messages received from untrusted sources and filters out invalid response messages from DHCP servers.

•Builds and maintains the DHCP snooping binding database, which contains information about untrusted hosts with leased IP addresses.

•Uses the DHCP snooping binding database to validate subsequent requests from untrusted hosts.

Dynamic ARP inspection (DAI) and IP Source Guard also use information stored in the DHCP snooping binding database.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_12dhcpsnoop.html#wp1272686

Dynamic Address Resolution Protocol (ARP) Inspection (DAI)

DAI is used to validate ARP requests and responses as follows:

•Intercepts all ARP requests and responses on untrusted ports.

•Verifies that a packet has a valid IP-to-MAC address binding before updating the ARP cache or forwarding the packet.

•Drops invalid ARP packets.

DAI can determine the validity of an ARP packet based on valid IP-to-MAC address bindings stored in a Dynamic Host Configuration Protocol (DHCP) snooping binding database. This database is built by DHCP snooping when it is enabled on the VLANs and on the device. It may also contain static entries that you have created.

If an ARP packet is received on a trusted interface, the device forwards the packet without any checks. On untrusted interfaces, the device forwards the packet only if it is valid.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_13arpinspect.html#wp1329252

IP Source Guard

IP Source Guard is a per-interface traffic filter that permits IP traffic only when the IP address and MAC address of each packet matches the IP and MAC address bindings of dynamic or static IP source entries in the Dynamic Host Configuration Protocol (DHCP) snooping binding table.

You can enable IP Source Guard on Layer 2 interfaces that are not trusted by DHCP snooping. IP Source Guard supports interfaces that are configured to operate in access mode and trunk mode. When you initially enable IP Source Guard, all inbound IP traffic on the interface is blocked except for the following:

•DHCP packets, which DHCP snooping inspects and then forwards or drops, depending upon the results of inspecting the packet.

•IP traffic from static IP source entries that you have configured in the Cisco Nexus 1000V.

The device permits the IP traffic when DHCP snooping adds a binding table entry for the IP address and MAC address of an IP packet or when you have configured a static IP source entry.

The device drops IP packets when the IP address and MAC address of the packet do not have a binding table entry or a static IP source entry.

http://www.cisco.com/en/US/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_2/security/configuration/guide/n1000v_security_14sourceguard.html#wp1096775

Reference Links

http://www.vmware.com/files/pdf/dmz-vsphere-nexus-wp.pdf

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMware.html#wp696333

Labels:


2010/11/13

VMware VAAI Certification Test Summary

Filed under: virtualization — Tags: , , , , , , , — iben @ 17:47

VMware VAAI Certification Test Summary

Based on the VMware VAAI Certification Guide Revision date: 20101011

This guide is intended for VMware partners who want to certify VAAI storage with ESX to claim compatibility in the VMware HCLs.

The vStorage API calls off load certain storage operations to the storage array and optimize the storage operation. They are the new application programming interfaces in the VMKernel. Using a small set of primitives or fundamental operations that can be issued to an array supporting these interfaces, ESX can improve the performance on certain storage operations such as cloning, snapshotting, mirroring, zeroing blocks, and replication.

You certify these offload operations with your storage arrays and use this certification to obtain a listing in the VMware compatibility guide:

  • Atomic Test and Set (ATS) also known as Hardware Assisted Locking: a mechanism to modify a disk sector to improve the performance of ESX updating metadata.
  • Full Copy: given a source range of LBAs, copies them into the given destination range of LBAs.
  • Block Zeroing or Write Same: zeroes out the given range of LBAs.

VAAI Certification Test Process List

  1. BlockZeroDiskTest
    1. This test verifies that when ESX uses the VAAI BlockZero primitive, an eager‐zeroed‐thick vmdk volume is created faster.
    2. The operation compares execution time with and without enabling the VAAI BlockZero primitive. The test passes only if the execution time with VAAI enabled is less than with VAAI disabled.
    3. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    4. IMPORTANT Do not run any extraneous workloads on the storage array under test during the first 30 minutes of this test to avoid the possibility of non‐constant workloads skewing the test times and causing a test failure.
    5. Estimated test time: 30 minutes
  2. BlockZeroRDMTests
    1. This test verifies that zeroing a vmdk volume on an RDM disk is performed correctly when ESX uses the VAAI BlockZero primitive. The test is run on both a non‐pass‐through RDM as well as a pass‐through RDM disk.
    2. The operation is conducted with and without enabling the VAAI BlockZero primitive. The test logs note the execution times with and without the VAAI BlockZero primitive, but the time does not determine test passing or failing.
    3. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    4. Estimated test time: 5 minutes to 3 hours
  3. BlockZeroMultiOffloadTests
    1. This test verifies that simultaneous creation of virtual disks on a shared datastore from two ESX hosts with VAAI BlockZero primitive enabled functions properly.
    2. The operation is conducted with and without enabling the VAAI BlockZero primitive. The test logs note the execution times with and without the VAAI BlockZero primitive, but the time does not determine test passing or failing.
    3. This test is conducted with no I/O to the array under test.
    4. Estimated test time: 10‐20 minutes
  4. FullCopyDiskTest
    1. This test verifies that when ESX uses the VAAI FullCopy primitive, a vmdk volume clones faster.
    2. The operation is conducted with and without enabling the VAAI FullCopy primitive. The test logs note the execution times with and without the VAAI FullCopy primitive, but the time does not determine test passing or failing.
    3. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    4. Estimated test time: 36 hours, with a majority of the time spent verifying cloned volume contents.
  5. FullCopyRDMTests
    1. This test verifies that cloning a vmdk volume to an RDM disk is done correctly when ESX host uses the VAAI FullCopy primitive. The test is run with both a non‐pass‐through RDM as well as a pass‐through RDM disk as the destination disk.
    2. The operation is conducted with and without enabling the VAAI FullCopy primitive. The test logs note the execution times with and without the VAAI FullCopy primitive, but the time does not determine test passing or failing.
    3. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    4. Estimated test time: 18 hours, with a majority of the time spent verifying cloned volume contents.
  6. FullCopyCloneVMTests
    1. This test verifies that virtual machine cloning operations function properly with the VAAI FullCopy primitive enabled.
    2. The test clones a virtual machine to both the same datastore as the source virtual machine as well as to a different datastore.
    3. The operation compares execution time with and without enabling the VAAI FullCopy primitive. The test passes only if the execution time with VAAI enabled is less than with VAAI disabled.
    4. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    5. IMPORTANT Do not run any extraneous workloads on the storage array under test during the first 30 minutes of this test to avoid the possibility of non‐constant workloads skewing the test times and causing a test failure.
    6. Estimated test time: 1 hour
  7. FullCopyCloneVMRDMTests
    1. This test verifies that virtual machine cloning operation from a non‐pass‐through RDM LUN to a pass‐through RDM LUN functions properly with the VAAI FullCopy primitive enabled.
    2. The operation is conducted with and without enabling the VAAI FullCopy primitive. The test logs note the execution times with and without the VAAI FullCopy primitive, but the time does not determine test passing or failing.
    3. The test is conducted with continuous I/O to the array under test from four virtual machines running on the ESX host.
    4. Estimated test time: 32 minutes
  8. FullCopyMultiOffloadTests
    1. This test verifies that the VAAI feature improves concurrent Full Copy from two ESX hosts.
    2. The operation is conducted with and without enabling the VAAI FullCopy primitive. The test logs note the execution times, but the time does not determine test passing or failing.
    3. This test is conducted with no I/O to the array under test.
    4. Estimated test time: 20 minutes
  9. ATSFileOpTests
    1. This test verifies that when ESX enables the VAAI ATS primitive, the file create, delete, read and write operations perform faster with simultaneous access to the LUN from two ESX hosts.
    2. The operation compares execution time with and without enabling the VAAI ATS primitive. The test passes only if the execution time with VAAI enabled is less than with VAAI disabled.
    3. This test is conducted with no I/O to the array under test.
    4. IMPORTANT Do not run any extraneous workloads on the storage array under test during the first 30 minutes of this test to avoid the possibility of non‐constant workloads skewing the test times and causing a test failure.
    5. Estimated test time: 12‐20 minutes
  10. ATSMultiLengthFileTests
    1. This test verifies that when ESX hosts use the VAAI ATS primitive, simultaneous file modifications from two ESX hosts function properly.
    2. The operation compares execution time with and without enabling the VAAI ATS primitive. The operation is conducted with and without enabling the VAAI ATS primitive. The test logs note the execution times, but the time does not determine test passing or failing.
    3. This test is conducted with no I/O to the array under test.
    4. Estimated test time: 3‐10 minutes
  11. ATSReserveTests
    1. This test verifies that when ESX hosts use the VAAI ATS primitive, file locking and unlocking modifications from two ESX hosts function properly.
    2. This test is conducted with no I/O to the array under test.
    3. Estimated test time: 3‐5 minutes

2010/10/28

VAAI – Netapp

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

New NetApp Virtual Storage Console 2.0 (VSC) integrates with VMware vSphere vStorage APIs for Array Integration (VAAI). VAAI provides additional interfaces to enable advanced capabilities developed by VMware vSphere workflows to integrate advanced storage capabilities from NetApp and other vendors.

http://media.netapp.com/documents/wp-7106.pdf

VSC consists of three distinct capabilities:

  • Storage Console is the foundation capability, providing storage discovery, health monitoring, capacity management, and storage configuration according to best practices.
  • Provisioning and Cloning (formerly NetApp Rapid Cloning Utility) provides end-to-end datastore management-provisioning, resizing, and deletion-and rapid, space-efficient VM server and desktop cloning, patching, and updating utilizing NetApp FlexClone technology.
  • Backup and Recovery (formerly NetApp SnapManager for Virtual Infrastructure) automates data protection processes by enabling VMware admins to centrally manage backup and recovery of datastores and VMs without impacting guest performance, and to rapidly recover from backups at any level of granularity-datastore, VM, VMDK, or guest file.

Provisioning and Cloning

The provisioning and cloning capability of VSC 2.0 includes all the capabilities of previous versions of RCU, including the ability to efficiently clone new virtual machines from a baseline using NetApp FlexClone technology, manage and secure storage paths, configure deduplication and thin provisioining for storage efficiency, and resize datastores.

Another significant feature is the ability to redeploy existing virtual machines to bring them up to date with the latest patches and so on. Working from a baseline virtual machine that contains the same OS and applications as your deployed virtual machines plus the desired updates, this feature allows you to quickly reconstruct your existing VMDK files while keeping the unique configuration files for each VM intact. You can also choose to maintain current customization settings or apply new settings.

baselines_902x646.jpg

Figure – Redeploying your existing virtual machines from an updated baseline.

VMFS Versions – Drivers and Formats

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

There are no significant on-disk format changes going from version 3.33 to 3.46. However, there is a significant change between VMFS driver version 3.46 and driver version 3.33. In particular, 3.46 contains VAAI extensions, which leads VMFS to use hardware accelerated locking and the hardware accelerated data mover on VAAI compliant hardware.

So the short answer is that you do not need to upgrade to a new on-disk vmfs 3.46 but instead the new 3.46 driver on ESX 4.1 will bring you the benefit even with vmfs 3.33 on-disk filesystem, if these are on array whose firmware is upgraded that provides such VAAI extensions.

VMware ESX 3 – VMFS ver 3.21
VMware ESX 3.5 – VMFS ver 3.31
VMware vSphere 4 – VMFS ver 3.33
VMware vSphere 4.1 – VMFS ver 3.46
VMware vSphere 5 – VMFS ver 5

HyTrust Appliance 2.1 Available

Filed under: virtualization — Tags: , , , , , , , , , , , , — iben @ 14:36

HyTrust recently celebrated its 3-year birthday.  HyTrust was founded in October 2007 to bring secure access control and policy to virtual infrastructure, enabling wider adoption of virtualization throughout the enterprise — exactly the same focus that we have today.

It’s amazing to see what we have achieved in the last three years: great enterprise customers; solid partnerships with the major players in virtualization (VMware, Cisco, RSA, Intel and Symantec); numerous accolades, including Best of Show at VMworld; and, of course, several significant releases of HyTrust Appliance…

So we’re excited to let you know that HyTrust Appliance 2.1 is now generally available. It is chock-full of exciting new enterprise features, including protection for the control of Cisco Nexus 1000V, application-level high availability, and smart card support.  As always, we have also made 2.1 available in the Community Edition form, which can be downloaded for free here: 
http://info.hytrust.com/appliance.html

New HyTrust Appliance Capabilities At a Glance

  • Support for VMware vSphere 4.1
  • Integrated access control, policy and audit logging for Cisco Nexus 1000V CLI management (NX-OS command set)
  • Support for complex, multi-domain Active Directory environments
  • Single sign-on via Windows pass-through authentication with smart card integration
  • New ESX hardening templates including VMware Hardening Guide 4.0 and (Sarbanes Oxley) SOX hardening template
  • Application-level high availability (in addition to VMware HA/FT and federation)

If you would like to take a look at the new functionality, we have recorded demos of the new version available for your viewing pleasure.
http://info.hytrust.com/recorded_product_demo.html

For those of you currently evaluating HyTrust Appliance, we’d like to extend an added incentive to make your purchase in Q4: for a limited time, HyTrust is offering a free “jump-start” professional services package to help you get up and running quickly. Contact sales (sales@hytrust.com) for more information.

2010/09/10

vsphere security best practices

Filed under: Uncategorized — Tags: , , , , , , — iben @ 07:54

VMware ESX 4.1 and vCenter Server 4.1

Background:

Follow the security principles of:
– separation of duties
– least privilege

Harden the hypervisor: upgrade to vSphere ESXi 4.1

Give the LAN back to the Network Team

Implement the Cisco Nexus 1000v and only assign ports to active systems.

Audit and control access

Use a tool like HyTrust to eliminate configuration drift and track and control system access.

Using Roles to Assign Privileges

A role is a predefined set of privileges. Privileges define individual rights that a user requires to perform actions and read properties.
When you assign a user or group permissions, you pair the user or group with a role and associate that pairing with an inventory object. A single user might have different roles for different objects in the inventory. For example, if you have two resource pools in your inventory, Pool A and Pool B, you might assign a particular user the Virtual Machine User role on Pool A and the Read Only role on Pool B. These assignments would allow that user to turn on virtual machines in Pool A, but not those in Pool B. The user would still be able to view the status of the virtual machines in Pool B.
The roles created on an ESX/ESXi host are separate from the roles created on a vCenter Server system. When you manage a host using vCenter Server, the roles created through vCenter Server are available. If you connect directly to the host using the vSphere Client, the roles created directly on the host are available.
vCenter Server and ESX/ESXi hosts provide default roles:

  • System roles
    • System roles are permanent. You cannot edit the privileges associated with these roles.
  • Sample roles
    • VMware provides sample roles for convenience as guidelines and suggestions. You can modify or remove these roles.

You can also create roles.
All roles permit the user to schedule tasks by default. Users can schedule only tasks they have permission to perform at the time the tasks are created.
Note: Changes to permissions and roles take effect immediately, even if the users involved are logged in. The exception is searches, where permission changes take effect after the user has logged out and logged back in.

Details:

Best Practices for vCenter Roles and Permissions

Use best practices for roles and permissions to maximize the security and manageability of your vCenter Server environment.
VMware recommends the following best practices when configuring roles and permissions in your vCenter Server environment:

  • Use folders to group objects to correspond to the differing permissions you want to grant for them.
  • Grant permissions to groups rather than individual users.
  • Grant permissions only where needed. Using the minimum number of permissions makes it easier to understand and manage your permissions structure.
  • If you assign a restrictive role to a group, check that the group does not contain the Administrator user or other users with administrative privileges. Otherwise, you could unintentionally restrict administrators’ privileges in parts of the inventory hierarchy where you have assigned that group the restrictive role.
  • Use caution when granting a permission at the root vCenter Server level. Users with permissions at the root level have access to global data on vCenter Server, such as roles, custom attributes, vCenter Server settings, and licenses. Changes to licenses and roles propagate to all vCenter Server systems in a Linked Mode group, even if the user does not have permissions on all of the vCenter Server systems in the group.
  • In most cases, enable propagation on permissions. This ensures that when new objects are inserted in to the inventory hierarchy, they inherit permissions and are accessible to users.
  • Use the No Access role to masks specific areas of the hierarchy that you don’t want particular users to have access to.

Use Host Profiles to Apply Permissions to Hosts

When you join a host to an Active Directory domain, you must define roles on the host for a user or group in that domain. Otherwise, the host is not accessible to Active Directory users or groups. You can use host profiles to set a required role for a user or group and to apply the change to one or more hosts.
It is recommended that you follow this procedure for System Administrators (Admin) and Auditors (ReadOnly).

Prerequisites

You must have an existing host profile. See Creating a Host Profile.
Verify that the hosts to which you apply a profile are in maintenance mode.

Procedure

  1. Using the vSphere Client, select View > Management > Host Profiles.
  2. Right-click an existing host profile and select Edit Profile.
  3. Expand the profile tree, and then expand Security configuration.
  4. Right-click the Permission rules folder and select Add Profile.
  5. Expand Permission rules and select Permission.
  6. On the Configuration Details tab in the right pane, click the Configure a permission drop-down menu and select Require a Permission Rule.
  7. Enter the name of the group that should have the role assigned to it.
    1. Use the format DOMAIN\name, where DOMAIN is the name of the Active Directory domain and name is the user name or group name.
  8. Select the Name refers to a group of users check box.
  9. Enter the assigned role name for the user or group (usually Admin or ReadOnly).
    1. The role name is case-sensitive. If this is a system role, you must use the nonlocalized role name. For example, for the Administrator role, enter Admin. For the Read-only role, enter ReadOnly.
  10. Select the Propagate permission check box and click OK.

Reference:

vSphere Datacenter Administration Guide : Setting Up Your Virtual Infrastructure : Managing Users, Groups, Roles, and Permissions : Best Practices for Roles and Permissions
http://pubs.vmware.com/vsphere-esx-4-1/wwhelp/wwhimpl/js/html/wwhelp.htm

2010/04/20

vSphere Network Isolation Addresses

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

http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_availability.pdf

Network Isolation Addresses

A network isolation address is an IP address that is pinged to determine if a host is isolated from the network. This address is pinged only when a host has stopped receiving heartbeats from all other hosts in the cluster. If a host can ping its network isolation address, the host is not network isolated, and the other hosts in the cluster have failed. However, if the host cannot ping its isolation address, it is likely that the host has become isolated from the network and no failover action is taken.

By default, the network isolation address is the default gateway for the host. There is only one default gateway specified, regardless of how many service console networks have been defined, so you should use the das.isolationaddress[…] advanced attribute to add isolation addresses for additional networks. For example,  das.isolationAddress2 to add an isolation address for your second network, das.isolationAddress3 for the third, up to a maximum of das.isolationAddress9 for the ninth.

When you specify additional isolation address, VMware recommends that you increase the setting for the das.failuredetectiontime advanced attribute to 20000 milliseconds (20 seconds) or greater. A node that is isolated from the network needs time to release its virtual machine’s VMFS locks if the host isolation response is to fail over the virtual machines (not to leave them powered on.) This must happen before the other nodes declare the node as failed, so that they can power on the virtual machines, without getting an error that the virtual machines are still locked by the isolated node.

For more information on VMware HA advanced attributes, see “Customizing VMware HA Behavior,” on page 26.

das.isolationaddress
Sets the address to ping to determine if a host is isolated from the network. This address is pinged only when heartbeats are not received from any other host in the cluster. If not specified, the default gateway of the console network is used. This default gateway has to be a reliable address that is available, so that the host can determine if it is isolated from the network. You can specify multiple isolation addresses (up to 10) for the cluster: das.isolationaddressX, where X = 1-10. Typically you should specify one per service console. Specifying too many addresses makes isolation detection take too long and can affect VMware HA behavior.

das.usedefaultisolationaddress
By default, VMware HA uses the default gateway of the console network as an isolation address. This attribute specifies whether or not this default is used (true|false).

2010/03/19

Number of ports to use for standard and distributed virtual switches

Filed under: virtualization — Tags: , , , , , , , , , , , , , , , , , — iben @ 14:30

VMware just updated their KB: Reserved or overhead ports for virtual switches (http://kb.vmware.com/kb/1008040) and we’ve run into this issue a number of times since upgrading to vSphere ESX 4. These new high memory hardware architectures allow an unprecedented number of virtual machine guests to be consolidated on a single ESX host.

By default a vswitch may not have enough ports to support the consolidation ratio your equipment can support. New ESX hosts can have 256 GB of RAM with 4 hex core processors and easily support 100 or more virtual machines. These virtual machines might have 1, 2, or more vNICs configured and each would need a port on the vswitch. One might imagine the need for 500 to 1000 ports needed per esx host. Why not just make it 2000 so we don’t have to worry about it later on?

Once you run out of vswitch ports you cannot power on any more vms on that host and even get errors about unplugged network cable.  Increasing the vSwitch port allocation seems easy enough, vmotion all workload off the host, put it in maintenance mode, change the vswitch config, reboot. Some system administrators run into this issue and decide to make the number of ports allocated to the vswitch really high to prevent this from ever being an issue. This can cause problems though.

There’s a limit of how many vswitch ports in total an ESX host has to hand out to it’s various vswitches. In addition, if security is a concern, you may start running firewall virtual appliances like vShield Zones or Catbird. WAN Accerators and Performance Monitoring tools like AppSpeed also require additional vSwitches to be created. Ports used on these vSwitches all take away from the total bucket of available ports.

Once 4096 ports are allocated to existing vSwitches you will not be able to add additional hosts to a vNetwork Distributed Switch either.

We also have the following Security Recommendation:

Only allocate vswitch ports to virtual machines on demand and as needed.

This will make it difficult if not impossible to “plug” a VM into the wrong network by accident. Testing for this can be done manually through the vSphere Client. If there are no ports available on a vSwitch then this is a positive test.

1. While connected to the vCenter Server Navigate to Home – Inventory – Networking in the vSphere Client and click on the vDS in question.
2. Click on the Ports Tab
3. If all of the ports in the list have a VM associated with it in the “connected”column then this is a positive test.

Deployment scenarios where a very large number of uplinks are teamed together on a single virtual switch might significantly impact the number of  ports on that virtual switch available for virtual machine use, and the overall size of the virtual switch might need to be adjusted accordingly.
 
The current port utilization data for virtual switches can be reviewed by using the esxcfg-vswitch –list command.
 
The current overhead utilization on a given virtual switch can be calculated by subtracting the Used Ports value for all PortGroups from the Used Ports value for that virtual switch.

Recommendation: Use VNDS vNetwork distributed Switches for all Virtual Machine traffic and limit the number of ports assigned to each standard vSwitch used for vmkernel and service console.

Standard vSwitch Procedure:

Note: A server reboot is required to apply the following configuration change.  Migrate the virtual machines off the ESX host to prevent any downtime.   On the vswitch there is an option to specify the number of ports the vswitch supports.  

To view this setting:

  1. Click the Configuration tab of the ESX host in the Virtual Infrastructure Client (VI Client).
  2. Click Networking.
  3. Click Properties.

  4. Click on vSwitch.
  5. Click Edit.

  6. On the General tab select the number of ports you want and click OK.

 

  • Reboot the ESX host for changes to take effect.

    • Reference Links

    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.
    Vmug V Sphere Storage (Rev E)

    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

    Older Posts »

    Powered by WordPress