[
https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554755#comment-14554755
]
Ian Downes commented on MESOS-2717:
-----------------------------------
(5) On slave recovery Containerizer::recover() is called. In the
MesosContainerizer this in turn calls Launcher::recover() on the launcher and
Isolator::recover() on each isolator. They each recover their state in
different ways but typically they examine the system to recover known
containers and identify unknown containers, e.g., a cgroup isolator will look
at the cgroups present.
> Qemu/KVM containerizer
> ----------------------
>
> Key: MESOS-2717
> URL: https://issues.apache.org/jira/browse/MESOS-2717
> Project: Mesos
> Issue Type: Wish
> Components: containerization
> Reporter: Pierre-Yves Ritschard
>
> I think it would make sense for Mesos to have the ability to treat
> hypervisors as containerizers and the most sensible one to start with would
> probably be Qemu/KVM.
> There are a few workloads that can require full-fledged VMs (the most obvious
> one being Windows workloads).
> The containerization code is well decoupled and seems simple enough, I can
> definitely take a shot at it. VMs do bring some questions with them here is
> my take on them:
> 1. Routing, network strategy
> ======================
> The simplest approach here might very well be to go for bridged networks
> and leave the setup and inter slave routing up to the administrator
> 2. IP Address assignment
> ====================
> At first, it can be up to the Frameworks to deal with IP assignment.
> The simplest way to address this could be to have an executor running
> on slaves providing the qemu/kvm containerizer which would instrument a DHCP
> server and collect IP + Mac address resources from slaves. While it may be up
> to the frameworks to provide this, an example should most likely be provided.
> 3. VM Templates
> ==============
> VM templates should probably leverage the fetcher and could thus be copied
> locally or fetch from HTTP(s) / HDFS.
> 4. Resource limiting
> ================
> Mapping resouce constraints to the qemu command line is probably the easiest
> part, Additional command line should also be fetchable. For Unix VMs, the
> sandbox could show the output of the serial console
> 5. Libvirt / plain Qemu
> =================
> I tend to favor limiting the amount of necessary hoops to jump through and
> would thus investigate working directly with Qemu, maintaining an open
> connection to the monitor to assert status.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
