[
https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000737#comment-15000737
]
Vaibhav Khanduja commented on MESOS-2717:
-----------------------------------------
Having a KVM integration with Mesos makes a lot of sense. Apparently there
seems to some projects around Hypervisor, which are using Docker as their
CLI/interface-
a) Intel Clear Containers:
The project aims at using kernel based virtualization - kvmtool for running
virtual machines, which may be ideally of same footprint as OS virtualized
containers. The interface is "lkvm", which is wrapped around "docker" giving a
similar user experience.
https://lists.clearlinux.org/pipermail/dev/2015-September/000049.html
b) Project bonneville at VMWare
The project is trying to bring VMWare hypervisor in the ecosystem and again
using Docker CLI as their main interface. The users shall use docker commands
to launch containers in small sized virtual machines (VMWare Photon).
https://blogs.vmware.com/cloudnative/introducing-project-bonneville/
c) Windows HyperV Containers.
Though I am not sure, I believe they too are working on having such similar
interfaces for their native containers and HyperV virtual machines.
https://msdn.microsoft.com/virtualization/windowscontainers/containers_welcome
> 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)
