On Wed, Aug 27, 2008 at 01:32:13PM -0700, Dan Smith wrote:
DB> +static int lxcContainerMountNewFS(virDomainDefPtr vmDef)
DB> +{
DB> + virDomainFSDefPtr tmp;
DB> +
DB> + /* Pull in rest of container's mounts */
DB> + for (tmp = vmDef->fss; tmp; tmp = tmp->next) {
DB> + char *src;
DB> + if (STREQ(tmp->dst, "/"))
DB> + continue;
DB> + // XXX fix
DB> + if (tmp->type != VIR_DOMAIN_FS_TYPE_MOUNT)
DB> + continue;
DB> +
DB> + if (asprintf(&src, "/.oldroot/%s", tmp->src) < 0)
DB> + return -1;
DB> +
DB> + if (virFileMakePath(tmp->dst) < 0 ||
DB> + mount(src, tmp->dst, NULL, MS_BIND, NULL) < 0) {
DB> + VIR_FREE(src);
DB> + lxcError(NULL, NULL, VIR_ERR_INTERNAL_ERROR,
DB> + _("failed to mount %s at %s for container: %s"),
DB> + tmp->src, tmp->dst, strerror(errno));
DB> + return -1;
DB> + }
DB> + VIR_FREE(src);
DB> + }
DB> + return -1;
Shouldn't this be "return 0"? AFAICT, this means this function will
always fail and thus any domain with a root target will fail to start.
If I change this to "return 0" I'm able to start such guests, with
properly pivoted roots.
Yes, it clearly should be return 0.
On a more general note, it seems like there are a lot of places
where
failures trigger a "return -1" that rolls completely up the stack with
no error information getting logged. Since you have the excellent
per-container logging functionality, can we increase the verbosity a
little so that there is some way to diagnose where things are failing?
Thus far, I've just started sprinkling fprintf()'s into the code until I
start to narrow things down. I'd be glad to help with that after this
goes in.
The newly improved virExec() API which LXC now uses ensures that libvirt's
error callback is reset to the default in child processes. This means that
any call to virRaiseError in the child is turned into a fprintf(stderr...).
We also wire the container stdout/err to /var/log/libvirt/lxc/NAME.log
So if everything is operating as I expect, all the lxcError() calls in
this code should result in log messages being written out to /var/log.
Daniel
--
|: Red Hat, Engineering, London -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 :|