[
https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14553786#comment-14553786
]
Pierre-Yves Ritschard commented on MESOS-2717:
----------------------------------------------
[~tnachen] You can indeed dynamically resize resources, but OS support for it
isn't always great (Linux for instance does not dynamically acknowledge new
resources). I'll prepare a design doc for this on the wiki.
[~idownes] Regarding 4 & 5:
4. I think I'll still need to give a resource profile to qemu, but wrapping it
in a cgroup makes sense
5. Re-establishing a connection to the qemu monitor will be simple enough. I
see that the docker containerizer just uses a name based matching mechanism to
rediscover its started containers, how does the mesos containerizer do it ?
> 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)
