CLARiiON Integration With VMware ESX Server

Emc Clariion Integration with Vmware Esx Server

http://www.vmware.com/pdf/clariion_wp_eng.pdf

VLAN Configuration on Virtual Switch, Physical Switch, and Virtual Machines

VLAN Configuration on Virtual Switch, Physical Switch, and Virtual Machines

Purpose

This article describes the various VLAN tagging methods used with ESX/ESXi.

Virtual LAN (VLAN) implementation is recommended in ESX/ESXi networking environments because:

• It integrates ESX/ESXi into a pre-existing network
• It secures network traffic
• It reduces network traffic congestion
• iSCSI traffic requires isolated network

Resolution

There are three methods of VLAN tagging that can be configured on ESXi:

• External Switch Tagging (EST)
• Virtual Switch Tagging (VST)
• Virtual Guest Tagging (VGT)

External Switch Tagging

• All VLAN tagging of packets is performed on the physical switch.
• ESX host network adapters are connected to access ports on the physical switch.
• The portroups connected to the virtual switch must have their VLAN ID set to 0.
• For more information, see Sample configuration - ESX/ESXi connecting to physical switch via VLAN access mode and external switch VLAN tagging (EST Mode) (1004127).
• See this example snippet of a code from a Cisco switch port configuration:switchport mode accessswitchport access vlan x

Virtual Switch Tagging

• All VLAN tagging of packets is performed by the virtual switch before leaving the ESX/ESXi host.
• The ESX host network adapters must be connected to trunk ports on the physical switch.
• The portgroups connected to the virtual switch must have an appropriate VLAN ID specified.
• For more information, see Configuring a VLAN on a portgroup (1003825).
• For a sample of VST, see Sample configuration of virtual switch VLAN tagging (VST Mode) (1004074).
• See the following example snippet of code from a Cisco switch port configuration:switchport trunk encapsulation dot1q
  switchport mode trunk
  switchport trunk allowed vlan x,y,zspanning-tree portfast trunk

Note: The Native VLAN is not tagged and thus requires no VLAN ID to be set on the ESX/ESXi portgroup.

Virtual Guest Tagging

• All VLAN tagging is performed by the virtual machine.
• You must install an 802.1Q VLAN trunking driver inside the virtual machine.
• VLAN tags are preserved between the virtual machine networking stack and external switch when frames are passed to/from virtual switches.
• Physical switch ports are set to trunk port.
• For more information, see Sample configuration of virtual machine VLAN tagging (VGT Mode) (1004252).
• See this example snippet of code from a Cisco switch port configuration:switchport trunk encapsulation dot1q
  switchport mode trunk
  switchport trunk allowed vlan x,y,zspanning-tree portfast trunk
  
  

Using vSphere Management Assistant(vMA) to collect ESX and ESXi logs

Purpose

The VMware vSphere Management Assistant (vMA) can be configured to accept logs from your ESX and ESXi host. For more information about downloading, installing, and configuring vMA, see the vSphere Management Assistant Documentation.

Resolution

Configuring your VMware vSphere Management Assistant (vMA) appliance to collect the logs from an ESX/ESXi host:

1. Run this command to add the ESX/ESXi host to the vMA appliance:
   
   # sudo vifp addserver [ESX/ESXi IP or HOSTNAME]
   
   You are prompted for the root password for the target system.
2. Run this command to view the list of ESX/ESXi hosts connected to the vMA appliance.
   
   # sudo vifp listservers
   
3. Run this command to enable the vilogger interface and to configure vMA to collect log files from the target ESX/ESXi or vCenter Server hosts according to the specified log policy:
   # vilogger enable --server [ESX/ESXi IP or HOSTNAME] --numrotation <ROTATION: 1 to 1024> --maxfilesize <SIZE in MB: 1 to 1024> --collectionperiod <PERIOD in seconds: 10 to 3600>
   Where is the ESX/ESXi IP or HOSTNAME  is the IP address or hostname of the ESX/ESXi host.
   
   For example, the command with default values is:
   
   # vilogger enable --server [ESX/ESXi IP or HOSTNAME] --numrotation 5 --maxfilesize 5 --collectionperiod 10

