Xen: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Нет описания правки
 
(не показано 65 промежуточных версий 22 участников)
Строка 1: Строка 1:
[[Категория:Admin]]
{{викифицировать}}
{{stub}}
Осторожно пока UNDERCONSTRUCTION
=== Введение ===
=== Введение ===
Xen является систему паравиртуализации. Тоесть системой позволяюзий запускать несколько ядер операционных систем специального вида на одной реальной машине. Xen сотоит из 3х частей:
Xen - это система [[ruwp:Виртуализация|виртуализации]]. Xen представляет собой паравиртуальный монитор виртуальных машин, т.е. позволяет запускать несколько операционных систем одновременно, либо с ядрами специального вида, либо немодифицированных (при наличии аппаратной поддержки паравиртуализации в CPU).
==== Hypervisor ====
Это собтвенно xen. Это маленкое ядро(в разы меньше чем ядро опероационной системы) загружаемое первым и управляющиее работой виртуальных машин. Обычно находиться в /boot/xen.gz. Гипервизор исполняется в круге 0. Он умеет упралять только памятью, процессором  и частично ACPI. Также гипервизор предоставлят API гипервызовов(hypercall) с помощью которых ядра операционных систем в виртуальных машинах могут с ним общаться. Загрузившись гипервизор загружает ядро dom0.
==== Domain 0 ====
Он же dom0 - перевлигерованная виртуальная машина, имющая доступ к практически всему железу и имеющая права давать команду гипервизуроу запустить новые виртуальные машины. На практитке это обычная Linux система, единственное чем она ограничена это объёмом памяти. Обычно в такой системе установлен минимальный набор программ, демон управления xen, утилиты для упраления xen, утилиты для создания виртуальных машин, и программный сетевой мост (bridge) который позволяет другим виртуальным машинам поподать в сеть. Поскольку xen пердоставляет машинам виртуальные жесткие диски, эти диски экспортируются из dom0, обычно это либо файлы подключеные через loopback/blktap или LVM тома.
==== Слова ====
Простая задача: x86_64 система на базе altlinux server 4.0, хотелось бы завести под нее xen-ядро. Благодаря Михаилу Якушину большинство работ уже сделано, осталось решить вопрос загрузки. Проблема в том что для x86_64 загрузчик grub не собирается. А на текущий момент именно grub-единственно легкий способ загрузки xen-ядер.


