sudo losetup /dev/loop1 disk.img
sudo kpartx -a -v /dev/loop1
sudo mount -t ntfs /dev/mapper/loop1p1 /mnt/tmp

Если монтируемый образ системы LVM то
sudo pvs
# /dev/dm-5 NAME lvm2 a- 9.52g 0
sudo lvdisplay
File descriptor 7 (pipe:[1047772]) leaked on lvdisplay invocation. Parent PID 20537: bash
 – Logical volume –
LV Name /dev/NAME/root
VG Name NAME
LV UUID MC2xwj-3cUr-7iYk-t4d8-dmfp-2RDX-In6Op7
LV Write Access read/write
LV Status NOT available
LV Size 9.02 GiB
Current LE 2310
Segments 1
Allocation inherit
Read ahead sectors auto

 – Logical volume –
LV Name /dev/NAME/swap_1
VG Name NAME
LV UUID rKuLfE-Drsk-KXPg-2Ghw-03mP-kjpA-8iY7hF
LV Write Access read/write
LV Status NOT available
LV Size 512.00 MiB
Current LE 128
Segments 1
Allocation inherit
Read ahead sectors auto

sudo vgchange -ay NAME
sudo mount /dev/solur/root /mnt/tmp

Размонтирование:
sudo umount /mnt/tmp

Если подключали LVM то
sudo vgchange -an NAME

sudo kpartx -dv /dev/loop1
sudo losetup -d /dev/loop1

Текстовая утилита virsh предназначена для управления гостевыми системами и гипервизором.
virsh использует libvirt API и служит альтернативой xm и графическому менеджеру виртуальных машин (virt-manager). Непривилегированные пользователи могут выполнять доступ в только в режиме чтения. С помощью virsh можно исполнять сценарии для виртуальных машин.
Обзор команд virsh
Приведенные ниже таблицы содержат перечень основных параметров командной строки virsh. Команда Description
help Краткая справка.
list Просмотр всех виртуальных машин.
dumpxml Вывести файл конфигурации XML для заданной виртуальной машины.
create Создать виртуальную машину из файла конфигурации XML и ее запуск.
start Запустить неактивную виртуальную машину.
destroy Принудительно остановить работу виртуальной машины.
define Определяет файл конфигурации XML для заданной виртуальной машины.
domid Просмотр идентификатора виртуальной машины.
domuuid Просмотр UUID виртуальной машины.
dominfo Просмотр сведений о виртуальной машине.
domname Просмотр имени виртуальной машины.
domstate Просмотр состояния виртуальной машины.
quit Закрыть интерактивный терминал.
reboot Перезагрузить виртуальную машину.
restore Восстановить сохраненную в файле виртуальную машину.
resume Возобновить работу приостановленной виртуальной машины.
save Сохранить состояние виртуальной машины в файл.
shutdown Корректно завершить работу виртуальной машины.
suspend Приостановить работу виртуальной машины.
undefine Удалить все файлы виртуальной машины.
migrate Перенести виртуальную машину на другой узел.

Таблица 15.1. Команды управления виртуальными машинами

Для управления ресурсами виртуальной машины и гипервизора используются следующие команды virsh: Команда Description
setmem Определяет размер выделенной виртуальной машине памяти.
setmaxmem Ограничивает максимально доступный гипервизору объем памяти.
setvcpus Изменяет число предоставленных гостю виртуальных процессоров.
vcpuinfo Просмотр информации о виртуальных процессорах.
vcpupin Настройка соответствий виртуальных процессоров.
domblkstat Просмотр статистики блочных устройств для работающей виртуальной машины.
domifstat Просмотр статистики сетевых интерфейсов для работающей виртуальной машины.
attach-device Подключить определенное в XML-файле устройство к гостю.
attach-disk Подключить новое дисковое устройство к гостю
attach-interface Подключить новый сетевой интерфейс к гостю
detach-device Отключить устройство от гостя (принимает те же определения XML, что и attach-device).
detach-disk Отключить дисковое устройство от гостя.
detach-interface Отключить сетевой интерфейс от гостя.

