UPDATE: The discount code is EXPIRED and OpenStack Summit is SOLD OUT! I hope you got your tickets early. See you there.

Red Hat is a Headline sponsor at OpenStack Summit in Portland, Oregon next month. There was an early bird registration, which is now over. If you missed it, Red Hat is offering attendees at discount on the current registration price: $450 instead of $600, a savings of $150 per attendee.

To get the discount visit the Eventbrite portal and during the registration process you will see a section prompting you to enter a promotional code above the green “Register” button.

Simply enter the code RedHat to get the discounted registration rate.

The preliminary conference schedule here.

I will be there as well as a ton of Red Hatters, those who have been making massive contributions to the OpenStack project code, as well as those of us who work on the business side. We will have plenty of great giveaways, and expect some cool news as well.

Cheers!

Agenda includes information on Red Hat virtualization, operating system, storage and cloud solutions. The full agenda can be found at http://www.redhat.com/virtual/optimize/agenda/

See you there!

It was also cool to meet Brent Spiner, Star Trek’s Commander Data himself, who was reprising his VMworld appearance from San Francisco again at the Barcelona show. And one of my colleagues managed to snap this photo of Mr. Spiner wearing a Red Hat:

Made this geek’s day

The interest in Red Hat Enterprise Virtualization continues to grow, especially now that we’re heading toward RHEV 3.1 release at the end of the year. The beta program, open to existing RHEV customers or through Red Hat partners and direct sales, is going very well. For more on the features and functionality in RHEV 3.1, see my previous post from Red Hat Summit.

Last month, I did a short trip through Eastern Canada to meet with customers and partners in Montreal and Toronto. One theme came shining through: customers are ready to diversify their virtualization infrastructure, and are looking to RHEV to do it. Even though VMware rightly eliminated the VRAM pricing for vSphere 5.0 and 5.1, customers are still concerned about being locked in to a single vendor, and are still waiting for the promised savings from virtualizing their workloads. Now is a great time to be checking out alternatives like RHEV.

Our friends at Zenoss also recently published some interesting data on virtualization and public cloud. Their survey results, published here on their blog at http://blog.zenoss.com/2012/10/the-state-of-the-open-source-cloud-2012-infographic-report/ shows a couple of interesting things.

One is the growth of the use of RHEV, at least among this audience, is remarkable given our short time on the market. And combined with the use of generic Linux KVM is tied with the overall use of opensource Xen and Citrix XenServer among Zenoss users. While I’d like to see more use of RHEV, obviously, it’s another testament to the momentum behind KVM and RHEV.

The second interesting point is the momentum behind OpenStack. Fully 50% of respondents say they have deployed an OpenStack open source cloud. The greatest barrier to open sound cloud adoption is maturity, followed by lack of support and concerns around security.

Many of your already know that Red Hat has been involved with OpenStack for over a year. We were the number 3 contributer to Essex and have stepped up our involvement since then, announcing that we were joining the OpenStack Foundation as a Platinum member and releasing a Preview of our OpenStack distribution running on Red Hat Enterprise Linux. To join the preview, go to http://openstack.redhat.com/

One of the reasons that Red Hat has joined the OpenStack community is that many of our customers are very excited about OpenStack, but have expressed many of the same concerns that Zenoss uncovered in their research. Making OpenStack stable, supportable, and secure is key to its broad adoption, and the skills required to do that are what Red Hat has demonstrated many times in the open source community, beginning with our enterprise grade Linux and virtualization solutions.

Our OpenStack Preview will soon be updated from the Essex release to the Folsom release (which just came out a week or so ago). Folsom will form the basis of our product release early next year.

To learn more about Red Hat’s OpenStack strategy, check out our OpenStack FAQ. And if you’re in San Diego next week for OpenStack Summit, come stop by our booth and meet me and some of our OpenStack engineers. We will be presenting at the Summit as well, including information on our release strategy.

I’ll be writing up my thoughts real-soon-now, but in the meantime, take a look at this video of my friend Andy Cathrow and me talking about the value of Red Hat Enterprise Virtualization and the roadmap for RHEV 3.1. I’ve been told it’s good, but honestly I can’t stand to watch myself on video so I’ve not watched it.

I present a couple of interesting slides towards the end of my presentation on value for performance that I’ll talk more about this week.

I will be giving a presentation with Andy Cathrow on Red Hat Enterprise Virtualization Overview and Roadmap from 1:20-2:20pm ET on Wednesday, June 27. This session will be live streamed on the Red Hat Summit Virtual Event platform, so even if you don’t attend in person you can find out about what’s coming next from the RHEV development team.

Register for the Virtual Event here

For more information including Agenda, go to http://www.redhat.com/summit

Also, if you are attending Summit this year, please join us in room 105 for a special RHEV Team Q&A session on Wednesday, June 27 at 12pm noon.

See you there!

If you’ve read in the last couple of weeks, you probably noticed that posting has attracted some less than positive comments from Xen adherents.

All cards on the table: I am a KVM adherent. I work for Red Hat, and I work on a KVM-based product. Moreover, I personally believe that KVM is the best technology going forward for open source virtualization.

My goal in the post was to point out the architectural differences between Xen and KVM, before and after the inclusion of some Xen code beginning with Linux 3.0. And yes, to poke some fun at Citrix and Oracle.

Based on the recent comments I’ve gotten, I thought it was worth writing a short post before going on to other topics.

I was tempted to do some editing to the original post (a footnote here, a qualification there), but aside from fixing a couple of incorrect links, I decided to let it stand as originally written and posted for better or worse.

