The IBM x3950 M2 provide with scalable version on 1TB of memory and maximum of 96 cores. The concept of doing this is basically scale as on demand. Each of the X3950 M2 is contained 4 physical CPU sockets which support up to current 6 cores processors from Intel and 256GB of physical memory. The chassis itself allow for further expansion of 3 additional of X3950 M2, and able to combine the resources in term of CPU, Memory and I/O module to become single host. Why is scale on demand? The answer is simple, as you start with 1, and scale to 4. When you scale the machine, it scale the I/O, processing power, and total number of memory, still you are managing single host. As HA/DRS is always important to us, you may end up which only require to manage 2 ESX host from the virtual center with this design. If we compare with the traditional way we manage the ESX host, we might end up managing 8 different ESX host. Of course, there are always pros and cons, but I still think that this idea is not bad as we may looking at virtualizing some powerful machine in the future, which you may require more processors and memory per VM. Personally, I am aiming to even run the heavy database environment in a virtual mode as the reason of doing this is not cost but is the important and flexibility we gain from Virtualization Vs Physical Environment always. At the same time, the competition between Intel and AMD had drive the processors power to be increased to the level that we may not able to fully utilize it in 90% of the environment we have today, except Virtualization. VMware is going to support 256GB per VM in the next release. It will not surprise to have such powerful machine like IBM to provide the resources to those who may require having it. Again, this is quite similar to the Z system as IBM is working on SUSE Linux installable on Z system, and able to provision the Xen’s VM to achieve 1:100 easily( This had been communicated by Novell during the seminar in town previously ). Now we may able to do the same for x86 platform and will be interesting to see whether this concept will be another next hot item to the market.
I may think the combination of IBM X3950 M2 with Xsigo Virtual I/O director will be something as perfect match for massive performance and volume for Virtualization. Of course, I believe the cost of this will require additional consideration for us to proceed further.

Many enterprise who have implemented virtual environments as a way to consolidate servers and centralize management are running may facing I/O bottleneck issue. No matter how many servers, switches, SAN storage or operating systems that you have, you’re still require to go through IO device.

Imaging you are running on multiple VMware ESX hosts that have more than 10 nics and multiple HBA cards each. How do you going to manage your cabling? How many network switches or port require? What is the costs? What is the maximum I/O you can get? Now Xsigo can help you on virtualization I/O.

What is Virtualization I/O? As I/O today is specify on storage and network throughputs. In most cases, we used to manage with seperate environment for Storage connectivities and Network connectivities. Therefore, we will have HBA FC connection as well as NIC connection for every servers we have in the Data Center. You will also have different manage switch exist in your DC which require more administrator to manage seperately. In Virtualization, we speak about consolidate, increase utilization, centralized manage and etc. Xsigo Virtualization I/O will able to achieve the concept for us to standardize, consolidate, simplify, increase throughput and utlization for the environment we invested in DC.

Let’s imagine what happen today, you will have 4Gbps connection on FC from your server to the storage, but you will not necessary utulize that. You will not able to allocate the under utilize bandwidth to the rest of the client or connection which require, which is consider a waste. It happen the same thing to Network connection, in most cases, you may not require 1Gbps connection for each servers. Without Virtualization I/O, we will end up buying more manage switches, invest more bandwidth in Data Center and under utilize it. This technology even provide a better bandwidth for each connection and allow the combination for both storage and network. This will simplify the cable managment and adminstration time lead for long term solution. Host Channel Adaptor is cheaper if we compare the price of Host Bus Adaptor today. Is Virtualize I/O make sense? My personal answer is yes and it will just do exactly the same as what VMware provide, fully utilize your environment, for cosolidate, simplify and central manage for I/O in data center.

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

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

http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_compat_matrix.pdf

http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf

Here is some of the compatible document been release for references. Is really helpful for everyone who plan to implement the virtualization on VMware.

As for the today, more users are actually deployed the mission critical and high I/O servers on the virtualization environment, but we do see some I/O bottle neck which cause by the storage performance always. VMDK do provide flexibility from management perspective, but it does sacrifice the performance you may require for your databases, files transfers and disk performance. I had run a couple of test with real case scenerio instead of I/O meter that been always use widely, and here is the summarize result I would like to share.

In disk perfomance, we always split it to 2 categories as sequential and random I/O. in sequential mode, you will see the huge different while you try to perform the file transfer locally or through network. My test environment is running with SAN storage from fiber channel with same LUN size and raid group which are created from the Storage Level. The only differences is VMFS Vs Raw.

Raid Group design 7+1 raid 5 configuration and run on MetaLun configuration

Each LUN size is 300GB

Performance monitoring tools = Virtual Center Performance Chart

VM Test Machine = 4 Vcpu, 8GB Memory

Operating System = SLES 10 x32, x64 ; Windows Server 2003 x32, x64

Sequential : RDM is out perform VS VMFS as it able to achieve > 2 times higher through put during the file transfer locally on the VM

Random I/O : The Raw Device Mapping is still out perform the VMFS and getting the similar through put with sequential file transfer. Multi session with random database query is been executed in the test

for NFS file transfer from VMFS to VMFS, I do see the bottle neck happen much more earlier than RDM.

Highest I/O rate for RDM = 180MB/s as during sequential files copy and DB query

Highest I/O rate for VMDK = 100MB/s during sequential files copy and DB query