2

Xen is an open source virtualization platform that allows you to install a bare metal hypervisor on a machine, which turns it into a host for other guest VMs.

I can't really understand what OpenStack/CloudStack/Eucalyptus are, because their buzzword-riddled press releases make it difficult, as an engineer, to understand exactly what these technologies do/offer, but my best understanding is that they allow you to build out your own platform-as-a-service.

But I'm curious about what types of relationships, if any, Xen could have with OpenStack. Specifically, if I have a physical machine with the Xen server/hypervisor installed on it, how could I integrate it with OpenStack?

  • Does OpenStack install as a guest VM/domain, and is thus controlled by the Xen hypervisor?; or
  • Does OpenStack act as a plugin to the Xen hypervisor (and/or controller domain) itself?; or
  • Does OpenStack get installed on its own physical server, and then sit on top of all the guest VMs/domains of 1+ Xen hypervisors?; or
  • Something else?

Concrete examples are usually the best way to get me to see the "forest through the trees". Thanks!

smeeb
  • 611

1 Answers1

4

Found this out after pouring over docks and running DevStack.org (which is OpenStack running locally on your laptop, in a single VM, or inside a Vagrant box).

OpenStack is not an executable. It is a suite of Python apps that get installed as Linux services. You take a bunch of beefy physical servers, and install these Python apps as follows:

  • 1 beefy physical is made the Controller node, where you install the OpenStack control service (a Python app) called Horizon
  • 1 beefy physical is made the Network Controller, where you install OpenStack Neutron (also a Python app)
  • 1+ beefy physicals are made Compute Nodes, where you install OpenStack Nova on all of them (Python app)
  • 1+ beefy physiccals are made Storage Nodes, where you installed OpenStack Cinder (Python)

There are other architectures and app-to-physical mappings out there, but this is a typical installation. All physicals are clustered and through configuration all nodes know about each other. Since these are Python apps, it is preferred to have a Linux distro (Ubuntu, CentOS, etc.) running as the OS on each of these physicals, because Linux distros ship with Python already installed. However, there are "bare metal" installations are in the works and are close to being production-ready.

When it is determined (either by manual or programmatic trigger) that OpenStack needs to spawn new VMs, the control node (Horizon) sends a signal to the Compute cluster (Nova). The Nova Python app running on these machines selects the physical where the VM will be spawned. There are Nova-Hypervisor bindings for most VM tools out there (Xen, KVM, vmware, etc.). When Nova receives the request to spawn a new VM, it essentially forwards the request on to the local Hypervisor to do the real work. I'm omitting an explanation of yet another OpenStack service called Glance which is actually where VM images get stored and fetched from, but that's the 30,000 foot view of how OpenStack actually works.

Bee tee dubs.

smeeb
  • 611