I do apologize for initially pointing to the incorrect article as the attribution link for Simon Crosby’s quote. I have made that correction in the post.

But unless there are technical inaccuracies, I am not making any further edits. You the reader can decide if I was fair, pushing things to make a point, or way off base and need to apologize for muckraking.

Let’s step back in time a bit…

Now, the post is a bit out of its historical context. After all I wrote most of it in July of 2011 for a different forum to address a real issue–the confusion about what Xen being “accepted” into Linux actually means.

Confusion still reigns

Almost a year later, people still ask what that announcement from Oracle and Citrix means. And still the overwhelming impression that people come away with from reading the coverage and talking to sales people is that Xen is now integrated into Linux, and that KVM’s advantages in that regard are moot.

Addressing that confusion was the ultimate intent of the post.

Was it a bit cheeky to call out the Oracle and Citrix at the top of the article? Sure. Guilty as charged. It helped get the post out to a broader audience than I  expected for what at its heart is a relatively dry but important architectural distinction.

Is there anything technically inaccurate in the post? I haven’t heard of anything yet, but I commit to immediately correct any technical inaccuracies.

Did I not give the people behind the posts the benefit of the doubt? Maybe. I admit I was fixated on the inaccuracies and FUD circulating at the time.

I will say this: if you understand enough about the architecture of Xen, of KVM, and the process of including code in the Linux kernel, then reading in full the cited articles will give you an accurate account of what the Xen announcement means for Xen and for KVM.

If however you don’t know hypervisor architectures that well, or you only read the press and second hand accounts, or what a sales person told you, or the headlines and soundbites, then you probably got the wrong impression. This article was written for you.

Enough said.

I’m moving on to other topics. Feel free to comment.

Here’s what Oracle and Citrix have said on the matter:

“I’ve heard over the last few years, competitors use “There is no Xen support in Linux” as a tagline to create FUD with the Xen userbase and promote alternatives. Well, it’s all there people.” — Wim Coekaert, Oracle

“During all the fuss of Citrix Synergy last week, an event of pretty earth-shattering importance occurred in the open source world: all key Xen code was accepted into the Linux mainline kernel.” – Simon Crosby, Citrix

Wrong!

The Oracle and Citrix marketing on this issue are misleading to say the least. It implies that the recent acceptance of some Xen enablement code into the Linux kernel equates to integration, or that the Xen architecture doesn’t matter now that some of  their code is in Linux.

KVM is still the only Linux kernel-integrated hypervisor technology. End of sentence. End of story.

There is no special KVM enablement needed in the Linux kernel. KVM is integrated into the Linux kernel. KVM uses Linux for everything from device management to CPU scheduling, memory page sharing, better algorithms for making use of lots of cores and lots of memory, and tying into all the hardware virtualization technology AMD and Intel have been building into x86 for the past 5 years.

Xen is no more mainline or mainstream today in 2012 when it comes to Linux than it was in 2007 when KVM was accepted into the Linux kernel, or 2009 when Red Hat decided to move forward with KVM instead of Xen and integrated KVM into RHEL.

OK, then, what’s the Real Scoop?

Xen has still not been accepted (and probably never will be) into the Linux kernel, and cannot leverage directly Linux technologies such as transparent huge pages, CFS scheduler, paging, memory overcommitment with KSM, etc. for its hypervisor technology. You still need to install the Xen kernel on bare metal and build a special VM called a Dom0 to manage it and to provide device drivers. And you still have the suboptimal Xen architecture with Xen-Dom0-DomU. See the ugly diagrams below for more details.

The announcement of Xen and Linux 3.0 means two (and only two) things:

1. The paravirtualized drivers that Xen uses will be integrated into Linux starting with 3.0. This means that just like virtio (KVM/Libvirt) and pv-scsi (VMware), the pv-ops drivers used for accelerated disk and NIC will be available in any Linux 3.x+ guest without having to integrate drivers. This leaves Microsoft Hyper-V alone in requiring integrating drivers for guests.

2. A Linux 3.0 or higher guest can be used unmodified as a Dom0. Remember Dom0 is where the console operating system resides and is also a slave for certain IO from the guests. It is not Xen itself. Xen still resides on the bare metal and is still a separate project from Linux that has to duplicate effort to support hardware and new virtualization technologies.

In summary, it will be slightly easier to use future versions of Linux guests with current and future versions of Xen, and it will be slightly easier to use future versions of Linux as a Dom0 for current and future versions of Xen.

If you want to use a pre-3.0 Linux as a Dom0 it won’t work without modifications. If you want to use pre-3.0 Linux guests, you still need to hack in the drivers.

Not such a big deal after all. So does this change anything for KVM?

In a word, No.

One of KVM’s strengths is that it is integrated into the Linux kernel and therefore can utilize Linux features for things that hypervisors do besides just being a hypervisor.

Xen hypervisor is still a separate project and a completely separate code base, and features that KVM can use for virtualization and inherits from Linux (scheduling, paging, frequency scaling and hardware enablement, for example) will still need to be separately implemented in Xen. This is part of the design of Xen and is not going to change.

KVM Architecture

Elegant, isn’t it?

Xen Architecture

What a mess…

What did they say? Word for word. I’m taking down names.

Here’s links to the various blogs Citrix and Oracle have put out:

http://blogs.citrix.com/2011/05/30/xen-celebrates-the-final-step-of-a-four-year-odyssey/

http://blogs.oracle.com/wim/entry/linux_mainline_contains_all_the