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”
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”
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'>
<feature policy='require' name='vmx'/>
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
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”
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”
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”
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 firstname.lastname@example.org
$ 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
# apt-get update
Continue reading “Debian GNU/Linux wheezy mirror 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”
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”
A turnkeylinux redmine is installed to store the tasks and files related to the management of the the.re OpenStack cluster. It is configured for git public read-only access ( git clone http://redmine.the.re/git/turnkey.git ) and online browsing.
Continue reading “Configuring redmine turnkeylinux on OpenStack”
The images provided by turnkeylinux are mirrored on the OpenStack node running the glance image service. Each image of interest is uploaded into glance using turnkey2glance.sh. New flavors are created with nova flavor create to take advantage of their small memory footprint.
Continue reading “Using turnkeylinux for OpenStack”