Utah Open Source Planet

The speed of the new Mac OS release has me thinking.  It’s really soon since Leopard was released, and Exchange support really isn’t enough to warrant it.  Then I keep coming back to the reasons Apple said they are releasing it:  Security, Efficiency, and Power Consumption.  This is really low-level stuff, down to the kernel. 

When Mac OS X was first released, the OS was built around the Mach kernel.  To date, there are only two OSes that I am aware of that have successfully used the Mach kernel:  Mac OS X and the NeXT OS.  THis shouldn’t be surprising, since Steve Jobs owned NeXT, and just brought it over to Apple when he came back.  

But the Mach kernel is very limiting, meaning that there is a lot of overhead to make it work across platforms.  While it can work fine on various architectures, the Mach kernel has to be developed specifically for that platform before it will work.  As such, there is an inherent flaw in using this core in an OS that is poised to do so many things.  

Another problem with the Mach kernel is virtualization.  Now, I’m not talking about virtualization in a desktop sense, but rather a server sense.  While it is possible to use the current OS in a virtual machine (both Parallels and VMWare are doing something just like that), it’s very difficult to get it to work in Compatibility Mode, because the kernel needs to be modified heavily.  Since Compatibility mode is more efficient than HVM, it should be a goal of Apple.

But then I read this article regarding the possibility of using Xen as a replacement for the Mach kernel, as tested and run by Moshe Bar.  All of a sudden, my heart skipped a beat.  Xen!  Running natively on the Mac as a Bare-bones OS, virtualizing the Mac OS!  I started looking back at the evidence:  no PPC support, which means Intel only.  The Core 2 Duo and Atom chips all have Intel VT technology, so it should be no problem.  With Xen at the core, they can still keep Darwin open source, which is a huge plus.  And, you no longer need to boot up to Windows to use it:  Just run it through Xen.  It would work almost like fast user switching, but fast OS switching.  

And, virtualization no longer becomes a problem, either for desktop or server level.  The OS can still be targeted specifically for Mac Hardware (though I think that will no longer be an issue as there is a law against requiring software to run on specific hardware), and could even be easily migrated to other hardware platforms, should Apple so choose.  

Okay, once the euphoria of the possibility of Xen being the platform for OS X 10.6 Snow Leopard, the nagging started to hit me.  Could there be reasons why Apple wouldn’t go with Xen?

1. The new “Grand Central” multi-core optimization project.  It *could* be Xen, but why rename it?  Perhaps because it isn’t Xen at all.  Of course it still could be, just modified to fix the Mac even more. 
2. XenSource was purchased by Citrix not long ago, and the question of it’s Open Source status is still hanging.  There could be some collaboration here, but Apple likes to have control of everything from start to finish.  It now becomes very unlikely.  

ZDnet  had an article on Citrix and their position/dedication to XEN.  For those that weren’t aware, Citrix bought XEN for $500 million last year.  I had one thought about this article until I read one of the comments.  So if you read it, beware maybe don’t jump to conclusions at first.  Here is the comment from Citrix’s CTO VMD Simon Crosby:

I hope this is ok.  If not please let me know and I apologize ahead of time.

Citrix is committed to Xen

It appears that somehow when we briefed Paula, we managed to confuse her. I accept full responsibility for this, but think it is important to state the facts:

1. The Xen project is in great shape, superbly funded by Citrix and the community, and is operated independently from Citrix, by the Xen project Advisory Board. Citrix has more than doubled XenSource’s open source team size already, and is continuing to develop new initiatives for Xen. At the most recent Xen developer summit in December, we had over 200 attendees, and there was fantastic participation from across the industry. Our own open source team operates independently from the product groups and has a blank check for headcount and resource. As I said previously, I’d be happy to fill you in on this.

2. XenServer is a core foundational product to Citrix. Specifically, XenApp (formerly Presentation Server) and XenDesktop (formerly Desktop Server, addressing the VDI use case) will both include XenServer in all future releases. Why? Because XenServer has been optimized to run the XenApp and XenDesktop workloads, and provides a fantastic set of manageability, availability, scalability, and flexibility options to the XenApp/XenDesktop administrator, with incredible performance (very significantly better than VMware’s, for those same workloads). Today our customers tell us that they hate to use VMware for virtualizing Presentation Server, because of the performance issues, but they need to do so for various reasons: test & dev flexibility, consistency of image management, DR, ease of provisioning etc. XenServer offers them all they need, at much better price/performance than VMware.

3. XenServer itself continues to go from strength to strength. The new release 4.1 boasts over 50 new features and performance optimizations, and a profound and strategic tight coupling between the virtual infrastructure platform and smart virtualization aware storage, such as the NetApp devices. Expect a range of exciting announcements as we move down this path.

In a nutshell: Xen is profoundly important to Citrix, is changing everything about the way that Citrix develops and delivers its products. Citrix is fully supportive of open source and the community, and you will see much more than just Xen as a core community focus from Citrix in the not too distant future.

Simon Crosby, CTO VMD, Citrix.

A while back, I found myself running out of hardware and wanting to host more sites than I currently was. In addition, I wanted to create a little bit more redundancy for some of the services I host. At the time, I was hosting a number of services with Xen. One physical server hosted [...]

Last Friday I asked a question about how to set up a network in Xen with a machine attached between a public and private network, like you might use in a firewall or load balancing situation. I want to be able to mimic real world networking situation in Xen for experimentation and modeling purposes.

There were numerous replies and I'm grateful for all the help. In the end, Steve Fulling (he's not as pointy haired as you though) came up with a pretty simple solution.

To use virt-install to create a bridged, public machine, you'd do something like this:

virt-install --paravirt --vcpus=1 --name $1 --ram 500 \\
             --file /var/lib/xen/images/${1}.img
             --network=bridge:eth0 \\
             --file-size 10 --nographics \\
             --location http://192.168.1.150/fedora8-i386

To use virt-install to create a private machine, you'd do something like this:

virt-install --paravirt --vcpus=1 --name $1 --ram 500 \\
             --file /var/lib/xen/images/${1}.img
             --network=network:default \\
             --file-size 10 --nographics \\
             --location http://192.168.1.150/fedora8-i386

The trick to getting a machine on both is to issue two --network commands:

virt-install --paravirt --vcpus=1 --name $1 --ram 500 \\
             --file /var/lib/xen/images/${1}.img  \\
             --network=bridge:eth0 --network=network:default \\
             --file-size 10 --nographics \\
             --location http://192.168.1.150/fedora8-i386

There are other, more complex scenarios. For example, you might want to create multiple VLANs, etc. I found these resources helpful:

• Xen network configuration and multiple VLANs
• XEN networking explained

Tags: xen virtualization networking kynetx

I want to create a setup on XEN that has one or more machines load balancing for a number of other machines on a private network. This diagram shows roughly what I'm thinking:

The idea is that some machines will be connected to both the public network and the private LAN and other machines will only be connected to the VLAN. This offers some security benefits and reduces the number of public IP numbers I need.

The catch is I want to do this all virtually. Does anyone know of the recommended way to do this with XEN? I can't seem to find a HOWTO guide with this kind of setup. Pointers welcome.

Tags: xen virtualization apache kynetx

I'm looking for a management console for Xen (besides the command line). I'd looked into this months and months ago and concluded that when the time came, I'd try Enomalism, but after some initial experiments I'm no longer sure. Any advice? Let me know what you use for managing the Xen hypervisor and why.

Tags: xen virtualization open+source kynetx

I'm looking for a management console for Xen (besides the command line). I'd looked into this months and months ago and concluded that when the time came, I'd try Enomalism, but after some initial experiments I'm no longer sure. Any advice? Let me know what you use for managing the Xen hypervisor and why.

Tags: xen virtualization open+source kynetx

Well… I finally received notice of my final day. I was one of the many laid off from Novell last Tuesday. What kind of surprised me was that most of the interns, at least all of the interns that I know, were laid off. In a way it doesn’t make sense to lay off all of the cheap labor unless its a head count issue. Luckily, my manager fought to keep another intern and myself until October 31. Hopefully I will be able to find a new job in the meantime. I will miss Novell and testing XEN as well as the people I was able to work with. Even though I won’t be an employee, I’m still part of the community and will continue to contribute to opensuse and most likely XEN (due to hardware limitations). Another change is that I will no longer appear on bugzilla as stshaw, but will be decriptor.

As I’m doing more XEN stuff, I just want to post quickly about #opensuse-xen on irc (freenode). We are few in numbers, but would love to see more people in there helping and sharing ideas.

I started to mention this in my xen networking page and figured since I’ve had a chance to look at the script a little that I’ll blog about it. This is an all-in-one script written by Ron Terry from pronetworkconsulting. The script is called network-multinet. I haven’t looked at his dhcp addition, so I’ll leave that for another post.

First, I’ll show you how to change over to this new script:

Warnings: This is changing and restarts your networking.

1. Download the script from the link above and copy it to:

/etc/xen/scripts

if you are using opensuse 10.3, then just check the version (in the file)

2. Edit /etc/xen/xend-config.sxp around line 128:

change from

(network-script network-bridge)

to

(network-script network-multinet)

3. Depending on your distro you might have to add or edit:

/etc/sysconfig/xend

4. Now to switch over to the new script:

/etc/xen/scripts/network-bridge stop

/etc/xen/scripts/network-multinet start

5. Check to make sure everything came back up:

/etc/xen/scripts/network-multinet status

and check your VMs.

That should do it. You are now switched over to a much newer and cooler script with more features. One of the things that I really like is the fact that you can now start, stop, restart, and status instead of just start and stop.

Running ‘/etc/xen/scripts/network-multinet status’ gives you a lot of information which is very useful.

I recommend looking around at the other scripts. There are some useful ones around the site.

This was originally going to be an article on networking in XEN, however I just couldn’t find the time to finish it or work on it. Hopefully there is some useful information there as it stands. Even more hopeful that I might be able to finish it one of these days. Until then, my XEN networking page

Or you can also click on the link on my page.

This is something that I was able to help test for a little bit. The idea behind these drivers is to make certain devices in a fully virtualized guest “xen aware”. Since the heaviest used parts of a hosted operating system are networking and disk access, they focused on improving them. For right now the supported operating systems are RHEL 4 and 5, and windows 2000, 2003, and XP. Without sounding like a sales person, I thought this was a really cool idea. Those that have run fully virtualized guests, you can understand why this would be welcome. Anyways, here is a link that you can read.

Novell Ships SLE 10 SP 1 and New VMDP

While working on some Xen stuff, I’ve found that a drawing is about the easiest way to document some things.

I’m going to be doing some drawings of custom Xen networks, but until then, here are a few drawings of default Xen networks to serve as a point of reference.

This first one just shows how a non-Xen networking setup might look. The white box is just a label. Not much to see :)

Now, we’ll look at what starting xend does to our network. Later on, I’ll try to blog about the scripts that make this change and how they work. If you boot into your Xen kernel in and haven’t done anything with Xen yet, this is what your setup looks like (well, maybe).

If you bring up a guest OS (DomU), this is what your networking will look like. This set-up is suitable for most Xen installs.

More to come…

Update: Changed the X in vifX.Y to match the domain ID. Good eye Lamont.