On 03/03/2016 11:03 AM, catern@xxxxxxxxxx wrote:
"Daniel P. Berrange" <berrange@xxxxxxxxxx> 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.
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
