Re: [Libvir] [PATCH] lxc: start domain

Daniel Veillard wrote: > >> +static int lxcStartContainer(virConnectPtr conn, >> + lxc_driver_t* driver, >> + lxc_vm_t *vm) >> +{ >> + int rc = -1; >> + int flags; >> + int stacksize = getpagesize() * 4; >> + void *stack, *stacktop; >> + >> + /* allocate a stack for the container */ >> + stack = malloc(stacksize); >> + if (!stack) { >> + lxcError(conn, NULL, VIR_ERR_NO_MEMORY, >> + _("unable to allocate container stack")); >> + goto error_exit; >> + } >> + stacktop = (char*)stack + stacksize; >> + >> + flags = CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD; >> + >> + vm->pid = clone(lxcChild, stacktop, flags, (void *)vm); >> + >> + DEBUG("clone() returned, %d", vm->pid); >> + >> + if (vm->pid < 0) { >> + lxcError(conn, NULL, VIR_ERR_INTERNAL_ERROR, >> + _("clone() failed, %s"), strerror(errno)); >> + goto error_exit; >> + } >> + >> + vm->def->id = vm->pid; >> + lxcSaveConfig(NULL, driver, vm, vm->def); > > We should make sure at some point taht there is some kind of locking > mechanism when creating those config files, no ? Good question. Right now libvirtd should be the only process accessing the file. Is it multi-threaded that would cause collisions? The other possibility is if we found we needed to save the config file from within the container. That's not currently the case and I'd stay away from that if at all possible.