In the vMA 4.x versions, the logs are located at /var/log/vmware. In earlier vMA versions, the logs are located at /var/log/syslog. 

Each host managed by the vMA appliance has a subdirectory within /var/log/vmware. Each of these subdirectories, in turn, contains the log files, such as hostd.log, messages.log, vmkernel.log, vmkwarning.log, and vpxa.log.

To read the log files, you can use commands such as tail -f. For example, to read the contents of the vpxa.log file, run this command:

# tail -f /var/log/vmware/<FQDN of Host>/vpxa.log

To customize the options for the vilogger command, see the vilogger Daemon and Log Management Commands section of the vSphere Management Assistant Guide.

Additional Information

The syntax of the vilogger command is:

vilogger <command>

Where <command> can be one of the following:

• enable         [--server <SERVER>]
                 [--logname <LOGNAME>]
                 [--collectionperiod <PERIOD in seconds: 10 to 3600>]
                 [--numrotation <ROTATION: 1 to 1024>]
                 [--maxfilesize <SIZE in MB: 1 to 1024>]
  
      
• disable        [--server <SERVER>]
                 [--logname <LOGNAME>]
                 [--force]
• list           [--server <SERVER>]
                 [--logname <LOGNAME>]
• updatepolicy   [--server <SERVER>]
                 [--logname <LOGNAME>]
                 [--collectionperiod <PERIOD in seconds: 10 to 3600>]
                 [--numrotation <ROTATION: 1 to 1024>]
                 [--maxfilesize <SIZE in MB: 1 to 1024>]
  
         
• help | --help | -h  [<command name>]

To increase disk space on an installed vMA appliance refer to How to increase/resize vMA Disks.

Cisco plans virtual switch for Hyper-V in Windows Server 8

Cisco is collaborating with Microsoft to bring its virtual switch to Hyper-V next year when Windows Server 8 is released. While Cisco’s Nexus 1000V distributed virtual switch already supports VMware software, Hyper-V in Windows Server 2008 R2 does not get the same love. The new support for Hyper-V will only apply to the forthcoming Windows Server 8, which introduces greater ability to integrate third-party modules than its predecessor, according to Cisco.


Click here for Full Story

Cisco Nexus 1000V Series Switches : Install and Upgrade Guides

http://www.cisco.com/en/US/products/ps9902/prod_installation_guides_list.html

Installing ESXi/ESX 4.1 and vCenter Server 4.1 best practices

Installing ESXi/ESX 4.1 and vCenter Server 4.1 best practices

 This article provides a quick reference to the information needed for a trouble-free installation or upgrade of ESX/ESXi 4.1 and vCenter Server 4.1.

Note: Because each environment is different, many installation decisions require knowledge and understanding beyond the scope of this article. For more detailed information about your installation, see the vSphere 4.1 documentation. 

Resolution

Note: See the VMware vSphere 4.1 Release Notes for known installation issues.

vCenter Server

To ensure a trouble-free installation of vCenter Server:

1. Make sure your hardware and operating system requirements are compliant. The vCenter Server 4.1 system can be a physical or a virtual machine. If you are installing vCenter Server 4.1 in a virtual machine, see Running vCenter Server in a virtual machine (10087) for more information.
   Note: For more information, see ESX and vCenter Server Installation Guide and vSphere Compatibility Matrix. vCenter Server 4.1 requires a 64-bit DSN to function properly.
   
   • Processor – Intel or AMD x86 processor with two or more logical cores, each with a speed of 2GHz.
   • Memory – 3GB RAM. RAM requirements may be higher if your database runs on the same machine. VMware VirtualCenter Management WebServices requires 128MB to 1.5GB of memory which is allocated at startup.
   • Disk storage – 2GB. Disk requirements may be higher if your database runs on the same machine.
   • Microsoft SQL Server 2005 Express disk requirements. The bundled database requires up to 2GB free disk space to decompress the installation archive.
   • Networking – 1Gbit recommended.
      
