Difference between revisions of "GSoC Ideas"
From Linux-VServer
(→libvirt Integration and Testing) |
(→iptables proxy and policy daemon) |
||
| Line 19: | Line 19: | ||
=== iptables proxy and policy daemon === | === iptables proxy and policy daemon === | ||
| − | Kernelside proxy, Userspace policy daemon | + | ''Kernelside proxy, Userspace policy daemon'' |
| + | |||
| + | Linux-VServer uses IP Isolation, so things like iptables cannot be allowed | ||
| + | inside a guest without applying some sanity checks and general host policy. | ||
| + | |||
| + | Part of this is a kernel side proxy mechanism, which will relay the netlink | ||
| + | commands issued from e.g. iptables inside a guest to a policy daemon running | ||
| + | on the host. | ||
| + | |||
| + | The other part is the policy daemon which has to check the requests for | ||
| + | plausibility, and if applicable implement them in a way which doesn't harm | ||
| + | the host or other guests (e.g. on a separate chain). | ||
=== hard limits for CFS scheduler === | === hard limits for CFS scheduler === | ||
Kernel modification (target upstream) | Kernel modification (target upstream) | ||
Revision as of 20:59, 11 March 2009
Contents |
Google Summer of Code Ideas
Minimalistic Web Frontend
Userspace, php or similar
Web Frontend or Framework to do basic administrational tasks like
- creating and destroying guests
- starting and stopping guests
- monitor status and resources
libvirt Integration and Testing
Userspace, scripting, testing
preliminary work exists, probably needs to be adapted to recent versions and integrated with the libvirt folks.
iptables proxy and policy daemon
Kernelside proxy, Userspace policy daemon
Linux-VServer uses IP Isolation, so things like iptables cannot be allowed inside a guest without applying some sanity checks and general host policy.
Part of this is a kernel side proxy mechanism, which will relay the netlink commands issued from e.g. iptables inside a guest to a policy daemon running on the host.
The other part is the policy daemon which has to check the requests for plausibility, and if applicable implement them in a way which doesn't harm the host or other guests (e.g. on a separate chain).
hard limits for CFS scheduler
Kernel modification (target upstream)
