On Thu, Mar 27, 2008 at 02:50:20PM -0700, Dave Leskovec wrote:
> 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.
This is safe as is. libvirtd is single threaded and is the only process that
should be touching the config files.
Dan.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list