[lxc-users] LXD an "hypervisor" for containers (based on liblxc)

[Stéphane Graber]

On Sat, Nov 08, 2014 at 03:06:51PM +0000, Rigved Rakshit wrote:
> Hello,
> 
> On 17:48, Sat, Nov 8, 2014 Guido Jäkel
> 
> wrote:
> 
> On 04.11.2014 18:33, Stéphane Graber wrote:
> > The main features and I'm sure I'll be forgetting some are:
> >  - Image based workflow (no more locally built rootfs)
> 
> Dear Stéphane,
> 
> is there any plan to support an (aehm, my) infrastructure design, where (at
> least) all the container rootfs's (and the containers configuration files)
> are on shared filesystem (e.g. NFS) used by the LXC-hosts. In fact, all the
> container private an shared data space is on a shared filesystem resorce,
> too.
> 
> In this design approach, each of the LXC hosts may serve any container.
> It's something like a LXC host cluster, a virtual LXC host in terms of CPU
> cores and RAM. And moving containers between different hosts (by stop and
> start) will need zero time for copying any image or data partitions. I use
> this to spread clustered containers (e.g. MySQL Master/Slave) for
> production on independent hardware or quickly rearrange some sets on the
> test stage.
> 
> It will be great to have some master where one may controll the containers
> without actually have to know where the container is running for the most
> of commands -- except something related to a concrete provisioning of
> course -- and may e.g. list the overall status of all containers on all
> hosts.
> 
> 
> 
>  This is exactly the setup someone using something like NetApp storage
> would use to store all their data while all the computation would occur on
> the LXC host cluster.
> 
> It would be great to see LXD managing all of this centrally!
> 
> Best Regards,
> Rigved

Yes, it is planned that the migration command (move) will check whether
the rootfs is already reachable by the target host and if it is, data
copy will be skipped (the container however may still need a uid/gid
remap).

The plugin system will also allow complex storage solutions to be
seamlessly integrated by having the migration ensure that the same block
devices are visible on the source and target hosts.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20141108/6f8434ab/attachment.sig>