Ok, so, for what it's worth, the following was successful for me:
sudo systemd-nspawn -bxD/
Practically identical to yours, except I don't give the machine a name and I get an -x ephemeral btrfs snapshot of my / for the container's root.
That brought up the container's getty on my terminal's pty and I logged in to login and all.
I confess I was a bit stumped for a little while, but after a little poking at systemctl in the container w/ zsh <tab> completion I came up with (run from within the container):
systemctl stop console-getty.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to manage system services or other units.
Authenticating as: mikeserv
Password:
==== AUTHENTICATION COMPLETE ===
Which got the machine to surrender its terminal control. The only thing is, I started that with sudo - which also gets its own layer of terminal control to authenticate in the first place. This left me with a blank terminal, and no amount of kill -CONT "$(pgrep ksh)" was doing me any good. And so I was again stumped for a moment or two, but (in another terminal)...
sudo fuser -v /dev/pts/*
USER PID ACCESS COMMAND
/dev/pts/0: mikeserv 8347 F.... zsh
root 18003 F.... sudo
/dev/pts/13: mikeserv 9553 F.... zsh
mikeserv 16838 F.... ksh
root 17657 F.... sudo
root 17658 F.... systemd-nspawn
/dev/pts/14: root 17675 F.... systemd
Gave me the above list, and so I thought - what the hell?
sudo kill -STOP 17657
And - lo and behold - I had ksh back in the original terminal. To wrap it up, I needed to verify I could still access the machine, though, of course, else it would be useless:
machinectl -l
MACHINE CLASS SERVICE
localhost-35ceaa76b1306897 container nspawn
Ok...
sudo machinectl login localhost-35ceaa76b1306897
Connected to machine localhost-35ceaa76b1306897.
Press ^] three times within 1s to exit session.
Arch Linux 4.0.7-2-ARCH (pts/0)
localhost-35ceaa76b1306897 login:
And I got another getty on another terminal!
Try systemd-run:
# systemd-nspawn -D <machine-root> -b 3 --link-journal host
# systemd-run --machine <machine-name> env
Running as unit run-1356.service.
# journalctl --machine <machine-name> -u run-1356 -b -q
Oct 30 07:45:09 jessie-64 systemd[1]: Started /usr/bin/env.
Oct 30 07:45:09 jessie-64 env[37]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Excerpt from the manpage:
Use shell (see below) or systemd-run(1) with the --machine= switch to directly invoke a single command, either interactively or in the background.
(The command shell available since v225)
Best Answer
systemd-detect-virt can tell you whether your system is running in a VM/container. This requires systemd-detect-virt inside your container, but the systemd documentation on minimal builds suggests that you can just build a package that only includes systemd-detect-virt.