Таблица 15.2. Параметры управления ресурсами

Другие команды virsh: Команда Description
version Просмотр версии virsh.
nodeinfo Просмотр информации о гипервизоре.

Таблица 15.3. Другие команды

Подключение к гипервизору
Подключение к сессии гипервизора с помощью virsh :
# virsh connect {hostname OR URL}
Where <name> is the machine name of the hypervisor. To initiate a read-only connection, append the above command with -readonly.
Создание XML-файла конфигурации виртуальной машины
Выведите файл конфигурации виртуальной машины:
# virsh dumpxml {domain-id, domain-name or domain-uuid}
This command outputs the guest’s XML configuration file to standard out (stdout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml:
# virsh dumpxml GuestID > guest.xml
This file guest.xml can recreate the guest (refer to Редактирование файла конфигурации виртуальной машины. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to Раздел 18.1, «Использование файлов конфигурации с помощью virsh» for more information on modifying files created with virsh dumpxml.
Пример вывода virsh dumpxml:
# virsh dumpxml r5b2-mySQL01
<domain type=’xen’ id=’13’>
<name>r5b2-mySQL01</name>
<uuid>4a4c59a7ee3fc78196e4288f2862f011</uuid>
<bootloader>/usr/bin/pygrub</bootloader>
<os>
<type>linux</type>
<kernel>/var/lib/libvirt/vmlinuz.2dgnU_</kernel>
<initrd>/var/lib/libvirt/initrd.UQafMw</initrd>
<cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline>
</os>
<memory>512000</memory>
<vcpu>1</vcpu>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<interface type=’bridge’>
<source bridge=’xenbr0’/>
<mac address=’00:16:3e:49:1d:11’/>
<script path=’vif-bridge’/>
</interface>
<graphics type=’vnc’ port=’5900’/>
<console tty=’/dev/pts/4’/>
</devices>
</domain>

Создание виртуальной машины на основе файла конфигурации
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Создание XML-файла конфигурации виртуальной машины). To create a guest with virsh from an XML file:
# virsh create configuration_file.xml
Редактирование файла конфигурации виртуальной машины
Instead of using the dumpxml option (refer to Создание XML-файла конфигурации виртуальной машины) guests can be edited either while they run or while they are offline. The virsh edit command provides this functionality. For example, to edit the guest named softwaretesting:
# virsh edit softwaretesting
Откроется окно текстового редактора, заданного переменной оболочки $EDITOR (по умолчанию используется vi).
Приостановка виртуальной машины
Команда приостановки виртуальной машины с помощью virsh:
# virsh suspend {domain-id, domain-name or domain-uuid}
When a guest is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest is suspended. This operation is immediate and the guest can be restarted with the resume (Возобновление работы виртуальной машины) option.
Возобновление работы виртуальной машины
Возобновить работу приостановленной виртуальной машины можно с помощью параметра resume команды virsh:
# virsh resume {domain-id, domain-name or domain-uuid}
Работа машины будет возобновлена немедленно. Параметры будут сохраняться между циклами suspend и resume.
Сохранение виртуальной машины
Команда сохранения текущего состояния виртуальной машины:
# virsh save {domain-name, domain-id or domain-uuid} filename
This stops the guest you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest. You can restore the state of the guest with the restore (Восстановление виртуальной машины) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Восстановление виртуальной машины
Restore a guest previously saved with the virsh save command (Сохранение виртуальной машины) using virsh:
# virsh restore filename
Сохраненная машина будет восстановлена из файла и перезапущена, что может занять некоторое время. Имя и идентификатор UUID виртуальной машины останутся неизменными, но будет предоставлен новый идентификатор домена.
Завершение работы виртуальной машины
Команда завершения работы:
# virsh shutdown {domain-id, domain-name or domain-uuid}
Поведение выключаемого гостя можно контролировать с помощью параметра on_shutdown в его файле конфигурации.
Перезагрузка виртуальной машины
Команда перезагрузки:
#virsh reboot {domain-id, domain-name or domain-uuid}
Поведение перезагружаемого гостя можно контролировать с помощью параметра on_reboot в его файле конфигурации.
Принудительная остановка виртуальной машины
Команда принудительной остановки:
# virsh destroy {domain-id, domain-name or domain-uuid}
This command does an immediate ungraceful shutdown and stops the specified guest. Using virsh destroy can corrupt guest file systems . Use the destroy option only when the guest is unresponsive. For para-virtualized guests, use the shutdown option(Завершение работы виртуальной машины) instead.
Определение идентификатора домена
Команда определения идентификатора домена виртуальной машины:
# virsh domid {domain-name or domain-uuid}
Определение имени домена
Команда определения имени домена виртуальной машины:
# virsh domname {domain-id or domain-uuid}
Определение UUID
Команда определения универсального идентификатора UUID виртуальной машины:
# virsh domuuid {domain-id or domain-name}
Пример вывода virsh domuuid:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011

Получение информации о виртуальной машине
Команда для получения информации:
# virsh dominfo {domain-id, domain-name or domain-uuid}
Пример вывода virsh dominfo:
# virsh dominfo r5b2-mySQL01
id: 13
name: r5b2-mysql01
uuid: 4a4c59a7-ee3f-c781-96e4-288f2862f011
os type: linux
state: blocked
cpu(s): 1
cpu time: 11.0s
max memory: 512000 kb
used memory: 512000 kb

Получение информации об узле
Команда получения информации об узле:
# virsh nodeinfo

Пример вывода virsh nodeinfo:
# virsh nodeinfo
CPU model x86_64
CPU (s) 8
CPU frequency 2895 Mhz
CPU socket(s) 2
Core(s) per socket 2
Threads per core: 2
Numa cell(s) 1
Memory size: 1046528 kb

Вывод содержит информацию об узле и машинах, поддерживающих виртуализацию.
Просмотр списка виртуальных машин
Команда для просмотра списка виртуальных машин и их состояния:
# virsh list

Можно добавить аргументы:
inactive покажет список неактивных доменов (неактивным считается тот домен, который был определен, но в настоящий момент не является активным).
--all покажет все виртуальные машины независимо от их состояния. Пример:
# virsh list --all
Id Name State
--------------------------------
0 Domain-0 running
1 Domain202 paused
2 Domain010 inactive
3 Domain9600 crashed

Столбец «Status» может содержать следующие значения:

running — работающие виртуальные машины, то есть те машины, которые используют ресурсы процессора в момент выполнения команды.

blocked — заблокированные, неработающие машины. Такой статус может быть вызван ожиданием ввода/вывода или пребыванием машины в спящем режиме.

paused — приостановленные домены. В это состояние они переходят, если администратор нажал кнопку паузы в окне менеджера виртуальных машин или выполнил команду xm pause или virsh suspend. В приостановленном состоянии гость продолжает потреблять ресурсы, но не может занимать больше процессорных ресурсов.

shutdown — виртуальные машины, завершающие свою работу. При получении виртуальной машиной сигнала завершения работы, она начнет завершать все процессы. Стоит отметить, что некоторые операционные системы не отвечают на такие сигналы.

dying — сбойные домены и домены, которые не смогли корректно завершить свою работу.

crashed — сбойные домены, работа которых была прервана. В этом состоянии домены находятся, если не была настроена их перезагрузка в случае сбоя.
Получение информации о виртуальных процессорах
Команда получения информации о виртуальных процессорах:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Пример вывода:
# virsh vcpuinfo r5b2-mySQL01
VCPU: 0
CPU: 0
State: blocked
CPU time: 0.0s
CPU Affinity: yy

Настройка соответствий виртуальных процессоров
Команда сопоставления виртуальных процессоров физическим:
# virsh vcpupin {domain-id, domain-name or domain-uuid} vcpu, cpulist
Здесь vcpu — номер виртуального процессора, а список_cpu — сопоставляемые ему физические процессоры.
Изменение числа виртуальных процессоров
Команда изменения числа процессоров для домена:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
Обратите внимание, что заданное число не может превышать значение, определенное при создании гостя.
Изменение выделенного объема памяти
Команда изменения выделенного виртуальной машине объема памяти:
# virsh setmem {domain-id or domain-name} count

Объем памяти, определяемый заданным числом, должен быть указан в килобайтах. Обратите внимание, что объем не может превышать значение, определенное при создании виртуальной машины, но в то же время не должен быть меньше 64 мегабайт. Изменение максимального объема памяти может оказать влияние на функциональность гостя только в том случае, если указанный размер меньше исходного. В таком случае использование памяти будет ограничено.
Получение информации о блочных устройствах
Команда для получения информации о блочных устройствах работающей виртуальной машины:
# virsh domblkstat GuestName block-device
Получение информации о сетевых устройствах
Команда для получения информации о сетевых интерфейсах работающей виртуальной машины:
# virsh domifstat GuestName interface-device
Миграция виртуальных машин
virsh позволяет переносить виртуальные машины с одного узла на другой. Для выполнения живой миграции просто нужно указать параметр live. Команда переноса выглядит так:
# virsh migrate --live GuestName DestinationURL
Параметр --live не является обязательным.
The GuestName parameter represents the name of the guest which you want to migrate.
The DestinationURL parameter is the URL or hostname of the destination system. The destination system must run the same version of Fedora, be using the same hypervisor and have libvirt running.
Once the command is entered you will be prompted for the root password of the destination system.
Управление виртуальными сетями
В этой секции будет рассмотрены управляющие команды virsh. Например, команда просмотра списка виртуальных сетей выглядит так:
# virsh net-list

Пример вывода этой команды:
# virsh net-list
Name State Autostart
---------------------------------------
default active yes
vnet1 active yes
vnet2 active yes

Просмотр информации для заданной виртуальной сети:
# virsh net-dumpxml NetworkName
Пример вывода этой команды (в формате XML):
# virsh net-dumpxml vnet1
<network>
<name>vnet1</name>
<uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
<forward dev=’eth0’/>
<bridge name=’vnet0’ stp=’on’ forwardDelay=’0’ />
<ip address=’192.168.100.1’ netmask=’255.255.255.0’>
<dhcp>
<range start=’192.168.100.128’ end=’192.168.100.254’ />
</dhcp>
</ip>
</network>

Другие команды управления виртуальными сетями:

virsh net-autostart имя_сети — автоматический запуск заданной сети.

virsh net-create файл_XML — создание и запуск новой сети на основе существующего XML-файла.

virsh net-define файл_XML — создание нового сетевого устройства на основе существующего XML-файла. Устройство не будет запущено.

virsh net-destroy имя_сети — удаление заданной сети.

virsh net-name UUID_сети — преобразование заданного идентификатора в имя сети.

virsh net-uuid имя_сети — преобразование заданного имени в идентификатор UUID.

virsh net-start имя_неактивной_сети — запуск неактивной сети.

virsh net-undefine имя_неактивной_сети — удаление определения неактивной сети.

https://debian.pro/87

Лето. Надоело сидеть за компом, решил отдохнуть и гулять-кататься побольше. Спам от мониторилок на андроид-телефон валится исправно. Хард клава любимого Зевсика с завтрашнего дня будет всегда со мной. (тьфу-тьфу-тьфу). Грех в такой ситуации не воспользоваться ssh-клиентом на телефоне с клавиатурой и 3g для управления VDSками. А ещё большим грехом было бы не рассказать всем вкратце, как же это делать.

Конечно же, вы настраивали KVM по мануалу /16 на этом сайте. И конечно же, у вас установлен libvirtd. Его консольным фронт-эндом является как раз таки virsh.
Итак. Virsh у нас есть. Если нет — смотрим статью /16.
Для проверки просто введем в консоли virsh
Теперь у вас открыт новый шелл:
virsh #
Сразу оговорюсь, что все последующие команды можно вводить в консоли virsh либо в обычной консоли с приставкой virsh.
То есть:
virsh # command vds
и
Debian:~# virsh command vds
эквивалентны. Но я рекоммендую использовать шелл virsh, так как там работает автодополнение команд virsh’a.
В дальнейшем в статье я не буду использовать приставки к командам. Знайте, что каждую из нижеперечисленных команд нужно писать с приставкой virsh либо в шелле virsh.
Так же условимся, что vdsX — это название VDSки, над которой вы желаете совершить действие.
Приступим. Поуправляем «питанием» виртуальных машин:
destroy vdsX — «выдергиваем кабель питания виртуалки»
reboot vdsX — передаст ядру VDSки команду reboot, как если бы она была написана из консоли.
shutdown vdsX — корректно выключаем VDS. Если не выключается — делаем destroy.
start vdsX — запускаем VDS
save vdsX file-name — сохранит состояние виртуалки в файл, выключит её и освободит RAM. Фактически — аналог команды hibernate. Только можно много состояний оперативки сохранять =) удобно для тестов. Учтите, что имя файла должно быть уникальным всегда (или его перезапишет, даже дампом другой виртуалки)
restore file-name — вернет виртуалку из сна. Саму виртуалку указывать не нужно, эта информация берется из файла. А жаль, на самом деле. Можно было бы создавать кучи одинаковых виртуалок и потом их поочередно грузить из файла и издеваться.
suspend vdsX — ещё один hibernate, но память, зарезервированная виртуалкой не освобождается. Надежнее, чем save/restore.
resume vdsX — возвращает vds из состояние, в которое мы её погрузили командой suspend

