Comments on: More on Cisco UCS http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/ The weblog of an IT pro specializing in virtualization, storage, and servers Fri, 12 Mar 2010 20:02:42 +0000 http://wordpress.org/?v=abc hourly 1 By: Brad Hedlund http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-44566 Brad Hedlund Sun, 24 May 2009 01:16:41 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-44566 @bob - A standard driver could be used, or NIC vendor specific "Plugins". @bob - A standard driver could be used, or NIC vendor specific “Plugins”.

]]> By: bob http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-44402 bob Thu, 07 May 2009 18:55:53 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-44402 One aspect that was touched on but is still not clear to me is the compatibility of VMDirectPath and vMotion. VMDirectPath presumably interfaces directly with the native VF (sr-iov virtual function, ie a physical interface). vMotion is possible because ESX was abstracting physical I/O interfaces used by the VM. How is vMotion accomplished if the VM is accessing the native/physical interface directly? One aspect that was touched on but is still not clear to me is the compatibility of VMDirectPath and vMotion. VMDirectPath presumably interfaces directly with the native VF (sr-iov virtual function, ie a physical interface). vMotion is possible because ESX was abstracting physical I/O interfaces used by the VM. How is vMotion accomplished if the VM is accessing the native/physical interface directly?

]]> By: Chad Sakac http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-44037 Chad Sakac Tue, 31 Mar 2009 18:05:58 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-44037 Brad - one thing to clarify my SR-IOV comment - SR-IOV is dependent in VMware land to use of VMDirectPath IO (which in gen 1 has significant limits, designed to be lifted in gen2). Cisco has been working with VMware to have a slightly accelerated functional capability here (using the underlying SR-IOV model) prior to VMDirectPath IO gen2. Brad - one thing to clarify my SR-IOV comment - SR-IOV is dependent in VMware land to use of VMDirectPath IO (which in gen 1 has significant limits, designed to be lifted in gen2). Cisco has been working with VMware to have a slightly accelerated functional capability here (using the underlying SR-IOV model) prior to VMDirectPath IO gen2.

]]> By: Brad Hedlund http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43911 Brad Hedlund Thu, 19 Mar 2009 04:36:39 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43911 Nik, The HP Flex-NIC you must be referring to is not SR-IOV based. Rather, Flex-10 and Flex-NIC is HP proprietary technology. Nik,
The HP Flex-NIC you must be referring to is not SR-IOV based. Rather, Flex-10 and Flex-NIC is HP proprietary technology.

]]> By: slowe http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43909 slowe Thu, 19 Mar 2009 03:06:13 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43909 Nik, You are quite correct--there is nothing stopping any other vendor from incorporating these technologies into their own products. Cisco appears, based on what we've seen thus far, to have done a great job with your second point--making it transparent to the end-user community--although it is still quite early to tell yet. Nik,

You are quite correct–there is nothing stopping any other vendor from incorporating these technologies into their own products. Cisco appears, based on what we’ve seen thus far, to have done a great job with your second point–making it transparent to the end-user community–although it is still quite early to tell yet.

]]> By: Nik Simpson http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43906 Nik Simpson Wed, 18 Mar 2009 18:54:11 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43906 I think it's important to note that in all this discussion of SR-IOV, VN-Tag, VT-c, VT-D (and the rest of the alphabet soup) there is nothing that other vendors can't leverage (assuming VN-Tag is standardized). In fact, HP is already offering an SR-IOV 10 GbE adapter for it's C-class blades and has been doing so for 6 months. So at the end of the day it will come down to who makes this stuff the most transparent to poor sys admins tasked with tying it all together. I think it’s important to note that in all this discussion of SR-IOV, VN-Tag, VT-c, VT-D (and the rest of the alphabet soup) there is nothing that other vendors can’t leverage (assuming VN-Tag is standardized). In fact, HP is already offering an SR-IOV 10 GbE adapter for it’s C-class blades and has been doing so for 6 months. So at the end of the day it will come down to who makes this stuff the most transparent to poor sys admins tasked with tying it all together.

]]> By: Cisco UCS Virtualization-Optimized CNAs - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43903 Cisco UCS Virtualization-Optimized CNAs - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, storage, and servers Wed, 18 Mar 2009 12:18:43 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43903 [...] allows VMs to attach directly to one of the SR-IOV virtual adapters (or, as Brad Hedlund put it in this comment to my original article, an “SR-IOV slice of the [...] [...] allows VMs to attach directly to one of the SR-IOV virtual adapters (or, as Brad Hedlund put it in this comment to my original article, an “SR-IOV slice of the [...]

]]> By: slowe http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43902 slowe Wed, 18 Mar 2009 02:30:22 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43902 Brad, That's very helpful information, thanks! Brad,

