On 03/03/2016 11:03 AM, catern@catern.com wrote:
"Daniel P. Berrange" <berrange@redhat.com> writes:
There's nothing in libvirt which auto-creates such resources by default.
IIRC, it is probably virt-manager and/or GNOME Boxes applications which are creating them. Ah, in this case it's virt-install, quite right. My mistake.
Nope. virt-install doesn't create any libvirt network. It only uses existing networks. Of course in session mode libvirt the type of networks that are usable are very limited. There is only one, as a matter of fact - the "unmanaged" network (one which simply points to an existing bridge on the host), e.g.: <network> <name>test</name> <bridge name='virbr0'/> <forward mode='bridge'/> </network> So you have a network like this automatically added? That doesn't happen when I run virt-install. Perhaps, as Daniel suggested, it was gnome-boxes that did this (virt-manager may add a default storage pool, but I'm pretty sure it wouldn't add a default network; it certainly doesn't do that when connected to qemu:///system - many users don't want any libvirt networks).
Still, then, what would be best way to have some initial configuration for qemu:///session?
The configuration in question is two networks, to use bridges that are set up on this system to be usable unprivileged with qemu-bridge-helper.
If you're creating the guests with virt-install and don't specify a particular network connection, it will add a usermode network interface, so adding a libvirt network pointing at an existing bridge isn't going to help you. Instead, you can just tell them that if they want [better/different/whatever] network connection, they should connect to the bridges you mention. e.g. in virt-install they would add: --network bridge=$bridgeblah to the commandline. That seems just as simple (especially if you give the bridges descriptive names).
Since I can't control, and don't want to try to control, what libvirt-consuming applications are run by the user, that method is out.
So is there some way I can put the configuration in /etc/skel and have the UUID be autogenerated?
If the file was placed in the correct location by something other than libvirt, then libvirtd would read it, see that there was no UUID, so it would autogenerate the UUID (but wouldn't write this new UUID back to the config file). That would work fine until libvirtd was terminated (due to timeout after not using it, or due to rebooting the host, etc). The next time libvirtd was run, it would again see the UUID was missing, autogenerate one (different this time!), etc. Would that cause a problem? Dunno, haven't tried. I can't think of a problem internal to libvirt. Of course putting stuff in /etc/skel only works for *new* users though, right? What about existing users?
Or am I going to have to write a script to be run on user-creation, to generate new UUIDs for each new user? Or does it not matter that all the network resources under the different users have the same UUIDs?
Since the session-mode libvirtd's don't communicate with each other in any way, I seriously doubt that would ever cause a problem.