Comments on: Pulling the Virtual Ethernet Plug http://jakob.engbloms.se/archives/248?&owa_medium=feed&owa_sid= Computer Technology: Simulation, Virtualization, Virtual Platforms, Embedded, Multicore and Multiprocessing (by Jakob Engblom) Thu, 12 Jan 2012 21:54:16 -0800 hourly 1 http://wordpress.org/?v=3.3.1 By: Jakob http://jakob.engbloms.se/archives/248/comment-page-1#comment-1728 Jakob Fri, 29 Aug 2008 06:31:41 +0000 http://jakob.engbloms.se/?p=248#comment-1728 Background technology first: The basic property that virtual system needs to fulfill is that you do indeed model a particular system's complete hardware. Once that is in place, pulling bits an pieces is pretty simple. And the software will react in whatever way it is designed to do (getting an alert interrupt, noting in a timeout that something has gone dead, etc.). This is something that I have been part of doing for rack-based telecom systems, which are on the same scale as typical servers (tens to hundreds of processors, tens of boards). Simics also has some models of olden Sparc servers like the US-III/IV/IV+-based SunFires. The nice thing with modeling the hardware directly rather than protocols in the middle of the stack is that killing things is pretty easy to do. Just turn off part of the model, or send in some "I am dead" interupt. And then let the software react in whatever manner it is written to. The hardware/software interface is very well-behaved in that respect in that it is narrow and well-defined. Pulling out virtual cables is a simple as a single line command like "link0.disconnect machine0_phy4". Background technology first: The basic property that virtual system needs to fulfill is that you do indeed model a particular system’s complete hardware. Once that is in place, pulling bits an pieces is pretty simple. And the software will react in whatever way it is designed to do (getting an alert interrupt, noting in a timeout that something has gone dead, etc.).

This is something that I have been part of doing for rack-based telecom systems, which are on the same scale as typical servers (tens to hundreds of processors, tens of boards). Simics also has some models of olden Sparc servers like the US-III/IV/IV+-based SunFires.

The nice thing with modeling the hardware directly rather than protocols in the middle of the stack is that killing things is pretty easy to do. Just turn off part of the model, or send in some “I am dead” interupt. And then let the software react in whatever manner it is written to. The hardware/software interface is very well-behaved in that respect in that it is narrow and well-defined.

Pulling out virtual cables is a simple as a single line command like “link0.disconnect machine0_phy4″.

]]> By: Bryan Cantrill http://jakob.engbloms.se/archives/248/comment-page-1#comment-1724 Bryan Cantrill Wed, 27 Aug 2008 14:18:53 +0000 http://jakob.engbloms.se/?p=248#comment-1724 I am of course wonderfully excited to hear that this problem has already been solved! So tell me: which virtualization platform allows me to pull a virtual 10 GigE NIC? Or allows me to pull out one half of a LACP'd 10 GigE link aggregation? Or allows me to pull an IPMP'd link under load and validate that the other path picks up full bandwidth within the response times that I must meet to deliver service? If the virtualized hardware is not "datacenter-oriented", you can forget it -- testing my software on a toy system has little value for me. I am of course wonderfully excited to hear that this problem has already been solved! So tell me: which virtualization platform allows me to pull a virtual 10 GigE NIC? Or allows me to pull out one half of a LACP’d 10 GigE link aggregation? Or allows me to pull an IPMP’d link under load and validate that the other path picks up full bandwidth within the response times that I must meet to deliver service? If the virtualized hardware is not “datacenter-oriented”, you can forget it — testing my software on a toy system has little value for me.

]]>