New tool: virt-builder

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:
[     2.0] Uncompressing:
[    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).


Filed under Uncategorized

13 responses to “New tool: virt-builder

  1. Hello

    I’d like to see an example using ansible for customization instead of a run script.

    • rich

      Can you explain a bit more about how that would work?

      • Hello

        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.

      • rich

        Not having actually tried it I’m guessing something like this would work (it needs a local file called playbook.yml):

        virt-builder fedora-19 \
          --install /usr/bin/ansible-pull \
          --upload playbook.yml:/tmp/playbook.yml \
          --run-command "ansible-pull /tmp/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.

      • Hello

        Ah, pull instead of push.

        Looking at this:

        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.

  2. 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?

    • rich

      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 ( 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.

      • rich

        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.

  3. Looks interesting … waiting to play with it..

  4. Pingback: New in virt-builder | Richard WM Jones

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.