Просмотрим некоторую информацию о VDSах:
nodeinfo — выдаст нам информацию о вашем сервере. Бесполезную, но малоли)
list — выведет список всех виртуалок и их состояние — running, halted, suspended и т.д. Полезно для включения в отчёты, кстати.
dominfo vdsX — выведет информацию о виртуалке. Есть и полезная, например, там можно посмотреть, сколько времени CPU скушала виртуалка (да да, будем на это основывать облака в ближайшем будущем =)) )
domblkstat vdsX device — должно выводить статистику по блочному устройству виртуалки. Пока не разобрался как работает. Буду рад подсказке. Точнее не знаю, что вписать вместо device.
domifstat vdsX vnetY — позволяет просмотреть информацию по сетевому интерфейсу виртуалки. vnetY должен использоваться именно виртуалкой vdsX, чтобы команда дала корректный вывод. Команда ценна тем, что позволяет проверить — не дропаются ли сетевые пакеты виртуалки.
ttyconsole vdsX — укажет нам, какой /dev/pts используется vdsом. Полезно, если знаете, что с pts можно сделать удалённо.
vncdisplay vdsX — укажет нам IP и порт виртуального IP-KVM… а точнее VNC сервера для VDSки. В virt-manager можно добавить новые.

Изменим кое-какие лимиты виртуалок:
setmem vdsX summ — изменяет лимит памяти виртуалки. summ указывается в килобайтах. Работает без ребута. Память по этому лимиту сразу помечается хостом как используемая.
setmaxmem vdsX summ — изменяет верхнюю планку памяти для виртуалки. summ — в килобайтах. Память по этому лимиту виртуалка получит, только если есть свободная память на хосте. По этому лимиту память помечается как используемая хостом, только если она действительно используется виртуалкой. (вообще setmaxmem для KVM не советую использовать, только в облаках если)
setvcpus vdsX count — устанавливает количество count виртуальных ядер для VDS. Можно использовать только для выключенной виртуалки. Сумму count для всех VDS не делаем больше суммы ядер на хосте, а лучше оставляем одно про запас, если не для своих нужд используем весь сервер со всеми виртуалками.

