EMC and VMware Deliver Service Assurance for Virtual Data Centers
Register Now<https://emcinformation.com/72105/REG/.ashx?reg_src=WEB>
Date:
Jul 24, 12
Time:
11:00 AM - 12:00 PM EDT (Set Time Zone)
Event Type:
EMC Live Webcast
Category:
Virtualization
Location:
Online
Details:
Join us for this informative live webcast to understand how EMC and VMware Operations Management Suite for Virtual Data Center environments can help you deliver new services quickly and reliably, identify and resolve problems before service impact, and improve operational efficiency.
Register to learn how Operations Management Suite for Virtual Data Center can help you:
* Resolve problems 80% faster
* Ensure maximum service uptime, and
* Achieve a 2 times improvement in operational efficiency
________________________________
Original Page: http://www.emc.com/events/2012/q3/07-24-12-emc-and-vmware-deliver-service-assurance-for-vdcs.htm?CMP=RSS-events
Thursday, 28 June 2012
Performance Study of Oracle RAC on VMware vSphere 5.0 - Eric Sloof
IT organizations that have implemented Oracle Real Application Clusters (RAC) often use RAC to support critical functions of their business. Performance of these database clusters is key to enabling IT organizations to meet the requirements of their businesses, customers, and shareholders.
VMware vSphere provides a high performance virtualization platform that is capable of hosting the most critical portions of infrastructure, including Oracle RAC databases. vSphere 5 has increased these capabilities, including support for virtual machines with up to 32 vCPUs and 1TB of RAM. This support for larger virtual machines (VMs) combined with vSphere's high performance capabilities makes vSphere a great platform for running large Oracle RAC database clusters.
EMC IT has implemented vSphere throughout many parts of their infrastructure and is now in the process of moving the largest and most critical applications to vSphere. EMC and VMware worked together to evaluate the performance of one of EMC's largest Oracle RAC databases on vSphere 5. A copy of this database was used to conduct a series of tests to compare physical performance versus virtual performance.
This testing, which was done with an Oracle RAC cluster made up of six 32-CPU-based nodes, four of them virtual and two of them physical, found that virtual performed within 12% of native and was acceptable to be used for the production instance. EMC IT plans to adopt this virtual configuration in its next refresh cycle.
http://www.vmware.com/files/pdf/techpaper/OracleRAC-perf-vSphere5.pdf
feedproxy.google.com [cid:/images/orig-link.png] <http://feedproxy.google.com/~r/Ntpronl/~3/ZhZzOGu7CPo/2076-Performance-Study-of-Oracle-RAC-on-VMware-vSphere-5.0.html>
VMware vSphere provides a high performance virtualization platform that is capable of hosting the most critical portions of infrastructure, including Oracle RAC databases. vSphere 5 has increased these capabilities, including support for virtual machines with up to 32 vCPUs and 1TB of RAM. This support for larger virtual machines (VMs) combined with vSphere's high performance capabilities makes vSphere a great platform for running large Oracle RAC database clusters.
EMC IT has implemented vSphere throughout many parts of their infrastructure and is now in the process of moving the largest and most critical applications to vSphere. EMC and VMware worked together to evaluate the performance of one of EMC's largest Oracle RAC databases on vSphere 5. A copy of this database was used to conduct a series of tests to compare physical performance versus virtual performance.
This testing, which was done with an Oracle RAC cluster made up of six 32-CPU-based nodes, four of them virtual and two of them physical, found that virtual performed within 12% of native and was acceptable to be used for the production instance. EMC IT plans to adopt this virtual configuration in its next refresh cycle.
http://www.vmware.com/files/pdf/techpaper/OracleRAC-perf-vSphere5.pdf
feedproxy.google.com [cid:/images/orig-link.png] <http://feedproxy.google.com/~r/Ntpronl/~3/ZhZzOGu7CPo/2076-Performance-Study-of-Oracle-RAC-on-VMware-vSphere-5.0.html>
Monday, 25 June 2012
VMware: VMware vSphere Blog: How to use Port-Mirroring feature of VDS for monitoring virtual machine traffic?
I would like to clarify few things in this blog entry about the Port-mirroring feature that is available on vSphere Distributed Switch (VDS). This feature is similar to the port mirroring capability available on the physical switches. Network administrators can use this feature to troubleshoot any network related issues in the virtual infrastructure and monitor virtual machine to virtual machine traffic that is flowing on the same ESXi host. Network administrators use network analyzer tool, which captures traffic, along with the port mirror feature to perform monitoring and troubleshooting activities. In the physical network, depending on where the analyzer or debug tool is placed in the network, network administrators choose different port mirroring options. The following are some of the standard port mirroring options available on physical switches:
- Switch Port Analyzer (SPAN)
- Remote Switch Port Analyzer (RSPAN)
- Encapsulated Remote Switch Port Analyzer (ERSPAN)
SPAN feature is local to the switch and requires the monitored ports and the destination port are on the same switch. With the release of vSphere 5.0, VMware provides support for only SPAN feature on VDS. The following blog entry<http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-port-mirroring.html> discusses the feature in little more detail. During the setup of a SPAN session customers have to select a virtual port that needs monitoring and then choose a destination virtual port where all the traffic will be mirrored. Here are some of the common monitoring and troubleshooting use cases based on where the analyzer tool is running.
1) Mirroring to an analyzer tool running in a virtual machine on the same host.
As shown in the figure below, you can have a virtual machine run analyzer tool. In such scenario you have to configure the pot mirror session with source as virtual port of the monitored virtual machine and destination as the virtual port of the virtual machine running analyzer tool.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-pi>
2) Mirroring to an external physical analyzer connected directly to the uplink port of the host.
In this case the analyzer tool is running on an external physical device, which is directly connected to the host through a NIC. As shown in the figure below, the source virtual port of the port mirror session remains same but the destination is changed to the uplink port connected to vmnic1. The mirror packets are sent through the vmnic1 to the analyzer device for monitoring.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-pi>
3) Mirroring to an external physical analyzer connected to a physical switch where the host is also connected.
This setup is possible provided you configure a SPAN session on the VDS and physical switch as well. Let's dig a little more here. As mentioned earlier, SPAN feature is local to a switch and requires both monitored and destination ports on the same switch. If you look at the diagram below, the analyzer is not directly connected to the VDS. It is connected through a physical switch. So this is not a straightforward use case 2.
Let's take a look at the mirror packet flow. The port mirror session is configured on the VDS with the virtual port of the monitored virtual machine as the source and uplink connected to vmnic 1 as the destination. All packets flowing through the monitored virtual machine are now copied through the vmnic1 to the physical switch port. On the same physical switch the analyzer is connected to a different port. The analyzer connected to a port on the same switch is not going to see the traffic mirrored by VDS. For this use case to work, it is not enough to configure the port mirror session on VDS. You have to configure SPAN session on the physical switch with the switch port where the host's vmnic 1 is connected is the monitored port and the destination port is where the analyzer is connected.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-pi>
VDS currently doesn't support RSPAN capability, which allows network administrators to monitor the traffic remotely multiple hops away from the source. Customers have to create a dedicated VLAN to carry the RSPAN traffic and the switches supporting RSPAN feature have to encapsulate all the monitored traffic in this special VLAN.
There is also some confusion because of the GUI screen options provided during the port mirroring setup on VDS.
If you take a look at the configuration screen shown below, there is an encapsulation option shown in the red box. This encapsulation option gives the feeling that RSPAN is supported. However, it is not and you shouldn't configure this parameter.
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-pi>
________________________________
Original Page: http://blogs.vmware.com/vsphere/2012/06/how-to-use-port-mirroring-feature-of-vds-for-monitoring-virtual-machine-traffic.html
- Switch Port Analyzer (SPAN)
- Remote Switch Port Analyzer (RSPAN)
- Encapsulated Remote Switch Port Analyzer (ERSPAN)
SPAN feature is local to the switch and requires the monitored ports and the destination port are on the same switch. With the release of vSphere 5.0, VMware provides support for only SPAN feature on VDS. The following blog entry<http://blogs.vmware.com/networking/2011/08/vsphere-5-new-networking-features-port-mirroring.html> discusses the feature in little more detail. During the setup of a SPAN session customers have to select a virtual port that needs monitoring and then choose a destination virtual port where all the traffic will be mirrored. Here are some of the common monitoring and troubleshooting use cases based on where the analyzer tool is running.
1) Mirroring to an analyzer tool running in a virtual machine on the same host.
As shown in the figure below, you can have a virtual machine run analyzer tool. In such scenario you have to configure the pot mirror session with source as virtual port of the monitored virtual machine and destination as the virtual port of the virtual machine running analyzer tool.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b7115c970d-pi>
2) Mirroring to an external physical analyzer connected directly to the uplink port of the host.
In this case the analyzer tool is running on an external physical device, which is directly connected to the host through a NIC. As shown in the figure below, the source virtual port of the port mirror session remains same but the destination is changed to the uplink port connected to vmnic1. The mirror packets are sent through the vmnic1 to the analyzer device for monitoring.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b71202970d-pi>
3) Mirroring to an external physical analyzer connected to a physical switch where the host is also connected.
This setup is possible provided you configure a SPAN session on the VDS and physical switch as well. Let's dig a little more here. As mentioned earlier, SPAN feature is local to a switch and requires both monitored and destination ports on the same switch. If you look at the diagram below, the analyzer is not directly connected to the VDS. It is connected through a physical switch. So this is not a straightforward use case 2.
Let's take a look at the mirror packet flow. The port mirror session is configured on the VDS with the virtual port of the monitored virtual machine as the source and uplink connected to vmnic 1 as the destination. All packets flowing through the monitored virtual machine are now copied through the vmnic1 to the physical switch port. On the same physical switch the analyzer is connected to a different port. The analyzer connected to a port on the same switch is not going to see the traffic mirrored by VDS. For this use case to work, it is not enough to configure the port mirror session on VDS. You have to configure SPAN session on the physical switch with the switch port where the host's vmnic 1 is connected is the monitored port and the destination port is where the analyzer is connected.
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d155a1970c-pi>
VDS currently doesn't support RSPAN capability, which allows network administrators to monitor the traffic remotely multiple hops away from the source. Customers have to create a dedicated VLAN to carry the RSPAN traffic and the switches supporting RSPAN feature have to encapsulate all the monitored traffic in this special VLAN.
There is also some confusion because of the GUI screen options provided during the port mirroring setup on VDS.
If you take a look at the configuration screen shown below, there is an encapsulation option shown in the red box. This encapsulation option gives the feeling that RSPAN is supported. However, it is not and you shouldn't configure this parameter.
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dc0cc3970b-pi>
________________________________
Original Page: http://blogs.vmware.com/vsphere/2012/06/how-to-use-port-mirroring-feature-of-vds-for-monitoring-virtual-machine-traffic.html
VMware: VMware vSphere Blog: Multi-disk replication into common directory with vSphere Replication
When replicating VMs with vSphere Replication you have control over the target location for your VMDKs that are being replicated. For example, you may have a VM with two disks and choose to place them in different directories and locations than they were in the primary site from which they are being copied.
That's great, but something that never came up with array replication is what happens when we want to put all the disks in the *same* directory at the recovery site?
If we have a machine ("VM1") that has 2 VMDKs each on different datastores, for example, they might both be named the same. We might have two "VM1.vmdk" files. In fact, this happens by default - the first disk in a directory is named for the parent VM without consideration for the fact that there may be other VMs elsewhere on different disks.
Disk one:
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-pi>
Looks a lot like disk 2:
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-pi>
Obviously attempting to replicate these VMs into a single directory on the same datastore will cause difficulty on the recovery site. We can't have more than one VMDK of a particular name in a directory.
vSphere Replication is smart - it will detect that an existing disk is in that directory, but it is not so smart that it understands what it is. It assumes very smartly that this is a seed disk you have copied in via sneakernet. If you've got this far with a multi-disk VM, don't choose this option, or you'll use the 'first' disk as a seed and it will do a full synch of the second disk against it, overwriting it!
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-pi>
What are the options? Well first, you can get to the CLI and use vmkfstools to detach, rename, and re-attach the disk then replicate to your heart's content.
Another idea is to create folders for these disks and populate them into unique folders. I.e. "VM1" is the main folder and within it there will be the VMX and all other items and sundry for a VM. In your other directories (such as "OS Disk" and "Data Disk") you can replicate the individual VMDKs. Each directory will then contain a unique but homonymous named "vm1.vmdk".
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-pi>
Set your VR target per-disk, and choose the appropriate directory at the recovery site by selecting to "specify datastore folder". This keeps your data separate, retains easy management and the ability to identify a VMDK by function easily, as well as giving you the freedom to use separate data stores at the source and single data stores at the recovery site.
Original Post by Ken Werneburg
Original Page: http://blogs.vmware.com/vsphere/2012/06/multidisk-replication.html
That's great, but something that never came up with array replication is what happens when we want to put all the disks in the *same* directory at the recovery site?
If we have a machine ("VM1") that has 2 VMDKs each on different datastores, for example, they might both be named the same. We might have two "VM1.vmdk" files. In fact, this happens by default - the first disk in a directory is named for the parent VM without consideration for the fact that there may be other VMs elsewhere on different disks.
Disk one:
[http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef016767dbd1fb970b-pi>
Looks a lot like disk 2:
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6d8ae970d-pi>
Obviously attempting to replicate these VMs into a single directory on the same datastore will cause difficulty on the recovery site. We can't have more than one VMDK of a particular name in a directory.
vSphere Replication is smart - it will detect that an existing disk is in that directory, but it is not so smart that it understands what it is. It assumes very smartly that this is a seed disk you have copied in via sneakernet. If you've got this far with a multi-disk VM, don't choose this option, or you'll use the 'first' disk as a seed and it will do a full synch of the second disk against it, overwriting it!
[http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017615d1212c970c-pi>
What are the options? Well first, you can get to the CLI and use vmkfstools to detach, rename, and re-attach the disk then replicate to your heart's content.
Another idea is to create folders for these disks and populate them into unique folders. I.e. "VM1" is the main folder and within it there will be the VMX and all other items and sundry for a VM. In your other directories (such as "OS Disk" and "Data Disk") you can replicate the individual VMDKs. Each directory will then contain a unique but homonymous named "vm1.vmdk".
[http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-500wi]<http://blogs.vmware.com/.a/6a00d8341c328153ef017742b6daa3970d-pi>
Set your VR target per-disk, and choose the appropriate directory at the recovery site by selecting to "specify datastore folder". This keeps your data separate, retains easy management and the ability to identify a VMDK by function easily, as well as giving you the freedom to use separate data stores at the source and single data stores at the recovery site.
Original Post by Ken Werneburg
Original Page: http://blogs.vmware.com/vsphere/2012/06/multidisk-replication.html
Wednesday, 20 June 2012
Tuesday, 19 June 2012
Performance of vCenter 5.0 in ROBO environments white paper released
by Duncan Epping
I just finished reading the "Performance of VMware vCenter 5.0 in remote offices and branch offices (ROBO)" white paper. I thought it was an excellent read and recommend it to anyone who has a ROBO environment. Also it is interesting to know what kind of traffic hosts / VMs drive in general to vCenter. Especially the details around the statistics level are worth reading for those deploying larger environments as it also gives a sense of the amount of data that vCenter is processing.
Nice work Fei Chen! You can find the paper here:
Performance of VMware vCenter 5.0 in Remote Offices and Branch Offices (ROBO)
<http://www.vmware.com/resources/techresources/10165>This document details the performance of typical vCenter 5.0 operations in a use case where vCenter manages ESXi hosts over a network with limited bandwidth and high latency, which is also known as a remote office, branch office (ROBO) environment.
(Although the date stamp on this entry says 2010 it is a June / 2012 paper, I will try to get this fixed!
________________________________
Original Page: http://feedproxy.google.com/~r/YellowBricks/~3/jw6HFBeViHo/
I just finished reading the "Performance of VMware vCenter 5.0 in remote offices and branch offices (ROBO)" white paper. I thought it was an excellent read and recommend it to anyone who has a ROBO environment. Also it is interesting to know what kind of traffic hosts / VMs drive in general to vCenter. Especially the details around the statistics level are worth reading for those deploying larger environments as it also gives a sense of the amount of data that vCenter is processing.
Nice work Fei Chen! You can find the paper here:
Performance of VMware vCenter 5.0 in Remote Offices and Branch Offices (ROBO)
<http://www.vmware.com/resources/techresources/10165>This document details the performance of typical vCenter 5.0 operations in a use case where vCenter manages ESXi hosts over a network with limited bandwidth and high latency, which is also known as a remote office, branch office (ROBO) environment.
(Although the date stamp on this entry says 2010 it is a June / 2012 paper, I will try to get this fixed!
________________________________
Original Page: http://feedproxy.google.com/~r/YellowBricks/~3/jw6HFBeViHo/
Friday, 15 June 2012
VMware Labs presents its latest fling - ThinApp Factory - Eric Sloof
The ThinApp Factory is a virtual appliance that brings centralized administration and automation to the process of creating virtualized Windows applications with VMware ThinApp technology. ThinApp Factory utilizes vSphere API's to spawn workloads which automatically convert fileshares of application installers into ThinApp application containers. These workloads can be run in parellel to maximize throughput and increase ROI for virtualization projects. Packagers and administrators can now utilize 'Recipes' during this packaging process. Recipes are simply small json files which contain a redistributable blueprint of the customizations and optimizations necessary for packaging complex applications. These recipes can be created and now exchanged freely with other customers via the ThinApp community site<http://labs.vmware.com/flings/ThinApp%20Community%20Site%20above%20to%20http://communities.vmware.com/thinap.jspa>.
Key Features
* Automates packaging of application installers into virtualized Windows applications.
* Leverages vSphere, vCenter for automation of workloads to efficiently package 1000's of applications.
* Provides and utilizes 'Recipes' as redistributable blueprints for application packaging.
* Provides a lightweight web UI with a dashboard for administrators to use for the entire workflow of packaging to distribution.
* Enables administrators to import and edit existing ThinApp projects and modify package.ini, registry, and file settings through the web UI.
* Integration with Horizon Application Manager application catalog for automated population of application metadata and deployment with the Horizon ThinApp Agent.
________________________________
Original Page: http://feedproxy.google.com/~r/Ntpronl/~3/Y_8QDnLUAEs/2071-VMware-Labs-presents-its-latest-fling-ThinApp-Factory.html
Key Features
* Automates packaging of application installers into virtualized Windows applications.
* Leverages vSphere, vCenter for automation of workloads to efficiently package 1000's of applications.
* Provides and utilizes 'Recipes' as redistributable blueprints for application packaging.
* Provides a lightweight web UI with a dashboard for administrators to use for the entire workflow of packaging to distribution.
* Enables administrators to import and edit existing ThinApp projects and modify package.ini, registry, and file settings through the web UI.
* Integration with Horizon Application Manager application catalog for automated population of application metadata and deployment with the Horizon ThinApp Agent.
________________________________
Original Page: http://feedproxy.google.com/~r/Ntpronl/~3/Y_8QDnLUAEs/2071-VMware-Labs-presents-its-latest-fling-ThinApp-Factory.html
Subscribe to:
Posts (Atom)