есть 2 сервера. 1 для работы, 1 для разработки. Системы стоят отлаженные, а ресурсов железа больше чем необходимо системе. в процессе работы возникает необходимость использовать новое ПО, и как часто это бывает с непосвященным пользователем — делается это путем проб и ошибок, а следовательно и лишний мусор на серверах. на серверах используется Debian и Ubuntu, хотелось бы их оставить хост системами с минимальными телодвижениями
в связи с вышеизложенным есть 2 задачи
1. разделить несколько сайтов по виртуальным машинам для того чтоб к некоторым из них дать безопасный для сервера вне данной виртуалки доступ
2. использовать виртуальную машину для тестов с ПО вроде Jabber, Mail, SQL, Phone сервера пр этом не вредя основному серваку (имеется ввиду чтоб после тестов и выбора снести виртуальную машину не оставив хвостов от тестируемого ПО) но и иметь с хост машины или с виртуальной доступ к тому же sql серверу или астериску
ну и как бонус было бы не плохо получить образ который можно было бы как виртуальную машину переместить с девелоперского сервера на основной в пару команд
изначально думал Virtualbox — удобно перемещать между машинами не взирая на железо, но почитав что пишут другие понял что это далеко не лучший выбор в плане виртуализации и производительности, да и наличие иксов мне не подходит, посмотрел в сторону VServer, но на сколько я понял — скомпрометировав контейнер в нем получаем угрозу хост системе, заинтересовал KVM и XEN, но последний показался слишком мудрым для обычного пользователя, поправьте меня если я дезинформирован и буду рад высказываниям гуру имеющих опыт в данной сфере
PS дабы сократить круг подозреваемых, ограничиваюсь рассмотрением 2-х вариантов KVM и XEN (Kronos). Вариант с Proxmox отпал ввиду того что необходимо с нуля поднимать сервак, да и по сути это тот же KVM только с графическим интерфейсом на базе Debian который не совсем понятно как актуально обновляется.
на сколько я понял из информации о нем — это обертка над KVM или OpenVZ
не понятно что в плане защищенности и есть ли опыт использования в моих целях.
так же не понятно что подразумевается в описании — тип ядра: модульное ядро?
> а вот это уже интереснее, можно поподробнее?
Linux машины обычно можно перенести обычным dd реального жёсткого диска в файл образа
Для Windows машины перед dd необходимо заменить драйвер контроллера жёстких дисков на стандартный.
Если речь идёт только о «поставить/удалить пакеты», то есть среда разработки более-менее вменяемая, то может быть достаточно банального chroot'а и отдельного ssh'а на отдельном IP в нём. Защиты от злодеев не даст, зато минимальный оверхед и удобство в перетаскивании данных туда/сюда.
попробую уточнить на примере.
я ставлю ejabber и он тянет за собой кучу пакетов, далее по каким-то причинам он меня перестает устраивать и я хочу сменить сервер на другой, при удалении сервера часть пакетов на сколько я понимаю могут остаться, виртуалка в данном случае решит проблему с этим — просто убил ее и поднял новую.
защита от злодеев имею ввиду для сайтов которые будут контролироваться не мною и к которым нужно дать доступ на моем сервере — как следствие могут быть залиты скрипты пытающиеся скомпрометировать всю систему, не обязательно владельцем сайта, достаточно того что он может пользоваться TotalComander, а как оттуда уводили пароли я уже не раз видел…
Используйте контейнеры OpenVZ. Это такой изолированный chroot и возможностью ограничения ресурсов. Оверхед у них на много меньше чем у виртуальных машин. Легко переносятся с машины на машину. Я знаю людей, которые их успешно используют для схожих с вами задачь. OpenVZ можно поставить на текущую машину или развернуть с нуля.
OpenVZ — перечрут-недовиртуалка. Память выделяемая через одно место, всякие vzcheck.sh, что бы понять что ему опять не нравится, привязка не только к конкретной OS, но и к конкретному ядру с дополнительными патчами которые не совместимы с другими.
Потери на виртуализацию при использовании аппаратной виртуализации настолько низки, что не стоит связываться с OpenVZ, можно использовать честный Xen и не знать горя
Работа с памятью была изменена в 2.6.32-ом ядре и теперь там все прозрачно. К ядру есть привзяка, но в ближайшем будующем и этот недостаток уйдет и все будет работать на мейнстримной ядре, правда с OpenVZ ядром функциональность будет шире. К примеру в мейстриме пока нет живой миграции.
Про потери все относительно. OpenVZ по прежнему вносит на порядок меньший оверхед и добавляет гибкости.
Вы просто не умели его готовить:). Ну и мы знали про кошмары наших пользователей и все поправили. Советую попробовать еще раз. Теперь работа с памятью ничем не отличается от виртуальных машин, как и у всех конфигурица двумя параметрами ram + swap.
ну там где мне нужны чруты я использую lxc, правда таких мест у меня немного, но спасибо, гляну, если оно так же просто разворачивается теперь, как lxc, то может и найду применение :)
Да, разворачивается просто. Проблема lxc в том что пока из них достаточно просто поафектить хостовую систему. К примеру там по дефолту разрешено писать в /proc/sysrq-trigger, это то что я сразу заметил. OpenVZ контейнеры местами работают более эффективно (например мемори менеджмент). В OpenVZ виртуализовано больше подсистема (например nfs). В OpenVZ есть живая миграция.
Все фичи постепенно переносятся в мейнстримное ядро (в том числе и при нашем участии) и появляются в LXC. А тем временем OpenVZ обрастает новыми фичами.
Версия тулзов OpenVZ, которая не будет работать поверх мейстримного ядра обещает появиться осенью: ru-openvz.livejournal.com/5561.html
спасибо, будем смотреть, может заведу виртуалку, как будет время под это на своем ксене :)
в lxc есть минимум еще одна совершенно прикладная проблема, с тем, что он может при стопе своего таза грохнуть сеть в основной машине, наблюдали в режиме бриджа, если память не изменяет. Но так как во-первых у нас это виртуалки для тестовых целей, а во-вторых всегда есть доступ до них через vnc с ксен-хоста это не показалось страшным
Рекомендую Но в бесплатной версии ограничение на 32Gb памяти и 1 проц, миграции межу серверами так же нет автоматической, но если диски с машинами общие, то погасить на одном серванте и поднять машину на другом не проблема.
Если я правильно понял, внешней хранилки нет.
В вашем случае систему виртуализации надо выбирать исходя из возможность live migration on local storage.
Такое можно построить на редхате по такому мануалу: alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial
Но хочу предупредить, любой самосад гарантированно прибавит вам седины. В моменты дедлайна все ляжет и ни один вендор вам не поможет.
XCP(проект Kronos), в случае если захотите смотреть в сторону Xen`а гуглите.
Если что, стучитесь в личку, подскажу-расскажу
Kronos — реализация XAPI собранная для Ubuntu/Debian
Основная проблема, что вы хотите сохранить текущую машину и сделать из неё виртуальный сервер.
Насколько я знаю, все они заточены под виртуализацию. Сделать из обычного сервера, сервер под виртуалки будет просто не эффективно. Лучше всего на основе текущего сервера сделать образ виртуальной машины, на основном железе развернуть уже с нуля систему виртуализации которую вы выберите. И работать дальше.
В чем заточка? Я слышал бабки на лавочке говорили?
В самом простом варианте вы можете устновить qemu-kvm и вы уже можете ранить виртуальные машины. Для упрощения работы с ними можно поставить libvirt, а на свой десктоп virt-manager.
Для установки OpenVZ придется поменять ядро, его можно взять из proxmox репозиториев сразу в deb или взять rpm с офф сайта и сконвертировать его в deb.
