Update an existing OpenStack instance after a global flag change

If a nova-compute flag ( for instance libvirt_use_virtio_for_bridges ) is changed after instances have been created, the existing instances won’t be changed accordingly. The libvirt XML description can be modified, both in /var/lib/nova/instances and in /etc/libvirt/qemu to reflect the desired change. The corresponding instance can then be rebooted with nova reboot so that kvm is run again with the new options.
Continue reading “Update an existing OpenStack instance after a global flag change”

OpenStack horizon : fix the Instance & Volumes page

In the horizon OpenStack dashboard, the display of the Instances & Volumes page fails for every account with administrative permissions, after a volume has been created and attached to an instance. While there are workarounds (such as using an unprivileged account to display the same page ), it affects almost all admin users deploying the current release of horizon in Essex. The bug was fixed and uploaded to Debian GNU/Linux sid. It was unblocked and will be in wheezy by the end of september 2012.
Continue reading “OpenStack horizon : fix the Instance & Volumes page”

OpenStack nested virtual machines

Running a virtual machine within a virtual machine (aka nested virtual machines) is supported by OpenStack by adding a stanza such as

    <cpu mode='custom' match='exact'>
      <model>Nehalem</model>
      <feature policy='require' name='vmx'/>
    </cpu>

in the libvirt.xml.template file. The nested feature must be enabled on the OpenStack node for intel processors by adding the nested=1 argument when loading the kvm_intel module so that:

# cat /sys/module/kvm_intel/parameters/nested
Y

This feature can be used to exercise an automated Openstack deployement on Debian GNU/Linux wheezy with razor within OpenStack itself.
Continue reading “OpenStack nested virtual machines”

tinc based L2 mesh for OpenStack

Given three bare metal machines hosted at Hetzner, eNovance and OVH, l2mesh can be used to create a new ethernet interface L2M on each of them. It behaves as if they had a physical ethernet card connected to a hardware switch in the same room. The machine at eNovance could be the DHCP server providing the IP for the L2M interface of the Hetzner machine. In addition, if the connection between the eNovance machine and the Hetzner machine does not work, the packets will use the OVH machine as an intermediary, making the mesh resilient to network outage.
The documentation page for l2mesh has been added to the example section of the tinc web site after a discussion with Guus Sliepen.
Continue reading “tinc based L2 mesh for OpenStack”

Fix for iscsitarget session expiration bug blocking OpenStack volume deletion

When iscsitarget is used for nova-volume, there is a volume deletion problem because the iscsi session does not expire properly. A NMU fixing the problem was uploaded to the delayed queue for Debian GNU/Linux wheezy. An unblock request has been issued because it fixes a critical bug and was accepted a few days later. The package will enter wheezy around November 3rd, 2012.
Continue reading “Fix for iscsitarget session expiration bug blocking OpenStack volume deletion”

Debian GNU/Linux wheezy mirror for OpenStack

Deploying OpenStack on Debian GNU/Linux requires the wheezy repository, which not stable yet at this date. When the HOWTO is tested to work against the current state of the wheezy repository, it is worth keeping a copy to ensure it can be re-run reliably. A virtual machine is dedicated to store a wheezy mirror, updated with the ftpsync shell script:

# ssh mirror@debian.the.re
$ bin/ftpsync sync:all

It can then be used as follows:

# cat > /etc/apt/sources.list.d/debian.the.re.list <<EOF
deb http://debian.the.re/debian wheezy main
deb-src http://debian.the.re/debian wheezy main
EOF
# apt-get update

Continue reading “Debian GNU/Linux wheezy mirror for OpenStack”

Cluster wide reverse proxy for OpenStack

A nginx based reverse proxy configuration is installed on each bare metal node. It helps when the OpenStack cluster is made of nodes located on various hosting providers ( such as eNovance, Hetzner, etc. ). Each machine to which the IP for a given web site is routed is able to find the actual virtual machine supporting it. The configuration is pulled from the git repository by the puppet agent running on each node.
Continue reading “Cluster wide reverse proxy for OpenStack”

Adding a Hetzner machine to the.re

Check the comments for updates

The the.re OpenStack cluster is made of machines hosted in various places. When it is rented from Hetzner, it must be configured with Debian GNU/Linux wheezy and partitionned with a large LVM volume group for storage. It is given the name bm0005.the.re. It is then configured with the compute role as instructed in the puppet HOWTO. A new tenant is created, with quotas corresponding to the resources provided by the hardware ( in this case an EX10 model with 64GB RAM, 12 3.20GHz cores, 6TB disk ).
Continue reading “Adding a Hetzner machine to the.re”