[ https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14550964#comment-14550964 ]
Ian Downes commented on MESOS-2717: ----------------------------------- The containerizer interface was designed to support this and I'd be happy to shepherd any efforts. Some initial notes: 1) I agree, bridged networking would be simplest. 2) This could be done by the custom executor. Work is being started on making IP addresses a global resource. 3) The fetcher should be used. Patches for caching objects will soon be committed. 4) You could just run the VM inside cgroups/namespaces etc. and leverage the existing code for managing them. 5) Be aware that you need to architect the code so the slave can be restarted while VMs/containers are running, i.e., you'll need to re-establish said connections during slave recovery. > 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)