New in libguestfs 1.24 will be a simple tool called virt-builder. This builds virtual machines of various free operating systems quickly and securely:
$ virt-builder fedora-19 --size 20G --install nmap [ 0.0] Downloading: http://libguestfs.org/download/builder/fedora-19.xz [ 2.0] Uncompressing: http://libguestfs.org/download/builder/fedora-19.xz [ 25.0] Running virt-resize to expand the disk to 20.0G [ 74.0] Opening the new disk [ 78.0] Random root password: RCuMKJ4NPak0ptJQ [did you mean to use --root-password?] [ 78.0] Installing packages: nmap [ 93.0] Finishing off
Some notable features:
- Fast: As you can see above, once it has downloaded and cached the template first time, it can churn out new guests in around 90 seconds.
- Install packages.
- Set the hostname.
- Generate a random seed for the guest.
- Upload files.
- Set passwords, create user accounts.
- Run custom scripts.
- Install firstboot scripts.
- Fetch packages from private repos and ISOs.
- Secure: Everything is assembled in a container (using SELinux if available).
- Guest templates are PGP-signed.
- No root or privileged access needed at all (no setuid, no sudo).
- Fully scriptable.
- Can be used in locked-down no-network scenarios.
- Can use UML as a backend (good for use in a cloud).
Richard WM Jones 
I’d like to see an example using ansible for customization instead of a run script.
Can you explain a bit more about how that would work?
I like the simplicity of being able to pass the names of packages which should be installed on the command line. Of course, often you’ll need more customization, so you’ve provided for a script to be run. But now you’re writing and maintaining scripts.
I was thinking it would be neat if you could put your packages and other customizations into an ansible playbook. You’d point virt-builder at the playbook and it would automatically set up the ssh or whatever other mechanism is needed.
Having typed that out, I guess another type of integration would be an ansible module for virt-builder, so ansible would invoke the tool to create your vm’s. Although you’d still need ansible to go into the vm and customize. Would be nice to make this easy without having to manually set up network and ssh etc.
Not having actually tried it I’m guessing something like this would work (it needs a local file called
playbook.yml):The biggest catch is that the network provided to the guest allows only outgoing connections (that’s because we want to do everything without needing root). So a “push” during virt-builder guest installation is not possible, as well as it being difficult to coordinate. However “pull” connections should work fine.
Ah, pull instead of push.
Looking at this:
https://github.com/ansible/ansible/tree/devel/lib/ansible/runner/connection_plugins
ansible’s connection plug-ins seem simple. Just need to implement put_file, fetch_file and exec_command methods. So however virt-builder puts scripts into the vm and runs them, an ansible connection module could do something similar.
This new functionality reminds me of OpenVZ and its OS Templates. Glad to see this was adopted. Now, any chance you guys would have a look at another OpenVZ thing… ploop?
ploop looks like an invitation to be 0wned when one of your container users finds a kernel exploit! However as an extension of loop (given that you don’t care about all its security problems) it’s obviously a good thing.
OpenVZ (sponsored by Parallels and a building block of their commercial product Virtuozzo Containers) has been around for 8 years and is widely deployed especially by hosting providers selling containers to the public and giving them container root access. Parallels employs a few kernel developers and have a track record of providing mainline bug fixes as well as appearing in the top kernel contributors a few times. The point is they haven’t had any significant security issues with their stuff so far as I know so your comment about not caring about security problems is short sighted. They plan on getting ploop into the mainline kernel at some point but are busy focusing on a few other things first. I don’t mean to make this a Parallels ad and it is ok to look a gift horse in the mouth… especially for security problems. They actually started gathering deployment stats a few months ago (http://stats.openvz.org) and given the fact that ploop is a relatively new OpenVZ feature, it is only deployed on ~ 7.3% of containers.The OpenVZ kernel patch/branches are based on RHEL kernel sources. They DO care a LOT about security and I’m sure ploop is no exception. If anyone can find security problems with ploop I’m sure they’d love to hear about them.
Sure, I hope and trust that they care a lot about security.
The problem is not with ploop, which looks like a fine enhancement to loop. The problem is the whole idea of mounting untrusted filesystems on the kernel which can invoke exploitable bugs in multiple VFS and block device drivers which bypass both ordinary Unix permissions and Linux security modules like SELinux.
Unless you are able to prove that the Acorn ADFS driver in your kernel is free of bugs … or the ext4 driver .. or the hundreds of other VFS and block device drivers … or the kernel ABI itself.
Friends don’t let friends mount untrusted filesystems on their kernel.
Looks interesting … waiting to play with it..
You can already play with it, if you can build libguestfs from source.
I know that.. I want to allocate some time ( =’waiting to play with it ‘) to go through the options available with the utility,trying different switches, poking source code..etc ..
Pingback: New in virt-builder | Richard WM Jones