2. Ensure that your database requirements and patch levels are compliant. For more information, see the vSphere Compatibility Matrix and vCenter Server Database Patch and Configuration Requirements. To use an existing database, you need to provide a 64-bit system DSN that points to the vCenter Server database. You also need to ensure that you have created a full backup of your database before proceeding.  In addition VMware Update Manager 4.1 is still a 32-bit application, and requires a 32-bit DSN to be created.
   Note:
   • Microsoft SQL Server 2005 Express is intended for use with small deployments of up to 5 hosts and/or 50 virtual machines.
   • IBM DB2 database is only supported for vCenter Server. There is no support for Update Manager or any plug-in that requires a database.
     
3. Download and fill out the vCenter Server Installation Worksheet.
   Note: For more information about the fields in this form, see Required Data for Installing vCenter Server in the ESX and vCenter Server Installation Guide.
    
4. The vCenter Server install wizard gives you the option to use the Windows system account or a user-specified account for the purpose of running vCenter Server. A user-specified account enables the use of Windows authentication for SQL Server.
   
   If you choose this option:
   • The user-specified account must be an Administrator on the local machine and act as part of the operating system and log in as a service rights.
   • You must specify the account name as DomainName\Username in the vCenter Server install wizard.
   • You must configure the SQL Server database to allow the domain account access to SQL Server.
      
5. Make sure your operating system meets these requirements:
   Note: vCenter Server 4.1 does not support 32-bit host operating systems. For more information, see the Operating System Compatibility for vSphere Client, vCenter Server, and VMware vCenter Update Manager section of the vSphere Compatibility Matrix.
    
   • Windows XP Pro SP2 (SP2 required, 64-bit)
   • Windows Server 2003 (SP1 required, 64-bit)
   • Windows Server 2008 (64-bit)
   • Windows Server 2008 R2 (64-bit)
      
6. vCenter Server 4.1 installs these components as a part of the installation:
   
   Note: For more information, see the  ESX and vCenter Server Installation Guide.
   
   • Apache Tomcat (64-bit)
   • Java Runtime Environment JRE (64-bit)
   • Active Directory Application Management (ADAM)
   • Visual C++ 2005 Runtime Redistributable
   • .NET 3.0 SP1 or above (optional based on DB selection)
      
7. These items are recommended or necessary for a successful installation:
   • You must have the installation DVD or download the installation ISO image.
   • Your hardware must meet the minimum hardware requirements. For more information, see vCenter Server and vSphere Client Hardware Requirements.
   • Ensure you have the required ports open. For more information, see vCenter Server 4.1 network port requirements (1022256).
   • If the machine on which you are installing vCenter Server has a previous version of vCenter installed, you may want to upgrade instead of performing a fresh installation of vCenter Server.
   • Make sure that the system you use for your vCenter Server installation belongs to a domain rather than a workgroup.
   • Ensure the system on which you are installing vCenter Server is not an Active Directory domain controller.
   • It is critical that you have reliable DNS and Time services.
   • During the installation, the connection between the machine and the domain controller must be working.
   • There must be no Network Address Translation (NAT) between the vCenter Server system and the hosts it manages.
   • The DNS name of the machine must match the actual computer name.
   • Log into the system using an account with local administrator rights. If joining another vCenter Server in Linked Mode, the account must be a local Administrator on both systems, can interact as part of
   • The operating system, and has rights to log on as a service.
   • The computer name cannot be more than 15 characters.
   • Assign a static IP address and host name to the Windows server that will host the vCenter Server system. This IP address must have a valid (internal) DNS registration that resolves properly from all managed ESX hosts.
      
