On Fri, Nov 11, 2016 at 02:15:38PM +0100, Michal Sekletar wrote: > On Mon, Nov 7, 2016 at 1:20 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > > > So if libvirt creates a private mount namespace for each QEMU and mounts > > a custom /dev there, this is invisible to udev, and thus udev won't/can't > > mess with permissions we set in our private /dev. > > > > For hotplug, the libvirt QEMU would do the same as the libvirt LXC driver > > currently does. It would fork and setns() into the QEMU mount namespace > > and run mknod()+chmod() there, before doing the rest of its normal hotplug > > logic. See lxcDomainAttachDeviceMknodHelper() for what LXC does. > > We try to migrate people away from using mknod and messing with /dev/ > from user-space. For example, we had to deal with non-trivial problems > wrt. mknod and Veritas storage stack in the past (most of these issues What kind of issues ? > remain unsolved to date). I don't like to hear that you plan to get > into /dev management business in libvirt too. I am judging based on > past experiences, nevertheless, I don't like this plan. Libvirt is already doing this for its LXC driver, populating a private /dev with only the devices permitted for the container in question. > Also, managing separate mount namespace for each qemu process and > forking helper that joins the namespace to do some work seems quite > complex too. Again, libvirt is already doing this for LXC so its not any great burden. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list