DB> IMHO there's too much forking going on here. With the stateful DB> driver we should have the daemon be the parent of the forked VM as DB> per the QEMU driver. This will avoid the need to unsafely re-write DB> the config files. It will also enable errors during the domain DB> creation process to be correctly propagated back to the caller. In the case of being called from libvirtd, this seems correct. However, if you're not going through the daemon, I think that the double-fork isolation is important, no? Being a child of something as complex as a CIM server seems like a bad idea to me. DB> eg, when I tested this patch 'mount' failed, but the libvirt DB> driver still thought all we fine becasue this part of domain DB> creation was being done in the double-fork()d child and thus no DB> errors could be propagated back. Perhaps the setup can be performed as part of the immediate child and then do the second fork to achieve the isolation (if desired)? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx
Attachment:
pgpHUE7bFibCl.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list