The Virtualization Practice

Tag Archive for cloud.com

On October 22nd, Microsoft announced that it has partnered with Cloud.com to provide integration and support of Windows Server 2008 R2 Hyper-V to the OpenStack project. The announcement caused a great deal of interest here at the Virtualization Practice, as it signals an unexpected willingness on Microsoft’s part to pursue interoperability at the IaaS layer, allowing users to break out of the Hyper-v stack, whilst still retaining Hyper-v at the bottom. The fact this announcement came from Microsoft (not Cloud.com, Rackspace or OpenStack) seems to signal the seriousness of the intent.

VMworld is clearly the largest dedicated virtualization conference, and yet from an Open Source perspective it is slightly disappointing because the VMware ecosystem naturally attracts proprietary software vendors, and also some of the more interesting activities in Open Source are through multi-vendor foundations which do not have the same marketing budgets as vendors themselves.

Nevertheless, there are a number of key Open Source players, and some interesting smaller players, represented at VMworld.

Cloud.com had lined itself up with Citrix by using only XenServer in the commercially-licensed version of its IaaS product, and now is being used by Citrix to ensure OpenStack supports XenServer (which it doesn’t at the moment), presumably to keep Red Hat’s KVM under control and VMware out. We’ve also been trawling through the available OpenStack documentation to understand why NASA thinks its cloud is more scalable than Eucalyptus. It seems to be all to do with how the state information is passed amongst the various servers that make up the system. GPL-based Open Core models break down when you move to multi-vendor foundations because the cross-licensing of IPR under GPL immediately infects the recipient codebase, and precludes commercial licensing of the resulting combined work. The result is that the GPL Open Core business model doesn’t work in the same way, and both Eucalyptus and Cloud.com cannot apply their current business model in these multi-vendor foundations. It is a big blow for Eucalyptus. They have turned their biggest potential customer into a massive and credible competitor, built in their own image (only – at least from a PR perspective – much more scalable).

In OpenStack the API is implemented in a separate service which translates external http requests into commands across the internal message bus, and so it looks (on the face of it) possible for someone (preferably Oracle) to implement the Oracle DMTF submission as a separable new API server module without disrupting the OpenStack architecture. In OpenStack the API is implemented in a separate service which translates external HTTP requests into commands across the internal message bus, and so it looks (on the face of it) possible for someone (preferably Oracle) to implement the Oracle DMTF submission as a separable new API server module without disrupting the OpenStack architecture.