On 12.12.2016 12:47, Daniel P. Berrange wrote:
> On Mon, Dec 12, 2016 at 10:55:55AM +, Daniel P. Berrange wrote:
>> On Wed, Dec 07, 2016 at 09:36:15AM +0100, Michal Privoznik wrote:
>>> Prime time. When it comes to spawning qemu process and
>>> relabelling all the devices it's going to touch,
On Wed, Dec 07, 2016 at 09:36:15AM +0100, Michal Privoznik wrote:
> Prime time. When it comes to spawning qemu process and
> relabelling all the devices it's going to touch, there's inherent
> race with other applications in the system (e.g. udev). Instead
> of trying convincing udev to not touch
On Mon, Dec 12, 2016 at 10:55:55AM +, Daniel P. Berrange wrote:
> On Wed, Dec 07, 2016 at 09:36:15AM +0100, Michal Privoznik wrote:
> > Prime time. When it comes to spawning qemu process and
> > relabelling all the devices it's going to touch, there's inherent
> > race with other applications
On Wed, Dec 07, 2016 at 09:36:15AM +0100, Michal Privoznik wrote:
> Prime time. When it comes to spawning qemu process and
> relabelling all the devices it's going to touch, there's inherent
> race with other applications in the system (e.g. udev). Instead
> of trying convincing udev to not touch
Prime time. When it comes to spawning qemu process and
relabelling all the devices it's going to touch, there's inherent
race with other applications in the system (e.g. udev). Instead
of trying convincing udev to not touch libvirt managed devices,
we can create a separate mount namespace for the
