DB> The trouble is then libvirt would be dictating policy to the host DB> admin, because once you mount a particular controller, you can't DB> change the wayu its mounted. So if libvirt mounted each controller DB> separately, then the admin couldn't have a mount with multiple DB> controllers active, and vica-verca.
Oh, I see. I had left that out of my quick test. I had assumed that it would behave as you would expect. DB> The kernel cgroups interface really sucks in this regard :-( I was going to go with "surprisingly unideal" ...but yeah. DB> At the same time having the controllers mounted is mandatory for DB> libvirt to work and asking the admin to set things up manually DB> also sucks. So perhaps we'll need to mount them automatically, but DB> make this behaviuour configurable in some way, so admin can DB> override it Perhaps we can: - Have a list of controllers we use (memory and devices so far) - Create each group in all mounts required to satisfy our necessary controllers - Select the appropriate mount when setting a cont.key value It will muck things up a bit, but I think it might be doable. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: [EMAIL PROTECTED]
pgpM7pKzf1UBT.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