8. Configure your database prior to the vCenter Server install, unless you are using default Microsoft 2005 Express.
   Note: Schema creation scripts mentioned in the documentation for both Microsoft SQL and Oracle are optional and intended for experienced Database Administrators. The vCenter Server installer performs the schema creation automatically if one does not already exist.
   • Microsoft SQL Database:
     • As the Database Administrator, use a script to create a local or remote Microsoft SQL Server Database. Optionally, the database can be created as it was in vCenter 2.5 by using SQL Server Management Studio.
     • Configure a SQL Server ODBC Connection. When you install the vCenter Server system, you can establish a connection with a SQL Server database.
     • Configure Microsoft SQL Server TCP/IP for JDBC. If the Microsoft SQL Server database has TCP/IP disabled and the dynamic ports are not set, the JDBC connection remains closed. This causes the vCenter Server statistics to malfunction.
        
   • Oracle Database:
     • As the Database Administrator, use a script to create a local or remote Oracle database.
     • Configure an Oracle Database User. If you plan to use an Oracle database when you install vCenter Server, you must configure the database user.
     • Configure an Oracle Connection for Local Access or Configure an Oracle Connection for Remote Access depending on where the database is located.
     • Connect to an Oracle Database locally.
        
   • DB2 Database:
     • Configure an IBM DB2 Database User and Group. If you plan to use an IBM DB2 database when you install vCenter Server, you must configure the database user and group.
     • Use a Script to Create a DB2 Database. When you use a DB2 database with vCenter Server, the database must have certain buffer pools, table spaces, and privileges.
     • Use a Script to Create the DB2 Database Schema. This script, in conjunction with the script that creates the DB2 database, enables you to have tighter control over the parameters of your database.
     • Configure a Connection to a Local Database on Windows. You can configure a DB2 database for vCenter Server either locally on the same Windows machine as vCenter Server or remotely on a network-connected host.
     • Configure a Connection to a Remote Database on Linux, Unix or Windows. You can configure a DB2 database for vCenter Server either locally on the same Windows machine as vCenter Server or remotely on a network-connected Windows, Linux, or Unix host.
        
9. VMware recommends using a separate database for vCenter Server and vCenter Update Manager.
10. Run the vCenter Server installer using the vCenter Server Installation Worksheet filled out in step 3. 

Update Manager
You can run the Update Manager on any system that meets the minimum hardware requirements. Minimum hardware requirements for Update Manager vary depending on how the Update Manager is deployed. If the database is installed on the same machine as Update Manager, requirements for memory size and processor speed are higher. To ensure acceptable performance, make sure that you meet the minimum requirements.

• The minimum hardware requirements are as follows:
  • Processor – Intel or AMD x86 processor with two or more logical cores, each with a speed of  2GHz.
  • Network – 10/100 Mbps. (For best performance, use a Gigabit connection between Update Manager and the ESX/ESXi)
  • Memory – 2GB RAM if Update Manager and vCenter Server are on different machines.
  • Memory – 4GB RAM if Update Manager and vCenter Server are on the same machine.
    Note: Update Manager uses a SQL Server or Oracle database. You should use a dedicated database for Update Manager and not share it with the database used with vCenter Server, and should back up the database periodically.  Best practice is to have the database on the same computer as Update Manager or on a computer in the local network.  Depending on the size of your deployment, Update Manager requires a minimum amount of free space per month for database usage. For more information about space requirements, see the VMware vCenter Update Manager Sizing Estimator.
    
• Update Manager works only with these operating systems:
  • Windows XP Pro SP2 (SP2 required, 64-bit)
  • Windows Server 2003 (SP1 required, 64-bit)
  • Windows Server 2008 (64-bit)
  • Windows Server 2008 R2 (64-bit)
    Note: The Update Manager plug-in requires the vSphere Client, and works with the same operating systems as the vSphere Client.
    IMPORTANT: You can only install Update Manager 4.1 on a 64-bit machine.
    
• Update Manager has specific database requirements:
  Note: Update Manager can handle small-scale environments using the bundled SQL Server 2005 Express. For environments with more than 5 hosts and 50 virtual machines, create either an Oracle or a SQL Server database for Update Manager. For large scale environments, set up the Update Manager database on a different computer other than the Update Manager server and the vCenter Server database.
  • SQL Server 2005
  • SQL Server 2008
  • Oracle 10g
  • Oracle 11g
    Note: Update Manager 4.1 is compatible only with vCenter Server 4.1. Although multiple versions of the Update Manager Client plug-in might coexist on the same computer, the Update Manager Client plug-in of version 4.1 can be installed and enabled only on vSphere Client 4.1. For more information about the Update Manager compatibility with VirtualCenter Server, vCenter Server, VI Client, and vSphere Client, see the vSphere Compatibility Matrixes.
    
