Xsigo

You are currently browsing articles tagged Xsigo.

Yesterday I published a short post titled “I/O Virtualization and the Double-Edged Sword”. In that post, I discussed how Xsigo was criticizing FCoE for “not going far enough” in the realm of I/O virtualization. Unfortunately, I didn’t do a very good job of really getting my point across, because the discussion rapidly turned into a discussion of the merits of various interconnect technologies and why one might win over the other. While that is a great discussion to have—and I’m thrilled my site can help further that discussion—it wasn’t really the key point behind my article. I/O virtualization was only the catalyst to prompt the original post.

Let me see if I can more clearly articulate what I’m trying to say here. If you are a Twitter user and into virtualization or storage, then you probably are following either Chad Sakac of EMC (@sakacc on Twitter), Vaughn Stewart of NetApp (@vaughn_stewart on Twitter), or both. That being the case, you are probably very familiar with the extensive “discussions” that take place between the two of them. Both of them are very passionate about storage and virtualization, but they have differing viewpoints. Now, before I’m accused by NetApp of being an EMC bigot (which would be ridiculous given the coverage I’ve given NetApp) or accused by EMC of being a NetApp bigot (that, at least, might be understandable as I’m just now starting to learn EMC storage), let me say that I’m not endorsing either product. NetApp’s products and EMC’s products are different; each of them has strengths and weaknesses in different areas.

Now, ask yourself, “Why do these products have different strengths and weaknesses?” Do you know the answer? These products have different strengths and weaknesses because of the technology decisions each company chose to make in the products’ development. NetApp chose one path, EMC chose another. For NetApp, that has created certain efficiences, certain strengths—and corresponding weaknesses. Likewise, EMC’s technology decisions have resulted in their products having certain strengths and weaknesses. Neither of these products is perfect. For NetApp to claim that “their way is the right way” is ridiculous; their way is only one of many different ways to accomplish something. The same is true for EMC. And, by extension, the same is true for every other technology vendor on the planet.

You want more examples? Consider the architectural differences between VMware ESX/ESXi and Microsoft Hyper-V. The technology choices made by each company created inherent strengths and weaknesses in each product. VMware claims their choices are the best choices; Microsoft believes their architecture is the best. Clearly, neither product is perfect. Both products have their flaws.

The real key takeaway here is that no technology vendor has the right to throw rocks at another technology vendor. All technology vendors live in glass houses. For VMware to claim that Microsoft’s architecture is all wrong is, well, wrong. For EMC to say that NetApp’s technology choices are stupid would be wrong. For Xsigo to claim that FCoE is the wrong path for I/O virtualization is wrong (although, personally, I don’t consider FCoE an I/O virtualization technology, but that’s a different discussion for a different day). Why? Because every company has to make technology choices, and those technology choices will—by the very nature of technology—automatically create inherent differences, strengths, and weaknesses in the resulting product. And when you accept that truth (and it is a truth, I promise you), then you see why vendors should not engage in negative marketing. When a vendor engages in negative marketing about the competition, that vendor is simply inviting others to pick apart the flaws in their own products.

Of course, I’m not naive enough to believe that vendors will stop negative competitive marketing overnight. Still, I stand firm in the belief that those vendors that focus on the strengths of their products instead of the flaws of others’ products will move ahead. I’m certainly more likely to do business with them.

I’d be interested to hear what others have to say. Voice your position in the comments.

Disclosure: As you probably know, I work for a reseller who represents many different vendors and manufacturers. My words here are not endorsed by my employer, nor do I represent my employer in this area.

Tags: , , , ,

I recently came across this blog entry over at Xsigo’s new corporate blog, I/O Unplugged. A key phrase in this blog entry really caught my eye:

The reality is that FCoE solves neither the complexity nor the management problems. It is a minor change to the status quo when a major leap forward comparable to server virtualization is needed for I/O.

At first glance, I’d say they are right. FCoE was designed from the ground up to be completely compatible with Fibre Channel—and that’s one of its key strengths. Yes, Xsigo’s InfiniBand-based solution is a very different architecture, and the set of capabilities provided by the Xsigo I/O Director are very different than the capabilities enabled by an FCoE solution such as the Cisco Nexus 5000 (or the newly-announced Nexus 4000). I wouldn’t necessarily disagree that Xsigo’s solution might offer some benefits over FCoE. I would strongly contend, however, that FCoE does offer some benefits over InfiniBand-based I/O virtualization solutions.

