Ossipee started off as OS-IPA. As it morphed into a tool for building development clusters,I realized it was more useful to split the building of the cluster from the Install and configuration of the application on that cluster. To install IPA and OpenStack, and integrate them together, we now use an ansible-playbook called Rippowam.
I often create and destroy a virtual machine multiple times in development. SSH records the host and key and often complains about a changed value for a given key. As I am attempting to automate more and more, I need to be able to communicate with these recreated hosts without dealing with the warning messages.
Continue reading
The Live CD shipped with Fedora 18 is a perfectly serviceable virtual machine image, provided you give it some writeable disk space. It even ships with a tool to make this happen. All it needs is a block device. Continue reading
If you want Openstack support for Fedora or RHEL, this day is for you! Once we get the F17 code stable, we will use that as the code base for EPEL, so lend a hand.
https://fedoraproject.org/wiki/Test_Day:2012-03-08_OpenStack_Test_Day
I’ll be lurking around to help out with Keystone questions, but at the same time I’ll also be involved with a local installfest so I expect to be logged in to IRC, but also very much walking around and answering questions….as well as running through test cases myself.
So join us:
IRC #fedora-test-day on Freenode
WebIRC: http://webchat.freenode.net/?channels=fedora-test-day
As a Fedora Community Member, I always feel guilty if I postpone trying out a testing release of Fedora. Since I have a limited amount of hardware, I can’t just install on a physical machine. Turns out that testing on a virtual machine is about as easy as it can be.
A recent discussion on the Openstack mailing list brought to light the high load that the Keystone server has due to each server having to authenticate each and every request against Keystone.
When running Fedora as a KVM/Qemu host for virtual machines, you have the issue that you don’t know the IP Address for a virtual machine once you create it. IP addresses that are assigned via
The MAC Address is in the config file saved in
/etc/libvirt/qemu/$VMNAME.xml
Once you start the virtual machine, you can fetch the IP Address from the DHCP lease file in:
/var/lib/dnsmasq/dnsmasq.leases
To correlate the two:
#!/bin/bash
VMNAME=$1
MAC=`cat /etc/libvirt/qemu/$VMNAME.xml | xml2 | awk 'BEGIN{FS="="} /mac..address/ {print $2}'`
IP=`grep $MAC /var/lib/dnsmasq/dnsmasq.leases | cut -d' ' -f3`
#$VMNAME has MAC $MAC and IPAddress $IP
echo $IP
This must be called as root or via sudo.
UPDATE:
Chris Lalancette notes that the cannonical version of the MAC address can be found using
virsh -c qemu:///system dumpxml $VMNAME
This past week at the Red Hat summit I got the chance to demonstrate Enterprise IPA, the Red Hat version of FreeIPA, at the Red Hat booth. One of the aspects of IPA we want to showcase is registering client systems. That means that I wanted to be able to get a client system in the pre-installed state pretty very quickly. My approach was to use Qemu/KVM virtual machines. I had one VM image that I did not touch, and all the rest of the virtual machines will be snapshots that overlay that image.
FreeIPA makes Kerberos a lot less painful.
Since My development now needs to target F14, not F13, I figured I start using a F14 virtual machine, but leave my F13 VM alone, just in case I needed something off of it. Well, it turns out I do need something off of it. But why should I have to wait for it to boot in order to see it? I can mount it loop back, right…