• Required data privileges to the database:
  
  Note: Before you install or upgrade Update Manager, you must create a database and grant a specific list of permissions to the database user. To run Update Manager you can use a set of minimum privileges.
  • Oracle Database Support
    Either assign the DBA role, or grant this set of privileges to the Update Manager Oracle database user:
    • connect
    • execute on dbms_lock
    • create view
    • create procedure
    • create table
    • create sequence
    • create any sequence
    • create any table
    • create type
    • unlimited tablespace
      
  • Microsoft SQL server Database Support
    • Make sure that the database user has either a sysadmin server role or the db_owner fixed database role on the Update Manager database and the MSDB database. Although the db_owner role is required for the upgrade, SQL jobs are not created as part of the Update Manager installation or upgrade.
      
• Database privileges needed for using Update Manager:
  • Oracle
    
    The minimum required privileges of the Oracle database user are:
    • create session
    • create any table
    • drop any table 
      
  • Microsoft SQL Server
    
    The database user must have either a sysadmin server role or the db_owner fixed database role on the Update Manager database and the MSDB database.
    
    Note: You can install or upgrade the Update Manager server on 64-bit operating systems. Even though Update Manager runs on 64-bit operating systems, it is a 32-bit application and requires a 32-bit DSN. The requirement for a 32-bit DSN applies to all supported databases. By default, any DSN created on a 64-bit system is a 64-bit DSN.
    
• Install the ODBC drivers.
  • For Microsoft SQL Server database servers, install the 64-bit database ODBC drivers on your  Microsoft Windows system. When you install the 64-bit drivers, the 32-bit drivers are installed automatically.
  • For Oracle database servers, install the 32-bit database ODBC drivers on your Microsoft Windows system.
  • Run the 32-bit ODBC Administrator application, located at [WindowsDir]\SysWOW64\odbcad32.exe.
  • Use the application to create your DSN.  You will now have a DSN that is compatible with the Update Manager server. When the Update Manager installer prompts you for a DSN, you should select the 32-bit DSN.
    
    Note: The Microsoft SQL Server 2005 Express database package is installed and configured when you select Microsoft SQL Server 2005 Express as your database during the VMware vCenter Update Manager installation or upgrade. No additional configuration is required.  

ESX/ESXi

To ensure a trouble free installation of ESX/ESXi:

1. Make sure your hardware is compliant on the Hardware Compatibility Guide. This includes:
   • System compatibility
   • I/O compatibility (Network and HBA cards)
   • Storage compatibility
   • Backup software compatibility
      
2. VMware ESX/ESXi 4.1 only installs and runs on servers with 64-bit x86 CPUs. 32-bit systems are no longer supported.
3. Make sure Intel VT is enabled in the host's BIOS.
4. If you are installing ESX/ESXi on the local disks and if a fibre attached SAN is connected to the ESX/ESXi host, detach the fibre before proceeding with the installation. If you do not disconnect the fibre, you may inadvertently choose an HBA Adapter as the primary boot partition, which may result in the loss of data on the LUNs attached to the HBA Adapter.
   Note: Do not disable HBA cards in the BIOS.
    
5. The /, swap, and all the optional partitions are stored on a virtual disk called esxconsole-<UUID>.vmdk. Set a size minimum of 8GB for this virtual disk.
   
   Note: For /var/log, VMware recommends a separate partition to prevent unexpected disk space constraints due to extensive logging.

Note: For more information, see ESX and vCenter Server Installation Guide.

Additional Information

For related information, see Upgrading to ESX 4.1 and vCenter 4.1 best practices (1022104).

Tags

install-esx  install-vcenter  install-esxi

See Also

• Running vCenter Server in a virtual machine
• Upgrading to ESX 4.1 and vCenter Server 4.1 best practices
• vCenter Server 4.1 network port requirements
• Recomendaciones para instalar ESX 4.1 / ESXi 4.1 y vCenter Server 4.1

 