See, every technology decision is a double-edged sword. Xsigo “breaks the mold” by using a new architecture based on InfiniBand, but this decision comes at the cost of compatibility. Cisco chooses to go with a “less innovative” solution, but gains the benefit of broad compatibility with a large installed base. There is no one solution that offers all advantages and no disadvantages. That being said, which is more important to you and your company: innovation or compatibility? These are the sorts of questions you need to ask when evaluating solutions.

What do you think? Feel free to post your thoughts below. Vendors, please be sure to disclose your affiliation. And, in the spirit of full disclosure, keep in mind that my employer is a Cisco partner, but I have worked with both Xsigo and Cisco solutions. The thoughts I post here do not reflect the thoughts or views of my employer.

Tags: , , , ,

For the last few weeks, I’ve had the privilege of using a Xsigo Systems VP780 I/O Director in my lab. After using the product for these past few weeks, I thought I’d share a few tips and tricks for integrating the product into your VMware Infrastructure 3 (VI3) environment.

Jumbo Frames

If you want to use jumbo frames in your VI3 environment with the VP780, you’ll need to set the MTU on the Ethernet ports before creating any vNICs. If any vNICs are already created, you’ll need to remove them, set the MTU, and then re-add them. Fortunately that’s no big deal with the VP780, but it is something to keep in mind. The command to set the MTU looks something like this:

set ethernet-port 13/6 -mtu=9000

Obviously, you’ll need to specify the appropriate Ethernet port instead of 13/6, and if you want to use an MTU size of something other than 9000 bytes you’ll need to specify the correct value there as well.

VLAN Trunking Mode

Like with jumbo frames, if you anticipate wanting to pass VLAN tags through the VP780 up to the ESX server, you’ll want to set the Ethernet port’s VLAN trunking mode before creating vNICs. Otherwise, as stated in the previous section, you’ll need to remove the vNICs, set the trunk mode, and then re-add the vNICs. I consider this an essential step, as I almost always recommend the use of VLANs in a VI3 environment.

The command for setting the VLAN trunking mode is very similar to the MTU command shown earlier:

set ethernet-port 13/6 -mode=trunk

It’s perfectly OK to combine these two commands into a single step:

set ethernet-port 13/6 -mode=trunk -mtu=9000

While you’re in there setting properties for the Ethernet ports, you may also want to consider whether you want the VP780 to tag native VLANs. I’ll refer you back to this blog entry and this blog entry for more information on VLANs and the native VLAN with ESX. Alternatively, you could just use the URL http://blog.scottlowe.org/tag/vlan to see all VLAN-related articles.

Using esxtop with the VP780

This one had me stumped, but Xsigo support found the problem pretty quickly. Originally, I was unable to use esxtop to view network statistics. It turns out that, as documented by VMware, ESX has a maximum number of NICs that are supported in a host. Since the Xsigo drivers pre-create 32 vNICs, this was causing the host to exceed the maximum and esxtop would simply quit when trying to view network statistics. The fix is to reload the Xsigo module and tell it to pre-create fewer NICs, like this:

vmkload_mod -u vnic (unloads the vnic module)
vmkload_mod vnic vmk_preregister=26 (loads the module, pre-creating 26 vNICs)
esxcfg-boot -r (makes the change persistent)

With this change in place, esxtop worked just fine. Obviously, you’ll need to adjust the number of pre-created vNICs according to the number of other NICs in the system so that the system-wide total does not exceed 32.

By the way, if you’d like more information on I/O virtualization and why it might be beneficial, have a look at a couple of articles I’ve written about the topic:

Benefiting from I/O Virtualization
Maximizing I/O Virtualization (New!)

It’s quite likely I’ll have more Xsigo-related tips in the future, so if you’re interested, be sure to stay tuned. The easiest way to do that would be to subscribe to the site’s RSS feed, which is easily accessible via the bright orange logo in the upper right corner of the site.

Tags: , , , , ,