==== Решение ====
'''XEN с недавних пор x86_64 only, на i586 работоспособность не проверяется и не гарантируется.''' http://lists.altlinux.org/pipermail/sisyphus/2012-July/357852.html
По хорошему, необходимо собрать grub для 32битной систему, использовать его для создания некого загрузочного cd-диска. Положить на него stage1 stage2. Ставить систему с любым ядром и lilo. Загружаться в эту систему, копировать сd-rom’а /boot/grub на диск, создавать /boot/grub/device.map и /boot/grub/menu.lst, перезагружаться и с помощью волшебного cd-диска устанавливать grub как основной загрузчик системы.
типа
<pre>root(hd0,1)
setup(hd0)
reboot</pre>
[http://wpkg.org/Running_Xen_with_LILO http://wpkg.org/Running_Xen_with_LILO]
[http://gentoo-wiki.com/HOWTO_Xen_and_Gentoo http://gentoo-wiki.com/HOWTO_Xen_and_Gentoo]
[http://www.tjd.phlegethon.org/software/#mbootpack http://www.tjd.phlegethon.org/software/#mbootpack]


==== Альтернативное решение ====
==== Hypervisor ====
В качестве альтернативного решения можно использовать загрузчик extlinux из пакета syslinux.
Это собственно Xen - маленькое ядро (в разы меньше, чем ядро операционной системы), загружаемое первым и управляющее работой виртуальных машин. Обычно находится в /boot/xen.gz. Гипервизор исполняется в нулевом круге защиты CPU. Гипервизор умеет управлять памятью, процессором и частично ACPI, а также предоставляет API гипервызовов (hypercall), с помощью которых ядра операционных систем в виртуальных машинах могут с ним общаться. Загрузившись, гипервизор загружает ядро dom0.


==== Domain 0 ====
Он же dom0 - привилегированная виртуальная машина, имеющая доступ практически ко всему железу и имеющая права давать гипервизору команду на запуск новых виртуальных машин. На практике это обычная Linux-система, единственное, чем она ограничена - это объёмом памяти. Обычно в такой системе установлен минимальный набор программ, демон управления xen, утилиты для управления xen, утилиты для создания виртуальных машин, и программный сетевой мост (bridge) который позволяет другим виртуальным машинам попадать в сеть. Виртуальные жесткие диски, предоставляемые Xen, также экспортируются из dom0. Обычно это файлы подключеные через loopback/blktap, либо LVM тома.


== Установка Xen в ALT Linux ==
==== Domain U ====
 
domU — это собственно виртуальная машина, запускаемая dom0. Получает свой участок памяти, жёсткие диски и сетевой интерфейс. Может быть запущена, остановлена, приостановлена, перезагруженна, задамплена на диск, перемещена, в том числе без остановки, на другую машину (live migration).
Пример на основе branch 4.0.
 
Моя конфигурация такова:


/dev/sda1 — root — 63G
==== Ядро xen-dom0 в ALT Linux ====
/dev/sda2 — swap — 4G


Ставим grub и устанавливаем его:
Ядро dom0 может работать как в dom0, так и в domU, собрано со всеми стандартными опциями наших ядер.


<tt> # apt-get install grub </tt>
== Установка ==
<tt> # grub-install /dev/sda </tt>
=== Установка загрузчика ===
Для загрузки Xen требуется использование загрузчика, поддерживающего multiboot (grub поддерживает, lilo - нет).
Про настройку grub можно почитать тут: [[Grub#Как загрузить Xen?]]


Примерный /boot/grub/menu.lst:
=== Установка Xen ===
==== Установка самого XEN ====
# apt-get install xen-hypervisor xen-runtime xen-libs xen
# update-kernel -t xen-dom0


<pre>timeout 5
Перезагружаемся в XEN, далее:
color black/cyan yellow/cyan
default 0


title default
# service xend start
kernel /boot/vmlinuz root=/dev/sda1 vga=normal
initrd /boot/initrd.img</pre>
 
Проверим, что grub грузит текущее ядро:
 
<tt> # reboot </tt>
 
После успешной загрузки ставим ядро и необходимые для работы железа модули:
 
<tt> # apt-get install kernel-image-xen-dom0 kernel-modules-необходимые-xen-dom0 xen-hypervisor xen </tt>
 
Редактируем /boot/grub/menu.lst примерно до такого:
 
<pre>timeout 5
color black/cyan yellow/cyan
default 0
 
title default
kernel /boot/vmlinuz root=/dev/sda1 vga=normal
initrd /boot/initrd.img
 
title XEN
kernel /boot/xen.gz dom0_mem=512M
module /boot/vmlinuz-2.6.18-xen-dom0-alt6.M40.1 root=/dev/sda1
module /boot/initrd-2.6.18-xen-dom0-alt6.M40.1.img</pre>
 
Обратите внимание на двойную module — это обязательно.
 
Перезагружаемся в XEN-ядро, далее:
 
<tt> # service xend start </tt>


Проверим, что все в порядке:
Проверим, что все в порядке:
Строка 105: Строка 63:
cc_compile_date        : Tue Mar  4 23:38:33 MSK 2008
cc_compile_date        : Tue Mar  4 23:38:33 MSK 2008
xend_config_format    : 4
xend_config_format    : 4
[root@wintermute ~]# brctl show
</pre>
bridge name    bridge id              STP enabled    interfaces
 
xenbr0          8000.feffffffffff       no              vif0.0
Если  при запуске команды xm info возникает ошибка  "Error: Unable to connect to xend: No such file or directory. Is xend running?", то может помочь добавление строки в файл /etc/fstab
                                                        peth0</pre>
 
<pre> none    /proc/xen      xenfs  defaults        0       0
</pre>


Поставим xend в автозапуск:
Поставим xend в автозапуск:


<tt> # chkconfig --level 345 xend on </tt>
# chkconfig xend on


Ставим kernel-image-xen-domU:
==== Настройка сети в XEN ====
Ещё есть проблема, актуальная для XEN, начиная с версии 3.2.0 — там очень кривой скрипт для запуска сетевого бриджа. Решается она переносом настройки бриджа в /etc/net.


<tt> # apt-get install kernel-image-xen-domU </tt>
===== Зачем нужен бридж? =====
В XEN сеть реализована так: для каждой (в том числе dom0) виртуальной машины создаётся n виртуальных сетевых интерфейсов. Каждый из них представляет собой две виртуальные сетевые карты, соединённые между собой. Одна, находящаяся в DomX под названием ethY, а другая в Dom0 под названием vifX.Y, где X — номер виртуальной машины, а Y больше или равно 0 и меньше n. На этом то, что предоставляет Xen сам по себе, заканчивается.


Далее возникает вопрос: что с этим всем делать?
Вариант 1. Присвоить каждому интерфейсу по IP адресу так, чтобы каждая пара была в своей сети. Поскольку в этом варианте данные ходят между dom0 и каждым доменом в отдельности, и при этом домены не имеют выхода во внешнюю сеть, этот вариант используется редко.
Вариант 2. Продолжение первого, но при этом организовать, например, маршрутизацию пакетов во внешнюю сеть и между виртуальными машинами. То есть, dom0 становится маршрутизатором этой сети.
Вариант 3. Продолжение 2-го, но ещё включается NAT.
Вариант 4. Сделать бридж и объединить им физическую сетевую карту и коннекторы во все остальные виртуальные машины. При этом, физическая сетевая карта переименовывается в p<oldname>, интерфейс лишается IP и MAC адресов. Таким образом, dom0 выполняет функцию коммутатора. Любопытно, что в XEN до 3.2 в dom0 IP и MAC старой сетевой карты присваивается интерфейсу ethY, а в 3.2 — бриджу.
Таким образом, бридж является самым удобным способом работы виртуальных машин с сетью, так как для сети машина с XEN выглядит как коммутатор, к которому подключены машины.
Для работы разных вариантов в XEN есть скрипты, по паре для разных вариантов. Один (network-*) запускается при старте системы и настраивает сеть в целом, и vif-*, который вызывается при запуске каждого нового сетевого интерфейса в виртуальных машинах.
===== Собственно, настройка бриджа =====
Стоит рассказать про настройку брижда подробнее, так как это самый удобный и востребованный вариант сети.
==== Установка виртуальной машины ====
Делаем образ машины. Я использовал один из собственноручно приготовленных openvz-темплейтов.
Делаем образ машины. Я использовал один из собственноручно приготовленных openvz-темплейтов.


<tt> # mkdir -p /xen/alt </tt>
<tt> # mkdir -p /xen/alt </tt><br>
<tt> # dd if=/dev/zero of=/xen/alt.img bs=1M seek=10240 count=0 </tt> — создаем 10 ГБ «раздел» для машины
<tt> # dd if=/dev/zero of=/xen/alt.img bs=1M seek=10240 count=0 </tt> создаем 10 ГБ «раздел» для машины<br>
<tt> # mkfs.ext3 /xen/alt.img </tt>
<tt> # mkfs.ext3 /xen/alt.img </tt><br>
<tt> # mount -o loop /xen/alt.img /xen/alt/ </tt>
<tt> # mount -o loop /xen/alt.img /xen/alt/ </tt><br>
<tt> # cd /xen/alt && tar xf /altlinux-4.0.tar.gz </tt>
<tt> # cd /xen/alt && tar xf /altlinux-4.0.tar.gz </tt><br>
 
Поставим внутрь будущей виртуальной машины domU-ядро:


<tt> # chroot /xen/alt/ /bin/bash </tt>
<tt> # chroot /xen/alt/ /bin/bash </tt><br>
<tt> # vim /etc/resolv.conf </tt> — установим нужный nameserver
<tt> # vim /etc/resolv.conf </tt> установим нужный nameserver<br>
<tt> # vim /etc/apt/sources.list </tt> — установим правильный репозиторий (можно пропустить, если устраивает тот, что преднастроен внутри контейнера)
<tt> # vim /etc/apt/sources.list </tt> установим правильный репозиторий (можно пропустить, если устраивает тот, что преднастроен внутри контейнера)<br>
<tt> # apt-get update && apt-get install kernel-image-xen-domu </tt>
<tt> # apt-get update && apt-get install kernel-image-xen-domu </tt><br>


Поправим /etc/fstab в чруте, чтобы выглядело примерно так:
Поправим /etc/fstab в чруте, чтобы выглядело примерно так:
Строка 142: Строка 120:
Отмонтируем чрут:
Отмонтируем чрут:
<tt> # umount /xen/alt </tt>
<tt> # umount /xen/alt </tt>
Ставим kernel-image-xen-domU в dom0-систему:
<tt> # apt-get install kernel-image-xen-domU </tt>


Пишем конфигурационный файл /etc/xen/alt:
Пишем конфигурационный файл /etc/xen/alt:
<pre>kernel = "/boot/vmlinuz-2.6.18-xen-domU-alt6"
<pre>kernel = "/boot/vmlinuz-2.6.32-xen-dom0-alt11"
memory = 256
memory = 256
name = "alt"
name = "alt"
Строка 162: Строка 136:
Для выхода из консоли нажать Ctrl-].
Для выхода из консоли нажать Ctrl-].


== См. также ==
==Администрирование==
* [[Загрузка Xen на x86-64]]
===Основные команды===
Команды выполнять с правами суперпользователя
*'''xm list''' — список виртуальных машин
*'''xentop''' — загрузка и состояние всех виртуальных машин
*'''xm reset vm''' - сброс машины vm (работающая команда для '''перезапуска''' VM с Windows)
*'''xm console vm''' — подключение на первую консоль виртуальной машины
*'''xm create vm'''— запускает виртуальную машину на основе конфигурационного файла
*'''xm pause vm'''— приостанавливает виртуальную машину
*'''xm unpause vm'''— запускает виртуальную машину после остановки
*'''xm save vm'''— сохраняет состояние виртуальной машины
*'''xm restore vm'''— восстанавливает состояние виртуальной машины
*'''xm reboot vm'''— перезагружает виртуальную машину
*'''xm shutdown vm'''— выключает виртуальную машину
*'''xm dmesg vm'''— показывает dmesg виртуальной машины
*'''xm delete vm'''— удаляет виртуальную машину
*'''xm destroy vm'''— принудительно удаляет виртуальную машину
 
===Статусы===
 
# xm list
Name    ID Mem(MiB) VCPUs State Time(s)
Domain-0 0  493    1    r----- 254.2
VM      3  255    1    -b---- 13.3
 
*Name  - имя домена. Domain-0 – это административный домен, сама хост-система. Остальные домены – это гостевые системы;
*ID – ID домена в котором находится ВМ;
*Mem(MiB) – объем памяти этой ВМ;
*VCPUs – сколько процессоров используется;
*State – статус ВМ, ниже перечислены возможные статусы;
**r – running, ВМ запущена;
**b – blocked, обычное состояние когда ВМ ожидает ввода/вывода, это '''нормальное''' состояние ВМ;
**p – paused, режим паузы, режим наступает при команде xm pause;
**s – shutdown, в процессе выключения или перезагрузки;
**c – crashed, произошла какая-то серьезная ошибка;
**d – dying, в процессе завершения своей работы, но пока не достигшийсостояния shutdown или crashed;
* Time(s) – как долго запущена ВМ.
 
===Проброс графики с ВМ===
Если на сервере не установлен X-сервер, можно подключиться к виртуальной машине пробросив X-ы и запустив vncviewer
ssh -l <user> <IP-адрес сервера> -p <порт> -Y
 
Если возникнет ошибка вида:
/usr/bin/xauth:  timeout in locking authority file /home/<user>/.Xauthority
нужно проверить и привести в порядок права на домашнюю директорию и её файлы пользователя, под которым идет подключение.
 
Запускаем VNC:
vncviewer :0
 
Дисплей :0 используется для 1-й виртуалки, для следующих будут 1,2 и т.д.
{{Category navigation|title=Xen|category=Xen|sortkey={{SUBPAGENAME}}}}
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}

Текущая версия от 14:34, 2 июля 2015

42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.
Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Осторожно пока UNDERCONSTRUCTION

Введение

Xen - это система виртуализации. Xen представляет собой паравиртуальный монитор виртуальных машин, т.е. позволяет запускать несколько операционных систем одновременно, либо с ядрами специального вида, либо немодифицированных (при наличии аппаратной поддержки паравиртуализации в CPU).

XEN с недавних пор x86_64 only, на i586 работоспособность не проверяется и не гарантируется. http://lists.altlinux.org/pipermail/sisyphus/2012-July/357852.html

Hypervisor

Это собственно Xen - маленькое ядро (в разы меньше, чем ядро операционной системы), загружаемое первым и управляющее работой виртуальных машин. Обычно находится в /boot/xen.gz. Гипервизор исполняется в нулевом круге защиты CPU. Гипервизор умеет управлять памятью, процессором и частично ACPI, а также предоставляет API гипервызовов (hypercall), с помощью которых ядра операционных систем в виртуальных машинах могут с ним общаться. Загрузившись, гипервизор загружает ядро dom0.

Domain 0

Он же dom0 - привилегированная виртуальная машина, имеющая доступ практически ко всему железу и имеющая права давать гипервизору команду на запуск новых виртуальных машин. На практике это обычная Linux-система, единственное, чем она ограничена - это объёмом памяти. Обычно в такой системе установлен минимальный набор программ, демон управления xen, утилиты для управления xen, утилиты для создания виртуальных машин, и программный сетевой мост (bridge) который позволяет другим виртуальным машинам попадать в сеть. Виртуальные жесткие диски, предоставляемые Xen, также экспортируются из dom0. Обычно это файлы подключеные через loopback/blktap, либо LVM тома.

Domain U

domU — это собственно виртуальная машина, запускаемая dom0. Получает свой участок памяти, жёсткие диски и сетевой интерфейс. Может быть запущена, остановлена, приостановлена, перезагруженна, задамплена на диск, перемещена, в том числе без остановки, на другую машину (live migration).

Ядро xen-dom0 в ALT Linux

Ядро dom0 может работать как в dom0, так и в domU, собрано со всеми стандартными опциями наших ядер.

Установка

Установка загрузчика

Для загрузки Xen требуется использование загрузчика, поддерживающего multiboot (grub поддерживает, lilo - нет). Про настройку grub можно почитать тут: Grub#Как загрузить Xen?

Установка Xen

Установка самого XEN

# apt-get install xen-hypervisor xen-runtime xen-libs xen
# update-kernel -t xen-dom0

Перезагружаемся в XEN, далее:

# service xend start

Проверим, что все в порядке:

[root@wintermute ~]# xm info
host                   : wintermute.tld
release                : 2.6.18-xen-dom0-alt6.M40.1
version                : #1 SMP Tue Mar 4 22:42:44 MSK 2008
machine                : i686
nr_cpus                : 4
nr_nodes               : 1
sockets_per_node       : 2
cores_per_socket       : 1
threads_per_core       : 2
cpu_mhz                : 2392
hw_caps                : bfebfbff:00000000:00000000:00000080:00004400
total_memory           : 4095
free_memory            : 3540
xen_major              : 3
xen_minor              : 1
xen_extra              : .2
xen_caps               : xen-3.0-x86_32p
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xf5800000
xen_changeset          : unavailable
cc_compiler            : gcc version 4.1.1 20070105 (ALT Linux, build 4.1.1-alt11)
cc_compile_by          : builder
cc_compile_domain      : rio.altlinux.org
cc_compile_date        : Tue Mar  4 23:38:33 MSK 2008
xend_config_format     : 4

Если при запуске команды xm info возникает ошибка "Error: Unable to connect to xend: No such file or directory. Is xend running?", то может помочь добавление строки в файл /etc/fstab

 none    /proc/xen       xenfs   defaults        0       0

Поставим xend в автозапуск:

# chkconfig xend on

Настройка сети в XEN

Ещё есть проблема, актуальная для XEN, начиная с версии 3.2.0 — там очень кривой скрипт для запуска сетевого бриджа. Решается она переносом настройки бриджа в /etc/net.

Зачем нужен бридж?

В XEN сеть реализована так: для каждой (в том числе dom0) виртуальной машины создаётся n виртуальных сетевых интерфейсов. Каждый из них представляет собой две виртуальные сетевые карты, соединённые между собой. Одна, находящаяся в DomX под названием ethY, а другая в Dom0 под названием vifX.Y, где X — номер виртуальной машины, а Y больше или равно 0 и меньше n. На этом то, что предоставляет Xen сам по себе, заканчивается.

Далее возникает вопрос: что с этим всем делать?

Вариант 1. Присвоить каждому интерфейсу по IP адресу так, чтобы каждая пара была в своей сети. Поскольку в этом варианте данные ходят между dom0 и каждым доменом в отдельности, и при этом домены не имеют выхода во внешнюю сеть, этот вариант используется редко.

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

Вариант 3. Продолжение 2-го, но ещё включается NAT.

Вариант 4. Сделать бридж и объединить им физическую сетевую карту и коннекторы во все остальные виртуальные машины. При этом, физическая сетевая карта переименовывается в p<oldname>, интерфейс лишается IP и MAC адресов. Таким образом, dom0 выполняет функцию коммутатора. Любопытно, что в XEN до 3.2 в dom0 IP и MAC старой сетевой карты присваивается интерфейсу ethY, а в 3.2 — бриджу.

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

Для работы разных вариантов в XEN есть скрипты, по паре для разных вариантов. Один (network-*) запускается при старте системы и настраивает сеть в целом, и vif-*, который вызывается при запуске каждого нового сетевого интерфейса в виртуальных машинах.

Собственно, настройка бриджа

Стоит рассказать про настройку брижда подробнее, так как это самый удобный и востребованный вариант сети.

Установка виртуальной машины

Делаем образ машины. Я использовал один из собственноручно приготовленных openvz-темплейтов.

# mkdir -p /xen/alt
# dd if=/dev/zero of=/xen/alt.img bs=1M seek=10240 count=0 — создаем 10 ГБ «раздел» для машины
# mkfs.ext3 /xen/alt.img
# mount -o loop /xen/alt.img /xen/alt/
# cd /xen/alt && tar xf /altlinux-4.0.tar.gz

# chroot /xen/alt/ /bin/bash
# vim /etc/resolv.conf — установим нужный nameserver
# vim /etc/apt/sources.list — установим правильный репозиторий (можно пропустить, если устраивает тот, что преднастроен внутри контейнера)
# apt-get update && apt-get install kernel-image-xen-domu

Поправим /etc/fstab в чруте, чтобы выглядело примерно так:

/dev/hda1       /               ext3    defaults    0       1

Выходим из чрута:

# exit

Отмонтируем чрут: # umount /xen/alt

Пишем конфигурационный файл /etc/xen/alt:

kernel = "/boot/vmlinuz-2.6.32-xen-dom0-alt11"
memory = 256
name = "alt"
root = "/dev/hda1 ro"
extra = "xencons=tty"
disk = [ 'file:/xen/alt.img,hda1,w' ]

Пробуем запустить: # xm create -c alt

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

Для выхода из консоли нажать Ctrl-].

Администрирование

Основные команды

Команды выполнять с правами суперпользователя

  • xm list — список виртуальных машин
  • xentop — загрузка и состояние всех виртуальных машин
  • xm reset vm - сброс машины vm (работающая команда для перезапуска VM с Windows)
  • xm console vm — подключение на первую консоль виртуальной машины
  • xm create vm— запускает виртуальную машину на основе конфигурационного файла
  • xm pause vm— приостанавливает виртуальную машину
  • xm unpause vm— запускает виртуальную машину после остановки
  • xm save vm— сохраняет состояние виртуальной машины
  • xm restore vm— восстанавливает состояние виртуальной машины
  • xm reboot vm— перезагружает виртуальную машину
  • xm shutdown vm— выключает виртуальную машину
  • xm dmesg vm— показывает dmesg виртуальной машины
  • xm delete vm— удаляет виртуальную машину
  • xm destroy vm— принудительно удаляет виртуальную машину

Статусы

# xm list
Name    ID Mem(MiB) VCPUs State Time(s)
Domain-0 0   493     1     r----- 254.2
VM       3   255     1     -b---- 13.3
  • Name - имя домена. Domain-0 – это административный домен, сама хост-система. Остальные домены – это гостевые системы;
  • ID – ID домена в котором находится ВМ;
  • Mem(MiB) – объем памяти этой ВМ;
  • VCPUs – сколько процессоров используется;
  • State – статус ВМ, ниже перечислены возможные статусы;
    • r – running, ВМ запущена;
    • b – blocked, обычное состояние когда ВМ ожидает ввода/вывода, это нормальное состояние ВМ;
    • p – paused, режим паузы, режим наступает при команде xm pause;
    • s – shutdown, в процессе выключения или перезагрузки;
    • c – crashed, произошла какая-то серьезная ошибка;
    • d – dying, в процессе завершения своей работы, но пока не достигшийсостояния shutdown или crashed;
  • Time(s) – как долго запущена ВМ.

Проброс графики с ВМ

Если на сервере не установлен X-сервер, можно подключиться к виртуальной машине пробросив X-ы и запустив vncviewer

ssh -l <user> <IP-адрес сервера> -p <порт> -Y 

Если возникнет ошибка вида:

/usr/bin/xauth:  timeout in locking authority file /home/<user>/.Xauthority

нужно проверить и привести в порядок права на домашнюю директорию и её файлы пользователя, под которым идет подключение.

Запускаем VNC:

vncviewer :0

Дисплей :0 используется для 1-й виртуалки, для следующих будут 1,2 и т.д.