Microsoft's Hyper-V R2 vs. VMware's vSphere: A feature comparison

By Scott Lowe

Takeaway: VMware and Microsoft are ramping up their virtualization games with relatively new releases. Scott Lowe compares and contrasts some of the major features in vSphere and Hyper-V R2.

Microsoft was late to the virtualization game, but the company has made gains against its primary competitor in the virtualization marketplace, VMware. In recent months, both companies released major updates to their respective hypervisors: Microsoft’s Hyper-V R2 and VMware’s vSphere. In this look at the hypervisor products from both companies, I’ll compare and contrast some of the products’ more common features and capabilities. I do not, however, make recommendations about which product might be right for your organization.

Table A compares items in four editions of vSphere and three available editions of Hyper-V R2. Below the table, I explain each of the comparison items. (Product note: With the release of vSphere, VMware has released an Enterprise Plus edition of its hypervisor product. Enterprise Plus provides an expanded set of capabilities that were not present in older product versions. Customers have to upgrade from Enterprise to Enterprise Plus in order to obtain these capabilities.)

Table A

Click the image to enlarge.

Max host processors. Indicates the number of physical host processors that can be recognized by the system. Bear in mind that the Windows columns are Windows limits and not necessarily Hyper-V limits.

Max cores/processor. How many processor cores per physical processor are recognized?

Max virtual SMP. In an individual virtual machine, this indicates the maximum number of supported virtual processors. Note: This is a maximum value; not every guest operating system can support the maximum number of virtual processors.

Max host RAM (GB). The maximum amount of RAM recognized by the hypervisor.

Max RAM/vm. The maximum amount of RAM that can be allocated to an individual virtual machine.

Failover nodes. The maximum number of physical hosts that can be clustered together. N/A indicates that failover clustering is not supported for that particular hypervisor edition.

Memory overcommit. Does the hypervisor support memory overcommit? Memory overcommitment is a technique available in vSphere that allows administrators to allocate more RAM to virtual machines than is physically available in the host. There are numerous pro and conarticles about this topic, but it’s clear that having the ability to allocate more resources than are physically available increases overall virtual machine density. The decision to use memory overcommit in a production environment is up to each organization. That said, in my opinion, when used in the right circumstances, I can see great benefit in this feature.

Transparent page sharing. Transparent page sharing is one method by which memory overcommitment is achieved. With this technique, common code shared between virtual machines is, itself, virtualized. Let’s say that you have 100 virtual machines running Windows XP for VDI. Using transparent page sharing, RAM isn’t necessarily a major limiting factor when it comes to desktop density on the server. VMware has an excellent example of this technique in action.

Live Migration/VMotion. The ability for the hypervisor to migrate virtual machines between host servers without significant downtime. This is considered one of the most significant availability benefits provided by virtualization solutions.

Simultaneous Live Migration. Can the product utilize its Live Migration capabilities to move multiple virtual machines simultaneously between nodes?

Live guests per host. The number of virtual machines that can be powered on for a maxed-out host. In the real world, I’d be extraordinarily surprised to see anyone getting close to these limits. Virtualization is a great way to lower costs, but there are limits.

Live guests/HA cluster node. If you’re running your hypervisor in a cluster, this is the maximum number of virtual machines that can be active on any single host in the cluster. For vSphere with update 1, if you have eight or fewer cluster hosts, you can run up to 160 VMs per host. With nine or more cluster hosts, that number drops to 40.

Distributed Resource Scheduler. DRS is a technology that enables the migration of virtual machines between hosts based on business rules. This can be a boon for organizations with strict SLAs.

Snapshots per VM. The maximum number of snapshots that can be taken of an individual virtual machine. A snapshot is a point-in-time image of a virtual machine that can be used as part of a backup and recovery mechanism. I find snapshots incredibly useful, particularly on the workstation side of the equation, where a lot of “playing” takes place.

