Почему контейнеры - это очень сложно управляемая технология для системного администратора?

Сейчас контейнеры - настоящий тренд в Linux ядре и современных дистрибутивах. Но почему-то при активном развитии ядра все забывают о user space, что приводит к очень большим проблемам при эксплутации контейнеризации.

Все ниже сказанное про актуальные версии утилит в CentOS 6 и репозитории Epel в контексте технологии OpenVZ.

* netstat: не имеет возможности изоляции, а также не представляет возможности посмотреть соединения только HWN 0 (физического сервера)
* lsof: его использование на OpenVZ почти невозможно из-за сотен и тысяч ошибок вида: lsof: no pwd entry for UID 33
* iotop: не имеет поддержки отображения дисковой нагрузки от отдельных контейнеров
* top: не имеет поддержки как отображения CTID, так и отображения нагрузки в контейнере
* ps: не имеет стандартной возможности фильтрации по CTID, не имеет возможности отображать только процессы виртуальной машины
* htop: имеет (!) поддержку отображения CTID процессов, но не умеет отображать нагрузку из виртуальных окружений
* ipcs: возможности просмотра IPC ресурсов конкретного контейнера нет, стандартно отображаются только ресурсы ноды

Что делать системным администраторам? В общем-то выбор невелик - писать многочисленные обвязки в стиле: https://gist.github.com/pavel-odintsov/3e7351ba4ceca33b8cc6

Почему такая ситуация ОЧЕНЬ ОПАСНА? А Вы попробуйте просмотреть слушающие (LISTEN) соединения на аппаратной ноде OpenVZ. Это просто рай для руткитов, там слона можно спрятать, так как возможности просмотреть все соединения _именно ноды_ тупо не существует без собственного ПО.

Ранее в проекте OpenVZ были утилиты vzps и vztop (тыц, тыц), которые работали просто замечательно (на CentOS 5) и выручали много раз, но в CentOS 6 их развитие было прекращено, а в связи с тем, что их код закрыт - нет возможности их портировать на CentOS 6 хотя бы вручную.