That’s very helpful information, thanks!

]]> By: Brad Hedlund http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43900 Brad Hedlund Wed, 18 Mar 2009 01:49:20 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43900 Scott, VN-Link is an umbrella Cisco marketing term that describes granular per virtual machine visibility and policy control. VN-Link can be accomplished in two ways, 1) via software with Nexus 1000V, 2) via Hardware with VN-Tags and SR-IOV. So, VN-Link is not different than VN-Tag -- rather, VN-Tag is one way to achieve "VN-Link". With Cisco UCS and the Palo adapter, you will be able to achieve "Hypervisor Bypass" (VM Direct Path), where the VM writes directly to its SR-IOV slice of the adapter. The adapter then applies a VN-Tag to uniquely identify the "virtual NIC" the traffic belongs to --- VN-Tag acts like a virtual patch cable running from the SR-IOV adapter to the UCS 6100 fabric switch. At this point the virtual machine is managed as if it is connected directly to the UCS 6100 fabric switch. Another advantage is much better network I/O performance for virtual machines, more like bare metal. The hypervisor is no longer context switching the data from a vNIC buffer to the adapter buffers, reducing latencies, and improving throughput. Furthermore, given the hypervisor CPU is freed from network I/O responsibilities, you can give back precious CPU cycles for hosting more virtual machines. Hope this clarifies. Brad Scott,
VN-Link is an umbrella Cisco marketing term that describes granular per virtual machine visibility and policy control. VN-Link can be accomplished in two ways, 1) via software with Nexus 1000V, 2) via Hardware with VN-Tags and SR-IOV.

So, VN-Link is not different than VN-Tag — rather, VN-Tag is one way to achieve “VN-Link”.

With Cisco UCS and the Palo adapter, you will be able to achieve “Hypervisor Bypass” (VM Direct Path), where the VM writes directly to its SR-IOV slice of the adapter. The adapter then applies a VN-Tag to uniquely identify the “virtual NIC” the traffic belongs to — VN-Tag acts like a virtual patch cable running from the SR-IOV adapter to the UCS 6100 fabric switch. At this point the virtual machine is managed as if it is connected directly to the UCS 6100 fabric switch.

Another advantage is much better network I/O performance for virtual machines, more like bare metal. The hypervisor is no longer context switching the data from a vNIC buffer to the adapter buffers, reducing latencies, and improving throughput. Furthermore, given the hypervisor CPU is freed from network I/O responsibilities, you can give back precious CPU cycles for hosting more virtual machines.

Hope this clarifies.

Brad

]]> By: slowe http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/comment-page-1/#comment-43894 slowe Tue, 17 Mar 2009 13:02:24 +0000 http://blog.scottlowe.org/2009/03/16/more-on-cisco-ucs/#comment-43894 Chad, From what I understand, I would agree with that statement. VN-Tag (not VN-Link, which is different, AFAIK) is the proposed IEEE spec that carries the VM-specific information through the network (i.e., outside the host), and SR-IOV is the technology used to allow multiple VMs to access the same physical adapter (i.e., inside the host). Two different technologies, serving two different purposes, but used together in this situation. Chad,

From what I understand, I would agree with that statement. VN-Tag (not VN-Link, which is different, AFAIK) is the proposed IEEE spec that carries the VM-specific information through the network (i.e., outside the host), and SR-IOV is the technology used to allow multiple VMs to access the same physical adapter (i.e., inside the host). Two different technologies, serving two different purposes, but used together in this situation.

]]>