Thin Provisioning. One decision that has to be made early on in the life of any server (virtual or physical) is how much storage to allocate to the system. Too much storage and you waste valuable disk space — too little storage and services crash. In order to maintain reliable services, most IT shops overprovision storage to make sure that it doesn’t run out; but that conservatism adds up over time. Imagine if you have 100 VMs all with 4 or 5 GB of “wiggle room” going unused. With thin provisioning, you can have the best of both worlds. You can provision enough disk space to meet your comfort level, but under the hood, the hypervisor won’t allocate it all. As space begins to run low, the hypervisor will make more space available up to the maximum volume size. Although thin provisioning shouldn’t be used for massive workloads, it can be a huge boon to organizations that want conservatism without breaking the bank.

Storage Live Migration. This feature enables the live migration of a virtual machine’s disk files between storage arrays and adds an additional level of availability potential to a virtual environment.

Distributed Switch. VMware and Microsoft have virtual switches in their products, but only VMware has taken it one step further with the introduction of vSphere Enterprise Plus’ Distributed Switch. According to VMware, “Distributed Switch maintains network runtime state for VMs as they move across multiple hosts, enabling inline monitoring and centralized firewall services. It provides a framework for monitoring and maintaining the security of virtual machines as they move from physical server to physical server and enables the use of third party virtual switches such as the Cisco Nexus 1000V to extend familiar physical network features and controls to virtual networks.” In short, this new capability increases VMware’s availability and security capabilities.

Direct I/O. The ability for a virtual machine to bypass the hypervisor layer and directly access a physical I/O hardware device. There is limited support for this capability in vSphere; the product supports direct I/O operations to a few storage and networking controllers. Called VMDirectPath I/O, this feature can improve overall performance since it eliminates the “virtualization penalty” that can take place when hardware access is run through the hypervisor. There are some major disadvantages to VMDirectPath; for example, VMotion can’t work anymore because of the hardware need. (Note: This feature is different than direct access to disks, which Hyper-V does support.)

Max. partition size (TB). What is the largest partition supported by the hypervisor? Although VHD-based volumes, such as those used by Hyper-V R2, can be up to 2 TB in size, read this blog by Brian Henderson for insight into maximum Windows partition sizes, particularly if you bypass the VHD option altogether and use disks directly.

Application firewall (vShield). According to VMware “VMware vShield Zones enables you to monitor, log and block inter-VM traffic within an ESX host or between hosts in a cluster, without having to divert traffic externally through static physical chokepoints. You can bridge, firewall, or isolate virtual machine between multiple zones defined by your logical organizational and trust boundaries. Both allowed and blocked activities are logged and can be graphed or analyzed to a fine-grained level.” In other words, you don’t need to run traffic through external switches and routers to protect applications from one another.

Virtual instance rights. This is a Microsoft-only right that can seriously lower the overall cost of running Hyper-V R2 in a Windows-only environment. If you use the Data Center edition of Windows, you can run as many Windows Server-based virtual machines as you like without incurring additional sever licensing costs.

Hypervisor licensing. The method by which the product is licensed. Either per host or per processor.

My school’s hypervisor of choice

At Westminster College, we continue to run VMware for its virtualization services. Why? Mainly because it’s tried and true. That said, budget pressure forces us to constantly reevaluate services and priorities. VMware’s total cost is beginning to become more of an issue. As Microsoft continues to improve Hyper-V R2, we will monitor its progress to determine if and when it might be able to replace VMware, although a possible investment in VMware’s VDI product might lock us into VMware for the long haul.

I like VMware’s memory overcommitment capabilities and believe that, if used right, the feature can be a boon when it comes to density, particularly as we look at virtualizing desktop computers. On the other hand, for very Microsoft-centric organizations, Hyper-V R2 makes Microsoft’s hypervisor offering extremely compelling.

VMware vs. Red Hat: Whose PaaS will rule?

VMware vs. Red Hat: Whose PaaS will rule?

2011

In this week's episode of Cloud Cover TV, the PaaS Master at Red Hat talks about why his company has better credentials than VMware for the Platform as a Service game.

We discuss:

• The differences between Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) at Red Hat
• Where are the enterprise developers on PaaS?
• What applications are being developed on PaaS?
• Red Hat OpenShift versus VMware Cloud Foundry
• Owning the whole cloud stack
• Microsoft's advantage in the cloud platform world