Cool Link Roundup

A bunch o’ interesting links I’ve happened across recently:

Simple disposable VMs with snap-guest

Have you ever wished you could easily spin up a virtual machine for a little testing? Something quick, but something you could (optionally) throw away when you were done?

Of course you have. And I think snap-guest is the answer to your dreams (mine, too!). It allows you to set up a “base” image, and then easily spin up copy-on-write copies of it.

Installation

You can follow the installation instructions in the README, though note the trap — the syntax for the symlink is backwards. With that setup, I built a handful of virtual machines. One is RHEL 6.3, and the other is Fedora 17. (I plan to set up more soon.) You may want to copy it into /usr/bin instead of symlinking it into /usr/local/bin if you use sudo.

The “base” VMs are something you should set up and then shut down, to never touch again, because otherwise you will cause problems with the “copy-on-write” copies which are now against something that has been changed underneath them. So create a base image that things will be based on. Here’s what I did after the base install:

  • yum update
  • yum install ntpd, set it up with working servers, and chkconfig ntpd on
  • Set up EPEL
  • yum install bash-completion git screen telnet (telnet is for checking ports, not insecure logins!)
  • Add a non-privileged user
  • I added repos for Aeolus, but did not install anything from them for the base image.
  • Disable smartd, enable acpid
  • Allow incoming traffic on ports 22, 80, 443, 3000 in the firewall
  • Set up Avahi — yum install avahi, chkconfig avahi-daemon on, and open UDP port 5353 in the firewall. Do the same on your desktop, edit /etc/nsswitch.conf‘s “hosts:” line to read “hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname”. Now, ssh vm-hostname.local will “just work”. (Thanks, eck, for this trick!)
  • Clean things out for provisioning of guests: touch /.unconfigure; yum clean all; rm -rf /etc/ssh/ssh_host_*; poweroff
  • In hindsight, it might have been worthwhile to set up a basic local LDAP server on the guest so that I could test Conductor against it when needed.

When the machine shuts down, you shouldn’t boot it again, unless you are prepared to wipe out any derivative guests.

Usage

I ended up using a little more than is ordinarily required, because I didn’t love all of the defaults:

sudo /usr/local/bin/snap-guest -b Fedora-17-base -t test_f17_guest -m 2048 -c4 -n bridge=br0

This will clone the “Fedora-17-base” image, starting a “test_f17_guest” VM. -m 2048 tells it to use 2048MB RAM instead of 800MB. -c4 gives it 4 cores, and -n bridge=br0 brings it up using my host’s virbr0 brdiged interface for networking. Obviously, customize all of this as required.

Note that the system will come up with a hostname matching whatever you used with -t. If you set up Avahi as I outlined above, you should be able to “ssh test_f17_guest.local” and log right in.

I still have some kinks to work out, like network interfaces coming up under different names. But I think this is going to be immensely useful going forward. Historically, needing to test a patch on RHEL, or finding a clean Fedora system to test an upstream patch on to rule out issues with my local setup, has been a real timesink. Now it takes about 10 seconds to make a cloned guest, and under a minute for it to boot. I can re-use guests, or just trash them when I’m done.

Aeolus Community-Building Meetup #2

Yesterday we had our second Aeolus Community-Building Meeting. The idea was initially suggested by Nitesh, a community member who wanted to share some ideas for growing the community. We met a few weeks ago, with the notes published here.

This week we had a follow-up call, with much greater attendance.

We’ve been using Google Hangouts for these meetings with pretty good success. The videoconference aspect is pretty neat, and Mo had good luck with the screen-sharing aspect as well. This time we did an On Air Hangout, which allowed people to watch the stream live on Youtube, and for us to post a recording after the fact.

You can watch the recording here. (As a warning, my audio is really low, so if you crank the audio up for me, be prepared for everyone else to blow out your eardrums in comparison.)

Here’s a quick recap of what was discussed:

  • Mo Morsi gave a preview of his upcoming talks on Aeolus. He put the slides on the Aeolus Presentations wiki page.
  • We should have a release calendar on our site, and also make sure to make noise (on our blog, and on Twitter/Facebook/etc.) about our releases.
  • It would be valuable to look at integrating with CloudStack and documenting how to use it. Google Compute / Google Cloud Platform, too!
  • Our templates site is a really good idea that needs to be finished up and launched. The template repo Justin set up is a good interim solution.
  • It would be interesting to look at integrating with other sources of templates, like Bitnami or CloudFormation.
  • In general, we really need to support more providers, and finally arrive at a complete API.
  • Justin has been working on getting OpenShift Origin running on Aeolus. This would be an excellent blog post, and maybe a good marketing angle.
  • Sponsoring “drinkups” seems to work well for attracting interest, though it’s not clear if there’s actually a good return on it.
  • Someone suggested cotton candy at booths. I love that idea. Cotton candy kind of looks like a cloud, too!
  • Stickers and flyers are a must. We need to get a ton ordered.
  • We should do more with social media. We have a Facebook page and a Google Plus page, and we’re @aeolusproject on Twitter, and we have a blog. But we don’t make extensive use of them. What we really need are others to blog about us, retweet us, and share our stuff on Facebook.
  • We need to get people to take these tasks and commit to making them happen, and we should be in good shape for the next meeting!

Procedurally, we had some notes for how to make things go more smoothly next time:

  • I really, really need to buy a headset so that people can actually hear me.
  • When you have a large group of people who don’t all know each other, you should have people introduce themselves.
  • The 10-person limit is a problem. I think I might do a separate post on some things I have in mind for how to handle this next time.
  • We need an easier way to share the link ahead of time, both for the Hangout and for the live Youtube stream for people who don’t intend to participate.
  • We need to pay attention to IRC during the call, so those watching on Youtube can participate.

While comments are welcome on this post, please don’t do so at the expense of replying on aeolus-devel!