I'd like to demonstrate some of OpenStacks HA/FT features (most importantly live migration and storage replication). For that purpose, I have a machine with 32 GB RAM and a Xeon e3v2 with 4 cores (8 threads). So far I've managed to get MAAS and Juju up and running, but I'm not sure about the number of virtual nodes I can safely deploy (and the CPU / RAM overcommit ratio, although I've read somewhere that the physical CPU can handle overcommitting with 1-vcpu-machines pretty well).

Currently, the VM that runs MAAS uses 1 vCPU and 8 GB RAM, Juju runs on the host. That leaves me with 7 vCPUs and 24 GB RAM without overcommiting any resources. What I've come up with is the following:

  • 1 Controller node: 2vCPUs, 4GB RAM - RabbitMQ, mysql, keystone, dashboard, cinder, nova-cloud-controller and glance in lxc containers
  • 2 Ceph nodes: 1 vCPU, 4GB RAM each - ceph
  • 2 Compute nodes: 2 vCPUs, 8GB RAM each - nova-compute
  • 1 Network node: 1 vCPU, 2GB RAM - quantum-gateway
  • Plus the MAAS host: 1 vCPU, 8GB RAM

This would result in a total of 38 GB RAM and 10 vCPUs, so I'm overcommiting a little.

My actual question is if anyone has a better architecture in mind. I really just plan to show some features of OpenStack (or clouds in general).


I have a similar setup, and let me suggest to your configuration:

  • Reduce the amount of RAM assigned to MAAS, around 2GB will be enough.
  • Add another ceph node, this will help you to demonstrate resilience when using ceph and 1 node goes down.
  • Overcommit in CPU isn't that bad, but you don't want to overcommit in memory, because the system will start swapping and everything will get unusable performance.
  • Something you don't mention is the disks you have, this is a huge bottleneck for me, I have 2 x 7200 RPMs disks with btrfs (raid0), but it isn't enough while the juju is deploying.
  • Also you may want to use juju-deployer and tweak the command line you use to deploy, specifically timeout modifiers and '-s' which is a delay between each "juju deploy" call.

I hope this helps.


  • Thanks! Is there any good documentation on how to actually deploy openstack and ceph using juju? I changed my setup according to your suggestions, but it seems that Canonical expects everything to work out of the box, or didn't feel the need to add a good documentation. I basically followed the instructions found in this documentation, but it seems they left out a lot of configuration options. – hoax Nov 21 '14 at 13:37
  • If you are using the config proposed in page 23, everything should work, wasn't that the case for you?. Is there something specific you want to do? or just take a look to the all config options? – Felipe Reyes Nov 21 '14 at 14:51
  • I somehow fail to create the test instance (described in page 28). I am able to start the instace with 'nova boot', but I can't add a floating IP to it because 'nova floating-ip-create' fails with 'ERROR: FloatingIpPoolNotFound: Floating ip pool not found. (HTTP 404)'. Other than that, I was hoping that the virtual machines would receive IPs from the quantum-gateway charm, but I guess it's not configured correctly, because the OpenStack dashboard does not show any Networks. I'm not sure about the network configuration in general. – hoax Nov 24 '14 at 14:16
  • I defined two networks in libvirt, one is an isolated 10/8 network, the other one is supposed to be the external network and uses NAT. Both compute and the quantum node show an unconfigured eth1 interface, which I suppose should be used for external networking. I then followed the documentation and created a private network with 'nova-manage network create' and a public network with 'nova-manage floating-create', but I have no idea what role my quantum node plays in this, and why nova-manage is used to create networks and not neutron. – hoax Nov 24 '14 at 14:23
  • You have to setup the cloud creating the public network and tenant's subnet, see docs.openstack.org/icehouse/install-guide/install/apt/content/… for more details – Felipe Reyes Nov 24 '14 at 18:17

I suggest you dump it if its still running and use LXD. You should have no issues deploying this without MaaS and just running Juju with local control of your local LXD as described here. Your machine should be able to run it without sweating too much. If you require MaaS to demonstrate it (It really is pretty awesome. You should try to check out the Openstack Roadshows that Canonical does if one comes nearby...) then it gets a bit more complicated.

This reference demonstrates setting it up on 3 machines, but you can get sneaky and deploy Juju and MaaS to the same other machine if you really need to. If your second machine was running MaaS and JuJu under LXD with the bridge connected to your lab LAN and your PXE traffic could get through you should be able to run it all in containers on two machines. I am attempting to do something similar with VMWare Fusion VMs on my laptop where I have bridged the internal network out to a thunderbolt NIC to allow the MaaS and Juju machines to orchestrate Raspberry Pi and NUC devices.


I do not have experience using juju for openstack orchestration, but from experience with ceph and openstack, for demo purposes you can run ceph on 2GB machines w/o problems and I think that the maas host can also be configured with 6GB instead of 8.

I do not know if juju allows you to combine different roles in the same VM, in our (non-juju) deployments we combine the controller and the network roles on the same VM (not using containers).


When using physical nodes in a small cluster, especially test-lab-type-stuff, one typical shortcut is to combine the ceph-nodes with your compute-nodes. See this ceph-0.48-era set of instructions for debian, or this more modern lab config for proxmox VE.

Using the numbers you provided, and the suggestions for ram-decreases plus triple-ceph in the other answers, perhaps something like this:

  1. 3vCpu + 8gb == RabbitMQ/keystone/glance/etc + cephMon1/Osd1
  2. 2vCpu + 10gb == novaComp2/Net2/Vol2 + cephMon2/Osd2/Httpd2/Rgw2
  3. 2vCpu + 10gb == novaComp3/Net3 + cephMon3/Osd3
  4. 1vCpu + 2gb == novaQuantum4
  5. 1vCpu + 3gb == MAAS_host5

I'm currently working on a one-node config of this nature myself, but have less RAM available, and only four disks to devote (cephOsd is better with multiple disks). I cannot confirm the numbers above will function for you with adequate performance, not having tried this scheme myself, but the core idea of merging somewhat-orthogonal nodes to be parsimonious with vCpu&ram may give you enough traction to get where you want to go.

p.s. See also, semi-official helpdocs for OpenStack in one physical node with one VM, plus the more relevant OpenStack on a dedicated box tutorial, at devstack.org

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.