И на закуску:
console vdsX — должно подключить нас к tty1 виртуалки. не работает частенько (
autostart —disable vdsX — отключает автостарт виртуалки при старте хоста. Если вы используете мануалы — заюзайте опцию для всех VDS — всё равно без br1/br2 (которые я рекоммендую не создавать при старте сервера, а создавать скриптами позже) — они не загрузятся.
autostart vdsX — включает автостарт виртуалки.

Остальные команды стоит посмотреть в man virsh, но вряд ли они вам понадобятся. Там ещё есть управление виртуальными устройствами VDSов, но это лучше делать через virt-manager. Ну и некоторые команды в моем случае заменены скриптами virt-install.

P.S. — почаще отдыхайте. Сегодня стал ощущать, что переутомлён… неприятно. А всего то 19 лет только( Зато я всё ближе и ближе к финалу stand-alone экспериментов )
28.07.2010 byinkvizitor68sl|Администрирование Метки: debian, kvm, ssh, virsh

По мотивам последних событий с моей работы решил написать этот пост, ибо ничего похожего в рунете к сожалению не обнаружил, а очень жаль, ибо перетаскивать виртуалки с VirtualBox и VMWare в благородный KVM все таки приходится. Один из популярных способов сводиться в сливу образа диска в KVM, а затем загрузка с установочного диска и востановление системы (а фактически новая установка поверх старых настроек). Лично меня подобная схема не устроила, потому что образ присланной виртуалки не содержал установочного диска с которого его можно было бы восстановить, а искать похожий образ муторно. Итак.

Мы имеем следующий набор. Виртуалка на VirtualBox или VMWare, гостевая система Windows (с linux такой свистопляски нет), и сервер с KVM на котором и будем размещать нашу виртуалку. В моем случае это сервер KVM который работает в связке с LVM, но я постараюсь затронуть и вариант когда KVM работает с файловыми образами диска.

Приступаем.

1. Готовим систему к переносу.

Не секрет, что и VirtualBox и VMWare для нормальной работы ставят в систему свои собственные дрова и утилиты. Так вот первое что нужно сделать – это избавиться от них. Удаляем и VirtualBox Guest Tools и VMWare tools...

Следующим шагом – необходимо будет отвязать нашу Windows от железа на котором она была установлена. К счастью для этого есть официальный мануал (http://support.microsoft.com/kb/314082/en-us). Мотаем его в самый низ, и создаем файлик Mergeide.reg содержащий код из мануала.

После того как файлик был создан и сохранен, запускаем его и вносим изменения в реестр. Теперь осталось проверить что все необходимые файлы для запуска в KVM есть, для этого идем в C:\Windows\system32\drivers\ и ищем там файлы:

atapi.sys
intelide.sys
pciide.sys
pciidex.sys

Если какого либо из этих файликов нет – то заходим внутрь архива C:\Windows\Driver Cache\i386\Driver.cab и копируем недостающие файлики оттуда.
На этом мы закончили приготовления системы, и можем ее без проблем выключить.

2. Готовим образ диска

Тут есть варианты. Все зависит от того какая у вас система виртуализации щас, и где KVM будет хранить свои образы дисков.

Так или иначе, вся схема создания образа делиться на две части, первая – это подготовка SGF (Single Growable File), и вторая – это перенос SGF в KVM.

VMWare

Нам необходимо сконвертировать vmdk файл нашей виртуалки в формат SGF. Этот формат фактически сырой RAW нашего диска, и имеет расширение VMDK. Для VMWare он делается так

“C:\Program Files\VMware\VMware Server\vmware-vdiskmanager” -r windows.vmdk -t 0 windows-sgf.vmdk

Если в этом месте возникают какие либо грабли, то попробуйте параметр “-t 0” заменить на “-t 2”. Хотя в большинстве случаев все должно пройти без проблем.

VirtualBox

Для того что бы сделать образ SGF в VBox’e необходимо в меню Файл -> Менеджер виртуальных дисков, выбрать диск интересующей нас виртуалки и нажать “Копировать”. В качестве источника оставляйте выбранный диск, Тип виртуального диска выбираем VMDK, Дополнительные атрибуты – Фиксированный виртуальный диск.

После того как копирование завершиться вы увидете два образа, с одинаковым именем, но второй будет иметь после имени “-flat”, например “windows.vmdk” и “windows-flat.vmdk”. Как раз второй образ с flat и будет нашим SGF диском.

3. Проверяем образ

Для того что бы избежать ошибок можно проверить полученный образ. Для этого в linux есть команда file. Вывод нормального образа должен иметь примерно следующий вид

# file windows-sgf.vmdk
windows-sgf.vmdk: x86 boot sector; partition 1: ID=0x83, active, starthead 1,
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 208845,
16563015 sectors, code offset 0x48

Если вывод говорит о том что это файл образа VMWare – значит мы не получили нужного нам формата образа.

4. Устанавливаем образ в KVM

Тут все зависит от настроек KVM. Используете ли вы файлы, либо используете LVM. Оба варианта приведены ниже

LVM

Тут особой писать нечего. dd он и в Африке dd.

# dd if=/path/to/windows-sgf.vmdk of=/dev/volgroup/partname

После этого можно кормить KVM этот раздел LVM

KVM File (qcom2)

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

qemu-img convert -f vmdk windows-sgf.vmdk -O qcow2 windows.qcow2

Я думаю что объяснять не нужно что меняя параметр “-О” можно выбрать другой формат хранения. После чего данный диск можно кормить KVM.

Стоит так же отметить, что qemu-img позволяет конвертировать не только SGF но и простые vmdk, хотя с менее предсказуемым результатом. Поэтому лучше конвертировать. Если при конвертации выпадает ошибка, попробуйте не использовать ключ “-f vmdk”, и дайте утилите самостоятельно определить формат образа. Говорят что помогает.

5. Первый запуск.

Я не буду расписывать как настраивать KVM, вы уже большие и сами знаете как это сделать, отмечу только тот факт, что Windows ни под каким соусом не поддерживает virtio, поэтому даже не пытайтесь.

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

6. P2V

С виртуалками разобрались, но как быть с реальными машинами? Честно говоря не пробовал, но есть мнение что данный способ годиться и для реальных машин.

Подготовка машины происходит тем же способом, после выключения можно загрузиться с какого либо Linux LiveCD, и запустить команду на копирование всего физического диска (именно всегодиска , а не раздела) в заранее созданный LVM, или файл.

# dd if=/dev/sda | ssh user@kvm-host “dd of=/path/to/file.vmdk”

И конечно же вы догадались, что вместо file.vmdk, образ можно заливать сразу же в LVM. Не забудьте проверить md5 суммы у исходного и конечного образов.

Удачи в экспериментах.

Если вы желаете перенаправить определенные порты с хостовой в виртуальную машину, например, если вы хотите иметь почтовый сервер на ваиртуальной машине с адресом 192.168.122.90 и перенаправить порт smtp 25 и хост машину с адресом 192.168.0.10, то это можно сделать как-то так (на хост-машине):

iptables -t nat -A PREROUTING -d 192.168.0.10 -p tcp --dport 25 -j DNAT --to-destination 192.168.122.90:25
возможные ошибки
Не работает DNAT в KVM qemu

Мне помогло добавить запись:
iptables -I FORWARD -i eth0 -o virbr0 -p tcp -m state --state NEW -j ACCEPT

http://gorbach.me/2011/ubuntu-10-04-lts-kvm-netwoking/

Для того, чтобы работал shutdown по ACPI в гостевой системе необходимо исправить ключ реестра:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\shutdownwithoutlogon
выставить 1.

p.s.
Правда одна проблема, если производится выключение терминального сервера с подключеными клиентами, выдается запрос:“Данный компьютер используется другими пользователями...”
и выключение не производится. Как обойти пока не знаю...

p.s.s.
Ура получилось!!!
Правим реестр:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Error Message Instrument]
“EnableDefaultReply”=dword:00000001

[добавлено]
На wiki от proxmox нашел еще один ключ, иногда windows выключался некорректно:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows]
“ShutdownWarningDialogTimeout”=dword:00000001

Перезагружаемся и проверяем.