[libvirt-users] Configuring default network/storage for qemu:///session

[Laine Stump]

On 03/03/2016 11:03 AM, catern at catern.com wrote:
> "Daniel P. Berrange" <berrange at 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.