[jira] [Commented] (MESOS-2717) Qemu/KVM containerizer
[ 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)
[jira] [Commented] (MESOS-2717) Qemu/KVM containerizer
[ https://issues.apache.org/jira/browse/MESOS-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539701#comment-14539701 ] Pierre-Yves Ritschard commented on MESOS-2717: -- One of the open points would be the willingness of mesos to adopt a solution that punts on part of the above points in a first versin. > 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)
[jira] [Created] (MESOS-2717) Qemu/KVM containerizer
Pierre-Yves Ritschard created MESOS-2717: Summary: 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)
