Запуск FreeBSD в Linux KVM

    Задача: запустить FreeBSD из-под Linux, желательно с минимумом изменений в Linux-системе при начальной настройке и обновлениях, возможностью запуска на рабочей станции и на сервере, и с минимальной потерей производительности.

    В качестве VPS-фермы можно использовать любой распространённый дистрибутив Linux. В нашем случае это будет Ubuntu 12.10 с ядром 3.5.0 для amd64.

    Гостевой системой будет FreeBSD 9.1 для i386. Архитектура i386 выбрана из-за существенно меньшего потребления ОЗУ 32-битными приложениями по сравнению с 64-битными.

    В качестве системы виртуализации будет использоваться Linux-KVM («Kernel-based Virtual Machine»).

    Краткое сравнение KVM с альтернативами


    Плюсы KVM:
    • не требует предварительной инсталляции гипервизора и планирования ресурсов, в отличие от Xen/ESXi/Hyper-V, и для изучения и тестирования может быть запущен на любом Linux-дистрибутиве, включая настольные,
    • в отличие от всех остальных систем виртуализации (кроме LXC и с оговорками OpenVZ), включён в базовое ядро Linux и развивается ключевыми Linux-разработчиками (в первую очередь — RedHat),
    • в отличие от LXC и OpenVZ, способен запускать произвольную ОС, в т.ч. Linux с собственным экземпляром ядра и набором драйверов.

    Минусы KVM:
    • процессор обязан иметь аппаратную поддержку виртуализации,
    • отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин,
    • из базовой системы отсутствует прозрачный доступ к файлам, процессам и консолям контейнеров (в LXC и OpenVZ он есть).

    Настройка окружения


    Дальше будем считать, что все образы дисков и файлы настроек хранятся в домашнем каталоге в подкаталоге virt:
    mkdir -p ~/virt && cd ~/virt
    

    Устанавливаем в Linux необходимое ПО:
    apt-get update && apt-get -y install kvm
    

    Собственно виртуализацию выполняет модуль в составе ядра, но в пакетах, которые apt-get установит по зависимостям, находятся управляющие и вспомогательные утилиты, KVM-специфичные настройки для основных Linux-сервисов (например, для udev) и т.д.

    Проверяем наличие аппаратной поддержки:
    kvm-ok
    

    Аппаратная виртуализация (а) должна поддерживаться процессором и (б) должна быть разрешена в BIOS'e. В противном случае KVM работать не сможет и команда запуска гостевой системы будет либо завершаться с ошибкой (если указан ключ "-enable-kvm"), либо переключаться в существенно менее производительный режим программной виртуализации на базе QEMU.
    Стандартный shell-сценарий kvm-ok выполняет типовые проверки и при неудачном результате советует способ исправления.

    Сеть для контейнеров


    KVM поддерживает множество вариантов организации гостевой сети (см. для примера краткий официальный обзор). В данный момент «man kvm» содержит 9! 8 вариантов ключа "-net" с несколькими десятками возможных подключей, причём зачастую "-net" нужно указывать в команде запуска контейнера дважды с разными наборами подключей — для создания гостевого интерфейса, и для создания интерфейса в базовой системе для связи с гостем. Возможно, сетевые настройки являются самой неочевидной частью KVM при начальном освоении.

    Для более-менее серьёзного использования имеют смысл два варианта:
    1. базовая система предоставляет гостевым прозрачный доступ во внешнюю сеть через т.н. сетевой мост («network bridge»),
    2. базовая система работает как маршрутизатор между внешней и гостевой сетью («router»).

    Оба требуют суперпользовательских привилегий, имеют в нашем случае одинаковый набор параметров для "-net ...", но отличаются набором действий в сценарии "-net ...,script=...", который KVM вызывает при старте контейнера для настройки сетевого интерфейса, созданного в базовой системе. Вариант с мостом несколько проще, поэтому наш сценарий ~/virt/kvm-ifup-bridge.sh будет делать следующее:
    • если мост отсутствует — создаёт его и добавляет в него внешний физический интерфейс,
    • назначает мосту такой же IP, как у физического интерфейса,
    • перемещает все маршруты с физического интерфейса на мост,
    • подключает в мост виртуальный интерфейс для связи с гостевой системой.

    #!/bin/sh
    
    # Constants
    BRIDGE_IFACE="br0"
    
    # Variables
    iface="$1"
    
    gwdev="$(ip route get 8.8.8.8 | grep ' via ' | sed -e 's,.* dev ,,' -e 's, .*,,' | head -1)"
    my_ip="$(ip addr list dev $gwdev | grep ' inet ' | sed -e 's,.* inet ,,' -e 's, .*,,' | head -1)"
    
    # Create and configure bridge
    if ! ip link list "$BRIDGE_IFACE" >/dev/null 2>&1
    then
            echo "Create bridge $BRIDGE_IFACE..."
            brctl addbr "$BRIDGE_IFACE"
            brctl addif "$BRIDGE_IFACE" "$gwdev"
            ip link set "$BRIDGE_IFACE" up
            ip addr add "$my_ip" dev "$BRIDGE_IFACE"
    fi
    
    # Move routes from physical iface to bridge
    if test "$gwdev" != "$BRIDGE_IFACE"
    then
            ip route list dev "$gwdev" | grep -v 'scope link' \
            | while read line; do
                    ip route delete $line dev "$gwdev"
                    ip route add    $line dev "$BRIDGE_IFACE"
            done
    fi
    
    # Add virtual iface to bridge
    ip link set "$iface" up
    brctl addif "$BRIDGE_IFACE" "$iface"
    

    В различных руководствах рекомендуется настраивать мост заранее, редактируя /etc/network/interfaces, но для тестовых целей на рабочей станции проще создавать его в тот момент, когда он становится действительно нужен, т.е. в момент первого запуска первого контейнера.

    Если во внешней сети недопустимо засвечивать дополнительные MAC-адреса, то вместо моста можно использовать маршрутизацию и ProxyARP. Если внешняя сеть разрешает ровно один MAC и один IP, тогда в базовой системе для выхода гостевых систем во внешний мир придётся использовать маршрутизацию, IP-адрес на внутренних интерфейсах и NAT. В обоих случаях потребуется либо настраивать в гостевых системах статические IP, либо настраивать в базовой системе DHCP-сервер для конфигурирования гостей.

    MAC-адреса для гостевых сетевых интерфейсов KVM способен генерировать автоматически при старте, но если планируется выпускать гостей во внешний мир через сетевой мост, лучше назначить им постоянные MAC-адреса. В частности, если во внешней сети запущен DHCP-сервер, это поможет гостевой системе получать от него одинаковый IP при каждом запуске. Сначала «сочиним» базовый MAC-адрес:
    perl -e '$XEN_RESERVED = "00:16:3e"; printf "%s:%02x:%02x:%02x\n", $XEN_RESERVED, int(rand(0x7f)), int(rand(0xff)), int(rand(0xff));'
    

    Для контейнеров будем заменять последнее число на их порядковый номер. Этот же номер будем использовать для их имён и для VNC-консолей. Например, контейнер с номером 25 будет называться «kvm_25», иметь MAC 00:16:3e:xx:xx:25 и слушать VNC-подключения на порту 5925. Чтобы не огрести геморроя с разными системами счисления не иметь лишних проблем, рекомендуется выбирать номера от 10 до 99. Разумеется, такой подход не используется в VDS-хостинге, но для личных нужд он годится.

    План действий


    1. Загружаемся с образа CD, инсталлируем ОС на пустой образ hdd, выключаем VM.
    2. Редактируем сценарий запуска (отключаем CD), загружаемся с hdd, настраиваем в гостевой ОС поддержку virtio, выключаем VM.
    3. Редактируем сценарий запуска (типы диска и сети меняем с IDE и Realtek на virtio), загружаемся.

    Подготовка к первой загрузке


    Скачиваем ISO-образ установочного диска FreeBSD:
    wget http://mirror.yandex.ru/freebsd/releases/ISO-IMAGES/9.1/FreeBSD-9.1-RELEASE-i386-disc1.iso
    

    Создаём образ жесткого диска:
    kvm-img create -f qcow2 freebsd9.img 8G
    kvm-img info freebsd9.img
    

    Формат образа выбирается ключом "-f": raw (default), qcow2, vdi, vmdk, cloop и т.д. Raw понятен любому ПО, но предоставляет минимум возможностей и сразу занимает максимально возможное место. Qcow2 компактнее (поддерживает динамическое увеличение размера) и функциональнее (поддерживает снимки, сжатие, шифрование и т.д.), но распознаётся только системами на основе QEMU.

    Первый запуск и инсталляция


    Сценарий для запуска ~/virt/freebsd9.start
    #!/bin/sh
    
    MACBASE="00:16:3e:33:28"
    VM_ID=10
    DIR=$HOME/virt
    
    sudo kvm \
    -net "nic,model=rtl8139,macaddr=$MACBASE:$VM_ID" \
    -net "tap,ifname=tap$VM_ID,script=$DIR/kvm-ifup-bridge.sh,downscript=/bin/true" \
    -name "kvm_$VM_ID" \
    -enable-kvm \
    -m 512M \
    -hda $DIR/freebsd9.img \
    -cdrom "$DIR/FreeBSD-9.1-RELEASE-i386-disc1.iso" \
    -boot order=d \
    
    ## END ##
    

    В открывшемся окне должны запуститься CD Loader и установщик FreeBSD. Выполняем установку обычным образом. Почти все параметры можно оставить по умолчанию.

    Пояснения к команде запуска


    Sudo необходим, т.к. для создания TAP-интерфейса KVM-загрузчику требуются права суперпользователя.

    Два ключа "-net" создают два соединенных друг с другом сетевых интерфейса: TAP в базовой системе и виртуальный Realtek-8139 в гостевой.

    Ключ "-enable-kvm" гарантирует, что QEMU не выберет автоматически режим программной эмуляции, если KVM не смог запуститься.

    Ключ "-name" определяет заголовок консольного окна, может использоваться для поиска в списке процессов и т.д.

    Загрузочным диском выбран CD ("-boot order=d"). Опция имеет силу только при включении контейнера, т.е. при перезагрузке поиск системы начнётся с первого диска.

    Ключ "-m" задаёт размер гостевого ОЗУ. По умолчанию — 128 мегабайт. Для работы установщика этого может быть достаточно, но уже после успешной установки первая же попытка собрать из портов большой проект при "-m 256M" и разделе подкачки на 512 мегабайт (размер автоматически выбран установщиком) вызвала kernel trap.

    Загрузчик KVM работает как обычный пользовательский процесс, поэтому для выключения виртуальной машины достаточно просто нажать в консоли Ctrl+C (естественно, при запущенной гостевой ОС лучше этого не делать и пользоваться poweroff в гостевой консоли). Связь с системой виртуализации в ядре загрузчик осуществляет через символьное псевдоустройство /dev/kvm, поэтому запускать виртуальные машины может любой пользователь, имеющий право писать в него. Как правило, для таких пользователей в системе создаётся группа "kvm".

    Для запуска в фоновом режиме у загрузчика есть ключ "-daemonize".

    Второй запуск и настройка virtio


    Перед запуском в сценарии freebsd9.start необходимо закомментировать строки "boot" и "cdrom". Затем запускаем его и после завершения загрузки FreeBSD входим в её командную строку с правами суперпользователя.

    Гостевые драйверы поддержки virtio для FreeBSD пока не включены в базовое ядро, а распространяются в виде порта, поэтому нам потребуется установить дерево портов:
    portsnap fetch extract
    

    Для сборки драйверам требуются исходные тексты текущего ядра:
    csup -h cvsup2.ru.FreeBSD.org /usr/share/examples/cvsup/standard-supfile
    

    После этого собираем и инсталлируем сами драйверы:
    make -C /usr/ports/emulators/virtio-kmod install clean
    

    В /boot/loader.conf обязательно должны быть добавлены следующие строки:
    virtio_load="YES"
    virtio_blk_load="YES"
    virtio_pci_load="YES"
    virtio_balloon_load="YES"
    if_vtnet_load="YES"
    

    Их можно скопировать из /var/db/pkg/virtio-kmod*/+DISPLAY. Если забудете — ядро FreeBSD вывалится при загрузке в приглашение «mountroot>», потому что не сможет увидеть дисковое устройство с корневой ФС. Потребуется перезагружаться, заходить в командную строку boot-менеджера и вручную загружать перед ядром эти модули командой «load».

    В /etc/rc.conf надо вставить одну из двух строк:
    ifconfig_vtnet0="DHCP"      # ..ifconfig_re0 можно удалить
    ifconfig_vtnet0_name="re0"  # ..ifconfig_re0 надо оставить!
    

    Если к старому сетевому интерфейсу уже привязано большое количество настроек, второй вариант позволяет избежать их повсеместного изменения. Но он же делает общую схему чуть более запутанной.

    В /etc/fstab надо заменить все "/dev/ada" на "/dev/vtbd". Если диск размечался установщиком автоматически, fstab станет таким:
    # Device	Mountpoint	FStype	Options	Dump	Pass#
    /dev/vtbd0p2	/		ufs	rw	1	1
    /dev/vtbd0p3	none		swap	sw	0	0
    

    Если забудете или неправильно отредактируете fstab — при следующей загрузке попадёте в приглашение «mountroot» и будете вынуждены вручную набирать в нём «ufs:/dev/vtbd0p2».

    Что такое virtio и зачем он вообще нужен?


    Если в контейнер предоставляется виртуальная копия реально существующего устройства (такого как сетевая карта Realtek или SCSI-диск), обращения к нему сначала проходят через драйвер устройства в гостевой системе. Драйвер преобразует высокоуровневые вызовы чтения-записи данных в низкоуровневые операции с прерываниями, регистрами, портами ввода-вывода и т.д. Их перехватывает система виртуализации и выполняет обратную работу — переводит в высокоуровневые вызовы для внешней системы (например, чтения-записи файла-образа диска).

    Если в контейнер предоставляется устройство типа virtio, драйвер гостевой системы немедленно передаёт данные во внешнюю систему и обратно. Драйвер упрощается, низкоуровневая виртуализация физических ресурсов не требуется.

    Пишут, что переход на virtio ускоряет в гостевой системе диск вдвое, а сеть почти на порядок.

    Ещё одна интересная возможность virtio связана с динамическим выделением памяти для гостевой системы ("ballooning") и объединением блоков памяти с одинаковым содержимым (KSM, «Kernel Samepage Merging»).

    VirtualBox и KVM используют совместимый механизм virtio, поэтому набор гостевых драйверов для них одинаковый. В Linux гостевые драйверы уже включены в стандартное ядро, для FreeBSD распространяются в виде порта (см.выше), для Windows написаны разработчиками KVM (см.тут).

    Третий запуск


    Меняем в ~/virt/freebsd9.start строки с указанием сетевого интерфейса и диска:
    -net "nic,model=rtl8139,macaddr=$MACBASE:$VM_ID" \
    -hda $DIR/freebsd9.img \
    

    … на следующие:
    -net "nic,model=virtio,macaddr=$MACBASE:$VM_ID" \
    -drive "file=$DIR/freebsd9.img,if=virtio" \
    

    Если загрузка FreeBSD пройдёт успешно, можете убедиться с помощью следующих команд, что виртуальные устройства теперь используются:
    ifconfig
    df; swapinfo
    kldstat
    dmesg | grep vt
    

    Гостевая консоль


    По умолчанию KVM отрисовывает гостевую консоль в графическом окне с помощью библиотеки SDL. Такой вариант плохо подходит для запуска контейнера в фоновом режиме, для запуска на сервере без графики и для доступа к консоли по сети.

    Для решения этой задачи KVM-контейнер может предоставлять доступ к гостевой консоли по сетевому протоколу VNC. В ~/virt/freebsd9.start вставьте в параметры запуска:
    -vnc localhost:$VM_ID \
    

    Теперь при запуске контейнера KVM откроет не графическое окно, а сетевое подключение. Увидеть его можно, например, командой "sudo netstat -ntlp | grep -w kvm".

    Установите клиентское приложение (например, tightvncviewer) и подключитесь к консоли:
    apt-get install vncviewer
    vncviewer :10
    

    Примечание: если в окне VNC нет реакции на клавиатуру, кликните по нему.

    VNC-соединение может быть защищено паролем, но назначить пароль непосредственно из командной строки, к сожалению, невозможно. Потребуется либо подключаться к управляющей консоли контейнера через отдельный управляющий сокет (краткое описание, как её настроить и как к ней подключиться), либо открывать её в основном VNC-окне нажатием Ctrl+Alt+Shift+2.

    В дополнение к SDL и VNC, поддерживается текстовый интерфейс на базе curses (ключ "-curses" или "-display curses"). Теоретически он мог бы быть удобен для фонового запуска в screen. На практике KVM направляет в создаваемую консоль собственный диагностический мусор и делает её использование неудобным.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 26
      +5
      > отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин
      Если не секрет, а чем libvirtd + virt-manager не устроили?
        +1
        > Если не секрет, а чем libvirtd + virt-manager не устроили?

        Тяжеловесностью, глючностью и заточенностью под представления авторов. Возможно, за год с момента последней проверки ситуация изменилась к лучшему, но тогда было так.

        Например, «virsh shutdown» менял статус контейнера на «shutdowning...», но kvm-контейнер продолжал работать до «killall kvm» на ферме либо «poweroff» в гостевой системе.

        Конфиги контейнеров (доменов в терминологии либвирта) требовалось менять при миграции с одной фермы на другую (например, между Дебианом и Центосом), потому что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров.

        Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, которых при прямом использовании КВМ не было и в помине:

        1) Сначала либвирт не давал КВМу создавать TAP-интерфейсы из-за зарезанных привилегий.

        2) Когда это победили и обновились с libvirt с 0.6 из Центоса до 0.7 из Епеля, появились новые ограничения привилегий, из-за которых настроенные конфиги снова нерабочими.

        3) Если в конфигах либвирта включались DHCP и/или TFTP, либвирт автоматически запускал dnsmasq, но с такими параметрами, что на TAP-интерфейсах использовать его было нельзя: с ключом «bind-interfaces» он их просто не видел, потому что запускался либвиртом ДО создания интерфейса.

        Получилось, что своими проблемами либвирт зря отнял время, а в плане облегчения работы с КВМ никак не помог. Скорее наоборот, разобраться непосредственно с КВМ оказалось бы быстрее. Но это только мой личный опыт, коллективный разум вроде бы считает иначе.
          0
          libvirt действительно был глючноват пару лет назад. Сейчас очень даже ничего.

          1. virsh destroy не?

          2.Ну как ещё то, если у каждого дистрибутива свой велосипедик? Как раз vibvirt и призван привнести некий уровень абстракции в это дело.

          3. Бред какой-то. Прямо сейчас у меня работает два конфига, один как роутер, второй как NAT. По умолчанию действительно bridge, но это меняется в один клик.

          4. Не знаю, TAP не делал, но 0.6 это древность какая-то.

          5. И правильно что он dnsmasq так запустил. По умолчанию dnsmasq считает своим долгом раздавать IP во все внешние сети, куда дотянется. Кстати, там есть какая-то версия dnsmasq с багом, где bind-interfaces не работает. Так вот libvirtd вообще не запустится с ней.

          Не знаю как на счёт freebsd, но я запустил netbsd6 через virsh, без каких либо проблем с конфигами по дефолту. Это заняло у меня 5 минут. Мне кажется вы придумали себе проблему и отчаянно с ней боритесь, а проблемы то особо и нет.
            0
            1. не. разбирайтесь, чем destroy отличается от shutdown.
            2. если особенности фермы запихнуты в настройки всех контейнеров, то это какой-то странный уровень абстракции.
            3. менялось так, как написано. проблемы были такие, как перечислены.
            4. версия из последнего на тот момент официального релиза rhel. все претензии к редхату.
            5. откройте для себя ключ dnsmasq --except-interface. если нужна более серьезная защита, можете почитать про iptables.
              0
              1. Я понимаю, чем они отличаются. У вас машина не слышит ACPI, но это не проблема не virt-manager явно.
              2. pastebin.com/rdnLTBmB Где тут что-то дистрибутиво-зависимое то?
              3. virt-manager 0.6.1 Monday Jan 26th, 2009 Я думаю что, обсуждать софт 4 летней давности смысла никакого нет
              4. см п3
              5. Тот же принцип, вид с боку. Зачем ещё городить забор из iptables, когда есть нормальное решение привязать dhcp сервер туда куда нужно?
                0
                2. /usr/bin/qemu-kvm
                Welcome to the real world, Luke.
        +2
        «отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин»…
        Тут вы батенька не правы, очень даже удобно:
        image
          +1
          Я выше написал, чем лично меня не устроила libvirt.
          Вряд ли virt-manager настолько умный, что умеет обходить её ограничения.

          Формально из того, что перечислено на странице www.linux-kvm.org/page/Management_Tools,
          для начального знакомства к KVM лучше всего подходит AQemu:
          лёгкая GUI-оболочка без собственных представлений о том, что правильно, а что нет.

          Увы, но на практике оказалось, что он пока слишком сырой: в первый раз кое-как запустился,
          но когда создал в ~/.aqemu описание первой виртуалки, стал стабильно падать с ошибкой сегментирования прямо при запуске.
            +1
            Не знаю, у меня описанных вами проблем с virt-manager небыло.
            В качестве хостовой системы ubuntu 12.10 server, изначально ставил 12.04 но случайно обновил, а переустанавливать было лень.

            -...что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров. — на мой взгляд так правильно
            -Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, — у меня такого небыло, специально экспериментировал с настройками сети, NAT есть и работает, DHCP работает. Возможно Ваши проблемы с виртуальными интерфейсами связаны с настройками Selinux, который в CentOS включён по-умолчанию.

            По поводу тяжеловесности virt-manage — я не замечал, но возможно по тому, что в качестве хостовой системы у меня достаточно мощный сервер.
              0
              SELinux был точно не причем, т.к. его принято отключать сразу после инсталляции.
              Проблема была одинаковой в Дебиане и Центосе.

              Возможно, за год libvirt подружили с NATом, но тогда потребовались совершенно
              лишние пляски с бубном, после чего я для себя решил дела с ним больше не иметь.
          +3
          Посмотрите в сторону Proxmox, вполне удобно и даст Вам KVM виртуализацию с GUI обвязкой.
          Proxmox cluster будет вполне удобно для фермы.
          Я гоняю на ней в продакше FreeBSD через KVM безо всяких проблем, даже очень старые типа 4.1.
          C другой стороны они потребовали гораздо меньше танцев при переноски с VmWare платформы виртуализации, чем Win2k например.
            0
            Спасибо, про Proxmox я знаю :) Запускал под ним бухгалтерскую Венду с терминал сервером, Астериски, контроллер Unifi и много другого интересного. В данном случае он плохо подходит под требования задачи — смотрите первое предложение статьи:
            Задача: запустить FreeBSD из-под Linux, желательно с минимумом изменений в Linux-системе при начальной настройке и обновлениях, возможностью запуска на рабочей станции и на сервере

            Proxmox: требует продуманной инсталляции на отдельный компьютер; вряд ли пригоден для экспериментов на десктопном компе; засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами, которым по хорошему место в отдельном контейнере; ради поддержки OpenVZ построен на сильно неновом и редко обновляемом кастомизированном ядре; имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.

            То есть у Proxmox есть своя ниша в Enterprise, где он imho лучший, но мне требовалось такое решение, которое можно было бы запустить на существующих серверах без кардинальных переделок, и иметь возможность до задействования серверов по максимуму тестировать его локально.
              0
              >Proxmox: требует продуманной инсталляции на отдельный компьютер;

              В общем и целом неправда, поверх дебиана ставится.

              >засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами,

              Сам интерфейс работает через апач, который работает совсем даже без рутовых прав:
              2233 root 20 0 268M 41780 5680 S 0.0 0.1 0:07.86 `- /usr/sbin/apache2 -k start
              208590 www-data 20 0 276M 40884 3908 S 0.0 0.1 0:00.13 | `- /usr/sbin/apache2 -k start
              208573 www-data 20 0 276M 40916 3924 S 0.0 0.1 0:00.20 | `- /usr/sbin/apache2 -k start

              >построен на сильно неновом и редко обновляемом кастомизированном ядре

              Первое не особо верное, они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:

              forum.proxmox.com/threads/12236-Updates-for-Proxmox-VE-2-2-including-QEMU-1-3

              >имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.

              Кластер пересоздать несложно, виртуалки никуда не денутся при этом, более того, их даже останавливать не придется. Вот, например:
              undefinederror.org/how-to-reset-cluster-configuration-in-proxmox-2/

              Единственное что в нем существенно — если ставить не на дебиан, то можно заиметь себе ненужных развлечений. Ну а для вашего случая вообще можно без танцев с мостами и конфигами. Я написал внизу, как именно.
                0
                >> Proxmox: требует продуманной инсталляции на отдельный компьютер;
                > В общем и целом неправда, поверх дебиана ставится.


                Спасибо, кэп :) У Вас на десктопе Дебиан?
                Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?
                «Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?

                > интерфейс работает через апач, который работает совсем даже без рутовых прав:

                И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
                и прочее, что очевидно требует суперпользовательских привилегий.
                Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?

                Кстати, вот неплохой отзыв: klinkov.ya.ru/replies.xml?item_no=2112
                У меня таких страшных косяков не было, возможно потому, что задачи для Проксмокса были попроще.

                > они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:

                Ядро скорее уж не от RHEL, а от Parallels: download.openvz.org/kernel/branches/rhel6-2.6.32/stable/
                То, что на pve.proxmox.com/wiki/Proxmox_VE_Kernel написано "based on RHEL6x", для ovz-ядра верно.

                Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу.
                На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:
                forum.nag.ru/forum/index.php?showtopic=70612&view=findpost&p=653589
                  0
                  >Спасибо, кэп :) У Вас на десктопе Дебиан?

                  Работаю я с линуксовой машины, на которой внезапно да, дебиан.

                  >Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?

                  Громоздил уже.

                  >«Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?

                  Не надо, чего там продумывать то? Имена мостам придумать?

                  >И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
                  >и прочее, что очевидно требует суперпользовательских привилегий.
                  >Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?

                  А там свои права есть, это уж как настроишь. Ну и да, общается этот интерфейс с сервисами которые из-под рута крутятся.

                  >Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу. На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:

                  Да, такое может быть. У меня еще правда не было, хотя есть и весьма новые сервера.
            0
            Если уж действительно с минимумом возни, то почему из командной строки не создать и не запустить виртуалку? Например, так для дебиана, в других системах аналогично, только kvm по-другому нужно ставить:

            aptitude install kvm
            mkdir /srv/kvm
            cd /srv/kvm
            
            wget ftp2.ru.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/FreeBSD-9.1-RELEASE-amd64-disc1.iso
            mv FreeBSD-9.1-RELEASE-amd64-disc1.iso freebsd.iso
            
            qemu-img create /srv/kvm/kvm1.raw -f raw 10G
            kvm -rtc base=localtime -smp 1 -m 1024 -vnc '10.0.0.1:0' -boot d kvm1.raw -net nic,vlan=0,model=e1000 -net tap,vlan=0,ifname=tap0,script=no -cdrom freebsd.iso &
            
            ip a a 10.2.2.1/29 dev tap0 
            ip link set dev tap0 up
            iptables -t nat -A POSTROUTING -s 10.2.2.2 -o eth0 -j MASQUERADE
            

            Когда фряха воткнется и virtio тоже, заменить model=e1000 на model=virtio.
              0
              А что мешает вручную в livecd или fixit поставить с virtio и блекджеком??
                0
                Автор не предложил такой вариант. А я фряху редко ставлю, и не знаю. Если знаете конкретно как, напишите.
                  0
                  Берете пакет отсюда (сейчас только amd64, но я думаю нет проблем собрать один раз пакет и ставить из локальной сети)
                  people.freebsd.org/~kuriyama/virtio/

                  Делаете как здесь только с ufs
                  www.infracaninophile.co.uk/articles/install-on-zfs/

                  Соответственно работаете с virtio подсистемами.

                  Для установки изначального пакета можно собрать свой livecd или не геморроится и подключить вторую сетевуху с em1000 и по ее коннекту поставить virtio драйвер. Потом ее отключить в настройке kvm.

                  Кстати:
                  csup -h cvsup2.ru.FreeBSD.org /usr/share/examples/cvsup/standard-supfile
                  это не будет работать скоро кстати, так как код переводят на svn

                  И добавлю в 10ке обещают virtio в базовом пакете. Так что может в 9.3 он тоже будет в базовом.
                    0
                    Дополнительный бонус:

                    Можно все комманды сохранить и записать в shell скрипт.
                    Потом ставить из livecd закачкой из сети скрипта.
                0
                1) Не мешает для гарантии включать sysctl net.ipv4.ip_forward=1

                2) В домашней или офисной локалке ProxyARP имхо предпочтительнее маскарадинга,
                потому что позволит без дополнительных настроек заходить на виртуалку с соседних компов.
                И не сильно сложнее в настройке.

                3) И без dnsmasq не комильфо, на гостевой системе придётся настраивать статический IP.
                  0
                  1) это я пропустил, да. без этого не взлетит.

                  2) ну тогда уж мост настроить, интерфейс смотрящий в эту локалку в него слейвом поставить, IP к мосту прибить, и интерфейс виртуалки тоже в этот же мост. Не проще будет?

                  3) а не пофигу для тестов то?
                  0
                  4) ip+iptables корректнее выносить в -net tap,script=kvm-ifup

                  5) vlan=0 не нужен, ifname=tap0 незачем (kvm-ifup получит автоматическое имя интерфейса в $1) и вредно (tap0 может быть уже занят).
                    0
                    4) Так вся моя идея в том, чтобы без скриптов обойтись. Вообще.

                    5) Про vlan не знал, завтра проверю. А про tap, я думаю что чтобы проверить в общем-то самое то. Я когда с KVM разбирался, скачал livecd и прибил интерфейс и IP руками. А если интерфейс уже занят, KVM насколько помню ругнется и не взлетит.
                    0
                    6) -boot d kvm1.raw
                    очепятка? не должно быть "-hda kvm1.raw"?
                      0
                      Не исключено, но возможно заработает и так. Проверить бы надо.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое