Since its announcement, there appears to have been some confusion and concern about lxd, how it relates to lxc, and whether it will be taking away from lxc development.
When lxc was first started around 2007, it was mainly a userspace tool – some c code and some shell scripts – to exercise the in-development new kernel features intended for container and checkpoint-restart functionality. The lxc command line experience, after all these years, is quite set in stone. While it is not ideal (the mandatory -n annoys a lot of people), it has served us very well for a long time.
A few years ago, we took all of the main container-related functions which could be done with various commands, and exported them through the new ‘lxc API’. For instance, lxc-create had been a script, and lxc-start and lxc-execute were separate c programs. The new lxc ‘API’ was premised around a container object with methods, including ‘create’ and ‘start’, for the common operations.
From the start we had in mind at least python bindings to the API, and in quick order bindings came into being for C, python3, python2, go, lua, haskell, and more, allowing container administration from these languages without having to shell out to the lxc commands. So now code running on the same machine can manipulate containers. But we still have the arguably crufty command line language, and the API is local only.
lxd addresses those two issues. First, it presents a REST API for manipulating containers, thereby exporting container management over the network. Secondly, it offers a command line client using the REST API to administer containers across remote hosts. The command line API is basically what we came up with when we asked “what, after years of working with containers, would the perfect, intuitive, most concise and still flexible CLI we could imagine?” For handling remote containers it borrows some good parts of the git remote API. (I say “we” here, but really the inestimable stgraber designed the CLI). This allows us to leave the legacy lxc api as-is for administering local containers (“lxc-create”, “lxc-start”, etc), while giving us a nicer API and easier administration using the new CLI (“lxc start c1”, “lxc start images:ubuntu/trusty/amd64 host2:new-container”).
Above all, lxd exports a new interface over the network, but entirely wrapped around lxc. So lxc will not be going away, and focus on lxd will mean further improvements for lxc, not a shift away from lxc.
S3hh's Blog 
So I take it stuff like lxc-attach is not being replaced by the lxc tool, since that is not something you can really do over REST, right? Or am I mistaken there?
Anyway, can lxc-{start,stop,create,attach,console} be used alongside lxd? Do you need to use -P /var/lib/lxd for each command?
Thanks!
Attach does work with lxd. Right now there is ‘shell’ which is a temporary hack, but Tycho’s working on ‘exec’ using websockets.
The lxd containers are stored in a special lxcpath so you’d always have to use ‘-P /var/lib/lxd/lxc’ with the lxc-* commands.
It’s possible that lxd will end up keeping some state making it un-recommended to use lxc-* with lxd containers, but since lxd uses the lxc go api, that would probably only be because using lxc-* could confuse lxd. (For the sake of speed of queries of large numbers of containers, lxd may want to cache container state, for instance).
Pingback: Serge Hallyn: Where does lxd fit in | Hi-tech news
Finally a clear explanation of LXD! I’ve been trying to understand what LXD is supposed to be, reading the official statements and info on the Ubuntu site only to be left with more confusion after every article. Kudos, s3hh! Sounds great. Will it be possible to remotely attach to a console via LXD? How will remote access to an LXD server instance be protected? A login and password, an SSH key, API key?
Connecting to a console is possible now. It’s the equivalent of ‘lxc-attach’, so it is protected by the certificates just as the rest of the container administration. See https://github.com/lxc/lxd/blob/master/specs/lxd-ssl-authentication.md for more details.
Thanks!