This ticket had assigned some Differential requests:
D376

I've been looking into this and after hacking on things a bit, I've found:
* by default, administrator users (wheel group) can manipulate virsh vms locally (at least on my f21 box)
* putting everything in a common dir (I used /var/lib/testCloud) with loose enough permissions allows a new VM to be booted

The potential catch/issue here is what happens with the different qemu connections. As a comparison

=== Using qemu:///session===
Good
* default for non-root commands
* leaves all the file owner bits alone
* each user can only change the VMs that it created

Not so good
* managing the VMs would require multiple hypervisor connections
* doesn't have access to the virtual networks that are created by libvirt and uses [[http://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29|qemu usermode networking]]
- according to qemu docs, this networking mode has quite a bit of overhead
- I haven't been able to figure out a way to determine the VM's IP address with usermode networking
- We'd likely need to change settings to make this work well - creating virtual networks of some sort to handle the NAT/bridging/whatever we end up using

=== Using qemu:///system ===
Good
* uses system virtual networks - simple NAT network on virbr0 works without extra configuration
* easier to manage since all the VMs would be available through the same hypervisor connection

Not so good
* file permissions are fun
- after initial boot, any files involved with the VM are owned by qemu.qemu while the VM is running and root.root when the VM is not running
- I've been able to delete the files for each vm and reboot the vm without root privs
- trying to run the current boot process when the old files still exist makes stuff like virt-builder blow up

Given all this, I'm thinking that using the qemu:///system connection will work better for now. It doesn't require running stuff as root (if we're smart about things) nor does it require any additional permissions beyond what a user already needs to boot VMs.

If testcloud is refactored to be smarter about not trying to manipulate old files and provides an interface for deleting those files (and cached downloads), I don't think this will be a big problem. The entire fix will not be small and will likely involve patches for #426, #425, #424, #418 and maybe more

PR merged into origin/dev:
https://github.com/Rorosha/testCloud/pull/11

Closing ticket as issue should be solved for now