Довелось разворачивать довольно сложную систему на чужом хосте. Тут главное чужое не повредить. К тому же дистрибутив непривычный. Решил запустить свою шняжку в виртуальной машине qemu. К ней прилагается консольный монитор, который целесообразно запускать в screen в headless-режиме:

su -c 'screen qemu-system-x86_64 -m 2048 -hda /path/to/virtual/hz.img -net nic,vlan=0,model=e1000  -net tap,script=no,vlan=0 -monitor stdio -vga none' 

Возвращаясь по ssh на удаленный хост и восстанавливая сессию screen, можно контролировать расход памяти виртуальной системы, управлять устройствами и т.п.

Если же просто нужно запустить qemu в бакграунде, подойдет такая команда:

#!/bin/bash

qemu-system-x86_64 -m 2048 -hda hz.img            \
	-net nic,vlan=0,model=e1000                   \
	-net tap,script=no,downscript=no,vlan=0 -k ru \
	-nographic 1>/dev/null 2>/dev/null &
sleep 3
ifconfig tap0 192.168.111.1
echo Qemu is started.

Она еще и ответный интерфейс заодно конфигурирует.

Помимо использования таких вещей, вроде Xen, которые выполняют код непосредственно напрямую центральным процессором, иногда требуется настоящая полная виртуализация платформы x86, для этих целей и был создан проект bochs.

Тут полная виртуализация платформы x86, можно выбрать разные виды процессоров, периферийных устройств и т.д. и т.п.



Список фишек:
bochs.sourceforge.net/doc/docbook/user/features.html

Сделал все вот по этому мануалу. Рекомендую к прочтению!
Автору большое спасибо! Сэкономил кучу времени.

Компьютер без сети — вещь довольно бесполезная. Это касается и виртуальных машин, тем более, что к ним иногда иначе, чем через сетевой интерфейс и не подберешься. Для технологии VirtualBox есть несколько способов сетевого соединения. Все они очень толково, с картинками, разжеваны здесь. Самым эффективным способом подключения к виртуальному компьютеру считается сетевой мост. Но вот незадача: создавая его, мы должны пожертвовать каким-то реальным устройством компьютера-хозяина: wifi-картой, ethernet-разъемом и т.п. Это, прямо скажем, несерьезно. Для решения проблемы используется пакет vde2. С его помощью можно создать виртуальный сетевой интерфейс, или даже несколько (tap0, tap1 и т.д.), например:

vde_switch -tap tap9 -daemon

После этого в настройках VBox нужно сделать примерно так:



Далее, настроив сетевые интерфейсы реальной и виртуальной машин так, чтобы они принадлежали к одной сети, можно устанавливать связь между ними. Tap-интерфейсы используются и для подключения к сети виртуальных машин Qemu, но там всё проще, т.к. qemu умеет создавать их сама, по мере необходимости.

SmartOS — довольно интересное сочетание таких технологий, как KVM и Zones, DTrace, ZFS. Основой является ядро Illumos (OpenSolaris, OpenIndiana).

Примеры создания виртуальных машин и разделов ZFS тут.

Будем надеяться, что у проекта будет большое будущее.

В галерее susestudio.com можно обнаружить довольно полезные вещи, например — готовый к работе образ с OpenStack.

Краткая инструкция по запуску виртуальных машин в облаке на OpenStack:

http://en.opensuse.org/SDB:Cloud_OpenStack_Quickstart

Сейчас многоядерными компьютерами никого не удивишь. Насколько эффективно такие системы используются? Как правило, одно из ядер простаивает, т.к. для полноценной работы нужны еще и специальным образом написанные программы. Но кое-что можно сделать и средствами bash. Например, если за компьютером одновременно работают два человека, каждый в своей вртуальной машине (не важно, по сети или с помощью, например, multiseat), вот как, можно запустить каждую на собственном ядре:

su win1 -c 'taskset -c 0 qemu bla-bla-bla'
su win2 -c 'taskset -c 1 qemu bla-bla-bla'

Товарищи помогите разобраться…
Что имеем:
Intel® S5000PAL

Начну с самого начала. Стало необходимо сделать на данном сервере виртуализацию, материнка и камушки 2х Intel Xeon E5410 Harpertown поддерживают Intel VT, но при попытки включить ее в БИОСе я данную строку не обнаружил, чем был изрядно удивлен.

Решил обновить БИОС, но тут тоже все не ладно, прошивальчик ругается на то, что не может считать id и версию прошивки. Решил глянуть в БИОСе и действительно на все параметры которые он должен показать в Server manager > System information везде прочерки ( материнка не знает как ее зовут какая версия и тд вообщем о себе незнает ничего).Удалось обновить только BMC, но ни к чему это не привело.

После обнаружил, что если сбросить БИОС джампером, то искомая мною строка Virtualization Technology появляется, но информации в Server manager > System information попрежнему нет. В БИОСе Intel VT поставил Enable, ребутнул, захожу снова в БИОС нет данной строки…

Может кто подскажет, что делать?
P.S. Версию прошивки БИОСа кторая стоит сейчас незнаю(

Контейнерная виртуализация LXC (Linux Containers) появилась в ядре с версии 2.6.29. Технология хороша тем, что не требует специфических патчей ядра в отличии от OpenVZ и очень проста в использовании. В Debian появилась в Squeeze.

Устанавливаем:

apt-get install lxc bridge-utils debootstrap

К слову, bridge-utils нужен только в случае настройки сети через мост, т.е. чтобы система в контейнере имела виртуальный сетевой интерфейс со своим mac и ip адресом. Я в данном топике настраивать мост не буду, мне LXC нужен в качестве удобного средства попробовать софт не засоряя основную систему. Без настройки моста контейнеры используют интерфейс основной машины.

Прописываем в /etc/fstab

cgroup          /cgroup         cgroup  defaults        0       0

Создаем директорию и монтируем:

mkdir /cgroup
mount -a

Создаем директорию для виртуальной системы и создаем ее с помощью скрипта lxc-debian, который установит минимальную версию Debian Lenny.

mkdir -p /var/lib/lxc/vm0

/usr/lib/lxc/templates/lxc-debian -p /var/lib/lxc/vm0/

Стартуем систему:

lxc-start -n vm0

Логин и пароль — root/root. Все команды для работы с LXC начинаются с префикса lxc- и разобраться в них очень просто.

При использовании ядра linux версии 3.0.0 я столкнулся со следующей проблемой при запуске.

lxc-start: No such file or directory — failed to rename cgroup /cgroup/28788->/cgroup/vm0
lxc-start: failed to spawn 'vm0'
lxc-start: No such file or directory — failed to remove cgroup '/cgroup/vm0'

При использовании ядра 2.6.39-2-686-pae все работает.

Почитать:

wiki.debian.org/LXC
nigel.mcnie.name/blog/a-five-minute-guide-to-linux-containers-for-debian
blog.foaa.de/2010/05/lxc-on-debian-squeeze/

В CentOS 6 по-умолчанию используется KVM, а не Xen (К слову, с KVM совместимы не все варианты Linux, используемые в качестве гостевых ОС. По установке Xen в CentOS 6 можно почитать здесь). Также не настроены по-умолчанию мосты на сетевых интерфейсов (bridged режим нужен, чтобы все гостевые ОС делили между собой сетевые интерфейсы dom0 так, чтобы каждая гостевая ОС выглядела отдельной машиной в сети со своим MAC и IP). Настроим это дело. Устанавливаем утилиты:

( Читать дальше )