Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Руководство по виртуализации

Virtualization Documentation

Редакция 5.8

Red Hat Engineering Content Services

Юридическое уведомление

Copyright © 2008, 2009, 2010, 2011, 2012 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

Аннотация
The Red Hat Enterprise Linux Virtualization Guide contains information on installation, configuring, administering, and troubleshooting virtualization technologies included with Red Hat Enterprise Linux.

Введение
1. Об этой книге
2. Соглашения документа
2.1. Типографические соглашения
2.2. Соглашения по выделению текста
2.3. Примечания и предупреждения
3. We need your feedback
3.1. Technical review requests
4. What is Virtualization?
5. Types of Virtualization
5.1. Full Virtualization
5.2. Para-Virtualization
5.3. Para-virtualized drivers
6. How CIOs should think about virtualization
I. Требования и ограничения виртуализации в Red Hat Enterprise Linux
1. Системные требования
2. Поддержка Xen и его ограничения
3. Поддержка KVM и его ограничения
4. Hyper-V restrictions and support
5. Ограничения виртуализации
5.1. Общие ограничения
5.2. Ограничения KVM
5.3. Ограничения Xen
5.4. Ограничения приложений
II. Установка
6. Установка пакетов виртуализации
6.1. Установка Xen в процессе установки Red Hat Enterprise Linux
6.2. Установка пакетов Xen в существующей системе Red Hat Enterprise Linux
6.3. Установка KVM в процессе установки Red Hat Enterprise Linux
6.4. Установка пакетов KVM в существующей системе Red Hat Enterprise Linux
7. Обзор установки виртуальных машин
7.1. Создание виртуальных машин с помощью virt-install
7.2. Создание виртуальных машин с помощью virt-manager
7.3. Установка виртуальных машин с помощью PXE
8. Установка гостевой операционной системы
8.1. Установка паравиртуализированной системы Red Hat Enterprise Linux 5
8.2. Установка полностью виртуализированной системы Red Hat Enterprise Linux
8.3. Установка полностью виртуализированной системы Windows XP
8.4. Установка полностью виртуализированной системы Windows Server 2003
8.5. Установка полностью виртуализированной системы Windows XP Server 2008
III. Настройка
9. Virtualized storage devices
9.1. Создание контроллера виртуального дисковода
9.2. Добавление устройств хранения в гостевую систему
9.3. Настройка постоянного хранилища в Red Hat Enterprise Linux 5
9.4. Добавление виртуального устройства CD-ROM или DVD в гостевую систему
10. Настройка сетевого окружения
10.1. Преобразование сетевых адресов с помощью libvirt
10.2. Мостовое соединение с помощью libvirt
11. Сетевое окружение Xen в Red Hat Enterprise Linux 5.4 и более ранних версиях
11.1. Настройка использования нескольких карт Ethernet сетевыми мостами виртуальных машин
11.2. Настройка сетевого окружения в ноутбуках Red Hat Enterprise Linux 5.0
12. Паравиртуализированные драйверы Xen
12.1. Системные требования
12.2. Поддержка и ограничения паравиртуализации
12.3. Установка паравиртуализированных драйверов
12.3.1. Последовательность действий при установке
12.3.2. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 3
12.3.3. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Настройка паравиртуализированного сетевого драйвера
12.5. Настройка дополнительного виртуального оборудования
12.5.1. Виртуальные сетевые интерфейсы
12.5.2. Виртуальные устройства хранения
13. Паравиртуализированные драйверы KVM
13.1. Установка паравиртуализированных драйверов Windows
13.2. Installing drivers with a virtualized floppy disk
13.3. Использование паравиртуализированных драйверов KVM для существующих устройств
13.4. Использование паравиртуализированных драйверов KVM для новых устройств
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Управление временем виртуальных машин KVM
IV. Управление
17. Рекомендации для сервера
18. Виртуализация и безопасность
18.1. Storage security issues
18.2. Виртуализация и SELinux
18.3. SELinux
18.4. Virtualization firewall information
19. Управление виртуальными машинами с помощью xend
20. Живая миграция Xen
20.1. Пример живой миграции
20.2. Настройка живой миграции
21. Живая миграция KVM
21.1. Требования живой миграции
21.2. Пример общего хранилища: Упрощение миграции за счет NFS
21.3. Живая миграция с помощью virsh
21.4. Миграция с помощью virt-manager
22. Удаленное управление виртуальными машинами
22.1. Удаленное управление с помощью SSH
22.2. Удаленное управление с помощью TLS и SSL
22.3. Режимы передачи данных
V. Virtualization Storage Topics
23. Using shared storage with virtual disk images
23.1. Using iSCSI for storing virtual disk images
23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux
23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install
VI. Подробнее о виртуализации
24. Утилиты виртуализации
25. Управление виртуальными машинами с помощью virsh
26. Управление виртуальными машинами с помощью менеджера виртуальных машин (virt-manager)
26.1. The Add Connection window
26.2. Главное окно менеджера виртуальных машин
26.3. The guest Overview tab
26.4. Графическая консоль виртуальной машины
26.5. Запуск virt-manager
26.6. Восстановление сохраненной машины
26.7. Просмотр информации о виртуальной машине
26.8. Мониторинг состояния
26.9. Просмотр идентификаторов виртуальных машин
26.10. Displaying a guest's status
26.11. Просмотр виртуальных процессоров
26.12. Просмотр информации о занятости процессора
26.13. Просмотр информации о занятости памяти
26.14. Управление виртуальной сетью
26.15. Создание виртуальной сети
27. Обзор команд xm
28. Настройка параметров загрузки ядра Xen
29. Настройка ELILO
30. libvirt configuration reference
31. Файлы конфигурации Xen
VII. Советы и хитрости
32. Советы и хитрости
32.1. Автоматический запуск виртуальных машин
32.2. Переключение между гипервизорами KVM и Xen
32.2.1. Хеn на KVM
32.2.2. KVM на Xen
32.3. qemu-img
32.4. Overcommitting Resources
32.5. Редактирование /etc/grub.conf
32.6. Проверка расширений виртуализации
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Создание уникального MAC-адреса
32.10. Ограничение сетевой полосы пропускания для гостя Xen
32.11. Настройка соответствий процессоров в Xen
32.12. Изменение гипервизора Xen
32.13. vsftpd
32.14. Настройка постоянства LUN
32.15. Отключение SMART-мониторинга дисков для гостевых систем
32.16. Очистка старых файлов конфигурации Xen
32.17. Настройка VNC-сервера
32.18. Дублирование файлов конфигурации виртуальных машин
32.19. Дублирование существующей виртуальной машины и ее файла конфигурации
33. Создание специализированных сценариев libvirt
33.1. Использование файлов конфигурации с помощью virsh
VIII. Диагностика проблем
34. Диагностика проблем Xen
34.1. Диагностика и отладка Xen
34.2. Обзор журналов
34.3. Описание журналов
34.4. Основные каталоги
34.5. Диагностика проблем с помощью журналов
34.6. Диагностика проблем с помощью последовательной консоли
34.7. Доступ к консоли паравиртуализированного гостя
34.8. Доступ к консоли полностью виртуализированного гостя
34.9. Типичные проблемы Xen
34.10. Ошибки создания виртуальных машин
34.11. Подробнее о последовательной консоли
34.11.1. Вывод на последовательную консоль
34.11.2. Вывод паравиртуализированных гостей на последовательную консоль
34.11.3. Вывод полностью виртуализированных гостей на последовательную консоль
34.12. Файлы конфигурации Xen
34.13. Интерпретация сообщений об ошибках
34.14. Каталоги с журналами
35. Диагностика проблем
35.1. Определение доступных накопителей и разделов
35.2. После перезагрузки виртуальных машин на основе Xen не работает консоль
35.3. Сетевые утилиты не могут найти виртуализированные устройства Ethernet
35.4. Ошибки петлевого устройства
35.5. Не удается создать домен из-за нехватки памяти
35.6. Ошибка: Неверный образ ядра
35.7. Ошибка: Неверный образ ядра — не-PAE ядро на платформе PAE
35.8. Не удается загрузить полностью виртуализированную 64-разрядную виртуальную машину
35.9. Отсутствие записи localhost приводит к сбою virt-manager
35.10. Ошибка микрокода в процессе загрузки виртуальной машины
35.11. Предупреждающие сообщения Python при запуске виртуальной машины
35.12. Как включить в BIOS аппаратные расширения виртуализации Intel VT и AMD-V?
35.13. Производительность сетевого окружения KVM
36. Диагностика проблем паравиртуализированных драйверов Xen
36.1. Журналы виртуализации Red Hat Enterprise Linux 5
36.2. Паравиртуализированная машина не загружает Red Hat Enterprise Linux 3
36.3. Предупреждение при установке драйверов в Red Hat Enterprise Linux 3
36.4. Загрузка паравиртуализированных драйверов вручную
36.5. Проверка успешной загрузки паравиртуализированных драйверов
36.6. Снижение пропускной способности при использовании паравиртуализированных драйверов
Glossary
A. Дополнительные ресурсы
A.1. Интернет-ресурсы
A.2. Установленная документация
B. Издание

Введение

The Red Hat Enterprise Linux Virtualization Guide covers all aspects of using and managing virtualization products included with Red Hat Enterprise Linux.

1. Об этой книге

This book is divided into 8 parts:
  • Системные требования
  • Установка
  • Настройка
  • Администрирование
  • Storage
  • Предметный указатель
  • Советы и хитрости
  • Диагностика проблем
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to Раздел 4, «What is Virtualization?» and the Glossary for more details on these terms.

2. Соглашения документа

В этом руководстве используются различные стили для выделения текста.
В PDF и бумажной версиях руководства используются шрифты семейства Liberation. Эти же шрифты будут использоваться для отображения HTML-версии, если они установлены в вашей системе. В противном случае будут использоваться аналогичные шрифты. Red Hat Enterprise Linux 5 и более поздние версии включают в свой состав комплект Liberation по умолчанию.

2.1. Типографические соглашения

Для выделения текста используются четыре стиля, которые будут перечислены далее.
Моноширинный жирный шрифт
Используется для выделения вводимого текста, включая команды оболочки, а также имен файлов, путей и комбинаций клавиш. Пример:
Чтобы просмотреть содержимое файла my_next_bestselling_novel в текущем каталоге, в строке приглашения оболочки введите cat my_next_bestselling_novel и нажмите Enter для выполнения этой команды.
Приведенный текст содержит имя файла, команду оболочки и имя клавиши, которые выделены моноширинным жирным шрифтом.
Для разделения клавиш в составе комбинаций используется дефис. Пример:
Нажмите Enter для исполнения команды.
Нажмите Ctrl+Alt+F2 для перехода в первый виртуальный терминал. Нажмите Ctrl+Alt+F1 , чтобы вернуться в сессию X-Windows.
В первом примере жирным шрифтом выделено название отдельной клавиши, во втором — комбинаций клавиш.
Этим же шрифтом выделяются имена классов, методов, функций, переменных и возвращаемые ими значения. Пример:
Классы файлов включают filesystem для файловых систем, file для файлов, dir для каталогов. Каждому классу соответствует набор разрешений.
Пропорциональный жирный
Выделяет системные слова и фразы, что включает имена приложений, текст диалогов, названия меню, текст кнопок, флажков и других элементов графического интерфейса. Пример:
В главном меню выберите СистемаПараметры Мышь для запуска утилиты Настройки мыши. На вкладке Кнопки установите флажок Настроить мышь под левую руку и нажмите кнопку Закрыть, чтобы настроить мышь для левши.
Чтобы вставить специальный символ в файл gedit, выберите ПриложенияСтандартные Таблица символов. Затем в меню выберите ПоискПоиск…, введите имя символа и нажмите кнопку Найти следующее. Найденный символ будет выделен в таблице символов. Дважды щелкните на этом символе, чтобы вставить его в поле Текст для копирования и нажмите кнопку Копировать. Теперь вернитесь к вашему документу и в меню выберите ПравкаВставить.
Приведенный выше текст содержит имя приложения, названия меню, кнопок и текста элементов графического интерфейса.
Моноширинный жирный курсив или пропорциональный жирный курсив
Оба типа выделения обозначают изменяемый или заменяемый текст. Курсив сообщает о том, что не следует вводить приведенный текст напрямую, а изменить в соответствии с вашими настройками. Пример:
Для подключения к удаленной машине с помощью SSH в строке приглашения выполните ssh имя_пользователя@имя_домена. Скажем, имя удаленной машины – example.com, а ваше имя пользователя – john, тогда команда будет выглядеть так: ssh john@example.com.
Команда mount -o remount файловая_система повторно подключит заданную файловую систему. Например, для /home команда будет выглядеть так: mount -o remount /home.
Чтобы просмотреть версию установленного пакета, выполните команду rpm -q пакет. Результат команды будет представлен в формате пакет-версия-выпуск.
В приведенных примерах жирным курсивом выделяются имя пользователя, имя домена, файловой системы, пакет, его версия и выпуск.
Также курсивом выделяются термины, которые встречаются в тексте документа впервые. Пример:
Publican — система публикации DocBook.

2.2. Соглашения по выделению текста

Вывод экрана и листинг исходного кода будут отделены от окружающего текста.
Для отображения текста, который вы увидите на экране, используется моноширинный шрифт:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Для отображения содержимого исходного кода используется моноширинный шрифт:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

2.3. Примечания и предупреждения

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

Примечание

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

Важно

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

Предупреждение

Не стоит игнорировать предупреждения, так как они содержат важную информацию, которая позволит избежать потери данных.

3. We need your feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you. Submit a report in Bugzilla: http://bugzilla.redhat.com/ against Red Hat Enterprise Linux with the Virtualization_Guide component.
When submitting a bug report, be sure to mention the manual's identifier: Virtualization_Guide and version number: 5.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

3.1. Technical review requests

All review requests are classified into one of the following five categories:
New content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

4. What is Virtualization?

Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer that controls hardware and provides guest operating systems with access to underlying hardware devices. The hypervisor allows multiple operating systems to run on the same physical system by offering virtualized hardware to the guest operating system.

5. Types of Virtualization

5.1. Full Virtualization

Red Hat Enterprise Linux contains virtualization packages and tools which provide system administrators with the means to run fully virtualized, unmodified, operating system guests on Red Hat Enterprise Linux. This provides companies with the ability to consolidate older systems onto newer, more efficient hardware. This reduces physical space and operating costs involved with powering and cooling older, less efficient systems. Full virtualization incurs worse I/O performance than native, also known as bare-metal, installations of operating systems.

5.2. Para-Virtualization

Para-virtualization is a virtualization technique which involves running modified versions of operating systems. The para-virtualized operating system is modified to be aware that it is being virtualized, offering an increased ability for optimization as the guest is more aware of its environment. Performance is generally very close to running bare-metal, non-virtualized operating systems.

5.3. Para-virtualized drivers

These two techniques, para-virtualization and full virtualization, can be combined to allow unmodified operating systems to receive near native I/O performance by using para-virtualized drivers on fully virtualized operating systems. This guide covers installation and configuration of the Red Hat Enterprise Linux para-virtualized drivers package for fully virtualized Microsoft Windows® guests.
The para-virtualized drivers package contains storage and network device drivers for fully virtualized Microsoft Windows® guests. The drivers provide Microsoft Windows® guests running on Red Hat Enterprise Linux with enhanced disk and network I/O performance.

6. How CIOs should think about virtualization

by Lee Congdon, Chief Information Officer, Red Hat, Inc.
Возможно, ваша организация уже активно утилизирует активно развивающиеся технологии виртуализации. Если нет, теперь самое время начать. Далее будут рассмотрены идеи, которые помогут эффективно использовать виртуализацию.
Виртуализация предоставляет ряд инструментов для обеспечения гибкости работы и снижения затрат, что достаточно важно для любой организации. Решения виртуализации становятся все более доступными, а их возможности постоянно расширяются.
Так как виртуализация является выгодным решением для реализации потребностей организации в различных областях, имеет смысл приступить к ее тестированию и заняться обучением персонала для достижения в дальнейшем максимального эффекта в ближайшем будущем.
Виртуализация для инновации
В сущности, виртуализация повышает гибкость работы посредством обеспечения независимости операционной системы (ОС), поддерживаемых этой ОС служб и приложений от конкретной платформы. Это позволяет создавать различные виртуальные окружения на одной аппаратной платформе.
Возможность создания новых систем и служб без необходимости установки дополнительного программного обеспечения (ПО) и быстрого их удаления, если они больше не нужны, является главным преимуществом новой технологии.
Основные подходы включают быструю установку систем разработки для создания произвольного ПО, возможность быстрого создания тестового окружения, предоставления альтернативных программных решений и их сравнения без больших затрат на оборудование, поддержку быстрого создания прототипов и гибких окружений разработки, возможность быстрой настройки служб при необходимости.
Такие окружения могут быть созданы или приобретены отдельно, как, например, Amazon EC2. При создании нового виртуального окружения стоимость будет невысока, так как при этом можно использовать существующее оборудование.
Виртуализация позволяет использовать виртуальные окружения для обучения. Например, студент может предпочесть работать в хорошо знакомом ему окружении, которое можно изолировать от рабочей сети и установить требуемые приложения без необходимости эксклюзивного выделения аппаратных ресурсов.
Возможности, предоставляемые виртуальными окружениями, постоянно расширяются, как и использование виртуализации для организации специализированных портативных окружений. Их можно динамически переносить независимо от расположения пользователя. Виртуальные окружения пользователей могут быть сохранены в сети или на переносных накопителях.
Подобная концепция присуща операционной системе AOS (Appliance Operating System), которая предназначена для выполнения в виртуальном окружении. Минималистический подход позволяет снизить затраты на производство и поддержку, а также позволяет обеспечить выполнение приложения в безопасном окружении.
Способы применения приложений виртуализации могут быть разными. Если вы уже используете эти технологии в перечисленных выше областях, можно взвесить преимущества дополнительного инвестирования в технологические решения, для которых быстрое развитие наиболее критично. Если же вы еще не сталкивались с виртуализацией, начните с изучения основных возможностей и затем перейдите к разработке приложений и тестированию. Компании с большим опытом работы с виртуализацией могут рассмотреть возможность организации портативных виртуальных окружений.
Виртуализация для снижения затрат
Использование возможностей виртуализации также помогает снизить затраты, например, возможно объединение серверов в группы в составе мощных платформ, на которых выполняются наборы виртуальных окружений. Затраты можно снизить не только за счет уменьшения занятого оборудования и его нагрузки, а также за счет повышения производительности вследствие того, что виртуальные машины выполняются на более мощном оборудовании.
Также можно добавлять дополнительное оборудование без нарушения работы и осуществлять динамический перенос нагрузки на доступные ресурсы.
В зависимости от потребностей вашей организации можно создать виртуальное окружение для аварийного восстановления. Виртуализация может значительно снизить необходимость репликации идентичных окружений оборудования и позволяет выполнять тестирование аварийных сценариев при минимальных затратах.
Виртуализация может использоваться для распределения нагрузки. Если вашей организации свойственны дополнительные нагрузки, можно обеспечить динамическое выделение ресурсов приложениям по мере необходимости. Так, например, в случае периодических всплесков нагрузки, вместо ее обработки внутри организации, можно приобрести дополнительные ресурсы за ее пределами и динамически их использовать с помощью возможностей виртуализации.
Экономия затрат в результате объединения серверов может быть достаточно значительной. Со временем вы познакомитесь с возможностями распределения нагрузки и виртуализированных окружений аварийного восстановления.
Виртуализация как стандартное решение
Независимо от того, какие цели преследует ваша организация, стоит внимательно присмотреться к технологиям виртуализации, которые становятся все более и более популярными. Не исключено, что в будущем производители операционных систем будут включать виртуализацию как стандартный компонент, производители оборудования будут встраивать виртуальные функции в платформы, а возможности самой виртуализации значительно расширятся.
Если на данном этапе вы не планируете использовать виртуализацию, попытайтесь идентифицировать проекты, выделить аппаратные платформы, которые не заняты на 100%, и проанализируйте, как виртуализация смогла бы улучшить управляемость и доступность.
Более подробную информацию о решениях виртуализации Red Hat можно получить на странице http://www.redhat.com/products/.

Часть I. Требования и ограничения виртуализации в Red Hat Enterprise Linux

Системные требования и ограничения

В последующих главах будут рассмотрены системные требования, ограничения виртуализации и ее поддержки в Red Hat Enterprise Linux.

Глава 1. Системные требования

This chapter lists system requirements for successfully running virtualization with Red Hat Enterprise Linux. Virtualization is available for Red Hat Enterprise Linux 5 Server.
The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.
For information on installing the virtualization packages, read Глава 6, Установка пакетов виртуализации.
Минимальные системные требования
  • 6 Гбайт свободного пространства на диске
  • 2 Гбайт ОЗУ

Перераспределение ресурсов KVM

KVM can overcommit physical resources for virtualized guests. Overcommiting resources means the total virtualized RAM and processor cores used by the guests can exceed the physical RAM and processor cores on the host. For information on safely overcommitting resources with KVM refer to Раздел 32.4, «Overcommitting Resources».
Требования паравиртуализации Xen
Для паравиртуализированных гостей потребуется сетевое дерево установки Red Hat Enterprise Linux 5, доступ к которому можно получить по FTP, HTTP, NFS.
Требования для полной виртуализации Xen
Полная виртуализация с гипервизором Xen требует:
  • an Intel processor with the Intel VT extensions, or
  • процессор AMD с расширениями AMD-V или
  • процессор Intel Itanium.
Refer to Раздел 32.6, «Проверка расширений виртуализации» to determine if your processor has the virtualization extensions.
Требования KVM
Гипервизор KVM требует:
  • процессор Intel с расширениями Intel VT и Intel 64 или
  • процессор AMD с расширениями AMD-V и AMD64.
Refer to Раздел 32.6, «Проверка расширений виртуализации» to determine if your processor has the virtualization extensions.
Поддержка хранилищ
Поддерживаемые типы хранилищ:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Файловые хранилища для гостевых систем

File-based guest images are stored in the /var/lib/libvirt/images/ directory by default. If you use a different directory you must label the new directory according to SELinux policy. Refer to Раздел 18.2, «Виртуализация и SELinux» for details.

Глава 2. Поддержка Xen и его ограничения

Red Hat Enterprise Linux 5 supports various architecture combinations for hosts and virtualized guests. All architectures have processor and memory limitations. Refer to the following URLs for the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Примечание

To utilize para-virtualization on Red Hat Enterprise Linux 5, your processor must have the Physical Address Extension (PAE) instruction set.

Поддержка Itanium®

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Установка гипервизора с помощью yum for more information.

Глава 3. Поддержка KVM и его ограничения

The KVM hypervisor requires a processor with the Intel-VT or AMD-V virtualization extensions.
To verify whether your processor supports the virtualization extensions and for information on enabling the virtualization extensions if they are disabled, refer to Раздел 32.6, «Проверка расширений виртуализации».
The following URLs explain the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Глава 4. Hyper-V restrictions and support

Certification of guests running under the Microsoft Hyper-V server is conducted by Microsoft. Red Hat Enterprise Linux 5 is fully certified to run under the Microsoft Hyper-V server.

Примечание

To avoid timing errors when running Red Hat Enterprise Linux 5 under the Microsoft Hyper-V server, use the divider=10 option in the grub.conf file.

Глава 5. Ограничения виртуализации

Здесь будут рассмотрены ограничения пакетов виртуализации в Red Hat Enterprise Linux.

5.1. Общие ограничения

Converting between hypervisors
Presently, there is no support for converting Xen-based guests to KVM or KVM-based guests to Xen. Guests can only be supported on the hypervisor type on which they were created. However, at the time of writing, a tool is in development which may be released with future versions of Red Hat Enterprise Linux.
Другие ограничения
For other details affecting virtualization, refer to the Red Hat Enterprise Linux Release Notes at http://docs.redhat.com for your version. The Release Notes cover the present new features, known issues and limitations as they are updated or discovered.
Сначала тестируйте
You should test for the maximum anticipated system and virtualized network load before deploying heavy I/O applications. Load testing and planning are important as virtualization performance can suffer due to high I/O usage.

5.2. Ограничения KVM

Ограничения гипервизора KVM включают:
Бит TSC
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Глава 16, Управление временем виртуальных машин KVM for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Перераспределение памяти
KVM supports memory overcommit and can store the memory of guests in swap. A guest will run slower if it is swapped frequently. When Kernel SamePage Merging (KSM) is used, make sure that the swap size is equivalent to the size of the overcommit ratio.
Перераспределение процессоров
Не допускается использование более 10 виртуальных процессоров на одном физическом процессорном ядре, так как слишком большое число может нарушить стабильность работы виртуализированных систем.
Overcommitting CPUs has some risk and can lead to instability. Refer to Раздел 32.4, «Overcommitting Resources» for tips and recommendations on overcommitting CPUs.
Виртуализированные устройства SCSI
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Виртуализированные устройства IDE
КVM допускает использование максимум четырех виртуализированных устройств IDE в одной гостевой системе.
Паравиртуализированные устройства
Паравиртуализированные устройства, использующие драйверы virtio, являются устройствами PCI. В настоящее время максимально допустимое число PCI-устройств для каждой виртуальной машины — 32. Некоторые устройства могут быть необходимы для работы гостевой системы, поэтому их нельзя удалить. Эти устройства включают:
  • мост узла,
  • мост ISA и USB (это одно и то же устройство),
  • видеокарта (использующая драйвер Cirrus или qxl),
  • устройство перераспределения памяти.
То есть из 32 доступных каждому гостю PCI-устройств 4 нельзя удалить. Это означает, что можно дополнительно подключить 28 устройств, которые могут включать паравиртуализированные сетевые или дисковые устройства и другие PCI-устройства, использующие VT-d. Каждое паравиртуализированное сетевое или блочное устройство занимает один слот.
Ограничения миграции
Живая миграция возможна только, если все процессоры были произведены одной и той же компанией (например, Intel или AMD).
Для выполнения живой миграции необходимо настроить бит NX (No eXecution) для обоих процессоров.
Storage limitations
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guests should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.

5.3. Ограничения Xen

Замечание

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Ограничения домена 0
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.

Увеличение числа паравиртуализированных устройств

There are two methods for working around the para-virtualized device limit: using phy devices (devices using the physical access mode) or using LVM on the guest.
Число устройств phy не ограничено. Узел может иметь столько устройств, сколько позволяют ресурсы.
Для создания дополнительных логических разделов на отдельном паравиртуализированном блочном устройстве можно прибегнуть к помощи LVM или аналогичного механизма разбиения на разделы.
Ограничения паравиртуализации Xen
  • For x86 guests, a maximum of 16GB memory per guest.
  • For x86_64 guests, a maximum of 168GB memory per guest.
  • A maximum of 254 devices per virtualized guest.
  • Максимум 15 сетевых устройств на каждую виртуальную машину.
Ограничения полной виртуализации Xen
  • For x86 guests, a maximum of 16GB memory per guest.
  • Максимум 4 виртуализированных IDE-устройства на каждую виртуальную машину.
    Это ограничение не накладывается на устройства, использующие паравиртуализированные драйверы для полностью виртуализированных гостей.
  • Virtualized (emulated) IDE devices are limited by the total number of loopback devices supported by the system. The default number of available loopback devices on Red Hat Enterprise Linux 5.8 is 8. That is, by default, all virtualized guests on the system can each have no more than 8 virtualized (emulated) IDE devices.
    For more information on loopback devices, refer to the Red Hat KnowledgeBase, article DOC-1722.

    Использование больше 8 петлевых устройств

    По умолчанию Red Hat Enterprise Linux ограничивает число петлевых устройств. Это число можно изменить на уровне ядра.
    Для этого в файл /etc/rc.local добавьте:
    options loop max_loop=64
    
    Reboot the machine or run the following commands to update the kernel with this new limit:
    # rmmod loop
    # modprobe loop
    
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.
  • A maximum of 254 block devices using the para-virtualized drivers per virtualized guest.
  • Максимум 15 сетевых устройств на каждую виртуальную машину.
  • Максимум 15 виртуализированных SCSI-устройств на каждую виртуальную машину.
PCI passthrough limitations
  • PCI passthrough (attaching PCI devices to guests) is presently only supported on the following architectures:
    • 32 bit (x86) systems.
    • Intel 64 systems.
    • Intel Itanium 2 systems.

5.4. Ограничения приложений

Здесь рассмотрены ограничения, которые делают виртуализацию неприемлемой для некоторых типов приложений.
Приложениям с большим объемом операций ввода и вывода следует использовать паравиртуализированные драйверы для полностью виртуализированных гостей. Иначе при больших нагрузках их производительность может пострадать.
Следует избегать использования следующих приложений в силу их высоких требований ввода/вывода:
  • сервер kdump
  • сервер netdump
You should carefully evaluate database applications before running them on a virtualized guest. Databases generally use network and storage I/O devices intensively. These applications may not be suitable for a fully virtualized environment. Consider para-virtualization or para-virtualized drivers in these cases for increased I/O performance.
Other applications and tools which heavily utilize I/O or require real-time performance should be evaluated carefully. Using full virtualization with the para-virtualized drivers or para-virtualization results in better performance with I/O intensive applications. Applications still suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using fully virtualized hardware.

Часть II. Установка

Установка виртуализации

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

Глава 6. Установка пакетов виртуализации

Прежде чем возможности виртуализации станут доступны в Red Hat Enterprise Linux, надо установить пакеты виртуализации. Это можно сделать в процессе установки или отдельно с помощью команды yum и Red Hat Network (RHN).
В одной системе можно одновременно установить гипервизоры KVM и Xen. Xen использует пакет ядра kernel-xen, а KVM — стандартное ядро Red Hat Enterprise Linux с модулем kvm. Именно поэтому только один гипервизор может быть активен в определенный момент времени. Red Hat рекомендует устанавливать только тот гипервизор, который вы планируете использовать.

6.1. Установка Xen в процессе установки Red Hat Enterprise Linux

В этой секции будет рассказано о том, как установить утилиты виртуализации и пакеты Xen в процессе установки новой системы Red Hat Enterprise Linux.

Нужна помощь в установке?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Запустите интерактивную установку Red Hat Enterprise Linux с установочного носителя (CD-ROM, DVD, PXE).
  2. You must enter a valid installation number when prompted to receive access to the virtualization and other Advanced Platform packages. Installation numbers can be obtained from Red Hat Customer Service.
  3. Complete all steps until you see the package selection step.
    Выберите группу Виртуализация и отметьте Настроить сейчас.
  4. Установите флажок напротив группы Виртуализация для выбора гипервизора Xen, virt-manager, libvirt, virt-viewer и их зависимостей.
  5. При необходимости измените список пакетов.

    Можно изменить список пакетов в выбранной группе.
    Press the Close button then the Forward button to continue the installation.

Замечание

Для получения обновлений пакетов виртуализации потребуется соответствующее полномочие виртуализации RHN.
Автоматизация установки пакетов Xen
Здесь рассмотрен процесс установки Red Hat Enterprise Linux с Xen с помощью файла кикстарта, что позволит выполнить одновременную установку для большого числа систем.
В секцию %packages добавьте следующее определение:
%packages
@xen

В системах Intel Itanium

Fully virtualized guests on the Itanium® architecture require the guest firmware image package (xen-ia64-guest-firmware). Append the following package to your kickstart file:
xen-ia64-guest-firmware
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.2. Установка пакетов Xen в существующей системе Red Hat Enterprise Linux

Далее будет рассмотрен процесс установки пакетов виртуализации в рабочей системе Red Hat Enterprise Linux.
Добавление пакетов в список полномочий Red Hat Network
Для установки и обновления пакетов виртуализации в Red Hat Enterprise Linux необходимы соответствующие полномочия RHN, а для их получения нужна учетная запись Red Hat Network.
Дополнительно, ваша система должна быть зарегистрирована в RHN. Это можно сделать с помощью утилиты rhn_register.
Подписку Red Hat можно приобрести в Интернет-магазине Red Hat.
Процедура 6.1. Добавление полномочия виртуализации
  1. Авторизуйтесь на сайте RHN.
  2. Выберите системы для добавления возможностей виртуализации.
  3. В секции системных настроек будут перечислены существующие полномочия, которые можно изменить, нажав ссылку редактирования.
  4. Отметьте флажок виртуализации.
Теперь ваша система сможет получать пакеты виртуализации. Ниже будет рассмотрен процесс установки этих пакетов.
Установка гипервизора с помощью yum
Чтобы использовать возможности виртуализации в Red Hat Enterprise Linux, необходимо установить пакеты xen и kernel-xen. Пакет xen содержит гипервизор и утилиты Xen, а kernel-xen включает модифицированное ядро Linux, которое может выполняться в качестве гостя виртуальной машины на гипервизоре.
Команда установки xen и kernel-xen:
# yum install xen kernel-xen
Для полностью виртуализированных гостевых систем на платформах Itanium® потребуется пакет xen-ia64-guest-firmware, который можно найти на дополнительном установочном диске. Этот пакет также можно установить с помощью yum:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Рекомендуемые пакеты виртуализации lists the recommended packages.
Команда установки пакетов:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Установка KVM в процессе установки Red Hat Enterprise Linux

В этой секции будет рассказано о том, как установить утилиты виртуализации и пакеты Xen в процессе установки новой системы Red Hat Enterprise Linux.

Нужна помощь в установке?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.

Действующий код установки

Код установки необходим для доступа к списку пакетов виртуализации.
  1. Запустите интерактивную установку Red Hat Enterprise Linux с установочного носителя (CD-ROM, DVD, PXE).
  2. По запросу введите действующий код установки для получения доступа к пакетам виртуализации.
  3. Complete all steps up to the package selection step.
    Выберите группу Виртуализация и отметьте Настроить сейчас.
  4. Снимите флажок напротив группы Виртуализация и отметьте KVM для выбора гипервизора KVM, virt-manager, libvirt и virt-viewer.
  5. При необходимости измените список пакетов.

    Можно изменить список пакетов в выбранной группе.
    Press the Close button then the Forward button to continue the installation.

Замечание

Для получения обновлений пакетов виртуализации потребуется соответствующее полномочие виртуализации RHN.
Автоматизация установки пакетов KVM
Здесь рассмотрен процесс установки Red Hat Enterprise Linux с KVM с помощью файла кикстарта, что позволяет выполнить одновременную установку для большого числа систем.
В секцию %packages добавьте следующее определение:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Установка пакетов KVM в существующей системе Red Hat Enterprise Linux

Далее будет рассмотрен процесс установки гипервизора KVM в рабочей системе Red Hat Enterprise Linux, начиная с версии 5.4.
Добавление пакетов в список полномочий Red Hat Network
Для установки и обновления пакетов виртуализации в Red Hat Enterprise Linux необходимы соответствующие полномочия RHN, а для их получения нужна учетная запись Red Hat Network.
Дополнительно, ваша система должна быть зарегистрирована в RHN. Это можно сделать с помощью утилиты rhn_register.
Подписку Red Hat можно приобрести в Интернет-магазине Red Hat.
Процедура 6.2. Добавление полномочия виртуализации
  1. Авторизуйтесь на сайте RHN.
  2. Выберите системы для добавления возможностей виртуализации.
  3. В секции системных настроек будут перечислены существующие полномочия, которые можно изменить, нажав ссылку редактирования.
  4. Отметьте флажок виртуализации.
Теперь ваша система сможет получать пакеты виртуализации. Ниже будет рассмотрен процесс установки этих пакетов.
Установка гипервизора KVM с помощью yum
Чтобы использовать возможности виртуализации в Red Hat Enterprise Linux, необходимо установить пакет kvm, который содержит модуль ядра KVM.
Команда установки kvm:
# yum install kvm
Теперь установите дополнительные пакеты виртуализации.
Команда установки пакетов:
# yum install virt-manager libvirt libvirt-python python-virtinst

Глава 7. Обзор установки виртуальных машин

После завершения установки пакетов виртуализации в размещающей системе можно приступить к созданию виртуальных машин. В этой главе будут описаны процессы установки гостевых операционных систем на виртуальных машинах. Это можно сделать, нажав кнопку Создать (New) в окне менеджера виртуальных машин (virt-manager) или с помощью команды virt-install. Оба способа будут рассмотрены ниже.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Глава 8, Установка гостевой операционной системы for those procedures.

7.1. Создание виртуальных машин с помощью virt-install

Виртуальную машину можно создать с помощью команды virt-install, которую можно либо запустить напрямую, либо включить в сценарий для автоматизации процесса создания виртуальных машин.
virt-install принимает параметры, полный список которых можно просмотреть, выполнив команду
$ virt-install --help
На странице помощи virt-install также перечислены наиболее важные параметры и переменные.
Прежде чем вызвать команду virt-install, можно выполнить qemu-img для настройки хранилища.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Пример 7.1. Создание гостя Red Hat Enterprise Linux 3 с помощью virt-install и KVM
В этом примере гостевая система Red Hat Enterprise Linux 3 с именем rhel3support будет создана с CD-ROM. Ей будет сопоставлен файловый образ блочного устройства размером 5 гигабайт и настроено виртуальное сетевое окружение. Пример использует гипервизор KVM.
# virt-install --accelerate --hvm --connect qemu:///system \
   --network network:default \
   --name rhel3support --ram=756\
   --file=/var/lib/libvirt/images/rhel3support.img \
   --file-size=6 --vnc --cdrom=/dev/sr0

Пример 7.2. Создание гостя Fedora 11 с помощью virt-install
# virt-install --name fedora11 --ram 512 --file=/var/lib/libvirt/images/fedora11.img \
	--file-size=3 --vnc --cdrom=/var/lib/libvirt/images/fedora11.iso

7.2. Создание виртуальных машин с помощью virt-manager

Менеджер виртуальных машин представляет собой приложение (virt-manager), с помощью которого можно управлять виртуальными машинами.
Процедура 7.1. Создание виртуальной машины с помощью virt-manager
  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.
  2. Optional: Open a remote hypervisor

    Open the File -> Add Connection. The dialog box below appears. Select a hypervisor and click the Connect button:
  3. Create a new guest

    Новую виртуальную машину можно создать, нажав кнопку Создать (New) в главном окне virt-manager.
  4. New guest wizard

    The Create a new virtual machine window provides a summary of the information you must provide in order to create a virtual machine:
    Просмотрите информацию и нажмите кнопку продолжения.
  5. Name the virtual machine

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  6. Choose virtualization method

    Выберите тип виртуализации (полная или паравиртуализация).
    Полная виртуализация требует наличия процессора Intel® VT или AMD-V. Если расширений виртуализации нет, то выбор полностью виртуализированной системы будет недоступен. Если же в этот момент не выполняется ядро kernel-xen, то будет недоступен выбор паравиртуализации.
    При подключении к гипервизору KVM будет доступна только полная виртуализация.
    Choose the virtualization type and click the Forward button.
  7. Select the installation method

    The Installation Method window asks for the type of installation you selected.
    Guests can be installed using one of the following methods:
    Local media installation
    This method uses a CD-ROM or DVD or an image of an installation CD-ROM or DVD (an .iso file).
    Network installation tree
    This method uses a mirrored Red Hat Enterprise Linux installation tree to install guests. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS.
    The network services and files can be hosted using network services on the host or another mirror.
    Network boot
    This method uses a Preboot eXecution Environment (PXE) server to install the guest. Setting up a PXE server is covered in the Red Hat Enterprise Linux Deployment Guide. Using this method requires a guest with a routable IP address or shared network device. Refer to Глава 10, Настройка сетевого окружения for information on the required networking configuration for PXE installation.
    Set the OS type and OS variant.
    Choose the installation method and click Forward to proceed.

    Para-virtualized guest installation

    Para-virtualized installation must be installed with a network installation tree. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS. The installation media URL must contain a Red Hat Enterprise Linux installation tree. This tree is hosted using NFS, FTP or HTTP.
  8. Installation media selection

    This window is dependent on what was selected in the previous step.
    1. ISO image or physical media installation

      If Local install media was selected in the previous step this screen is called Install Media.
      Select the location of an ISO image or select a DVD or CD-ROM from the dropdown list.
      Click the Forward button to proceed.
    2. Network install tree installation

      If Network install tree was selected in the previous step this screen is called Installation Source.
      Network installation requires the address of a mirror of a Linux installation tree using NFS, FTP or HTTP. Optionally, a kickstart file can be specified to automated the installation. Kernel parameters can also be specified if required.
      Click the Forward button to proceed.
    3. Network boot (PXE)

      PXE installation does not have an additional step.
  9. Storage setup

    The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Раздел 18.2, «Виртуализация и SELinux» for details.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap based on size of the RAM allocated to the guest.
    При необходимости выделите дополнительное пространство. Например, веб-серверы обычно требуют больше пространства для хранения журналов.
    Нажмите кнопку продолжения.

    Примечание

    It is recommend that you use the default directory for virtual machine images, /var/lib/libvirt/images/. If you are using a different location (such as /images/ in this example) make sure it is added to your SELinux policy and relabeled before you continue with the installation (later in the document you will find information on how to modify your SELinux policy).
  10. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  11. Memory and CPU allocation

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Виртуальной машине понадобится достаточный для ее работы объем оперативной памяти (как минимум 512 мегабайт). Стоит помнить, что виртуальные машины используют физическую память. Выполнение слишком большого числа гостей или предоставление размещающей системе недостаточного объема памяти может привести к повышенному использованию виртуальной памяти и области подкачки. Как известно, виртуальная память значительно медленнее физической, как следствие, работа системы существенно замедлится. Этого можно избежать, выделив виртуальным машинам достаточный объем памяти.
    Аналогичным образом, виртуальной машине следует выделить достаточное число виртуальных процессоров. Если она выполняет многопотоковые приложения, примите это во внимание при выделении процессорных ресурсов. Однако число виртуальных процессоров не должно превышать число доступных физических процессоров (или гиперпотоков). В свою очередь, предоставление слишком большого числа виртуальных процессоров отрицательно скажется на производительности из-за лишних издержек.
    Press Forward to continue.
  12. Verify and start guest installation

    The Finish Virtual Machine Creation window presents a summary of all configuration information you entered. Review the information presented and use the Back button to make changes, if necessary. Once you are satisfied click the Finish button and to start the installation process.
    Появится окно VNC, в котором можно следить за установкой.
This concludes the general process for creating guests with virt-manager. Глава 8, Установка гостевой операционной системы contains step-by-step instructions to installing a variety of common operating systems.

7.3. Установка виртуальных машин с помощью PXE

Для установки виртуальной машины с помощью PXE необходимо наличие общего сетевого устройства — сетевого моста. Ниже будет рассмотрено, как создать такой мост и использовать его при PXE-установке.
  1. Создайте новый мост

    1. Создайте сценарий в каталоге /etc/sysconfig/network-scripts/. В приведенном примере файл с именем ifcfg-installation содержит определение моста installation.
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      Предупреждение

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
    2. Start the new bridge by restarting the network service. The ifup installation command can start the individual bridge but it is safer to test the entire network restarts properly.
      # service network restart
      
    3. К нему еще не были добавлены интерфейсы. Выполните команду brctl show для получения информации о всех сетевых мостах в системе.
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      Мост virbr0 используется по умолчанию утилитой libvirt для преобразования адресов NAT.
  2. Добавьте интерфейс

    Откройте файл конфигурации интерфейса, добавьте параметр BRIDGE и укажите имя созданного выше моста.
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    Перезапустите сетевое окружение или полностью перезагрузите систему.
    # service network restart
    
    Убедитесь, что интерфейс был подключен:
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. Обеспечение защиты

    В настройках iptables разрешите перенаправление всего трафика через мост.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Отключите iptables для трафика мостов

    Или же можно отключить обработку трафика мостов правилами iptables. Для этого в /etc/sysctl.conf добавьте
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Перезагрузите параметры ядра, настроенные с помощью sysctl
    # sysctl -p /etc/sysctl.conf
    
  4. Перезапустите libvirt

    Перед началом установки перезапустите libvirt:
    # service libvirtd reload
    
Мост успешно настроен, можно приступить к установке.
PXE-установка с помощью virt-install
В строке virt-install добавьте параметр --network=bridge:installation (где installation — созданный мост). Для PXE-установок используется параметр --pxe.
Пример 7.3. PXE-установка с помощью virt-install
# virt-install --accelerate --hvm --connect qemu:///system \
    --network=bridge:installation --pxe\
    --name EL10 --ram=756 \
    --vcpus=4
    --os-type=linux --os-variant=rhel5
    --file=/var/lib/libvirt/images/EL10.img \

PXE-установка с помощью virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Глава 8, Установка гостевой операционной системы.
  1. Выберите PXE

    В качестве способа установки выберите PXE.
  2. Выберите мост

    Отметьте Общее физическое устройство (Shared physical device) и выберите созданный ранее мост.
  3. Начните установку

    Все готово к установке.
Будет отправлен DHCP-запрос и, если найден действующий PXE-сервер, начнется процесс установки виртуальной машины.

Глава 8. Установка гостевой операционной системы

This chapter covers how to install various guest operating systems in a virtualized environment on Red Hat Enterprise Linux. To understand the basic processes, refer to Глава 7, Обзор установки виртуальных машин.

Важно

When installing a Red Hat Enterprise Linux guest, the installer will ask to perform an integrity check on your installation source (CD/DVD media, or ISO file). If you select to perform the check, once the media is tested and the installation continues, you may encounter a message that states: The Red Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry.
This behavior is intentional, provided as a convenience to make sure media is ejected in case a CD install (requiring multiple discs/images) is being performed as opposed to a DVD install.
To proceed past this message, make sure you either insert the next CD, or edit the guest's XML file specifying the next ISO file (or re-insert the DVD media). Next, run virsh update-device Guest1 ~/Guest1.xml (substituting your guest's name and XML file), and select OK to continue past this step.

8.1. Установка паравиртуализированной системы Red Hat Enterprise Linux 5

Дальше будет описан процесс установки Red Hat Enterprise Linux 5 в качестве паравиртуализированной гостевой системы. Паравиртуализация характеризуется более высокой скоростью работы по сравнению с полной виртуализацией, в то же время обладая всеми ее достоинствами. Для организации паравиртуализации необходимо специальное ядро kernel-xen.

Важное замечание

Паравиртуализация возможна при наличии гипервизора Xen. С гипервизором KVM паравиртуализация невозможна.
Прежде чем приступить к установке, убедитесь, что у вас есть права доступа root.
Здесь рассматривается установка Red Hat Enterprise Linux с удаленного сервера. Приведенные инструкции по установке аналогичны инструкциям по выполнению минимальной установки с Live CD.
Create para-virtualized Red Hat Enterprise Linux 5 guests using virt-manager or virt-install. For instructions on virt-manager, refer to the procedure in Раздел 7.2, «Создание виртуальных машин с помощью virt-manager».
Создайте паравиртуализированную систему с помощью virt-install (для графической установки укажите --vnc). В приведенном ниже примере будет создана система с именем rhel5PV, ее образ расположен в rhel5PV.dsk, локальное зеркало дерева установки Red Hat Enterprise Linux 5 — в ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/.
# virt-install -n rhel5PV -r 500 \
-f /var/lib/libvirt/images/rhel5PV.dsk -s 3 --vnc -p \
-l ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/

Автоматизация установки

Кикстарт позволяет автоматизировать установку Red Hat Enterprise Linux.
Независимо от того, выполняете ли вы обычную или кикстарт-установку, появится окно исходной загрузки гостевой системы.
После завершения исходной загрузки начнется стандартный процесс установки Red Hat Enterprise Linux. В большинстве случаев можно принимать предложенные варианты ответов.
Процедура 8.1. Установка паравиртуализированной гостевой системы Red Hat Enterprise Linux
  1. Выберите язык и нажмите OK.
  2. Выберите раскладку клавиатуры и нажмите OK.
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Если вы выбрали DHCP, будет предпринята попытка получения IP-адреса.
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. Укажите IP-адрес и убедитесь, что с помощью этого адреса действительно можно достичь сервера с деревом установки.
    2. Укажите маску подсети, шлюз и адрес сервера имен.
    Выберите язык и нажмите OK.
  6. Ниже приведен пример настройки статического IP-адреса.
  7. Начнется процесс получения файлов с сервера.
Затем начнется графическая установка.
Если вы устанавливаете бета-версию, потребуется подтвердить, что вы действительно хотите установить эту операционную систему. Нажмите кнопку Установить все равно (Install Anyway), затем Далее (Next).
Процедура 8.2. Графическая установка
  1. Введите код регистрации. Если у вас есть ключ подписки RHN, введите его в поле Код установки.

    Замечание

    Если вы пропустили регистрацию, данные учетной записи Red Hat Network можно подтвердить после установки с помощью команды rhn_register (потребуются права root).
  2. Будет запрошено подтверждение удаления всех данных на выбранном носителе.
    Нажмите Да (Yes).
  3. Review the storage configuration and partition layout. You can chose to select the advanced storage configuration if you want to use iSCSI for the guest's storage.
    Make your selections then click Forward.
  4. Подтвердите выбор устройства хранения.
    Нажмите Да (Yes).
  5. Следующий экран содержит настройки сетевого окружения, которые были введены в процессе установки. Измените их при необходимости.
    Нажмите кнопку продолжения.
  6. Выберите часовой пояс.
  7. Укажите пароль root.
    Нажмите кнопку продолжения.
  8. Выберите пакеты для установки, для этого нажмите Настроить сейчас (Customize Now). Не забудьте выбрать пакет kernel-xen из группы Система (System) — он необходим для виртуализации.
    Click Forward.
  9. Будет выполнена проверка зависимостей.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Выбранные пакеты будут установлены автоматически.
  12. После завершения установки потребуется перезагрузить виртуальную машину.
  13. Созданная система не будет перезагружена, а вместо этого завершит работу.
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Раздел 8.1, «Установка паравиртуализированной системы Red Hat Enterprise Linux 5». If you used the default example the name is rhel5PV.
    Перезагрузите виртуальную машину:
    # virsh reboot rhel5PV
    Или же откройте virt-manager, выберите имя гостевой системы и нажмите Открыть (Open), затем Запустить (Run).
    A VNC window displaying the guest's boot processes now opens.
  15. При первой загрузке вы увидите экран настройки, который позволит выбрать параметры конфигурации для вашей гостевой системы.
  16. Ознакомьтесь с текстом лицензионного соглашения и примите условия.
    Нажмите кнопку продолжения.
  17. Настройте межсетевой экран.
    Нажмите кнопку продолжения.
    1. Если вы решили отключить межсетевой экран, потребуется подтвердить выбор. Нажмите Да (Yes). По большому счету, отключать межсетевой экран не рекомендуется.
  18. Затем настройте SELinux. Настоятельно рекомендуется установить SELinux в строгом режиме.
    Нажмите кнопку продолжения.
    1. Если вы отключите SELinux, появится предупреждающее сообщение. Нажмите Да (Yes).
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Нажмите кнопку продолжения.
  20. Confirm time and date are set correctly for your guest. If you install a para-virtualized guest time and date should synchronize with the hypervisor.
    If the users sets the time or date during the installation it is ignored and the hypervisor's time is used.
    Нажмите кнопку продолжения.
  21. Настройте обновления программ. Если у вас есть подписка Red Hat Network, систему можно зарегистрировать в RHN.
    Нажмите кнопку продолжения.
    1. Подтвердите выбор.
    2. Если вы отказались от регистрации в RHN, вы не сможете получать программные обновления и после завершения настройки появится дополнительный экран.
      Нажмите кнопку продолжения.
  22. Создайте учетную запись пользователя root. Рекомендуется также создать непривилегированного пользователя.
    Нажмите кнопку продолжения.
  23. Если была обнаружена звуковая карта, настройте ее в следующем окне. Завершив, нажмите кнопку продолжения.
  24. You can install additional packages from a CD or another repository using this screen. It is often more efficient to not install any additional software at this point but add packages later using the yum command or RHN. Click Finish.
  25. Процесс загрузки будет продолжен.
  26. Откроется окно приветствия Red Hat Enterprise Linux 5. Войдите в систему, указав имя и пароль только что созданного пользователя.
  27. Вы успешно установили паравиртуализированную гостевую систему Red Hat Enterprise Linux.

8.2. Установка полностью виртуализированной системы Red Hat Enterprise Linux

This section covers installing a fully virtualized Red Hat Enterprise Linux 5 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Процедура 8.3. Создание полностью виртуализированной гостевой системы Red Hat Enterprise Linux 5 с помощью virt-manager
  1. Откройте virt-manager

    Чтобы начать сеанс менеджера виртуальных машин, выберите соответствующий ему пункт в меню Приложения > Система или в режиме root просто выполните команду virt-manager.
  2. Выберите гипервизор

    Выберите Xen или KVM (при условии, что они установлены). В этом примере будет выбран KVM (qemu).
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Раздел 26.1, «The Add Connection window».
    Как только будет определено соединение для гипервизора, кнопка создания новой виртуальной машины станет доступна.
  3. Запустите мастер создания виртуальных машин.

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Выберите имя для виртуальной машины

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Выберите тип виртуализации

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Шаг 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Выберите способ установки

    Способы установки Red Hat Enterprise Linux:
    • С локального установочного носителя — диска или образа ISO.
    • При наличии сетевого дерева установки для Red Hat Enterprise Linux, доступного по HTTP, FTP, NFS, можно выбрать сетевой способ установки.
    • PXE можно выбрать, если есть сервер PXE, специально настроенный для загрузки установочного носителя Red Hat Enterprise Linux. За исключением этого этапа, сам процесс установки ничем не отличается от других способов и здесь рассматриваться не будет.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Укажите путь к установочному носителю

    Вы можете указать путь к ISO-образу или устройству чтения дисков. В приведенном примере будет указан путь к образу установочного DVD-диска Red Hat Enterprise Linux.
    1. Нажмите кнопку Обзор (Browse).
    2. Выберите файл ISO. Нажмите Открыть (Open) для подтверждения выбора.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Файлы образов и SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Раздел 18.2, «Виртуализация и SELinux» for details.
  8. Настройка хранилищ

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.

    Миграция

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to Часть V, «Virtualization Storage Topics».
  9. Настройка сетевого окружения

    Выберите виртуальную сеть или общее физическое устройство.
    Выбор виртуальной сети позволяет обеспечить общий доступ к текущему сетевому устройству с помощью преобразования NAT (Network Address Translation). Эта опция обычно выбирается для беспроводных сетей.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Выделение ресурсов памяти и процессоров

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Виртуальной машине понадобится достаточный для ее работы объем оперативной памяти. Стоит помнить, что гостевые системы используют физическую память. Выполнение слишком большого числа гостей или предоставление размещающей системе недостаточного объема памяти может привести к повышенному использованию виртуальной памяти и области подкачки. Как известно, виртуальная память значительно медленнее физической, поэтому работа системы существенно замедлится. Этого можно избежать, выделив виртуальным машинам достаточный объем памяти.
    Аналогичным образом, виртуальной машине следует выделить достаточное число виртуальных процессоров. Если машина выполняет многопотоковые приложения, примите это во внимание при выделении процессорных ресурсов. Однако число виртуальных процессоров не должно превышать число доступных физических процессоров (или гиперпотоков). В свою очередь, предоставление слишком большого числа виртуальных процессоров также отрицательно скажется на производительности из-за лишних издержек.
    Press Forward to continue.
  11. Проверьте настройки и начните установку

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Установка Red Hat Enterprise Linux

    Дождитесь завершения процесса установки Red Hat Enterprise Linux 5 (сам процесс подробно рассмотрен в руководстве по установке на странице документации Red Hat).
Вы успешно установили полностью виртуализированную гостевую систему Red Hat Enterprise Linux 5.

8.3. Установка полностью виртуализированной системы Windows XP

Дальше будет описан процесс установки Windows XP в качестве полностью виртуализированного гостя в Red Hat Enterprise Linux.
This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Прежде чем приступить к установке, убедитесь, что у вас есть права доступа root.

Поддержка Itanium®

В настоящее время Red Hat Enterprise Linux на платформах Itanium® не поддерживает полностью виртуализированные системы Windows XP. Для Itanium поддерживается только Windows Server 2003.
  1. Откройте virt-manager

    Open Applications > System Tools > Virtual Machine Manager. Open a connection to a host (click File > Add Connection). Click the New button to create a new virtual machine.
  2. Выберите имя виртуальной системы

    Введите имя новой системы и нажмите кнопку продолжения.
  3. Выберите тип виртуализации

    If you selected KVM or Xen earlier (step Шаг 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Напомним, Windows можно установить только в качестве полностью виртуализированного гостя.
  4. Выберите способ установки

    В этом окне можно выбрать способ установки и тип операционной системы.
    В выпадающем списке Тип ОС (OS Type) выберите Windows, а в качестве самой системы укажите Microsoft Windows XP.
    Установка гостевых систем с помощью PXE поддерживается в Red Hat Enterprise Linux 5.2. В этой главе PXE-установка не рассматривается.

    Файлы образов и SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Раздел 18.2, «Виртуализация и SELinux» for details.
    Нажмите кнопку продолжения.
  5. Choose installation image

    Choose the installation image or CD-ROM. For CD-ROM or DVD installation select the device with the Windows installation disc in it. If you chose ISO Image Location enter the path to a Windows installation .iso image.
    Нажмите кнопку продолжения.
  6. The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest's storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Раздел 18.2, «Виртуализация и SELinux» for details.
    При необходимости выделите дополнительное пространство. Например, веб-серверы требуют больше пространства для хранения журналов.
    Выберите размер хранилища и нажмите кнопку продолжения.

    Примечание

    Для хранения образов виртуальных машин рекомендуется использовать стандартный каталог /var/lib/libvirt/images/ . Если же вы хотите изменить каталог (например, на /images/), прежде чем приступить к установке, потребуется его добавить в политику SELinux. Позднее будет описано, как изменить политику SELinux.
  7. Настройка сетевого окружения

    Выберите виртуальную сеть или общее физическое устройство.
    Выбор виртуальной сети позволяет обеспечить общий доступ к текущему сетевому устройству с помощью преобразования NAT (Network Address Translation). Эта опция обычно выбирается для беспроводных сетей.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  8. The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Виртуальной машине понадобится достаточный для ее работы объем оперативной памяти (как минимум 512 мегабайт). Стоит помнить, что они используют физическую память. Выполнение слишком большого числа виртуальных машин или предоставление размещающей системе недостаточного объема памяти может привести к повышенному использованию виртуальной памяти и области подкачки. Как известно, виртуальная память значительно медленнее физической, как следствие, работа системы существенно замедлится. Этого можно избежать, выделив виртуальным машинам достаточный объем памяти.
    Аналогичным образом, виртуальной машине следует выделить достаточное число виртуальных процессоров. Если она выполняет многопотоковые приложения, примите это во внимание при выделении процессорных ресурсов. Однако число виртуальных процессоров не должно превышать число доступных физических процессоров (или гиперпотоков). В свою очередь, предоставление слишком большого числа виртуальных процессоров также отрицательно скажется на производительности из-за лишних издержек.
  9. На следующем экране будут показаны введенные вами данные. Чтобы начать установку, нажмите кнопку завершения.
  10. You must make a hardware selection so open a console window quickly after the installation starts. Click Finish then switch to the virt-manager summary window and select your newly started Windows guest. Double click on the system name and the console window opens. Quickly and repeatedly press F5 to select a new HAL, once you get the dialog box in the Windows install select the 'Generic i486 Platform' tab. Scroll through selections with the Up and Down arrows.
  11. Установка Windows продолжится в обычном режиме.
  12. Создайте разделы на жестком диске.
  13. После форматирования диска Windows приступит к копированию файлов.
  14. После завершения копирования будет выполнена перезагрузка Windows.
  15. Перезапустите созданную систему Windows
    # virsh start WindowsGuest
    Замените имя именем созданной виртуальной машины.
  16. В открывшемся окне консоли вы увидите экран настройки установки Windows.
  17. Если оказалось, что процесс установки завис на этом этапе, попробуйте перезапустить виртуальную машину еще раз, выполнив команду virsh reboot имя. Вы должны увидеть сообщение о повторном запуске процесса настройки.
  18. Наконец, появится экран загрузки Windows.
  19. Теперь можно продолжить стандартную настройку установки Windows.
  20. Процесс настройки завершен.

8.4. Установка полностью виртуализированной системы Windows Server 2003

This chapter describes installing a fully virtualized Windows Server 2003 guest with the virt-install command. virt-install can be used instead of virt-manager This process is similar to the Windows XP installation covered in Раздел 8.3, «Установка полностью виртуализированной системы Windows XP».

Поддержка Itanium®

В настоящее время Red Hat Enterprise Linux на платформах Itanium® не поддерживает полностью виртуализированные системы Windows. Информация в этой секции применима к размещающим системам x86 и x86-64.
  1. Using virt-install for installing Windows Server 2003 as the console for the Windows guest opens the virt-viewer window promptly. The examples below installs a Windows Server 2003 guest with the virt-install command.
    1. Xen virt-install

      # virt-install --virt-type=xen -hvm  \
         --name windows2003sp1 
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
    2. KVM virt-install

      # virt-install --accelerate --hvm --connect qemu:///system \
         --name rhel3support  \
         --network network:default \
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
  2. После начала установки быстро нажмите F5, чтобы открыть окно выбора HAL или типа компьютера. Если вы не успели нажать F5, придется начать установку заново. В появившемся окне диалога выберите вариант Standard PC.
  3. Остальные этапы установки не отличаются от уже рассмотренных в предыдущей секции.
  4. Вы успешно установили полностью виртуализированную гостевую систему Windows Server 2003.

8.5. Установка полностью виртуализированной системы Windows XP Server 2008

This section covers installing a fully virtualized Windows Server 2008 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Процедура 8.4. Установка Windows Server 2008 с помощью virt-manager
  1. Откройте virt-manager

    Чтобы начать сеанс менеджера виртуальных машин, выберите соответствующий ему пункт в меню Приложения > Система или в режиме root просто выполните команду virt-manager.
  2. Выберите гипервизор

    Выберите Xen или KVM (при условии, что они установлены). В этом примере будет выбран KVM (qemu).
    После этого кнопка создания новой виртуальной машины станет доступна.
  3. Запустите мастер создания виртуальных машин

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Выберите имя для виртуальной машины

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Выберите тип виртуализации

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (step 2) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Выберите способ установки

    Для любых версий Windows надо выбрать локальный установочный носитель.
    PXE можно выбрать, если есть сервер PXE, специально настроенный для выполнения сетевой установки Windows. В этом руководстве сетевая установка Windows не рассматривается.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Укажите путь к установочному носителю

    Вы можете указать путь к ISO-образу или устройству чтения дисков. В приведенном примере будет указан путь к образу установочного компакт-диска Windows Server 2008.
    1. Нажмите кнопку Обзор (Browse).
    2. Search to the location of the ISO file and select it.
      Press Open to confirm your selection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Файлы образов и SELinux

    For ISO image files and guest storage images, the recommended directory to use is the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Раздел 18.2, «Виртуализация и SELinux» for details.
  8. Настройка хранилищ

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.
  9. Настройка сетевого окружения

    Выберите виртуальную сеть или общее физическое устройство.
    Выбор виртуальной сети позволяет обеспечить общий доступ к текущему сетевому устройству с помощью преобразования NAT (Network Address Translation). Эта опция обычно выбирается для беспроводных сетей.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Выделение ресурсов памяти и процессоров

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Виртуализированной машине понадобится достаточный для ее работы объем оперативной памяти. Стоит помнить, что гостевые системы используют физическую память. Выполнение слишком большого числа виртуальных машин или предоставление размещающей системе недостаточного объема памяти может привести к повышенному использованию виртуальной памяти и области подкачки. Как известно, виртуальная память значительно медленнее физической, поэтому работа системы существенно замедлится. Этого можно избежать, выделив виртуальным машинам достаточный объем памяти.
    Аналогичным образом, виртуальной машине следует выделить достаточное число виртуальных процессоров. Если гость выполняет многопотоковые приложения, примите это во внимание при выделении процессорных ресурсов. Однако число виртуальных процессоров не должно превышать число доступных физических процессоров (или гиперпотоков). В свою очередь, предоставление слишком большого числа виртуальных процессоров также отрицательно скажется на производительности из-за лишних издержек.
    Press Forward to continue.
  11. Проверьте настройки и начните установку

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Установка Windows

    Complete the Windows Server 2008 installation sequence. The installation sequence is not covered by this guide, refer to Microsoft's documentation for information on installing Windows.

Часть III. Настройка

Настройка виртуализации в Red Hat Enterprise Linux

These chapters cover configuration procedures for various advanced virtualization tasks. These tasks include adding network and storage devices, enhancing security, improving performance, and using the Para-virtualized drivers on fully virtualized guests.

Содержание

9. Virtualized storage devices
9.1. Создание контроллера виртуального дисковода
9.2. Добавление устройств хранения в гостевую систему
9.3. Настройка постоянного хранилища в Red Hat Enterprise Linux 5
9.4. Добавление виртуального устройства CD-ROM или DVD в гостевую систему
10. Настройка сетевого окружения
10.1. Преобразование сетевых адресов с помощью libvirt
10.2. Мостовое соединение с помощью libvirt
11. Сетевое окружение Xen в Red Hat Enterprise Linux 5.4 и более ранних версиях
11.1. Настройка использования нескольких карт Ethernet сетевыми мостами виртуальных машин
11.2. Настройка сетевого окружения в ноутбуках Red Hat Enterprise Linux 5.0
12. Паравиртуализированные драйверы Xen
12.1. Системные требования
12.2. Поддержка и ограничения паравиртуализации
12.3. Установка паравиртуализированных драйверов
12.3.1. Последовательность действий при установке
12.3.2. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 3
12.3.3. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Настройка паравиртуализированного сетевого драйвера
12.5. Настройка дополнительного виртуального оборудования
12.5.1. Виртуальные сетевые интерфейсы
12.5.2. Виртуальные устройства хранения
13. Паравиртуализированные драйверы KVM
13.1. Установка паравиртуализированных драйверов Windows
13.2. Installing drivers with a virtualized floppy disk
13.3. Использование паравиртуализированных драйверов KVM для существующих устройств
13.4. Использование паравиртуализированных драйверов KVM для новых устройств
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Управление временем виртуальных машин KVM

Глава 9. Virtualized storage devices

This chapter covers installing and configuring storage devices in virtualized guests. The term block devices refers to various forms of storage devices. All the procedures in this chapter work with both Xen and KVM hypervisors.

Valid disk targets

The target variable in libvirt configuration files accepts only the following device names:
  • /dev/xvd[a to z][1 to 15]
    Example: /dev/xvdb13
  • /dev/xvd[a to i][a to z][1 to 15]
    Example: /dev/xvdbz13
  • /dev/sd[a to p][1 to 15]
    Example: /dev/sda1
  • /dev/hd[a to t][1 to 63]
    Example: /dev/hdd3

9.1. Создание контроллера виртуального дисковода

В контроллерах дисководов все еще есть необходимость в старых операционных системах, в частности, для установки драйверов. В настоящее время обращение к физическим дисководам из виртуализированных систем невозможно, но поддерживается создание и обращение к образам дискет из виртуализированных дисководов.
An image file of a floppy disk is required. Create floppy disk image files with the dd command. Replace /dev/fd0 with the name of a floppy device and name the disk appropriately.
# dd if=/dev/fd0 of=~/legacydrivers.img

Замечание о паравиртуализированных драйверах

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Глава 13, Паравиртуализированные драйверы KVM.
В этой главе в качестве примера будет рассмотрена виртуальная машина, созданная с помощью virt-manager, в которой выполняется полностью виртуализированная система Red Hat Enterprise Linux. Ее образ расположен в /var/lib/libvirt/images/rhel5FV.img.
  1. В работающей гостевой системе создайте файл конфигурации в формате XML для гостевого образа:
    # virsh dumpxml rhel5FV > rhel5FV.xml
    
    This saves the configuration settings as an XML file which can be edited to customize the operations and devices used by the guest. For more information on using the virsh XML configuration files, refer to Глава 33, Создание специализированных сценариев libvirt.
  2. Создайте образ дискеты.
    # dd if=/dev/zero of=/var/lib/libvirt/images/rhel5FV-floppy.img bs=512 count=2880
    
  3. Add the content below, changing where appropriate, to your guest's configuration XML file. This example is an emulated floppy device using a file-based image.
    <disk type='file' device='floppy'>
    	<source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
    	<target dev='fda'/>
    </disk>
    
  4. Force the guest to stop. To shut down the guest gracefully, use the virsh shutdown command instead.
    # virsh destroy rhel5FV
  5. Перезапустите ее с использованием нового файла конфигурации.
    # virsh create rhel5FV.xml
    
Теперь дисковод должен быть доступен в гостевой системе и сохранен в размещающей системе в виде файла образа.

9.2. Добавление устройств хранения в гостевую систему

В этой секции будет рассмотрен процесс добавления устройств хранения в виртуальную машину. Дополнительные накопители могут быть добавлены только после создания виртуальных машин. Типы поддерживаемых накопителей и протоколов:
  • разделы на локальных жестких дисках;
  • логические тома;
  • Fibre Channel или iSCSI, подключенные напрямую;
  • файловые контейнеры, расположенные в файловой системе размещающей системы;
  • файловые системы NFS, напрямую подключенные виртуальной машиной;
  • накопители iSCSI, к которым гостевые системы обращаются напрямую;
  • кластерные файловые системы (GFS).
Добавление накопителя на основе файла в гостевую систему
Накопители на основе файлов представляют собой файлы, расположенные в файловой системе размещающей операционной системы, которые функционируют как виртуальные жесткие диски для виртуальных машин. Последовательность действий при добавлении таких устройств хранения:
  1. Можно создать пустой файл контейнера или использовать существующий (например, файл ISO).
    1. Для создания разреженного файла выполните приведенную ниже команду (обратите внимание, что использование таких файлов не рекомендуется, так как при этом может быть нарушена целостность данных). Эти файлы создаются намного быстрее и обычно используются при тестировании, но в производственной среде все же лучше к ним не прибегать.
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. Чтобы создать неразреженный файл, выполните
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
      
    Both commands create a 4GB file which can be used as additional storage for a virtualized guest.
  2. Сохраните существующую конфигурацию гостя в отдельный файл. В приведенном примере файл конфигурации гостевой системы Guest1 будет сохранен в домашний каталог.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Теперь откройте этот файл Guest1.xml в текстовом редакторе и найдите записи, которые начинаются с «disk=». Они выглядят примерно так:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. Добавьте дополнительное хранилище, добавив соответствующую запись в конец секции <disk=>. Не забудьте указать имя виртуального блочного устройства, которое еще не упоминается в файле конфигурации. Пример добавления образа FileName.img:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/FileName.img'/>
        <target dev='hda'/>
    </disk>
    
  5. Перезапустите гостевую систему с использованием нового файла конфигурации.
    # virsh create Guest1.xml
    
  6. The following steps are Linux guest specific. Other operating systems handle new storage devices in different ways. For other systems, refer to that operating system's documentation
    The guest now uses the file FileName.img as the device called /dev/sdb. This device requires formatting from the guest. On the guest, partition the device into one primary partition for the entire device then format the device.
    1. Нажмите n, чтобы создать новый раздел.
      # fdisk /dev/sdb
      Command (m for help):
      
    2. Нажмите p, чтобы определить этот раздел как основной.
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. Выберите доступный номер раздела. В этом примере будет выбран первый раздел.
      Partition number (1-4): 1
      
    4. Нажмите Enter и введите номер первого цилиндра.
      First cylinder (1-400, default 1):
      
    5. Выберите размер раздела. В этом примере раздел будет занимать весь диск. Нажмите Enter.
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. Нажмите t, чтобы указать тип раздела.
      Command (m for help): t
      
    7. Выберите номер созданного раздела (в этом примере — 1).
      Partition number (1-4): 1
      
    8. Введите 83 (linux).
      Hex code (type L to list codes): 83
      
    9. Сохраните изменения и нажмите q для выхода.
      Command (m for help): w 
      Command (m for help): q
      
    10. Создайте файловую систему ext3.
      # mke2fs -j /dev/sdb1
      
  7. Подключите диск.
    # mount /dev/sdb1 /myfiles
    
Теперь гостевая система обладает дополнительным виртуальным файловым устройством хранения.
Добавление жестких дисков и других блочных устройств в гостевую систему
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Процедура 9.1, «Добавление физических блочных устройств в гостевую систему», describes how to add a hard drive on the host to a virtualized guest.
Процесс добавления аналогичен для всех типов физических блочных устройств, будь то CD-ROM, DVD или дисковод.

Block device security

The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.
Процедура 9.1. Добавление физических блочных устройств в гостевую систему
  1. Физически подключите жесткий диск. Настройте к нему доступ.
  2. При необходимости настройте режим multipath и сохранение постоянства в размещающей системе.
  3. Use the virsh attach command. Replace: myguest with your guest's name, /dev/sdb1 with the device to add, and sdc with the location for the device on the guest. The sdc must be an unused device name. Use the sd* notation for Windows guests as well, the guest will recognize the device correctly.
    Append the --type cdrom parameter to the command for CD-ROM or DVD devices.
    Для дисководов добавьте параметр --type floppy.
    # virsh attach-disk myguest
    					/dev/sdb1
    					sdc --driver tap --mode readonly
    
  4. The guest now has a new hard disk device called /dev/sdb on Linux or D: drive, or similar, on Windows. This device may require formatting.

9.3. Настройка постоянного хранилища в Red Hat Enterprise Linux 5

В окружениях с внешними накопителями (например, Fibre Channel или iSCSI) рекомендуется настроить постоянные имена устройств, что облегчит выполнение живой миграции, так как в разных системах будут использоваться одни и те же имена.
Уникальные идентификаторы UUID (Universally Unique Identifier) — стандарт идентификации компьютеров и устройств в распределенных компьютерных окружениях. В этой секции идентификаторы UUID будут использоваться для идентификации LUN iSCSI и Fibre Channel. UUID аналогичен метке устройства и не изменяется между перезагрузками, отключениями и сменой устройств.
Systems which are not running multipath must use Настройка одного пути. Systems running multipath can use Многопутевая настройка.
Настройка одного пути
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. Внесите изменения в файл /etc/scsi_id.config.
    1. Убедитесь, что строка options=-b отмечена как комментарий.
      # options=-b
      
    2. Добавьте строку
      options=-g
      
      При этом udev будет подразумевать, что все подключенные устройства SCSI возвращают UUID.
  2. Чтобы получить UUID для конкретного устройства, выполните команду scsi_id -g -s /block/sd*. Пример:
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    Вывод команды содержит UUID устройства /dev/sdc.
  3. Убедитесь, что UUID, полученный в результате выполнения команды scsi_id -g -s /block/sd*, совпадает с идентификатором, получаемым компьютером, который обращается к устройству.
  4. Далее следует создать правило для назначения имени устройству. В каталоге /etc/udev/rules.d создайте файл 20-names.rules, в который мы будем добавлять все новые правила. Формат правил:
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Замените UUID полученным ранее значением, а имя_устройства именем. Пример правила:
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    Демон udev теперь будет искать в правиле все устройства /dev/sd* для заданного UUID. После подключения найденного устройства в систему ему будет присвоено заданное правилом имя. Так, в нашем примере устройство с UUID 3600a0b800013275100000015427b625e будет обозначено как /dev/rack4row16.
  5. В файл /etc/rc.local добавьте строку
    /sbin/start_udev
    
  6. Скопируйте изменения в файлы /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules, /etc/rc.local на всех узлах.
    /sbin/start_udev
    
Сетевые устройства хранения с настроенными правилами теперь будут использовать одинаковые имена на всех узлах, где вы применили изменения. Теперь при миграции гостевых систем между узлами можно использовать общее хранилище, а гостевые системы смогут обращаться к устройствам хранения с помощью своих файлов конфигурации.
Многопутевая настройка
В системах с несколькими физическими путями к устройствам хранения используется пакет multipath, обеспечивающий высокую отказоустойчивость и производительность сетевых устройств хранения, подключенных к системам Red Hat Enterprise Linux.
Implementing LUN persistence in a multipath environment requires defined alias names for your multipath devices. Each storage device has a UUID which acts as a key for the aliased names. Identify a device's UUID using the scsi_id command.
# scsi_id -g -s /block/sdc
Многопутевые устройства создаются в каталоге /dev/mpath. В приведенном ниже примере определено 4 устройства в файле /etc/multipath.conf:
multipaths { 
	multipath { 
	wwid		3600805f30015987000000000768a0019 
	alias		oramp1 
	} 
	multipath { 
	wwid		3600805f30015987000000000d643001a 
	alias		oramp2 
	} 
	mulitpath { 
	wwid		3600805f3001598700000000086fc001b 
	alias		oramp3 
	} 
	mulitpath { 
	wwid		3600805f300159870000000000984001c 
	alias		oramp4 
	} 
}
This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWID to their new names are now persistent after rebooting.

9.4. Добавление виртуального устройства CD-ROM или DVD в гостевую систему

To attach an ISO file to a guest while the guest is online use virsh with the attach-disk parameter.
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
The source and target parameters are paths for the files and devices, on the host and guest respectively. The source parameter can be a path to an ISO file or the device from the /dev directory.

Глава 10. Настройка сетевого окружения

В этой главе рассматриваются варианты конфигурации сетевого окружения, используемые приложениями на основе libvirt. Приведенная здесь информация применима ко всем гипервизорам, в том числе Xen и KVM. Дополнительно можно обратиться к документации libvirt.
Две типичные конфигурации позволяют настроить виртуальную сеть или общее физическое устройство. Конфигурация виртуальной сети будет одинакова для всех дистрибутивов, ее можно сразу применять. А общее физическое устройство будет нуждаться в дополнительной настройке для разных дистрибутивов.
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.1. Преобразование сетевых адресов с помощью libvirt

Преобразование сетевых адресов (NAT, Network Address Translation) используется довольно часто для организации общих сетевых соединений (виртуальных сетей).
Настройка размещающей системы
Every standard libvirt installation provides NAT based connectivity to virtual machines out of the box. This is the so called 'default virtual network'. Verify that it is available with the virsh net-list --all command.
# virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes
Если запись «default» отсутствует, попробуйте подключить следующий файл конфигурации:
# virsh net-define /usr/share/libvirt/networks/default.xml
/usr/share/libvirt/networks/default.xml содержит определения сетевого окружения, используемого по умолчанию.
Настройте автоматический запуск:
# virsh net-autostart default
Network default marked as autostarted
Запустите сеть:
# virsh net-start default
Network default started
Вы должны увидеть изолированный мост. К этому устройству не подключены физические интерфейсы, так как оно использует перенаправление IP и NAT для подключения к внешней сети. Не добавляйте новые интерфейсы.
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt добавит правила iptables, разрешающие прохождение трафика гостевых систем, подключенных к устройству virbr0 в цепочках INPUT, FORWARD, OUTPUT и POSTROUTING. Затем libvirt попытается включить параметр ip_forward. Но другие программы могут его отключить, поэтому в файл /etc/sysctl.conf стоит добавить выражение
 net.ipv4.ip_forward = 1
Настройка виртуальной машины
Once the host configuration is complete, a guest can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following XML can be used in the guest:
<interface type='network'>
  <source network='default'/>
</interface>

Замечание

Можно дополнительно определить MAC-адрес. Если он не задан вручную, он будет сгенерирован автоматически.
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

10.2. Мостовое соединение с помощью libvirt

Мостовое соединение используется для выделения физического устройства виртуальной машине и часто применяется для более тонкой настройки серверов с несколькими сетевыми интерфейсами.
Отключите сетевые сценарии Xen
Если ваша система использует мост Xen, рекомендуется его отключить. Для этого в файле /etc/xen/xend-config.sxp измените строку
 (network-script network-bridge)
To:
 (network-script /bin/true)
Отключите NetworkManager
NetworkManager does not support bridging. Running NetworkManager will overwrite any manual bridge configuration. Because of this, NetworkManager should be disabled in order to use networking via the network scripts (located in the /etc/sysconfig/network-scripts/ directory):
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Замечание

As an alternative to turning off NetworkManager, add "NM_CONTROLLED=no" to the ifcfg-* scripts used in the examples. If you do not either set this parameter or disable NetworkManager entirely, any bridge configuration will be overwritten and lost when NetworkManager next starts.
Создание сценариев инициализации сети
Создайте или отредактируйте указанные ниже файлы конфигурации сети. Повторите для каждого дополнительного сетевого моста (изменив имя).
Перейдите в каталог /etc/sysconfig/network-scripts.
# cd /etc/sysconfig/network-scripts
Откройте сценарий для добавляемого устройства. В приведенном примере ifcfg-eth0 содержит определение физического сетевого интерфейса, входящего в состав моста:
DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0

Tip

You can configure the device's Maximum Transfer Unit (MTU) by appending an MTU variable to the end of the configuration file.
MTU=9000
Создайте новый сценарий с именем ifcfg-br0 (или аналогичным названием) в каталоге /etc/sysconfig/network-scripts. Здесь br0 обозначает имя моста и может иметь любую длину, главное — чтобы эта часть имени файла совпадала с параметром DEVICE.
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

IP address configuration

IP address configuration, be it dynamic or static, should be configured on the bridge itself (for example, in the ifcfg-br0 file). Network access will not function as expected if IP address details are configured on the physical interface that the bridge is connected to.

Внимание

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Завершив настройку, перезапустите службу сети или перезагрузите компьютер.
# service network restart
Настройте iptables так, чтобы весь трафик перенаправлялся по созданному мосту.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Отключение обработки iptables

Или же можно запретить обработку трафика правилами iptables. Для этого в файл /etc/sysctl.conf добавьте
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Перезагрузите параметры ядра, настроенные с помощью sysctl.
# sysctl -p /etc/sysctl.conf
Перезапустите libvirtd.
# service libvirtd reload
Теперь должно быть доступно общее физическое устройство, которое гости могут подключить. Проверьте его наличие:
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Обратите внимание, что созданный мост совершенно не зависит от virbr0. НЕ пытайтесь подключить физическое устройство к virbr0. Мост virbr0 используется исключительно для NAT.

Глава 11. Сетевое окружение Xen в Red Hat Enterprise Linux 5.4 и более ранних версиях

Эта глава охватывает темы настройки сетевого окружения и организации сетевых подключений с помощью гипервизора Xen.
Most guest network configuration occurs during the guest initialization and installation process. To learn about configuring networking during the guest installation process, read the relevant sections of the installation process, Глава 7, Обзор установки виртуальных машин.
Network configuration is also covered in the tool specific reference chapters for virsh (Глава 25, Управление виртуальными машинами с помощью virsh) and virt-manager (Глава 26, Управление виртуальными машинами с помощью менеджера виртуальных машин (virt-manager)). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. Глава 12, Паравиртуализированные драйверы Xen explains how to utilize para-virtualized network drivers.

11.1. Настройка использования нескольких карт Ethernet сетевыми мостами виртуальных машин

Последовательность действий при настройке сетевых мостов с помощью гипервизора Xen:
  1. Настройте новый сетевой интерфейс с помощью утилиты system-config-network или создайте новый файл конфигурации ifcfg-ethX в /etc/sysconfig/network-scripts. Замените «X» любым незанятым числом. Пример файла конфигурации для второго сетевого интерфейса eth1:
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=static
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    GATEWAY=10.1.1.254
    ARP=yes
    
  2. Скопируйте /etc/xen/scripts/network-bridge в /etc/xen/scripts/network-bridge.xen.
  3. Comment out any existing network scripts in /etc/xen/xend-config.sxp and add the line (network-xen-multi-bridge). A typical xend-config.sxp file should have the following line. Comment this line out. Use the # symbol to comment out lines.
    network-script network-bridge
    
    Below is the commented out line and the new line, containing the network-xen-multi-bridge parameter to enable multiple network bridges.
    #network-script network-bridge
    network-script network-xen-multi-bridge
  4. Create a script to create multiple network bridges. This example creates a script called network-xen-multi-bridge.sh in the /etc/xen/scripts/ directory. A sample scripts is below, this example script will create two Xen network bridges (xenbr0 and xenbr1) one will be attached to eth1 and the other one to eth0. If you want to create additional bridges just follow the example in the script and copy nad paste the lines as required:
    #!/bin/sh
    # network-xen-multi-bridge
    # Exit if anything goes wrong.
    set -e
    # First arg is the operation.
    OP=$1
    shift
    script=/etc/xen/scripts/network-bridge.xen
    case ${OP} in
    start)
    	$script start vifnum=1 bridge=xenbr1 netdev=eth1
    	$script start vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    stop)
    	$script stop vifnum=1 bridge=xenbr1 netdev=eth1
    	$script stop vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    status)
    	$script status vifnum=1 bridge=xenbr1 netdev=eth1
    	$script status vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    *)
    	echo 'Unknown command: ' ${OP}
    	echo 'Valid commands are: start, stop, status'
    	exit 1
    esac
    
  5. Make the script executable.
    # chmod +x /etc/xen/scripts/network-xen-multi-bridge.sh
  6. Restart networking or restart the system to activate the bridges.
    # service network restart
Multiple bridges should now be configured for guests on the Xen hypervisor.

11.2. Настройка сетевого окружения в ноутбуках Red Hat Enterprise Linux 5.0

Для версий Red Hat Enterprise Linux, начиная с 5.1

В этой секции будет рассмотрено добавление сетевых мостов вручную для версий Red Hat Enterprise Linux, предшествующих 5.0. Для более новых версий используйте адаптеры виртуальной сети в virt-manager. В Red Hat Enterprise Linux, начиная с 5.1, можно использовать NetworkManager.
Пример файла конфигурации virsh для виртуального сетевого устройства:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
В файлах конфигурации xm виртуальные сетевые устройства отмечены как «vif».
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
Рассмотренная здесь конфигурация позволит выполнять Xen в автономном режиме при отсутствии активного сетевого соединения. Наиболее простое решение включает следующие шаги:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • Используйте статический IP-адрес, так как DHCP не будет прослушивать фиктивный интерфейс. Можно скомпилировать собственную версию DHCP для прослушивания псевдо-интерфейсов или же использовать dnsmasq для служб DNS, DHCP и tftpboot в окружении Xen. Подробнее настройка будет рассмотрена позднее в этой главе.
  • Также можно настроить маскирование NAT и IP для активации доступа к сети из гостевых систем.
Настройка фиктивного сетевого интерфейса
В размещающей системе выполните следующие шаги:
  1. Создайте фиктивный интерфейс dummy0 и присвойте ему статический IP-адрес. В нашем примере используется адрес 10.1.1.1, позволяющий избежать возможных проблем в окружении. Для активации поддержки псевдо-устройства в /etc/modprobe.conf добавьте следующее:
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Чтобы настроить сетевое подключение для dummy0 измените существующий или создайте новый файл /etc/sysconfig/network-scripts/ifcfg-dummy0:
    DEVICE=dummy0
    BOOTPROTO=none
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    ARP=yes
    
  3. Сопоставьте xenbr0 фиктивному интерфейсу dummy0, чтобы сетевое подключение можно было использовать даже при отсутствии соединения с физической сетью. В файл /etc/xen/xend-config.sxp добавьте запись netdev=dummy0:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
    
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    GATEWAY=10.1.1.1
    IPADDR=10.1.1.10
    NETMASK=255.255.255.0
    
  5. Настройка преобразования адресов NAT на узле позволит виртуальным машинам получить доступ к Интернету, используя беспроводное подключение, что решит проблемы с Xen и беспроводными картами. Приведенный сценарий включит преобразование NAT для используемого интерфейса.
Настройка преобразования адресов для виртуальных машин
Преобразование NAT (Network Address Translation) позволяет нескольким сетевым адресам использовать единственный IP-адрес, получая предназначенные им пакеты и направляя их частным IP-адресам. Можно скопировать приведенный ниже сценарий в /etc/init.d/xenLaptopNAT и создать символьную ссылку на /etc/rc3.d/S99xenLaptopNAT. Это позволит запускать NAT автоматически во время загрузки.

NetworkManager и беспроводное преобразование NAT

Приведенный ниже сценарий не является идеальным решением для беспроводных сетей и NetworkManager из-за начальных задержек. В таком случае следует выполнить сценарий вручную после загрузки.
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
start)
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
    else
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
fi
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
	;;
*)
echo "Usage: $0 {start|restart|status}"
;;
esac
Настройка dnsmasq для служб DNS, DHCP и tftpboot
Постоянные изменения сетевых интерфейсов и вопросы их доступности составляют основную трудность виртуализации в ноутбуках и других компьютерах без постоянного сетевого подключения. Использование фиктивного интерфейса способствует созданию стабильного окружения, но в то же время вносит дополнительные сложности при предоставлении служб DHCP, DNS и tftpboot виртуальным машинам. Стандартный демон DHCP, входящий в поставку Red Hat Enterprise Linux и Fedora Core, не будет прослушивать фиктивные интерфейсы, в то время как перенаправленная информация DNS может изменяться при подключении к другим сетям и VPN.
Для решения перечисленных проблем можно использовать dnsmasq, предоставляющий все перечисленные выше службы в одном пакете и позволяющий настроить службу так, чтобы она была доступна только для запросов, поступающих с фиктивного интерфейса. Последовательность шагов при настройке dnsmasq в ноутбуке с виртуализацией будет выглядеть приблизительно так:
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from http://et.redhat.com/~jmh/tools/xen/ and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • nm-dnsmasq, который может выполнять роль распределяющего сценария для NetworkManager. Он будет выполняться каждый раз, когда NetworkManager обнаружит изменения подключения, и вызовет принудительный перезапуск или перезагрузку dnsmasq. Скопируйте его в /etc/NetworkManager/dispatcher.d/nm-dnsmasq.
    • xenDNSmasq, который может использоваться в качестве основного сценария запуска и остановки для /etc/init.d/xenDNSmasq.
    • dnsmasq.conf содержит пример файла конфигурации для /etc/dnsmasq.conf.
    • dnsmasq — двоичный образ для /usr/local/sbin/dnsmasq.
  • Распакуйте архив, выполните сборку dnsmasq (исходная установка будет представлять собой двоичный файл в /usr/local/sbin/dnsmasq). Затем в файл конфигурации dnsmasq (/etc/dnsmaqs.conf) необходимо внести изменения.
  • Измените настройки в соответствии с вашими требованиями. Обычно изменяются следующие параметры:
    • interface. Укажите имя интерфейса (например, dummy0), который dnsmasq будет прослушивать на предмет запросов DHCP и DNS. Можно указать фиктивный интерфейс, но не локальный петлевой или общедоступные интерфейсы. Для одного интерфейса используется одна строка, повторите строку для других интерфейсов. Пример: interface=dummy0.
    • dhcp-range. Для активации интегрированного сервера DHCP необходимо предоставить диапазон адресов, доступных для аренды, и, дополнительно, время аренды. Этот параметр нужно повторно определить для каждой сети, в которой будет предоставляться служба DHCP. Например, для сети 10.1.1.* при 12-часовой аренде запись будет выглядеть так: dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h.
    • dhcp-option. Переопределяет исходный маршрут, определенный dnsmasq, который изначально подразумевает, что маршрутизатор расположен в той же системе, где выполняется dnsmasq. Пример: dhcp-option=3,10.1.1.1.
  • Завершив настройку dnsmasq, скопируйте сценарий в /etc/init.d и присвойте ему имя xenDNSmasq.
  • Для автоматического запуска dnsmasq при загрузке необходимо зарегистрировать его с помощью chkconfig(8):
    chkconfig --add xenDNSmasq
    
    Настройка автоматического запуска:
    chkconfig --levels 345 xenDNSmasq on
    
  • Чтобы перезапускать dnsmasq каждый раз, когда NetworkManager определяет изменения соединения, можно воспользоваться предоставленным сценарием nm-dnsmasq.
    • Скопируйте сценарий nm-dnsmasq в /etc/NetworkManager/dispatcher.d/.
    • NetworkManager будет запускать сценарий при каждом изменении состояния соединения. Если каталог содержит несколько сценариев, они будут выполнены в алфавитном порядке.
  • dnsmasq также будет определять изменения в /etc/resolv.conf и автоматически их применять (например, при запуске сеанса VPN).
  • Сценарии nm-dnsmasq и xenDNSmasq также настроят преобразование сетевых адресов NAT, если виртуальные машины расположены в скрытой сети, так чтобы они могли обращаться к открытой сети.

Глава 12. Паравиртуализированные драйверы Xen

Para-virtualized drivers provide increased performance for fully virtualized Red Hat Enterprise Linux guests. Use these drivers if you are using fully virtualized Red Hat Enterprise Linux guests and require better performance.

Другие драйверы

Существуют и другие паравиртуализированные драйверы Windows для Xen и KVM.
Так, в случае гостевых систем Windows на узлах Xen обратитесь к руководству Windows по паравиртуализированным драйверам.
RPM-пакеты для паравиртуализированных драйверов включают модули драйверов для хранилища и сетевого окружения для поддерживаемых гостевых ОС Red Hat Enterprise Linux. Драйверы обеспечивают высокую производительность операций ввода/ вывода в немодифицированных гостевых системах Red Hat Enterprise Linux, которые размещены в Red Hat Enterprise Linux версии 5.1 или выше.
Поддерживаемые типы гостевых операционных систем:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Поддержка паравиртуализированных драйверов на уровне архитектуры

Минимальные требования к гостевой операционной системе могут отличаться в зависимости от архитектуры. Поддерживаются только гостевые системы x86 и x86-64.
Системы, предшествующие Red Hat Enterprise Linux 3, не поддерживают паравиртуализированные драйверы для гостевых систем.
Использование Red Hat Enterprise Linux 5 в качестве платформы виртуализации позволяет перенести нагрузку Linux и Windows на более мощное оборудование. Гостевым операционным системам Red Hat Enterprise Linux 4 (начиная с 4.6) и Red Hat Enterprise Linux 5 будет известно о положенной в основу технологии, взаимодействие с которой осуществляется с помощью специализированных интерфейсов. При таком подходе вполне возможно достичь уровня производительности, аналогичного производительности обычных, немодифицированных систем.
As para-virtualization requires a modified guest operating system, not all operating systems can use para-virtualization. For operating systems which can not be modified, full virtualization is required. Full virtualization, by default, uses emulated disk, network, video and other hardware devices. Emulated I/O devices can be very slow and are not suited for applications requiring high disk and/or network throughput. The majority of the performance loss with virtualization occurs through the use of emulated devices.
Драйверы паравиртуализированных устройств входят в состав пакетов Red Hat Enterprise Linux и позволяют улучшить производительность паравиртуализированных гостевых систем по сравнению с немодифицированными ОС, так как только драйверу, а не всей системе, будет известно о платформе виртуализации, лежащей в основе операционной системы.
После установки паравиртуализированных драйверов дисковое устройство или сетевую карту система будет распознавать как обычный физический диск и сетевую карту. Но в данном случае драйвер устройства будет напрямую взаимодействовать с платформой виртуализации для обеспечения доступа к диску и сети, что позволит дисковым и сетевым подсистемам работать с оптимальной скоростью даже в виртуализированном окружении, без какой-либо необходимости модификации гостевых операционных систем.
Паравиртуализированные драйверы предъявляют собственные требования к размещающим системам. Так, в 64-разрядной размещающей системе могут работать:
  • 32-разрядные гостевые системы;
  • 64-разрядные гостевые системы;
  • комбинация 32-разрядных и 64-разрядных гостевых систем.

12.1. Системные требования

В этой секции перечислены системные требования для паравиртуализированных драйверов, используемых в окружении Red Hat Enterprise Linux.
Установка
Прежде чем приступить к установке паравиртуализированных драйверов, убедитесь, что удовлетворены перечисленные ниже условия.

Red Hat Enterprise Linux 4.7, 5.3 и более новые версии

Все версии Red Hat Enterprise Linux, начиная с 4.7 и 5.3, включают модуль pv-on-hvm для паравиртуализированных драйверов в составе стандартного пакета ядра.
При установке каждой гостевой системы потребуются следующие пакеты для паравиртуализированных драйверов:
Minimum host operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
Minimum guest operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
  • Red Hat Enterprise Linux 4 Update 6 or newer.
  • Red Hat Enterprise Linux 3 Update 9 or newer.
Red Hat Enterprise Linux 5 requires:
  • kmod-xenpv.
Red Hat Enterprise Linux 4 requires:
  • kmod-xenpv,
  • modules-init-tools (for versions prior to Red Hat Enterprise Linux 4.6z you require modules-init-tools-3.1-0.pre5.3.4.el4_6.1 or greater), and
  • modversions.
Red Hat Enterprise Linux 3 requires:
  • kmod-xenpv.
You require at least 50MB of free disk space in the /lib file system.

12.2. Поддержка и ограничения паравиртуализации

В этой секции описаны требования и ограничения, накладываемые при использовании паравиртуализированных драйверов в Red Hat Enterprise Linux.
Поддерживаемые типы гостевых операционных систем
Следующие системы поддерживают использование паравиртуализированных драйверов:
  • Red Hat Enterprise Linux 5.1 и новее;
  • Red Hat Enterprise Linux 4.6 и новее;
  • Red Hat Enterprise Linux 3.9 и новее.
Паравиртуализированные драйверы поддерживаются 32-разрядными гостевыми системами, построенными на основе 64-разрядной Red Hat Enterprise Linux 5.
В приведенной ниже таблице перечислены варианты ядра, поддерживаемые паравиртуализированными драйверами. Указанная далее команда поможет определить точную версию ядра. Сравните полученный результат с содержимым таблицы, чтобы узнать, поддерживается ли ваша версия ядра.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Ядро Red Hat Enterprise Linux 5 i686 и x86_64 поддерживает симметричную многопроцессорность (SMP, Symmetric Multiprocessing), поэтому нет необходимости в отдельном модуле SMP.
Обратите внимание на требования к ядру гостевых систем Red Hat Enterprise Linux 3 (см. таблицу).
Таблица 12.1. Поддерживаемые архитектуры ядра гостей для паравиртуализированных драйверов
Архитектура ядра Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon Поддерживается (AMD)   
athlon-SMP Поддерживается (AMD)   
i32e Поддерживается (Intel)   
i686 Поддерживается (Intel) Поддерживается Поддерживается
i686-PAE Поддерживается
i686-SMP Поддерживается (Intel) Поддерживается  
i686-HUGEMEM Поддерживается (Intel) Поддерживается  
x86_64 Поддерживается (AMD) Поддерживается Поддерживается
x86_64-SMP Поддерживается (AMD) Поддерживается  
x86_64-LARGESMP Поддерживается  
Itanium (IA64) Поддерживается

Важно

В качестве размещающей системы должна использоваться версия Red Hat Enterprise Linux, начиная с 5.1.

Определение версии ядра

Выполните приведенную далее команду и запишите ее вывод, содержащий пакеты и модули, которые потребуется загрузить.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Вывод будет выглядеть приблизительно так:
kernel-PAE-2.6.18-53.1.4.el5.i686
В этом примере имя ядра — PAE (Physical Address Extension), версия — 2.6.18, выпуск — 53.1.4.el5 и архитектура — i686. Имя пакета ядра должно следовать формату ядро-имя-версия-выпуск.архитектура.rpm.
Важные ограничения
Паравиртуализированные драйверы могут быть установлены после успешной установки гостевой операционной системы. Прежде чем вы сможете приступить к установке драйверов, проверьте работоспособность размещающей системы и виртуальных машин.

Паравиртуализированные блочные устройства и GRUB

В настоящее время GRUB не может обращаться к паравиртуализированным блочным устройствам. Как следствие, гостевая система не сможет быть загружена с устройств, использующих драйверы паравиртуализированного блочного устройства, таких как диск, содержащий главную загрузочную запись (MBR, Master Boot Record), диск с загрузчиком GRUB или диск с образами ядра initrd. Поэтому любой диск, содержащий раздел или каталог /boot, не сможет использовать драйверы паравиртуализированных блочных устройств.
Зависимости архитектуры ядра Red Hat Enterprise Linux 3
Приведенная далее таблица поможет с выбором RPM-пакетов ядра и паравиртуализированных драйверов для систем Red Hat Enterprise Linux 3. Если вы не установили необходимый пакет драйвера, то попытка загрузки модуля xen-pci-platform завершится неудачей.
В таблице указано, какое ядро потребуется для выполнения гостевой системы Red Hat Enterprise Linux 3, если сама гостевая система скомпилирована для процессора Intel.
Таблица 12.2. Архитектура ядра, необходимая для размещения гостевых систем, использующих паравиртуализированные драйверы в Red Hat Enterprise Linux 3 для процессоров Intel
Тип ядра гостевой системы Требуемый тип ядра размещающей системы
ia32e (UP и SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

Приведенная ниже таблица отражает, какое ядро потребуется для выполнения гостевой системы Red Hat Enterprise Linux 3, если она была скомпилирована для процессора AMD.
Таблица 12.3. Архитектура ядра, необходимая для размещения гостевых систем, использующих паравиртуализированные драйверы в Red Hat Enterprise Linux 3 для процессоров AMD
Тип ядра гостевой системы Требуемый тип ядра размещающей системы
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Установка паравиртуализированных драйверов

В следующих трех главах будет рассмотрен процесс установки и настройки полностью виртуализированных гостей в системах, начиная с Red Hat Enterprise Linux 5.1, с помощью паравиртуализированных драйверов.

Убедитесь, что ваша архитектура поддерживается

Паравиртуализированные драйверы поддерживаются лишь некоторыми типами оборудования и версиями ОС. Если ваше оборудование и ОС их поддерживают, можно приступить к установке.

Эффективность паравиртуализированных драйверов

Чтобы наиболее эффективно использовать драйверы паравиртуализированных устройств, при установке новой гостевой системы предоставьте ей как минимум два диска.
Так, первый диск будет использоваться для MBR, загрузчика (GRUB) и раздела /boot. Этот диск не должен быть большим, его размер должен быть достаточен для размещения раздела /boot.
Второй диск и любые другие дополнительные диски используются для размещения остальных разделов (/, /usr и т.д.) или логических томов.
При таком методе установки с последующей установкой паравиртуализированных драйверов блочных устройств только действия загрузки гостя и доступа к разделу /boot будут использовать драйверы блочных устройств.

12.3.1. Последовательность действий при установке

Далее описаны общие действия, которые будут выполнены во всех гостевых ОС.
  1. Copy the RPMs for your hardware architecture to a suitable location in your guest operating system. Your home directory is sufficient. If you do not know which RPM you require verify against the table at Раздел 12.2, «Поддержка и ограничения паравиртуализации».
  2. Установите пакеты с помощью rpm или yum. Четыре модуля ядра будут установлены в /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release:
    • the PCI infrastructure module, xen_platform_pci.ko,
    • the ballooning module, xen_balloon.ko,
    • the virtual block device module, xen_vbd.ko,
    • and the virtual network device module, xen_vnif.ko.
  3. Если гостевая ОС (например, Red Hat Enterprise Linux 3) не поддерживает автоматическую загрузку паравиртуализированных драйверов, для их копирования потребуется выполнить дополнительные действия после завершения установки.
  4. Завершите работу гостевой операционной системы.
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Удалите запись «type=ioemu» сетевого устройства.
  7. Add any additional disk partitions, volumes or LUNs to the guest so that they can be accessed via the para-virtualized (xen-vbd) disk driver.
  8. For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
  9. A typical disk entry resembles the following:
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/dev/hda6'/>
      <target dev='hda'/>
    </disk>
    
    Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/dev/hda6'/>
      <target dev='xvda'/>
    </disk>
    
  10. Добавьте записи для дополнительных накопителей, если вы планируете использовать драйверы блочных устройств.
  11. Перезапустите виртуальную машину:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.
  12. Reconfigure the guest network.

12.3.2. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 3

Эта секция содержит подробную информацию об использовании паравиртуализированных драйверов в гостевых системах Red Hat Enterprise 3.

Замечание

Перечисленные далее пакеты не поддерживают загрузку с паравиртуализированного диска. Загрузка ядра гостевой операционной системы все еще требует эмуляции драйвера IDE, в то время как любые пользовательские приложения и данные могут использовать драйвер паравиртуализированного блочного устройства.
Установка драйверов
Далее приведена последовательность действий при установке гостевой системы Red Hat Enterprise Linux 3 с паравиртуализированными драйверами.
  1. Install the latest kernel version. The para-virtualized drivers require at least Red Hat Enterprise Linux 3.9 kernel version kernel-2.4.21-60.EL for all the required headers.
  2. Скопируйте пакет kmod-xenpv для вашей архитектуры и ядра в гостевую операционную систему.
  3. Установите пакеты с помощью утилиты rpm. Важно правильно выбрать пакет для вашего варианта гостевой операционной системы и архитектуры.
    [root@rhel3]# rpm -ivh kmod-xenpv*
    
  4. Use the commands below load the para-virtualized driver modules. %kvariant is the kernel variant the para-virtualized drivers have been build against and %release corresponds to the release version of the para-virtualized drivers.
    [root@rhel3]# mkdir -p /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# cp -R /lib/modules/2.4.21-52.EL[%kvariant]/extra/xenpv/%release \
    /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# depmod -ae
    [root@rhel3]# modprobe xen-vbd
    [root@rhel3]# modprobe xen-vnif
    

    Замечание

    При установке двоичных модулей драйверов команда insmod будет генерировать предупреждающие сообщения, так как в Red Hat Enterprise Linux 3 активен MODVERSIONS. Эти сообщения можно проигнорировать.
  5. Проверьте файл /etc/modules.conf и убедитесь в наличии псевдонима для eth0. Если планируется настроить несколько интерфейсов, для каждого интерфейса добавьте дополнительную строку.
    alias eth0 xen-vnif
    
    В файл /etc/rc.local добавьте:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Замечание

    Замените “%release” номером версии (например, 0.1-5.el). Если вы обновляете паравиртуализированный драйвер, не забудьте соответственно изменить версию.
  6. Завершите работу виртуальной машины, выполнив команду #shutdown -h now в гостевой системе.
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Удалите type=ioemu из записи vif=.
    • Добавьте остальные разделы, тома или LUN в гостевую систему, чтобы к ним можно было обращаться с помощью паравиртуализированного драйвера xen-vbd.
    • For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
    • A typical disk entry resembles the following:
      <disk type='file' device='disk'>
        <driver name='file'/>
        <source file='/dev/hda6'/>
        <target dev='hda'/>
      </disk>
      
      Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
      <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/dev/hda6'/>
        <target dev='xvda'/>
      </disk>
      
      
    • Once complete, save the modified configuration file and restart the guest.
  8. Boot the virtual machine:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.

Осторожно

Паравиртуализированные драйверы не будут добавлены и загружены автоматически, так как Red Hat Enterprise Linux 3 не включает поддержку weak-modules и modversions. Для добавления модуля выполните команду
insmod xen_vbd.ko
В Red Hat Enterprise Linux 3 потребуется вручную создать специальные файлы для блочных устройств, использующих xen-vbd. Далее приведена последовательность шагов для создания и регистрации паравиртуализированных блочных устройств.
После загрузки драйвера создайте специальные файлы с помощью следующего сценария:
#!/bin/sh
module="xvd"
mode="664"
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
# < mknod for as many or few partitions on xvd disk attached to FV guest >
# change/add xvda to xvdb, xvbd, etc. for 2nd, 3rd, etc., disk added in
# in xen config file, respectively.
mknod /dev/xvdb b $major 16
mknod /dev/xvdb1 b $major 17
mknod /dev/xvdb2 b $major 18
chgrp disk /dev/xvd*
chmod 0660 /dev/xvd*
Для каждого дополнительного виртуального диска увеличивайте вспомогательный номер на 16. В приведенном ниже примере будет создано дополнительное устройство с номером 16.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
Следующее устройство будет иметь номер 32:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Теперь убедитесь, что созданные вами разделы стали доступны.
[root@rhel3]# cat /proc/partitions
major   minor     #blocks   name

  3        0      10485760  hda
  3        1        104391  hda1
  3        2      10377990  hda2
202        16         64000  xvdb
202        17         32000  xvdb1
202        18        32000  xvdb2
253        0       8257536  dm-0
253        1       2031616  dm-1
Этот вывод показывает, что в системе доступно устройство xvdb.
Приведенный далее набор команд добавит в гостевую систему новое устройство так, чтобы подключение осуществлялось во время каждой загрузки.
  1. Создайте каталоги для последующего подключения блочных устройств.
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Смонтируйте устройства в созданные каталоги:
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Проверьте результат:
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. В гостевой системе измените файл /etc/fstab так, чтобы подключение устройств осуществлялось во время загрузки системы.
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Подсказка

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Домену dom0 Red Hat Enterprise Linux 5.2 этот параметр не понадобится.

Важно

В настоящее время двоичные RPM-пакеты Itanium (ia64) не доступны.

12.3.3. Установка и настройка паравиртуализированных драйверов в Red Hat Enterprise Linux 4

Этот раздел содержит подробные инструкции по установке паравиртуализированных драйверов в гостевой операционной системе Red Hat Enterprise 4.

Замечание

Эти пакеты не поддерживают загрузку с паравиртуализированного диска. Загрузка ядра гостевой операционной системы все еще требует эмуляции драйвера IDE, в то время как любые пользовательские приложения и данные могут использовать драйвер паравиртуализированного блочного устройства.
Установка драйверов
Далее приведена последовательность действий при установке гостевой системы Red Hat Enterprise Linux 4 с паравиртуализированными драйверами.
  1. Скопируйте пакеты kmod-xenpv, modules-init-tools и modversions для вашей архитектуры и ядра в гостевую операционную систему.
  2. Установите пакеты с помощью утилиты rpm. Важно правильно выбрать пакет для вашего варианта гостевой операционной системы и архитектуры. Потребуется обновленная версия пакета module-init-tools, которая начала поставляться с ядром Red Hat Enterprise Linux 4-6-z.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Замечание

    Архитектурам UP, SMP, Hugemem соответствуют различные версии пакета, поэтому важно выбрать правильный RPM-пакет для вашего типа ядра.
  3. Execute cat /etc/modprobe.conf to verify you have an alias for eth0 like the one below. If you are planning to configure multiple interfaces add an additional line for each interface. If it does not look like the entry below change it.
    alias eth0 xen-vnif
    
  4. Завершите работу виртуальной машины, выполнив команду #shutdown -h now в гостевой системе.
  5. Внесите следующие изменения в файл конфигурации /etc/xen/имя_гостя:
    • Удалите type=ioemu из записи vif=.
    • Добавьте остальные разделы, тома и LUN в гостевую систему, чтобы к ним можно было обращаться с помощью паравиртуализированного драйвера xen-vbd.
    • Для каждого дополнительного физического устройства, LUN, раздела или тома добавьте запись, подобную приведенной ниже. Поместите ее в секцию disk= файла конфигурации гостевой ОС.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • После добавления устройств, разделов, LUN и томов запись паравиртуализированного драйвера в XML-файле конфигурации будет выглядеть приблизительно так:
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Замечание

      Если используется файловый образ, обозначьте паравиртуализированное устройство как tap:aio.
  6. Загрузите виртуальную машину:
    # virsh start YourGuestName
При первой перезагрузке виртуального гостя kudzu предложит выбрать, удалить или оставить сетевое устройство Realtek, и попросит настроить устройство xen-bridge. Настройте xen-bridge и удалите сетевое устройство Realtek.

Совет

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Домену dom0 Red Hat Enterprise Linux 5.2 этот параметр не понадобится.
Теперь проверьте возможность доступа к созданным разделам.
[root@rhel4]# cat /proc/partitions
major    minor   #blocks   name

   3        0    10485760  hda
   3        1      104391  hda1
   3        2    10377990  hda2
 202        0       64000  xvdb
 202        1       32000  xvdb1
 202        2       32000  xvdb2
 253        0     8257536  dm-0
 253        1     2031616  dm-1
В этом примере системе доступно устройство xvdb.
Приведенный далее набор команд добавит в гостевую систему новое устройство так, чтобы подключение осуществлялось во время каждой загрузки.
  1. Создайте каталоги для последующего подключения блочных устройств.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Смонтируйте устройства в созданные каталоги:
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Проверьте результат:
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. В гостевой системе измените файл /etc/fstab так, чтобы подключение устройств осуществлялось во время загрузки системы.
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Замечание

Этот пакет не поддерживается, начиная с основного выпуска Red Hat Enterprise Linux 4 до Red Hat Enterprise Linux 4.2.

Важно

В настоящее время двоичные RPM-пакеты IA64 не доступны.

Автоматическая загрузка модулей

Если драйвер xen-vbd не загружается автоматически, в окне терминала виртуальной машины выполните приведенную ниже команду. Замените %release номером версии паравиртуализированного драйвера.
# insmod /lib/modules/'uname -r'/weak-updates/xenpv/%release/xen_vbd.ko

12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5

This section contains detailed instructions for the para-virtualized drivers in a Red Hat Enterprise Linux 5 guest operating system.

Замечание

Перечисленные далее пакеты не поддерживают загрузку с паравиртуализированного диска. Загрузка ядра гостевой операционной системы все еще требует эмуляции драйвера IDE, в то время как любые пользовательские приложения и данные могут использовать драйвер паравиртуализированного блочного устройства.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Процедура 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Завершите работу виртуальной машины, выполнив команду #shutdown -h now в гостевой системе.
  2. Внесите следующие изменения в файл конфигурации /etc/xen/<имя_гостя>:
    1. Удалите type=ioemu из записи vif=.
    2. Добавьте остальные разделы, тома или LUN в гостевую систему, чтобы к ним можно было обращаться с помощью паравиртуализированного драйвера xen-vbd.
    3. Для каждого дополнительного физического устройства, LUN, раздела или тома добавьте запись, подобную приведенной ниже. Поместите ее в секцию disk= файла конфигурации гостевой ОС.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. После добавления устройств, разделов, LUN и томов запись паравиртуализированного драйвера в XML-файле конфигурации будет выглядеть приблизительно так:
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Замечание

      Если используется файловый образ, обозначьте паравиртуализированное устройство как tap:aio.
  3. Загрузите виртуальную машину:
    # virsh start YourGuestName
    
Чтобы проверить, был ли интерфейс активирован после установки, паравиртуализированные драйверы исполнят приведенную далее команду в гостевой системе. В результате должна быть отображена информация об интерфейсе, включая его IP-адрес.
[root@rhel5]# ifconfig eth0
Теперь проверьте возможность доступа к созданным разделам.
[root@rhel5]# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvdb
 202     1      32000   xvdb1
 202     2      32000   xvdb2
 253     0    8257536   dm-0
 253     1    2031616   dm-1
В этом примере системе доступно устройство xvdb.
Приведенный далее набор команд добавит в гостевую систему новое устройство так, чтобы подключение осуществлялось во время каждой загрузки.
  1. Создайте каталоги для последующего подключения блочных устройств.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Смонтируйте устройства в созданные каталоги:
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Проверьте результат:
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. В гостевой системе измените файл /etc/fstab так, чтобы подключение устройств осуществлялось во время загрузки системы.
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Совет

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Домену dom0 Red Hat Enterprise Linux 5.2 этот параметр не понадобится.
Hiding fake interfaces
Sometimes, activating the para-virtualized drivers does not delete the old virtualized network interfaces. To remove these interfaces from guests use the following procedure.
  1. Add the following lines to the /etc/modprobe.d/blacklist file. Blacklist 8139cp and 8139too for the RealTek 8139 and e1000 for the virtualized Intel e1000 NIC.
    8139cp
    8139too
    e1000
    
  2. Remove the old network scripts from the /etc/sysconfig/network-scripts directory.
  3. Reboot the guest. The default network interface should now use the para-virtualized drivers.

12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6

This section describes the use of para-virtualized drivers in a Red Hat Enterprise Linux 6 guest.
The para-virtualized drivers are enabled by default for a Red Hat Enterprise Linux 6 guest. The guest will automatically unplug any emulated devices that are presented to it, and will use the para-virtualized drivers instead.
Although the para-virtualized drivers are enabled by default, they can be disabled. Add the following to the guest kernel command line upon boot to disable the para-virtualized drivers:
xen_emul_unplug=never

12.4. Настройка паравиртуализированного сетевого драйвера

Once the para-virtualized network driver is loaded you may need to reconfigure the guest's network interface to reflect the driver and virtual Ethernet card change.
Последовательность действий при перенастройке сетевого интерфейса:
  1. Откройте окно консоли в virt-manager для гостевой системы и авторизуйтесь как root.
  2. В Red Hat Enterprise Linux 4 убедитесь, что файл /etc/modprobe.conf содержит строку alias eth0 xen-vnif.
    # cat /etc/modprobe.conf
    alias eth0 xen-vnif
    
  3. To display the present settings for eth0 execute “# ifconfig eth0”. If you receive an error about the device not existing you should load the modules manually as outlined in Раздел 36.4, «Загрузка паравиртуализированных драйверов вручную».
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:00:00:6A:27:3A  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:846 (846.0 b)
    
  4. Start the network configuration utility(NetworkManager) with the command “# system-config-network”. Click on the “Forward” button to start the network card configuration.
  5. Select the 'Xen Virtual Ethernet Card (eth0)' entry and click 'Forward'.
    Configure the network settings as required.
  6. Complete the configuration by pressing the 'Apply' button.
  7. Press the 'Activate' button to apply the new settings and restart the network.
  8. Таким образом, новые настройки должны вступить в силу.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:16:3E:49:E4:E0
              inet addr:192.168.78.180  Bcast:192.168.79.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:501209 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:46265452 (44.1 MiB)
    

12.5. Настройка дополнительного виртуального оборудования

В этой секции будет рассмотрен процесс добавления дополнительных виртуальных накопителей и сетевых устройств в гостевую операционную систему. Подробную информацию о настройке сетевых ресурсов и накопителей можно найти в документе Развивающиеся технологии, Red Hat.com

12.5.1. Виртуальные сетевые интерфейсы

Последовательность действий при настройке дополнительных сетевых устройств:
Внесите изменения в файл конфигурации /etc/xen/имя_гостя.
Исходная запись выглядит примерно так:
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Измените ее, чтобы она выглядела так:
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Убедитесь, что для нового интерфейса генерируется уникальный MAC-адрес.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
После перезагрузки гостевой системы убедитесь, что обновление было добавлено в /etc/modules.conf (для Red Hat Enterprise Linux 3) или /etc/modprobe.conf (для Red Hat Enterprise Linux 4 и Red Hat Enterprise Linux 5). Для всех добавляемых интерфейсов создайте новый псевдоним.
alias eth1 xen-vnif
Теперь проверьте возможность доступа к интерфейсам из гостевой системы.
# ifconfig eth1
В результате выполнения этой команды будут показаны настройки eth1. Повторите команду для eth2 и других интерфейсов.
Теперь можно настроить новые сетевые интерфейсы с помощью утилиты redhat-config-network (для Red Hat Enterprise Linux 3) или system-config-network (для Red Hat Enterprise Linux 4 и Red Hat Enterprise Linux 5).

12.5.2. Виртуальные устройства хранения

Последовательность действий при настройке дополнительных накопителей для гостевых систем:
Внесите изменения в файл конфигурации /etc/xen/имя_гостя. Исходная запись будет выглядеть примерно так:
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Теперь добавьте дополнительную запись для нового физического устройства, LUN, раздела или тома в параметр disk=. Ниже приведен пример записи описания паравиртуализированных драйверов. Параметр tap:aio заставит гипервизор использовать паравиртуализированный драйвер.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Новые записи можно добавить в секцию disk=, разделяя их запятой.

Замечание

You need to increment the letter for the 'xvd' device, that is for your second storage entity it would be 'xvdb' instead of 'xvda'.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage2.dsk,xvdb,w" ]
Убедитесь, что разделы были созданы, и проверьте возможность доступа.
# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvda
 202     1      64000   xvdb
 253     0    8257536   dm-0
 253     1    2031616   dm-1
Обратите внимание, что системе доступен раздел (или устройство) xvdb.
Смонтируйте новые устройства и диски в локальные каталоги и измените файл /etc/fstab в гостевой системе, чтобы подключение осуществлялось во время загрузки.
# mkdir /mnt/pvdisk_xvda
# mkdir /mnt/pvdisk_xvdb
# mount /dev/xvda /mnt/pvdisk_xvda
# mount /dev/xvdb /mnt/pvdisk_xvdb
# df /mnt
Filesystem           1K-blocks      Used   Available Use%  Mounted on
/dev/xvda                64000        15       63985   1%  /mnt/pvdisk_xvda
/dev/xvdb                64000        15       63985   1%  /mnt/pvdisk_xvdb

Глава 13. Паравиртуализированные драйверы KVM

Para-virtualized drivers are available for virtualized Windows guests running on KVM hosts. These para-virtualized drivers are included in the virtio-win package. The virtio-win package supports block (storage) devices and network interface controllers.
As with the KVM module, the virtio-win drivers package is only available on hosts running Red Hat Enterprise Linux 5.4 and newer.
Паравиртуализированные драйверы позволяют повысить производительность полностью виртуализированных гостевых систем, снизить задержки операций ввода-вывода и значительно увеличить скорость обработки.
The KVM para-virtualized drivers are automatically loaded and installed on the following versions of Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux 4.8 and newer
  • Red Hat Enterprise Linux 5.3 and newer
  • Red Hat Enterprise Linux 6.
Those Red Hat Enterprise Linux versions detect and install the drivers so additional installation steps are not required.

Замечание

PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
Системы Microsoft Windows, которые поддерживают паравиртуализированные драйверы KVM:
  • Windows XP (32-bit only)
  • Windows Server 2003 (32-bit and 64-bit versions)
  • Windows Server 2008 (32-bit and 64-bit versions)
  • Windows 7 (32-bit and 64-bit versions)

13.1. Установка паравиртуализированных драйверов Windows

В этой секции будет рассмотрен процесс установки паравиртуализированных драйверов KVM для работы Windows. Их можно загрузить во время установки Windows и установить после установки гостевой системы.
You can install the para-virtualized drivers on your guest by one of the following methods:
  • hosting the installation files on a network accessible to the guest,
  • using a virtualized CD-ROM device of the driver installation disk .iso file, or
  • using a virtualized floppy device to install the drivers during boot time (for Windows guests).
This guide describes installation from the para-virtualized installer disk as a virtualized CD-ROM device.
  1. Загрузите драйверы

    The virtio-win package contains the para-virtualized block and network drivers for all supported Windows guests.
    If the Red Hat Enterprise Linux Supplementary channel entitlements are not enabled for the system, the download will not be available. Enable the Red Hat Enterprise Linux Supplementary channel to access the virtio-win package.
    Download the virtio-win package with the yum command.
    # yum install virtio-win
    
    The drivers are also available on the Red Hat Enterprise Linux Supplementary disc or from Microsoft (windowsservercatalog.com). Note that the Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Linux are created on the same code base so the drivers for the same version (for example, 5.5) are supported for both environments.
    Пакет virtio-win установит образ virtio-win.iso в каталог /usr/share/virtio-win/.
  2. Установите паравиртуализированные драйверы

    Рекомендуется сначала установить драйверы в гостевой системе, а уже после этого подключать или изменять устройства с целью использования паравиртуализированных драйверов.
    Для блочных устройств, на которых расположены корневые файловые системы или другие блочные устройства, необходимые для загрузки гостя, потребуется установить драйверы, прежде чем приступить к изменению настроек устройства.
Installing drivers with a virtualized CD-ROM
This procedure covers installing the para-virtualized drivers with a virtualized CD-ROM after Windows is installed.
Процедура 13.1. Монтирование образа CD-ROM для гостя Windows с помощью virt-manager
  1. Open virt-manager and the virtualized guest

    Open virt-manager, select your virtualized guest from the list by double clicking the guest name.
  2. Open the hardware tab

    Click the Add Hardware button in the Hardware tab.
  3. Select the device type

    This opens a wizard for adding the new device. Select Storage from the dropdown menu.
    Click the Forward button to proceed.
  4. Select the ISO file

    Choose the File (disk image) option and set the file location of the para-virtualized drivers .iso image file. The location file is named /usr/share/virtio-win/virtio-win.iso.
    Если драйверы расположены на обычном компакт-диске, выберите Обычный дисковый раздел (Normal Disk Partition).
    Set the Device type to IDE cdrom and click Forward to proceed.
  5. Disc assigned

    The disk has been assigned and is available for the guest once the guest is started. Click Finish to close the wizard or back if you made a mistake.
  6. Reboot

    Reboot or start the guest to add the new device. Virtualized IDE devices require a restart before they can be recognized by guests.
Once the CD-ROM with the drivers is attached and the guest has started, proceed with Процедура 13.2, «Windows installation».
Процедура 13.2. Windows installation
  1. Open My Computer

    On the Windows guest, open My Computer and select the CD-ROM drive.
  2. Select the correct installation files

    There are four files available on the disc. Select the drivers you require for your guest's architecture:
    • the para-virtualized block device driver (RHEV-Block.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • the para-virtualized network device driver (RHEV-Network.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • or both the block and network device drivers.
    Double click the installation files to install the drivers.
  3. Install the block device driver

    1. Start the block device driver installation

      Double click RHEV-Block.msi or RHEV-Block64.msi.
      Press Next to continue.
    2. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    3. Finish

      Press Finish to complete the installation.
  4. Install the network device driver

    1. Start the network device driver installation

      Double click RHEV-Network.msi or RHEV-Network64.msi.
      Press Next to continue.
    2. Performance setting

      This screen configures advanced TCP settings for the network driver. TCP timestamps and TCP window scaling can be enabled or disabled. The default is, 1, for window scaling to be enabled.
      TCP window scaling is covered by IETF RFC 1323. The RFC defines a method of increasing the receive window size to a size greater than the default maximum of 65,535 bytes up to a new maximum of 1 gigabyte (1,073,741,824 bytes). TCP window scaling allows networks to transfer at closer to theoretical network bandwidth limits. Larger receive windows may not be supported by some networking hardware or operating systems.
      TCP timestamps are also defined by IETF RFC 1323. TCP timestamps are used to better calculate Return Travel Time estimates by embedding timing information is embedded in packets. TCP timestamps help the system to adapt to changing traffic levels and avoid congestion issues on busy networks.
      ValueAction
      0Disable TCP timestamps and window scaling.
      1Enable TCP window scaling.
      2Enable TCP timestamps.
      3Enable TCP timestamps and window scaling.
      Press Next to continue.
    3. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    4. Finish

      Press Finish to complete the installation.
  5. Reboot

    Reboot the guest to complete the driver installation.

13.2. Installing drivers with a virtualized floppy disk

Здесь рассматривается установка паравиртуализированных драйверов в процессе установки Windows.
  • Во время первой установки виртуальной машины Windows подключите viostor.vfd как дисковод.
    1. Windows Server 2003

      Когда Windows предложит нажать F6, чтобы задать сторонние драйверы, следуйте инструкциям.
    2. Windows Server 2008

      При запросе драйверов нажмите Загрузить драйвер (Load Driver), перейдите к диску A: и выберите подходящий для вашей операционной системы драйвер.

13.3. Использование паравиртуализированных драйверов KVM для существующих устройств

Modify an existing hard disk device attached to the guest to use the virtio driver instead of virtualized IDE driver. This example edits libvirt configuration files. Alternatively, virt-manager, virsh attach-disk or virsh attach-interface can add a new device using the para-virtualized drivers Раздел 13.4, «Использование паравиртуализированных драйверов KVM для новых устройств».
  1. Типичная запись для виртуализированного гостя, не использующего паравиртуализированные драйверы, которая определяет блочное устройство на основе файла выглядит примерно так:
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. Присвойте bus= значение virtio, чтобы использовать паравиртуализированное устройство.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. Использование паравиртуализированных драйверов KVM для новых устройств

Здесь рассматривается процесс создания новых устройств, использующих паравиртуализированные драйверы KVM, с помощью virt-manager.
Новое устройство с использованием паравиртуализированных драйверов также можно добавить с помощью команд virsh attach-disk и virsh attach-interface.

Сначала установите драйверы

Прежде чем приступить к установке новых устройств, убедитесь, что в гостевой системе Windows уже установлены драйверы. В противном случае устройство не будет обнаружено и, как следствие, работать не будет.
  1. Открыть окно сведений виртуальной машины можно дважды щелкнув мышью на ее имени в virt-manager.
  2. Перейдите на вкладку Оборудование (Hardware).
  3. Нажмите кнопку Добавить оборудование (Add Hardware).
  4. На открывшейся вкладке выберите Накопители (Storage) или Сеть (Network).
    1. New disk devices
      Выберите диск или файл образа. В качестве типа устройства укажите диск virtio и нажмите кнопку продолжения.
    2. New network devices
      Выберите Виртуальная сеть (Virtual network) или Общее физическое устройство (Shared physical device). В качестве типа устройства укажите virtio и нажмите кнопку продолжения.
  5. Чтобы сохранить устройство, нажмите кнопку завершения.
  6. Перезагрузите виртуальную машину, чтобы убедиться, что Windows распознает устройство.

Глава 14. PCI passthrough

This chapter covers using PCI passthrough with Xen and KVM hypervisors.
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
The VT-d or AMD IOMMU extensions must be enabled in BIOS.
Процедура 14.1. Preparing an Intel system for PCI passthrough
  1. Enable the Intel VT-d extensions

    The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. The main benefit of the feature is to improve the performance as native for device access.
    The VT-d extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
    These extensions are often called various terms in BIOS which differ from manufacturer to manufacturer. Consult your system manufacturer's documentation.
  2. Activate Intel VT-d in the kernel

    Activate Intel VT-d in the kernel by appending the intel_iommu=on parameter to the kernel line of the kernel line in the /boot/grub/grub.conf file.
    The example below is a modified grub.conf file with Intel VT-d activated.
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.18-190.el5)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-190.el5 ro root=/dev/VolGroup00/LogVol00 intel_iommu=on
       initrd /initrd-2.6.18-190.el5.img
  3. Ready to use

    Reboot the system to enable the changes. Your system is now PCI passthrough capable.
Процедура 14.2. Preparing an AMD system for PCI passthrough
  • Enable AMD IOMMU extensions

    The AMD IOMMU extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
AMD systems only require that the IOMMU is enabled in the BIOS. The system is ready for PCI passthrough once the IOMMU is enabled.

PCI passthrough with Xen

Xen and KVM require different kernel arguments to enable PCI passthrough. The previous instructions are for KVM. For both AMD and Intel systems, PCI passthrough on Xen requires the iommu=on parameter to the hypervisor command line. Modify the /boot/grub/grub.conf file as follows to enable PCI passthrough:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=on
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 
   module /initrd-2.6.18-190.el5xen.img

14.1. Adding a PCI device with virsh

These steps cover adding a PCI device to a fully virtualized guest under the Xen or KVM hypervisors using hardware-assisted PCI passthrough. Refer to Раздел 14.4, «PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux» for details on adding a PCI device to a para-virtualized Xen guest.

Важно

The VT-d or AMD IOMMU extensions must be enabled in BIOS.
This example uses a USB controller device with the PCI identifier code, pci_8086_3a6c, and a fully virtualized guest named win2k3.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command:
    # virsh nodedev-dumpxml pci_8086_3a6c
    <device>
      <name>pci_8086_3a6c</name>
      <parent>computer</parent>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>26</slot>
        <function>7</function>
        <id='0x3a6c'>82801JD/DO (ICH10 Family) USB2 EHCI Controller #2</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
  3. Detach the device from the system. Attached devices cannot be used and may cause various errors if connected to a guest without detaching first.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  4. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
    For example, if bus = 0, slot = 26 and function = 7 run the following:
    $ printf %x 0
    0
    $ printf %x 26
    1a
    $ printf %x 7
    7
    The values to use:
    bus='0x00'
    slot='0x1a'
    function='0x7'
  5. Run virsh edit (or virsh attach device) and add a device entry in the <devices> section to attach the PCI device to the guest. Only run this command on offline guests. Red Hat Enterprise Linux does not support hotplugging PCI devices at this time.
    # virsh edit win2k3
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
          <address domain='0x0000' bus='0x00' slot='0x1a' function='0x7'/>
      </source>
    </hostdev>
  6. Once the guest system is configured to use the PCI address, we need to tell the host system to stop using it. The ehci driver is loaded by default for the USB PCI controller.
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/ehci_hcd
  7. Detach the device:
    $ virsh nodedev-dettach pci_8086_3a6c
  8. Verify it is now under the control of pci_stub:
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/pci-stub
  9. Set a sebool to allow the management of the PCI device from the guest:
    # setsebool -P virt_use_sysfs 1
  10. Start the guest system :
    # virsh start win2k3
    
The PCI device should now be successfully attached to the guest and accessible to the guest operating system.

14.2. Adding a PCI device with virt-manager

PCI devices can be added to guests using the graphical virt-manager tool. The following procedure adds a 2 port USB controller to a virtualized guest.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Detach the PCI device

    Detach the device from the system.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  3. Power off the guest

    Power off the guest. Hotplugging PCI devices into guests is presently unsupported and may fail or crash.
  4. Open the hardware settings

    Open the virtual machine and select the Hardware tab. Click the Add Hardware button to add a new device to the guest.
  5. Add the new device

    Select Physical Host Device from the Hardware type list. The Physical Host Device represents PCI devices. Click Forward to continue.
  6. Select a PCI device

    Select an unused PCI device. Note that selecting PCI devices presently in use on the host causes errors. In this example a PCI to USB interface device is used.
  7. Confirm the new device

    Click the Finish button to confirm the device setup and add the device to the guest.
The setup is complete and the guest can now use the PCI device.

14.3. PCI passthrough with virt-install

To use PCI passthrough with the virt-install parameter, use the additional --host-device parameter.
  1. Identify the PCI device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
  2. Add the device

    Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter.
    # virt-install \
     -n hostdev-test -r 1024 --vcpus 2 \
     --os-variant fedora11 -v --accelerate \
     -l http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
     -x 'console=ttyS0 vnc' --nonetworks --nographics  \
     --disk pool=default,size=8 \
     --debug --host-device=pci_8086_10bd 
    
  3. Complete the installation

    Complete the guest installation. The PCI device should be attached to the guest.

14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux

PCI passthrough is used to allow a Xen guest exclusive access to a PCI device, rather than sharing with other guests or with dom0. PCI passthrough for para-virtualized Xen guests is supported on all Red Hat Enterprise Linux 5 systems, however PCI passthrough with fully virtualized guests is only supported on Red Hat Enterprise Linux 5.4 and newer.

Предупреждение

PCI passthrough to para-virtualized guests is considered insecure and is not supported for Red Hat Enterprise Linux 6 guests.
Limitations of Xen PCI passthrough:
Any guest using PCI passthrough will no longer be available for save, restore, or migration capabilities, as it will be tied to a particular non-virtualized hardware configuration.
A guest which has access to a non-virtualized PCI device via PCI passthrough also has the potential to access the DMA address space of dom0, which is a potential security concern.
To link a PCI device to a guest the device must first be hidden from the host. If the host is using the device the device cannot be assigned to the guest.
Процедура 14.3. Example: attaching a PCI device
  1. Given a network device which uses the bnx2 driver and has a PCI id of 0000:09:00.0, the following lines added to /etc/modprobe.conf hides the device from dom0. Either the bnx2 module must be reloaded or the host must be restarted.
    install bnx2 /sbin/modprobe pciback; /sbin/modprobe --first-time --ignore-install bnx2
    options pciback hide=(0000:09:00.0)
  2. Multiple PCI identifiers can be added to /etc/modprobe.conf to hide multiple devices.
    options pciback hide=(0000:09:00.0)(0000:0a:04.1)
  3. Use one of the following methods to add the passed-through device to the guest's configuration file:

Глава 15. SR-IOV

15.1. Introduction

The PCI-SIG (PCI Special Interest Group) developed the Single Root I/O Virtualization (SR-IOV) specification. The PCI-SIG Single Root IOV specification is a standard for a type of PCI passthrough which natively shares a single device to multiple guests. SR-IOV does not require hypervisor involvement in data transfer and management by providing an independent memory space, interrupts, and DMA streams for virtualized guests.
SR-IOV enables a Single Root Function (for example, a single Ethernet port), to appear as multiple, separate, physical devices. A physical device with SR-IOV capabilities can be configured to appear in the PCI configuration space as multiple functions, each device has its own configuration space complete with Base Address Registers (BARs).
SR-IOV uses two new PCI functions:
  • Physical Functions (PFs) are full PCIe devices that include the SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions.
  • Virtual Functions (VFs) are simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to virtualized guests.
The hypervisor can map one or more Virtual Functions to a virtualized guest. The Virtual Function's configuration space is mapped, by the hypervisor, to the virtualized guest's configuration space.
Each Virtual Function can only be mapped once as Virtual Functions require real hardware. A virtualized guest can have multiple Virtual Functions. A Virtual Function appears as a network card in the same way as a normal network card would appear to an operating system.
The SR-IOV drivers are implemented in the kernel. The core implementation is contained in the PCI subsystem, but there must also be driver support for both the Physical Function (PF) and Virtual Function (VF) devices. With an SR-IOV capable device one can allocate VFs from a PF. The VFs appear as PCI devices which are backed on the physical PCI device by resources (queues, and register sets).
Advantages of SR-IOV
SR-IOV devices can share a single physical port with multiple virtualized guests.
Virtual Functions have near-native performance and provide better performance than para-virtualized drivers and emulated access. Virtual Functions provide data protection between virtualized guests on the same physical server as the data is managed and controlled by the hardware.
These features allow for increased virtualized guest density on hosts within a data center.
Disadvantages of SR-IOV
Live migration is presently unsupported. As with PCI passthrough, identical device configurations are required for live (and offline) migrations. Without identical device configurations, guest's cannot access the passed-through devices after migrating.

15.2. Using SR-IOV

This section covers attaching Virtual Function to a guest as an additional network device.
SR-IOV requires Intel VT-d support.

SR-IOV with Xen

Xen requires additional kernel arguments to use SR-IOV. Modify the /boot/grub/grub.conf file to enable SR-IOV. To enable SR-IOV with Xen for Intel systems append the pci_pt_e820_access=on parameter to the kernel.
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5xen)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=1
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 pci_pt_e820_access=on
   module /initrd-2.6.18-192.el5xen.img
Процедура 15.1. Attach an SR-IOV network device
  1. Enable Intel VT-d in BIOS and in the kernel

    Enable Intel VT-D in BIOS. Refer to Процедура 14.1, «Preparing an Intel system for PCI passthrough» for more information on enabling Intel VT-d in BIOS and the kernel, or refer to your system manufacturer's documentation for specific instructions.
  2. Verify support

    Verify if the PCI device with SR-IOV capabilities are detected. This example lists an Intel 82576 network interface card which supports SR-IOV. Use the lspci command to verify if the device was detected.
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    

    Примечание

    Note that the output has been modified to remove all other devices.
  3. Start the SR-IOV kernel modules

    If the device is supported the driver kernel module should be loaded automatically by the kernel. Optional parameters can be passed to the module using the modprobe command. The Intel 82576 network interface card uses the igb driver kernel module.
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
    
  4. Activate Virtual Functions

    The max_vfs parameter of the igb module allocates the maximum number of Virtual Functions. The max_vfs parameter causes the driver to spawn, up to the value of the parameter in, Virtual Functions. For this particular card the valid range is 0 to 7.
    Remove the module to change the variable.
    # modprobe -r igb
    Restart the module with the max_vfs set to 1 or any number of Virtual Functions up to the maximum supported by your device.
    # modprobe igb max_vfs=1
    
  5. Inspect the new Virtual Functions

    Using the lspci command, list the newly added Virtual Functions attached to the Intel 82576 network device.
    # lspci | grep 82576
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    
    The identifier for the PCI device is found with the -n parameter of the lspci command.
    # lspci -n | grep 03:00.0
    03:00.0 0200: 8086:10c9 (rev 01)
    # lspci -n | grep 03:10.0
    03:10.0 0200: 8086:10ca (rev 01)
    
    The Physical Function corresponds to 8086:10c9 and the Virtual Function to 8086:10ca.
  6. Find the devices with virsh

    The libvirt service must find the device to add a device to a guest. Use the virsh nodedev-list command to list available host devices.
    # virsh nodedev-list | grep 8086
    pci_8086_10c9
    pci_8086_10c9_0
    pci_8086_10ca
    pci_8086_10ca_0
    [output truncated]
    
    The serial numbers for the Virtual Functions and Physical Functions should be in the list.
  7. Get advanced details

    The pci_8086_10c9 is one of the Physical Functions and pci_8086_10ca_0 is the first corresponding Virtual Function for that Physical Function. Use the virsh nodedev-dumpxml command to get advanced output for both devices.
    # virsh nodedev-dumpxml pci_8086_10ca
    # virsh nodedev-dumpxml pci_8086_10ca_0
    <device>
      <name>pci_8086_10ca_0</name>
      <parent>pci_8086_3408</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>16</slot>
        <function>1</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
    
    This example adds the Virtual Function pci_8086_10ca_0 to the guest in Шаг 8. Note the bus, slot and function parameters of the Virtual Function, these are required for adding the device.
  8. Add the Virtual Function to the guest

    1. Shut down the guest.
    2. Use the output from the virsh nodedev-dumpxml pci_8086_10ca_0 command to calculate the values for the configuration file. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
      The example device has the following values: bus = 3, slot = 16 and function = 1. Use the printf utility to convert decimal values to hexadecimal values.
      $ printf %x 3
      3
      $ printf %x 16
      10
      $ printf %x 1
      1
      This example would use the following values in the configuration file:
      bus='0x03'
      slot='0x10'
      function='0x01'
    3. Open the XML configuration file with the virsh edit command. This example edits a guest named MyGuest.
      # virsh edit MyGuest
      
    4. The default text editor will open the libvirt configuration file for the guest. Add the new device to the devices section of the XML configuration file.
      <hostdev mode='subsystem' type='pci' managed='yes'>
            <source>
              <address bus='0x03' slot='0x10' function='0x01'/>
            </source>
      </hostdev>
      
    5. Save the configuration.
  9. Restart

    Restart the guest to complete the installation.
    # virsh start MyGuest
    
The guest should start successfully and detect a new network interface card. This new card is the Virtual Function of the SR-IOV device.

15.3. Troubleshooting SR-IOV

This section contains some issues and solutions for problems which may affect SR-IOV.
Error starting the guest
Start the configured vm , an error reported as follows:
# virsh start test
error: Failed to start domain test
error: internal error unable to start guest: char device redirected to
/dev/pts/2
get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied
init_assigned_device: Error: Couldn't get real device (03:10.0)!
Failed to initialize assigned device host=03:10.0
This error is often caused by a device which is already assigned to another guest or to the host itself.

Глава 16. Управление временем виртуальных машин KVM

Некоторые процессоры не поддерживают постоянную частоту счетчика, что может негативно сказаться на работе виртуальных машин, использующих счетчик тактов процессора (TSC, Time Stamp Counter). Неточности могут привести к замедлению или, наоборот, ускорению работы сетевых приложений, что изменит скорость работы самой виртуальной машины.
KVM позволяет обойти эту проблему посредством предоставления виртуальным машинам паравиртуализированных часов. Некоторые системы могут использовать другие часы для x86, которые будут включены в их будущие версии.
В настоящее время только версии Red Hat Enterprise Linux, начиная с 5.4, полностью поддерживают паравиртуализированные часы.
Потенциальные проблемы, связанные с неточностью часов и счетчиков процессора:
  • Нарушение синхронизации часов может привести к несвоевременному завершению сеансов и сказаться на работе сети;
  • Виртуальные машины с замедленными часами могут столкнуться с проблемами при миграции;
Эти проблемы существуют и на других платформах виртуализации, поэтому настоятельно рекомендуется тестировать счетчики и часы.

NTP

В размещающей и гостевых системах должен быть активен сетевой протокол NTP (Network Time Protocol). Команда запуска:
# service ntpd start
Добавьте службу ntpd в последовательность загрузки:
# chkconfig ntpd on
В большинстве случаев служба ntpd поможет минимизировать последствия расхождения часов.
Определение наличия постоянного счетчика TSC
Наличие постоянного счетчика TSC подтверждается флагом constant_tsc. Чтобы узнать, есть ли флаг constant_tsc:
$ cat /proc/cpuinfo | grep constant_tsc
Непустой вывод команды подтверждает наличие бита constant_tsc. Если же вывод пуст, обратитесь к приведенным ниже инструкциям.
Настройка узлов без постоянного счетчика TSC
Для процессоров, не поддерживающих постоянную частоту счетчика TSC, потребуется дополнительная настройка. Возможности управления питанием для виртуальных машин надо будет отключить, так как они отрицательно сказываются на синхронизации времени с KVM.

Замечание

Эти инструкции применимы только для процессоров AMD F.
В случае отсутствия бита constant_tsc отключите все возможности управления питанием (BZ #513138). Каждая система обладает несколькими таймерами, которые используются для синхронизации. В размещающей системе частота счетчика TSC может колебаться вследствие изменений cpufreq, перехода в Deep C-состояние или миграции на узел с более быстрым TSC. Для отключения Deep C-состояния остановите счетчик, добавьте processor.max_cstate=1 в строку параметров grub на узле:
term Red Hat Enterprise Linux Server (2.6.18-159.el5)
        root (hd0,0)
	kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
Отключите cpufreq (только если отсутствует бит constant_tsc). Для этого в файле /etc/sysconfig/cpuspeed измените значения переменных MIN_SPEED и MAX_SPEED на максимально возможное значение частоты. Диапазоны частот можно найти в файлах /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies.
Использование паравиртуализированных часов в гостевых системах Red Hat Enterprise Linux
В некоторых гостевых системах Red Hat Enterprise Linux потребуется настроить дополнительные параметры ядра. Их можно добавить в конец строки /kernel файла /boot/grub/grub.conf, расположенного в гостевой системе.
Приведенная ниже таблица содержит перечень версий Red Hat Enterprise Linux и параметров ядра, необходимых для систем, не поддерживающих постоянную частоту счетчика TSC.
Red Hat Enterprise LinuxДополнительные параметры ядра
5.4 AMD64/Intel 64 с паравиртуализированными часамиДополнительные параметры не нужны
5.4 AMD64/Intel 64 без паравиртуализированных часовdivider=10 notsc lpj=n
5.4 x86 с паравиртуализированными часамиДополнительные параметры не нужны
5.4 x86 без паравиртуализированных часовdivider=10 clocksource=acpi_pm lpj=n
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64Дополнительные параметры не нужны
3.9 x86Дополнительные параметры не нужны
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
В системах Windows используются и часы реального времени (RTC, Real-Time Clock), и тактовый счетчик TSC. Поэтому виртуальные машины Windows могут использовать часы RTC вместо тактового счетчика во избежание расхождения времени между разными виртуальными машинами.
PMTIMER обычно использует счетчик TSC. Чтобы включить RTC для PMTIMER, в файл boot.ini добавьте следующее:
/use pmtimer
Дальнейшую информацию о параметрах загрузки Windows можно найти на странице параметров, используемых в файле Boot.ini в Windows XP и Windows Server 2003.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
В системах Windows используются и часы реального времени (RTC, Real-Time Clock), и тактовый счетчик TSC. Поэтому виртуальные машины Windows могут использовать часы RTC вместо тактового счетчика во избежание расхождения времени между разными виртуальными машинами.
The boot.ini file is no longer used from Windows Vista and newer. Windows Vista, Windows Server 2008 and Windows 7 use the Boot Configuration Data Editor (bcdedit.exe) to modify the Windows boot parameters.
This procedure is only required if the guest is having time keeping issues. Time keeping issues may not affect guests on all host systems.
  1. Open the Windows guest.
  2. Open the Accessories menu of the start menu. Right click on the Command Prompt application, select Run as Administrator.
  3. Confirm the security exception, if prompted.
  4. Set the boot manager to use the platform clock. This should instruct Windows to use the PM timer for the primary clock source. The system UUID ({default} in the example below) should be changed if the system UUID is different than the default boot device.
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
This fix should improve time keeping for Windows Vista, Windows Server 2008 and Windows 7 guests.

Часть IV. Управление

Глава 17. Рекомендации для сервера

Приведенные далее советы и рекомендации помогут обеспечить безопасность и надежность сервера Red Hat Enterprise Linux 5 (dom0).
  • Включите строгий режим SELinux, выполнив команду
    # setenforce 1
    
  • Удалите или отключите службы, в которых нет необходимости, такие как AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail и пр.
  • Добавьте лишь минимальное число учетных записей, которое требуется для управления платформой, и удалите ненужные записи.
  • Постарайтесь не выполнять посторонние приложения на узле, так как это может негативно сказаться на производительности виртуальной машины и подвергнуть риску стабильность работы сервера.
  • Образы виртуальных машин следует сохранить в /var/lib/libvirt/images/. Если же вы используете другой каталог, убедитесь, что это отражено в настройках политики SELinux.
  • Источники установки, иерархии каталогов и установочные образы должны быть сохранены в одном месте — обычно там, где расположен сервер vsftpd.

Глава 18. Виртуализация и безопасность

При реализации технологии виртуализации в корпоративной инфраструктуре необходимо обеспечить безопасность размещающей системы. Домен 0 является привилегированным доменом, выполняющим функции управления системой и виртуальными машинами. Если он не защищен, все остальные домены подвергаются риску. Существует несколько способов усиления защиты систем, утилизирующих виртуализацию. Сначала разработайте комплексный план по развертыванию, содержащий описание спецификаций и служб, обязательных для виртуальных машин и размещающих серверов, а также информацию о том, что необходимо для поддержки этих служб. Ниже перечислены наиболее важные принципы защиты, которые следует принять во внимание при разработке такого плана.
  • Убедитесь, что на главном узле выполняется минимально необходимое число служб. Чем меньше заданий и служб выполняется в домене 0, тем меньше он подвержен риску.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Раздел 18.2, «Виртуализация и SELinux» for more information on using SELinux and virtualization.
  • Используйте межсетевой экран для ограничения трафика к dom0. Для усиления защиты межсетевой экран может быть настроен на автоматический отказ. Также рекомендуется ограничить число служб, использующих сетевое подключение.
  • Не открывайте доступ к dom0 для обычных пользователей. Помните, домен 0 является привилегированным, а разрешение доступа непривилегированных пользователей может подвергнуть его безопасность неоправданному риску.

18.1. Storage security issues

Administrators of virtualized guests can change the partitions the host boots in certain circumstances. To prevent this administrators should follow these recommendations:
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.

18.2. Виртуализация и SELinux

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attackers abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that Red Hat recommends all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.
SELinux prevents guest images from loading if SELinux is enabled and the images are not correctly labeled. SELinux requires that image files have the virt_image_t label applied to them. The /var/lib/libvirt/images directory has this label applied to it and its contents by default. This does not mean that images must be stored in this directory; images can be stored anywhere, provided they are labeled with virt_image_t.
Добавление хранилища LVM при включенном SELinux
Дальше будет рассмотрен пример добавления логического тома в виртуальную систему, где SELinux работает в строгом режиме. Приведенные инструкции также подходят для разделов жестких дисков.
Процедура 18.1. Создание и монтирование логического тома
  1. Создайте логический том. Команда создания тома размером 5 гигабайт в группе томов группа_томов будет выглядеть так:
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Отформатируйте новый_том и создайте файловую систему, поддерживающую расширенные атрибуты, например, ext3.
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. Создайте новый каталог, куда будет смонтирован новый логический том. Этот каталог может быть расположен в любом месте, хотя не рекомендуется его размещать в системных каталогах (/etc, /var, /sys) и домашних каталогах (/home или /root).
    # mkdir /virtstorage
    
  4. Смонтируйте созданный том.
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    или для каталога KVM:
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    При использовании целевой политики (целевая политика используется по умолчанию) команда добавит дополнительную строку в файл /etc/selinux/targeted/contexts/files/file_contexts.local. Добавленное выражение обеспечит постоянство этих изменений.
    /virtstorage(/.*)?    system_u:object_r:xen_image_t:s0
    
  6. Label the device node (for example, /dev/volumegroup/NewVolumeName with the correct label:
    # semanage fcontext -a -t xen_image_t /dev/volumegroup/NewVolumeName
    # restorecon /dev/volumegroup/NewVolumeName
    

18.3. SELinux

Эта секция содержит информацию, которую важно помнить при реализации SELinux в окружении виртуализации. Не забывайте обновлять политику SELinux, если вы внесли изменения в систему или добавили новые устройства. Так, чтобы настроить том LVM для виртуальной машины, необходимо изменить контекст SELinux для соответствующего блочного устройства и группы томов.
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
Логический параметр xend_disable_t переводит xend в незащищенный режим после его перезапуска. Если вы решили отключить защиту, лучше это сделать отдельно для демона, а не для всей системы. Не рекомендуется задавать метку xen_image_t для каталогов, которые планируется использовать для других целей.
KVM and SELinux
There are several SELinux booleans which affect KVM. These booleans are listed below for your convenience.
KVM SELinux Booleans
SELinux BooleanDescription
allow_unconfined_qemu_transitionDefault: off. This boolean controls whether KVM guests can be transitioned to unconfined users.
qemu_full_networkDefault: on. This boolean controls full network access to KVM guests.
qemu_use_cifsDefault: on. This boolean controls KVM's access to CIFS or Samba file systems.
qemu_use_commDefault: off. This boolean controls whether KVM can access serial or parallel communications ports.
qemu_use_nfsDefault: on. This boolean controls KVM's access to NFS file systems.
qemu_use_usbDefault: on. This boolean allows KVM to access USB devices.

18.4. Virtualization firewall information

Various ports are used for communication between virtualized guests and management utilities.

Guest network services

Any network service on a virtualized guest must have the applicable ports open on the guest to allow external access. If a network service on a guest is firewalled it will be inaccessible. Always verify the guests network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guests if ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host.
  • Ports 5634 to 6166 are used for guest console access with the SPICE protocol.
  • Port 8002 is used by Xen for live migration.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is required for virtual bridge devices. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

Примечание

Note that enabling IP forwarding is not required for physical bridge devices. When a guest is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.

Глава 19. Управление виртуальными машинами с помощью xend

Демон xend выполняет определенные функции по управлению виртуальными машинами, в том числе осуществляет контроль виртуализированных ресурсов. Для взаимодействия с виртуальными машинами необходимо, чтобы xend работал. Прежде чем вы запустите xend, задайте параметры в файле конфигурации /etc/xen/xend-config.sxp. Ниже приведены доступные параметры.
Таблица 19.1. Параметры конфигурации xend
Параметр Описание
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
Определяет минимальный объем памяти в мегабайтах, выделяемый домену 0. Если указано значение 0, объем не меняется.
(dom0-cpus)
Определяет число процессоров, которые домен 0 сможет использовать. По умолчанию назначается 1.
(enable-dump)
Определяет, выполнять ли дамп ядра при сбое. По умолчанию установлено в 0.
(external-migration-tool)
Задает приложение или сценарий, отвечающий за миграцию внешних устройств. Сценарии должны располагаться в /etc/xen/scripts/external-device-migrate.
(logfile)
Задает расположение файла журнала. По умолчанию журнал будет сохранен в /var/log/xend.log.
(loglevel)
Устанавливает уровень критичности сообщений, записываемых в журнал. Доступные значения: DEBUG, INFO, WARNING, ERROR, CRITICAL. По умолчанию используется DEBUG.
(network-script)
Задает сценарий, активирующий сетевое окружение. Сценарии должны располагаться в каталоге /etc/xen/scripts.
(xend-http-server)
Определяет, активировать ли HTTP-сервер управления пакетами. По умолчанию сервер отключен.
(xend-unix-server)
Определяет, активировать ли сокет-сервер домена. Сокет-сервер представляет собой конечную точку, где обрабатываются сетевые соединения низкого уровня, которая разрешает или запрещает входящие подключения. Значение по умолчанию — yes.
(xend-relocation-server)
Активирует сервер перемещения для поддержки миграции между машинами. По умолчанию сервер отключен.
(xend-unix-path)
Задает расположение вывода данных команды xend-unix-server. По умолчанию вывод будет сохранен в /var/lib/xend/xend-socket.
(xend-port)
Определяет порт, используемый HTTP-сервером. По умолчанию используется порт 8000.
(xend-relocation-port)
Определяет порт, используемый сервером перемещения. По умолчанию используется порт 8002.
(xend-relocation-address)
Определяет адреса узлов, которым разрешена миграция. По умолчанию используется значение параметра xend-address.
(xend-address)
Определяет адрес, которому сопоставлен сокет-сервер. По умолчанию разрешены все подключения.

Установив параметры, запустите демон xend. Для его запуска выполните:
service xend start
Остановка xend:
service xend stop
Эта команда остановит xend, если он запущен.
Перезапуск xend:
service xend restart
Эта команда перезапустит xend, даже если он уже работает.
Также можно проверить состояние xend:
service xend status
The output displays the daemon's status.

Активация xend во время загрузки

С помощью команды chkconfig добавьте xend в initscript.
chkconfig --level 345 xend
xend будет запущен на уровнях выполнения 3, 4, 5.

Глава 20. Живая миграция Xen

The Xen hypervisor supports Virtualization Migration for para-virtualized guests and fully virtualized guests. Migration is only supported on Red Hat Enterprise Linux 5.1 and newer systems. Migration can be performed offline or live.
  • В режиме автономной миграции работа виртуальной машины будет приостановлена, затем она будет перенесена, после чего ее работа будет восстановлена. Команда virsh migrate осуществляет перенос.
    # virsh migrate GuestName libvirtURI
  • A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. The Xen hypervisor estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until Xen predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
    Для выполнения живой миграции используется опция --live команды virsh migrate:
    # virsh migrate--live GuestName libvirtURI

Замечание для систем Itanium®

Архитектура Itanium® в настоящее время не поддерживает миграцию виртуальных машин.
Чтобы добавить возможности миграции Xen, необходимо внести изменения в файл конфигурации /etc/xen/xend-config.sxp. По умолчанию миграция отключена во избежание проблем безопасности, так как при открытии порта для переноса возникает риск инициации процесса миграции неавторизованными узлами. Поскольку не существует специального механизма аутентификации для обработки запросов миграции, следует уделить особое внимание защите порта миграции.

Защита процесса миграции

Фильтры IP-адресов и имен узлов обеспечивают лишь минимальную защиту. Оба эти атрибута могут быть подделаны, если злоумышленник знает адрес или имя узла клиента миграции. Поэтому лучше всего изолировать сеть, в которой находится узел и клиент, от неавторизованных внутренних и внешних подключений.
Настройка миграции
Для добавления возможностей миграции в файле /etc/xen/xend-config.sxp измените следующие записи:
(xend-relocation-server yes)
Исходное значение «no» отключает миграцию. Измените его на «yes».
(xend-relocation-port 8002)
Параметр (xend-relocation-port) позволяет задать порт, используемый демоном xend для интерфейса переноса. При этом xend-relocation-server должен иметь значение «yes».
Стандартное значение подойдет для большинства установок. Если же вы решили его изменить, используйте незанятый порт на сервере.
Указанный порт должен быть открыт в обеих системах.
(xend-relocation-address '')
(xend-relocation-address) задает адрес, который xend должен прослушивать на предмет поступления команд миграции для relocation-socket (если определен xend-relocation-server).
The default is to listen on all active interfaces. The (xend-relocation-address) parameter restricts the migration server to only listen to a specific interface. The default value in /etc/xen/xend-config.sxp is an empty string(''). This value should be replaced with a single, valid IP address. For example:
(xend-relocation-address '10.0.0.1')
(xend-relocation-hosts-allow '')
The (xend-relocation-hosts-allow 'hosts') parameter controls which hostnames can communicate on the relocation port.
Unless you are using SSH or TLS, the guest's virtual memory is transferred in raw form without encryption of the communication. Modify the xend-relocation-hosts-allow option to restrict access to the migration server.
Если значение не определено (характеризуется пустой строкой, заключенной в одинарные кавычки), будут разрешены все подключения. При этом подразумевается, что запрос подключения поступает на порт и интерфейс, которые прослушиваются сервером перемещения (см. выше xend-relocation-port и xend-relocation-address).
Или же параметр (xend-relocation-hosts-allow ) может содержать набор регулярных выражений, разделенных пробелом. Будут разрешены подключения с узлов, полностью квалифицированные имена или IP-адреса которых удовлетворяют одному из выражений.
Пример:
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Завершив настройку параметров в файле конфигурации, перезапустите Xen.
# service xend restart

20.1. Пример живой миграции

Далее приведен пример настройки простого окружения для выполнения живой миграции. Для организации общего хранилища эта конфигурация использует NFS, что вполне подходит для демонстрации, но в рабочих окружениях лучше использовать Fibre Channel, iSCSI или GFS.
Приведенная конфигурация включает два сервера (et-virt07 и et-virt08). Оба сервера в качестве стандартного интерфейса используют eth1, и, как следствие, сетевой мост xenbr1. Для организации общего хранилища с помощью NFS мы будем использовать локально подключенный SCSI-диск /dev/sdb на сервере et-virt07.
Подготовка к живой миграции
Создайте и смонтируйте каталог, который будет использоваться для миграции:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Важно

Убедитесь, что каталог экспортируется с правильными параметрами. Например, если вы экспортируете каталог /var/lib/libvirt/images/, убедитесь, что осуществляется экспорт ТОЛЬКО /var/lib/libvirt/images/ а НЕ /var/lib/xen/, так как этот каталог используется демоном xend и другими процессами. Разрешение совместного доступа к /var/lib/xen/ может привести к непредсказуемым результатам.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Убедитесь, что экспортирование выполняется с помощью NFS:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Установка виртуальной машины
Команда установки в этом случае будет выглядеть так:
# virt-install -p -f /var/lib/libvirt/images/testvm1.dsk -s 5 -n\
testvm1 --vnc -r 1024 -l http://example.com/RHEL5-tree\
Server/x86-64/os/ -b xenbr1
Проверьте настройки окружения миграции
Убедитесь, что сетевые мосты настроены верно и имеют одно и то же имя на обоих узлах:
[et-virt08 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
[et-virt07 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
Убедитесь, что параметры переноса совпадают на обоих узлах:
[et-virt07 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[et-virt08 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
Убедитесь, что сервер перемещения запущен и прослушивает заданный порт (8002):
[et-virt07 ~]# lsof -i :8002
COMMAND  PID  USER   FD   TYPE  DEVICE SIZE NODE NAME
python 3445 root 14u IPv4 10223 TCP *:teradataordbms (LISTEN)
[et-virt08 ~]# lsof -i :8002
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
python 3252 root 14u IPv4 10901 TCP *:teradataordbms (LISTEN)
That the default /var/lib/libvirt/images directory is available and mounted with networked storage on both hosts. Shared, networked storage is required for migrations.
[et-virt08 ~]# df /var/lib/libvirt/images
Filesystem           1K-blocks      Used Available Use% Mounted on
et-virt07:/var/lib/libvirt/images    70562400   2379712  64598336   4% /var/lib/libvirt/images
[et-virt08 ~]# file /var/lib/libvirt/images/testvm1.dsk 
/var/lib/libvirt/images/testvm1.dsk: x86 boot sector; partition 1: ID=0x83,
active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, 
starthead 0, startsector 208845, 10265535 sectors, code offset 0x48
[et-virt08 ~]# touch /var/lib/libvirt/images/foo
[et-virt08 ~]# rm -f /var/lib/libvirt/images/foo
Проверка сохранения и восстановления виртуальной машины
Запустите виртуальную машину:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Убедитесь, что виртуальная машина работает:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Сохраните виртуальную машину на локальном узле:
[et-virt07 images]# time virsh save testvm1 testvm1.sav
real    0m15.744s
user    0m0.188s
sys     0m0.044s
[et-virt07 images]# ls -lrt testvm1.sav
-rwxr-xr-x 1 root root 1075657716 Jan 12 06:46 testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Восстановите виртуальную машину на локальном узле:
[et-virt07 images]# virsh restore testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Start the live migration of domain-id from et-virt08 to et-virt07. The hostname you are migrating to and <domain-id> must be replaced with valid values. This example uses the et-virt08 host which must have SSH access to et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Verify the virtual machine is no longer present on et-virt08
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verify the virtual machine has been migrated to et-virt07:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        running
Проверка прогресса и начало живой миграции
Create the following script inside the virtual machine to log date and hostname during the migration. This script performs I/O tasks on the guest's file system.
#!/bin/bash

while true
do
touch /var/tmp/$$.log
echo `hostname` >>  /var/tmp/$$.log
	echo `date`     >>  /var/tmp/$$.log
	cat  /var/tmp/$$.log
	df /var/tmp
	ls -l  /var/tmp/$$.log
	sleep 3
	done
Обратите внимание, что сценарий используется лишь в целях тестирования; в нем нет необходимости при выполнении живой миграции в рабочем окружении.
Прежде чем приступить к переносу виртуальной машины на et-virt07, убедитесь, что она работает на et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Начните живую миграцию на et-virt07. Чтобы просмотреть, сколько времени займет процесс миграции, можно добавить команду time.
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Выполните сценарий в гостевой системе:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:33 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 02:26 /var/tmp/2279.log
Fri Jan 12 02:26:45 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:48 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:51 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:54:57 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 744 Jan 12 06:55 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Убедитесь, что работа виртуальной машины завершена на et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Убедитесь, что виртуальная машина запущена на et-virt07:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Повторите цикл миграции с et-virt07 на et-virt08.
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Убедитесь, что работа виртуальной машины завершена:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Перед началом миграции в гостевой системе выполните следующий сценарий и обратите внимание на изменение времени при миграции гостя:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 248 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 310 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:06 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 372 Jan 12 02:30 /var/tmp/2418.log
После завершения команды миграции на et-virt07 убедитесь, что виртуальная машина запущена на et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Выполните перенос еще раз:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
Таким образом, вы выполнили тест автономной и живой миграции.

20.2. Настройка живой миграции

Ниже будет рассмотрена настройка миграции гостей Xen на другие серверы Red Hat Enterprise Linux в автономном режиме с помощью xm migrate. Живая миграция выполняется аналогично, но сначала необходимо внести некоторые изменения в файл конфигурации xend-config.
(xend-relocation-server yes)
The default for this parameter is 'no', which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
(xend-relocation-port 8002)
Снимите с этого выражения знак комментария. xend-relocation-port определяет порт, используемый демоном xend для миграции. Это значение надо изменить, только если сетевое окружение этого требует.
(xend-relocation-address )
При активном xend-relocation-server этот параметр определяет адрес, прослушивающий соединения сокета перемещения. Гипервизор Xen прослушивает сетевой трафик миграции для заданного интерфейса.
(xend-relocation-hosts-allow )
Этот параметр управляет узлом, который сообщается с портом, используемым для перемещения. Если значение не определено, будут разрешены все входящие подключения. Вместо этого надо ввести набор регулярных выражений, разделенных пробелом. Пример:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Допускается указать полностью квалифицированные имена доменов, IP-адреса или разделенные пробелом регулярные выражения.
Завершив настройку, перезагрузите виртуальную машину.

Глава 21. Живая миграция KVM

В этой главе будет рассмотрен процесс живой миграции виртуальных машин, работающих на гипервизоре KVM, на другой узел KVM.
Migration is the process of moving a virtualized guest from one host to another. Migration is a key feature of virtualization as software is completely separated from hardware. Migration is useful for:
  • Распределение нагрузки — виртуальные машины могут быть перенесены на узлы с наименьшей нагрузкой.
  • Обеспечение отказоустойчивости — в случае сбоя устройств размещающей системы можно перенести виртуальные машины, тем самым освободив поврежденный узел для диагностики.
  • Энергосбережение — виртуальные машины можно перенести на другие узлы, чтобы сократить затраты энергии в периоды низкой нагрузки.
  • Географический перенос — перенос виртуальных машин с целью сокращения задержек при обмене данными.
Migrations can be performed live or offline. To migrate guests the storage must be shared. Migration works by sending the guests memory to the destination host. The shared storage stores the guest's default file system. The file system image is not sent over the network from the source host to the destination host.
При выполнении миграции в автономном режиме работа виртуальной машины останавливается, затем образы памяти переносятся в целевую систему. После переноса работа машины на новом узле возобновляется, а на исходном узле используемая этим ей память будет освобождена.
Длительность автономной миграции зависит от полосы пропускания и сетевой задержки. Так, перенос виртуальной машины с 2 Гбайт памяти по 1 гигабит Ethernet займет около 10 секунд.
Живая миграция характеризуется тем, что работа виртуальных систем не останавливается при переносе. Все изменяемые за это время страницы памяти отслеживаются и передаются целевому узлу после завершения передачи образа. Процесс продолжается до тех пор, пока не будут скопированы все страницы или пока не истечет заданный гипервизором KVM период времени. Если страницы источника изменяются слишком быстро, то работа виртуальной машины на исходном узле будет приостановлена и будет выполнена передача регистров и буферов. Регистры будут загружены на новом узле и машина возобновит работу на целевом узле. Если же синхронизация невозможна, что вероятно в случае большой нагрузки, то виртуальная машина будет приостановлена для выполнения миграции в автономном режиме.
Длительность такой миграции зависит от полосы пропускания, сетевой задержки и активности сети.

21.1. Требования живой миграции

Ниже перечислены требования для успешного выполнения миграции.
Требования миграции
  • Виртуальная машина, установленная на общем устройстве хранения с использованием одного из следующих протоколов:
    • Fibre Channel
    • iSCSI
    • NFS
    • GFS2
  • Как минимум две системы Red Hat Enterprise Linux одной версии с одними и теми же обновлениями.
  • Обе системы должны открыть соответствующие порты.
  • Сетевая конфигурация обеих систем должна совпадать.
  • В исходной и целевой системах общее хранилище должно быть смонтировано в одну и ту же точку. Путь к этому каталогу и его имя также должны совпадать.
Настройка сетевого хранилища
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Часть V, «Virtualization Storage Topics».

21.2. Пример общего хранилища: Упрощение миграции за счет NFS

В рассмотренном ниже примере совместный доступ узлов KVM к образам виртуальных машин будет обеспечен за счет NFS. Этот пример не подходит для масштабных установок, его целью является лишь демонстрация процесса миграции, поэтому не стоит его использовать для миграции большого количества виртуализированных гостей.
For advanced and more robust shared storage instructions, refer to Часть V, «Virtualization Storage Topics»
  1. Экспортируйте каталог с образом libvirt

    Добавьте каталог с образом в файл /etc/exports:
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    Замените *.bne.redhat.com необходимым именем узла.
  2. Запустите NFS

    1. Если пакеты NFS еще не установлены, установите их:
      # yum install nfs
      
    2. В iptables откройте порты для NFS и добавьте NFS в файл /etc/hosts.allow.
    3. Запустите службу:
      # service nfs start
      
  3. Смонтируйте общее хранилище

    Смонтируйте /var/lib/libvirt/images в целевой системе:
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    Расположение каталога должно совпадать на обоих узлах

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

21.3. Живая миграция с помощью virsh

Виртуальную машину можно перенести на другой узел с помощью команды virsh. Ее аргумент migrate принимает параметры в следующем формате:
# virsh migrate --live GuestName DestinationURL
Замените имя_гостя именем переносимой виртуальной машины.
целевой_URL можно заменить ссылкой или именем узла принимающей системы. Она должна выполняться в той же версии Red Hat Enterprise Linux, использовать тот же гипервизор и в ней должна выполняться утилита libvirt.
Эта команда запросит ввод пароля root для доступа к целевой системе.
Пример живой миграции с помощью virsh
Этот пример демонстрирует перенос виртуальной машины RHEL4test с узла test1.example.com на test2.example.com.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Требования миграции).
  1. Убедитесь, что виртуальная машина работает

    Убедитесь, что RHEL4test выполняется на test1.example.com:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Можно приступить к миграции

    Выполните приведенную ниже команду, чтобы начать перенос на test2.example.com. В конец ссылки добавьте /system, чтобы сообщить libvirt о необходимости получения полного доступа.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Эта команда запросит ввод пароля root для доступа к целевой системе.
  3. Подождите

    Процесс миграции может занять некоторое время в зависимости от нагрузки и размера виртуальной машины. virsh будет сообщать только об ошибках. Машина будет продолжать работу на исходном узле до завершения переноса.
  4. Проверьте результат переноса

    Убедитесь, что RHEL4test выполняется на test2.example.com:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
Живая миграция успешно завершена.

Другие сетевые механизмы

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Глава 22, Удаленное управление виртуальными машинами for more information on using other methods.

21.4. Миграция с помощью virt-manager

В этой секции рассматривается миграция виртуальных машин, работающих на гипервизоре KVM, с помощью virt-manager.
  1. Подключитесь к отправляющей и получающей системам. В меню Файл (File) выберите Добавить соединение (Add Connection).
    В открывшемся окне измените следующее:
    • В качестве гипервизора выберите QEMU.
    • В списке соединений выберите тип соединения.
    • В поле Имя узла (Hostname) введите имя узла.
    Нажмите кнопку подключения.
    Менеджер виртуальных машин покажет список подключенных узлов.
  2. Добавьте общий пул хранилищ.
    В меню правки выберите пункт сведений об узле.
    Перейдите на вкладку Хранилище (Storage).
  3. Чтобы добавить пул хранилищ, в левом нижнем углу нажмите кнопку + и в открывшемся окне укажите следующие параметры:
    В открывшемся окне измените следующее:
    • Имя (Name): Введите имя для создаваемого пула.
    • Тип (Type): Выберите netfs: Network Exported Directory.
    Нажмите кнопку продолжения.
  4. В открывшемся окне измените следующее:
    • Формат (Format): Для живой миграции выберите NFS или iSCSI.
    • Узел (Host name): Введите адрес IP или полностью квалифицированное имя домена сервера хранилища.
    Нажмите кнопку заверешения.
  5. Нажмите кнопку Создать том (New Volume), чтобы создать том в общем пуле.
  6. Заполните поля и нажмите Создать том (Create Volume).
  7. Создайте виртуальную машину, использующую этот том, и запустите ее.
    Появится окно виртуальной машины.
  8. В окне менеджера виртуальных машин откройте контекстное меню созданной виртуальной машины и выберите пункт миграции, затем выберите целевой узел.
  9. Нажмите Да (Yes) для подтверждения.
    The Virtual Machine Manager displays the virtual machine in its new location.
    The VNC connection displays the remote host's address in its title bar.

Глава 22. Удаленное управление виртуальными машинами

В этой главе рассматривается удаленное управление виртуальными машинами с использованием ssh, TLS и SSL.

22.1. Удаленное управление с помощью SSH

Пакет ssh предоставляет зашифрованный сетевой протокол, который позволяет безопасно передавать управляющие функции удаленным серверам виртуализации. Ниже рассматривается управление удаленными машинами утилитой libvirt по SSH-туннелю. Аутентификация осуществляется за счет использования общих ключей SSH и паролей или проверочных фраз, получаемых локальным агентом SSH. Доступная виртуальным машинам консоль VNC также защищена SSH.
Обычно используется стандартная конфигурация SSH, поэтому нет необходимости в создании дополнительных правил межсетевого экрана для обеспечения доступа к управляющей службе или консоли VNC.
При организации удаленного управления виртуальными машинами следует принять во внимание следующие моменты относительно SSH:
  • потребуются права root для доступа к удаленной машине и управления ее виртуальными машинами;
  • изначальный процесс настройки соединения может быть замедлен;
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • при значительном увеличении числа удаленных машин могут возникнуть сложности с использованием SSH.
Configuring password less or password managed SSH access for virt-manager
The following instructions assume you are starting from scratch and do not already have SSH keys set up. If you have SSH keys set up and copied to the other systems you can skip this procedure.

The user is important for remote management

SSH keys are user dependent. Only the user who owns the key may access that key.
virt-manager must run as the user who owns the keys to connect to the remote host. That means, if the remote systems are managed by a non-root user virt-manager must be run in unprivileged mode. If the remote systems are managed by the local root user then the SSH keys must be own and created by root.
You cannot manage the local host as an unprivileged user with virt-manager.
  1. Optional: Changing user

    Change user, if required. This example uses the local root user for remotely managing the other hosts and the local host.
    $ su -
  2. Generating the SSH key pair

    Generate a public key pair on the machine virt-manager is used. This example uses the default key location, in the ~/.ssh/ directory.
    $ ssh-keygen -t rsa
    
  3. Coping the keys to the remote hosts

    Remote login without a password, or with a passphrase, requires an SSH key to be distributed to the systems being managed. Use the ssh-copy-id command to copy the key to root user at the system address provided (in the example, root@example.com).
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.com root@example.com's password: Now try logging into the machine, with "ssh 'root@example.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting 
    
    Repeat for other systems, as required.
  4. Optional: Add the passphrase to the ssh-agent

    Add the passphrase for the SSH key to the ssh-agent, if required. On the local host, use the following command to add the passphrase (if there was one) to enable password-less login.
    # ssh-add ~/.ssh/id_rsa.pub
The SSH key was added to the remote system.
Демон libvirt (libvirtd)
The libvirt daemon provide an interface for managing virtual machines. You must have the libvirtd daemon installed and running on every remote host that needs managing.
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
После завершения настройки libvirtd и SSH вы сможете обращаться к удаленным виртуальным машинам, управлять ими и обращаться к гостевым системам через VNC.
Accessing remote hosts with virt-manager
Remote hosts can be managed with the virt-manager GUI tool. SSH keys must belong to the user executing virt-manager for password-less login to work.
  1. Start virt-manager.
  2. Open the File->Add Connection menu.
  3. Input values for the hypervisor type, the connection, Connection->Remote tunnel over SSH, and enter the desired hostname, then click connection.

22.2. Удаленное управление с помощью TLS и SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Раздел 22.1, «Удаленное управление с помощью SSH»). TLS and SSL is the same technology used by web browsers for secure connections. The libvirt management connection opens a TCP port for incoming connections, which is securely encrypted and authenticated based on x509 certificates. In addition the VNC console for each guest virtual machine will be setup to use TLS with x509 certificate authentication.
This method does not require shell accounts on the remote machines being managed. However, extra firewall rules are needed to access the management service or VNC console. Certificate revocation lists can revoke users' access.
Последовательность действий при настройке доступа TLS/SSL для virt-manager
Здесь подразумевается, что вы начинаете работу с нуля и не обладаете опытом работы с сертификатами TLS/SSL. При наличии сервера управления сертификатами первые шаги можно пропустить.
Настройка сервера с помощью libvirt
Информацию о создании сертификатов можно найти на сайте libvirt по адресу http://libvirt.org/remote.html.
VNC-сервер Xen
На VNC-сервере Хеn можно включить TLS, изменив файл конфигурации /etc/xen/xend-config.sxp. Снимите комментарий с параметра (vnc-tls 1).
The /etc/xen/vnc directory needs the following 3 files:
  • ca-cert.pem - The CA certificate
  • server-cert.pem - The Server certificate signed by the CA
  • server-key.pem - The server private key
This provides encryption of the data channel. It might be appropriate to require that clients present their own x509 certificate as a form of authentication. To enable this remove the commenting on the (vnc-x509-verify 1) parameter.
Настройка клиентов virt-manager и virsh
В настоящее время процесс настройки клиентов может варьироваться. Для активации API libvirt через TLS необходимо поместить сертификаты клиента и CA в /etc/pki. На сайте http://libvirt.org/remote.html можно найти подробную информацию.
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
Формат ссылки URI для virsh:
  • qemu://hostname.guestname/system (для KVM);
  • xen://hostname.guestname/ (для Xen).
Чтобы включить SSL и TLS для VNC, необходимо поместить сертификатор CA и сертификаты клиента в $HOME/.pki. Эти файлы включают:
  • CA или ca-cert.pem: Сертификат CA.
  • libvirt-vnc или clientcert.pem: Сертификат клиента, подписанный центром CA.
  • libvirt-vnc или clientkey.pem: Частный ключ клиента.

22.3. Режимы передачи данных

libvirt поддерживает следующие режимы передачи для удаленного управления:
TLS
Протокол TLS (Transport Layer Security) 1.0 (SSL 3.1) — криптографический протокол, предоставляющий возможности аутентификации и безопасной передачи данных по TCP/IP. Обычно используется для прослушивания общего порта, по умолчанию — порт 16514. Для этого потребуется создать сертификаты для клиента и сервера.
Сокеты UNIX
Сокеты доменов UNIX доступны только на локальной машине. Они не зашифрованы и для аутентификации используют разрешения UNIX или SELinux. Стандартные имена сокетов — /var/run/libvirt/libvirt-sock и /var/run/libvirt/libvirt-sock-ro (только для чтения).
SSH
Для передачи данных с использованием SSH (Secure Shell) необходимо установить Netcat (пакет nc), в удаленной системе должен выполняться демон libvirtd, а порт 22 должен быть открыт для SSH-доступа. Инструменты управления ключами, подобные ssh-agent, позволят избежать необходимости повторного ввода пароля.
ext
Параметр ext используется внешними программами, которые подключаются к удаленной машине без помощи libvirt, что обычно включает программы сторонних производителей без официальной поддержки безопасности. Поэтому этот параметр не поддерживается.
tcp
Незашифрованный сокет TCP/IP по умолчанию использует порт 16509 и не рекомендуется для использования в производственной среде, поэтому он обычно отключен. Администраторы могут прибегнуть к его помощи в целях тестирования или при работе в доверенной сети.
Если способ передачи не задан, по умолчанию будет использоваться TLS.
Удаленные URI
virsh и libvirt используют единообразный идентификатор ресурса URI (Uniform Resource Identifier) для подключения к удаленному узлу. Аргумент --connect команды virsh использует URI для выполнения команд на удаленном узле.
Формат URI в libvirt (необязательные параметры заключены в квадратные скобки):
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
Отличие локального URI от внешнего состоит в том, что для него не требуется указание режима передачи и имени узла.
Примеры параметров удаленного управления
  • Подключение пользователя ccurran к удаленному гипервизору Xen на узле towada с использованием SSH:
    xen+ssh://ccurran@towada/
    
  • Подключение к удаленному гипервизору Xen на узле towada с использованием TLS:
    xen://towada/
    
  • Connect to a remote Xen hypervisor on host towada using TLS. The no_verify=1 tells libvirt not to verify the server's certificate.
    xen://towada/?no_verify=1
    
  • Подключение к удаленному гипервизору KVM на узле towada с использованием SSH:
    qemu+ssh://towada/system
    
Примеры тестирования
  • Подключение к локальному гипервизору KVM с использованием нестандартного сокета UNIX с указанием полного пути:
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • Подключение к демону libvirt на сервере с IP-адресом 10.1.1.10 (порт 5000) с использованием незашифрованного соединения TCP/IP и стандартных настроек драйвера test.
    test+tcp://10.1.1.10:5000/default
    
Дополнительные параметры URI
Extra parameters can be appended to remote URIs. The table below Таблица 22.1, «Дополнительные параметры URI» covers the recognized parameters. All other parameters are ignored. Note that parameter values must be URI-escaped (that is, a question mark (?) is appended before the parameter and special characters are converted into the URI format).
Таблица 22.1. Дополнительные параметры URI
Параметр Режим передачи Описание Пример
name все Имя можно получить из URI путем удаления протокола, имени узла, пользователя, номера порта и всех дополнительных параметров. В некоторых случаях, однако, имя рекомендуется задать напрямую. Оно будет передано удаленной функции virConnectOpen. name=qemu:///system
command ssh, ext Внешняя команда. Обязательна для ext. Для SSH по умолчанию используется «ssh». Поиск команды будет осуществляться в соответствии со значением PATH. command=/opt/openssh/bin/ssh
socket unix, ssh Путь к сокету домена UNIX. Переопределяет путь, используемый по умолчанию. Для SSH будет передаваться удаленной команде netcat (см. ниже). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
Подключиться к удаленным системам можно с помощью команды netcat. По умолчанию используется nc. Формат команды при использовании SSH:
								command -p port [-l username] hostname
								netcat -U socket
Здесь порт, пользователь, узел являются составляющими удаленного URI, а command, netcat и socket — получают свои значения из соответствующих параметров.
netcat=/opt/netcat/bin/nc
no_verify tls If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration. no_verify=1
no_tty ssh Ненулевое значение отключает запрос пароля, если SSH не может пройти авторизацию автоматически на удаленной машине (для ssh-agent и пр.). Используется при отсутствии доступа к терминалу, например, в графических программах использующих libvirt. no_tty=1

Часть V. Virtualization Storage Topics

Introduction to storage administration for virtualization

This part covers using shared, networked storage with virtualization on Red Hat Enterprise Linux.
The following methods are supported for virtualization:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Networked storage is essential for live and offline guest migrations. You cannot migrate guests without shared storage.

Глава 23. Using shared storage with virtual disk images

This chapter covers the use of shared and network storage devices for virtual disks.

23.1. Using iSCSI for storing virtual disk images

This section demonstrates how to set up an iSCSI target on Red Hat Enterprise Linux and how to configure iSCSI on a libvirt KVM host using virsh, and finally how to provision a guest on iSCSI using virt-install.

Важно

Setting up a Red Hat Enterprise Linux server as an iSCSI target is not recommended. The example used in this section should not be used in production, and is provided as an example which should only be referred to for basic shared storage testing and educational purposes.

23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux

  1. Install and enable the iSCSI target service

    Install and enable the iSCSI target service with the following commands:
    # yum install scsi-target-utils
    # chkconfig tgtd on
    # service tgtd start
    

    Важно

    The scsi-target-utils package required for this example is provided only in the Cluster Storage add-on for Red Hat Enterprise Linux 5, and may not be available for your system. Contact your support agent to activate this add-on if you are currently unable to install this package.
  2. Allocate storage for the LUNs

    The iSCSI target service is not dependent on a particular type of exported LUN. The LUNs can be plain files, LVM volumes, or block devices. There is however a performance overhead if using the LVM and/or file system layers as compared to block devices. The guest providing the iSCSI service in this example has no spare block or LVM devices, so raw files will be used.
    This example demonstrates the creation of two LUNs; one is a 10GB thin-provisioned (sparse file) LUN, and the other has 500MB, of which are fully-allocated. The following commands will achieve this configuration. Be aware that your environment will be different and this is provided only as an example:
    # mkdir -p /var/lib/tgtd/kvmguest
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/rhelx86_64.img bs=1M seek=10240 count=0
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/shareddata.img bs=1M count=512
    # restorecon -R /var/lib/tgtd
    
  3. Export the iSCSI target and LUNs

    For Red Hat Enterprise Linux 5, a series of tgtadm commands is required to create a target and associate the storage volumes created earlier. First, the following command adds a target using an iSCSI Qualified Name (IQN):
    # tgtadm --lld iscsi --op new --mode target --tid 1 --targetname \ 
    iqn.2004-04.rhel:rhel5:iscsi.kvmguest
    
    Now the storage volumes must be associated with LUNs in the iSCSI target with these two commands:
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 \
    --backing-store /var/lib/tgtd/kvmguest/rhelx86_64.img
    
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 \
    --backing-store /var/lib/tgtd/kvmguest/shareddata.img
    

    Важно

    Add the previous 3 tgtadm commands to the end of the /etc/rc.local file to ensure normal operation upon restarting of the system.
    To confirm the successful operation of the previous commands, query the iSCSI target setup:
    tgtadm --lld iscsi --op show --mode target
    Target 1: iqn.2004-04.rhel:rhel5:iscsi.kvmguest
        System information:
            Driver: iscsi
            State: ready
        I_T nexus information:
        LUN information:
            LUN: 0
                Type: controller
                SCSI ID: IET     00010000
                SCSI SN: beaf10
                Size: 0 MB, Block size: 1
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: null
                Backing store path: None
                Backing store flags: 
            LUN: 1
                Type: disk
                SCSI ID: IET     00010001
                SCSI SN: beaf11
                Size: 10737 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/rhelx86_64.img
                Backing store flags: 
            LUN: 2
                Type: disk
                SCSI ID: IET     00010002
                SCSI SN: beaf12
                Size: 537 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/shareddata.img
                Backing store flags: 
        Account information:
        ACL information:
    
  4. Allow client access to the target

    Finally, this example command allows access to all clients without any authentication:
    # tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
    

Two common mistakes

The two most common problems encountered when configuring the iSCSI target are SELinux and iptables. If adding plain files as LUNs in an iSCSI target, ensure the files are labelled system_u:object_r:tgtd_var_lib_t:s0. TCP port 3260 must also be open in your iptables configuration.

23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install

The previous section described how to set up an iSCSI target. This section demonstrates how to configure iSCSI on a libvirt KVM instance using virsh, and then how to provision a guest using virt-install.
  1. Defining the storage pool

    All libvirt storage is managed through storage pools, of which there are many possible types: SCSI, NFS, ext4, plain directory and iSCSI. All libvirt objects are configured via XML description files, and storage pools are no different in this regard. For an iSCSI storage pool there are three important pieces of information to provide:
    • The target path - this determines how libvirt will expose device paths for the pool. Paths like /dev/sda and /dev/sdb are not an ideal choice as they can change between reboots, and can change across machines within a cluster; in other words, the names are assigned on a first come, first served basis by the kernel. It is strongly recommended to use the /dev/disk/by-path format. This results in a consistent naming scheme across all machines.
    • The host name - this is simply the fully-qualified DNS name of the iSCSI server.
    • The source path - this is the iSCSI qualified name (IQN) seen in the previous setup procedure (iqn.2004-04.rhel:rhel5:iscsi.kvmguest).
    Although your environment will likely be different, the following text is what an iSCSI configuration will look like:
    <pool type='iscsi'>
        <name>kvmguest</name>
        <source>
            <host name='myiscsi.example.com'/>
            <device path='iqn.2004-04.rhel:rhel5:iscsi.kvmguest'/>
        </source>
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
    
    Save this XML code to a file named iscsirhel5.xml and load it into libvirt using the pool-define command:
    # virsh pool-define iscsirhel5.xml
    Pool kvmguest defined from iscsirhel5.xml
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    kvmguest             inactive   no
    
  2. Starting the storage pool

    The configuration is saved, but the iSCSI target has not yet been logged into, so no LUNs will be visible on the host at this point. Use the pool-start command the make the LUNs visible with the vol-list command.
    # virsh pool-start kvmguest
    Pool kvmguest started
    
    # virsh vol-list kvmguest
    Name                 Path
    -----------------------------------------
    10.0.0.1             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    10.0.0.2             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2
    
  3. Querying LUN information

    Further information about each LUN can be obtained using the vol-info and vol-dumpxml commands:
    # virsh vol-info /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    
    Name:           10.0.0.1
    Type:           block
    Capacity:       10.00 GB
    Allocation:     10.00 GB
    
    
    # virsh vol-dumpxml /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    <volume>
      <name>10.0.0.1</name>
      <key>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1</key>
      <source>
      </source>
      <capacity>10737418240</capacity>
      <allocation>10737418240</allocation>
      <target>
        <path>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2</path>
        <format type='unknown'/>
        <permissions>
          <mode>0660</mode>
          <owner>0</owner>
          <group>6</group>
          <label>system_u:object_r:fixed_disk_device_t:s0</label>
        </permissions>
      </target>
    </volume>
    
  4. Activating the storage at boot time

    If everything is configured properly, the pool can be set to start automatically upon booting of the host:
    # virsh pool-autostart kvmguest
    Pool kvmguest marked as autostarted
    
  5. Provisioning a guest on iSCSI

    The virt-install command can be used to install new guests from the command line. The --disk argument can take the name of a storage pool, followed by the name of any contained volumes. Continuing this example, the following command will begin the installation of a guest with two disks; the first disk is the root file system, the second disk can be shared between multiple guests for common data:
    # virt-install --accelerate --name rhelx86_64 --ram 800 --vnc --disk \ vol=kvmguest/10.0.0.1 --disk vol=kvmguest/10.0.0.2,perms=sh --pxe
    
    Once this rhelx86_64 guest is installed, the following command and output shows the XML that virt-install used to associate the guest with the iSCSI LUNs:
    # virsh dumpxml rhelx86_64
    
    <domain type='kvm' id='4'>
      <name>rhelx86_64</name>
      <uuid>ad8961e9-156f-746f-5a4e-f220bfafd08d</uuid>
      <memory>819200</memory>
      <currentMemory>819200</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='rhel'>hvm</type>
        <boot dev='network'/>
      </os>
      <features>
        <acpi/>
        <apic/>
        <pae/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>destroy</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/libexec/qemu-kvm</emulator>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1'/>
          <target dev='hda' bus='ide'/>
          <alias name='ide0-0-0'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2'/>
          <target dev='hdb' bus='ide'/>
          <shareable/>
          <alias name='ide0-0-1'/>
          <address type='drive' controller='0' bus='0' unit='1'/>
        </disk>
        <controller type='ide' index='0'>
          <alias name='ide0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='network'>
          <mac address='52:54:00:0a:ca:84'/>
          <source network='default'/>
          <target dev='vnet1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </interface>
        <serial type='pty'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </serial>
        <console type='pty' tty='/dev/pts/28'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <alias name='video0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
      </devices>
    </domain>
    
    There are two important items of note in this output:
    • The guest uses the large /dev/disk/by-path paths to refer to the LUNs. As described earlier, this is so that file names and paths will remain constant.
    • The second disk has the <shareable/> flag set. Critical for the disk to be safely shared between guests, this ensures that the SELinux labelling will be appropriate for multiple guests to access the disk and that all I/O caching is disabled on the host.
For migration of guests between hosts to succeed, some form of shared storage is required. Although NFS is often used for this purpose, the lack of SELinux labelling for NFS means there is limited sVirt protection between guests. This lack of sVirt support could allow one guest to use another guest's disks, which is usually undesirable.
Using iSCSI provides full sVirt isolation between guests to the same degree of non-shared storage.

Часть VI. Подробнее о виртуализации

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

Последующие главы содержат подробное описание команд виртуализации, системных утилит и приложений в составе Red Hat Enterprise Linux для пользователей, интересующихся расширенными возможностями.

Глава 24. Утилиты виртуализации

Далее приведен список инструментов для управления виртуализацией, отладки, а также сетевых утилит, которые используются в системах с Xen.
Утилиты системного администрирования
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
Расширенные утилиты отладки
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Сетевое окружение
brtcl
  • # brctl show
    bridge name  bridge id            STP enabled    interfaces
    xenbr0       8000.feffffffffff    no             vif13.0
    						 pdummy0
                                                     vif0.0
    
  • # brctl showmacs xenbr0
    port no  mac addr                is local?       aging timer
      1      fe:ff:ff:ff:ff:ff       yes             0.00
    
  • # brctl showstp xenbr0
    xenbr0
    bridge id              8000.feffffffffff
    designated root        8000.feffffffffff
    root port              0                    path cost                 0
    max age                20.00                bridge max age            20.00
    hello time             2.00                 bridge hello time         2.00
    forward delay          0.00                 bridge forward delay      0.00
    aging time            300.01
    hello timer            1.43                 tcn timer                 0.00
    topology change timer  0.00                 gc timer                  0.02
    flags
    
    vif13.0 (3)
    port id                8003                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8003                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    pdummy0 (2)
    port id                8002                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8002                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    vif0.0 (1)
    port id                8001                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8001                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
  • ifconfig
  • tcpdump
Утилиты KVM
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Утилиты Xen
  • xentop
  • xm dmesg
  • xm log

Глава 25. Управление виртуальными машинами с помощью virsh

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

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

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

Подключение к гипервизору
Подключение к сеансу гипервизора с помощью virsh :
# virsh connect {hostname OR URL}
где <узел> — имя машины гипервизора. Чтобы начать сеанс в режиме чтения, добавьте параметр -readonly.
Создание XML-файла конфигурации виртуальной машины
Output a guest's XML configuration file with virsh:
# 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 Editing a guest's configuration file. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to Раздел 33.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
Editing a guest's configuration file
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
This restarts the saved guest, which may take some time. The guest's name and UUID are preserved but are allocated for a new id.
Завершение работы виртуальной машины
Команда завершения работы:
# virsh shutdown {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_shutdown parameter in the guest's configuration file.
Перезагрузка виртуальной машины
Команда перезагрузки:
#virsh reboot {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_reboot element in the guest's configuration file.
Принудительная остановка виртуальной машины
Команда принудительной остановки:
# 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
Получение информации о виртуальной машине
Using virsh with the guest's domain ID, domain name or UUID you can display information on the specified guest:
# 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
Столбец «State» может содержать следующие значения:
  • 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 vcpu cpulist
The domain-id parameter is the guest's ID number or name.
Параметр VCPU является обязательным и определяет число выделенных гостю виртуальных процессоров.
список_CPU — список идентификаторов сопоставленных физических процессоров, разделенных запятой.
Изменение числа виртуальных процессоров
Команда изменения числа процессоров для домена:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
Обратите внимание, что заданное число не может превышать значение, определенное при создании виртуальной машины.
Изменение выделенного объема памяти
To modify a guest's memory allocation with virsh :
# 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 не является обязательным.
Замените виртуальная_машина именем виртуальной машины, которую вы планируете перенести на другой узел.
Вместо URL укажите ссылку на принимающий узел или его имя. Требования к принимающей системе:
  • должна быть той же версии Red Hat Enterprise Linux, что и отправляющая система;
  • должна использовать тот же гипервизор;
  • в ней должна работать служба libvirt.
При запуске команды потребуется ввести пароль root для доступа к принимающей системе.
Управление виртуальными сетями
В этой секции будет рассмотрены управляющие команды 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 имя_неактивной_сети — удаление определения неактивной сети.

Глава 26. Управление виртуальными машинами с помощью менеджера виртуальных машин (virt-manager)

Данная глава содержит описание элементов интерфейса менеджера виртуальных машин: окон, диалогов, управляющих компонентов.
virt-manager предоставляет графический интерфейс для доступа к гипервизорам и виртуальным машинам в локальной и удаленных системах. С помощью virt-manager можно создать и полностью виртуализированные, и паравиртуализированные виртуальные машины. Кроме того, virt-manager выполняет управляющие функции:
  • выделение памяти;
  • выделение виртуальных процессоров;
  • мониторинг производительности;
  • сохранение и восстановление, приостановка и возобновление работы, запуск и завершение работы виртуальных машин;
  • доступ к текстовой и графической консоли;
  • автономная и живая миграция.

26.1. The Add Connection window

Это окно появится первым и предложит выбрать сеанс гипервизора. Непривилегированные пользователи смогут запустить сеанс в режиме чтения, а пользователь root может получить полный доступ. Обычно в качестве гипервизора можно выбрать локальный узел Xen или QEMU (при наличии KVM).
Окно соединений менеджера виртуальных машин
Рисунок 26.1. Окно соединений менеджера виртуальных машин

26.2. Главное окно менеджера виртуальных машин

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
Главное окно менеджера виртуальных машин
Рисунок 26.2. Главное окно менеджера виртуальных машин

26.3. The guest Overview tab

The Overview tab displays graphs and statistics of a guest's live resource utilization data available from virt-manager. The UUID field displays the globally unique identifier for the virtual machines.
The Overview tab
Рисунок 26.3. The Overview tab

26.4. Графическая консоль виртуальной машины

This window displays a virtual machine's graphical console. Para-virtualized and fully virtualized guests use different techniques to export their local virtual framebuffers, but both technologies use VNC to make them available to the Virtual Machine Manager's console window. If your virtual machine is set to require authentication, the Virtual Machine Graphical console prompts you for a password before the display appears.
Окно графической консоли
Рисунок 26.4. Окно графической консоли

Замечание относительно безопасности и VNC

VNC is considered insecure by many security experts, however, several changes have been made to enable the secure usage of VNC for virtualization on Red Hat enterprise Linux. The guest machines only listen to the local host (dom0)'s loopback address (127.0.0.1). This ensures only those with shell privileges on the host can access virt-manager and the virtual machine through VNC.
Remote administration can be performed following the instructions in Глава 22, Удаленное управление виртуальными машинами. TLS can provide enterprise level security for managing guest and host systems.
Your local desktop can intercept key combinations (for example, Ctrl+Alt+F11) to prevent them from being sent to the guest machine. You can use the virt-manager sticky key capability to send these sequences. To use this capability, you must press any modifier key (Ctrl or Alt) 3 times and the key you specify gets treated as active until the next non-modifier key is pressed. You can then send Ctrl-Alt-F11 to the guest by entering the key sequence 'Ctrl Ctrl Ctrl Alt+F1'.

Примечание

Due to a limitation of virt-manager, it is not possible to use this sticky key feature to send a Sysrq key combination to a guest.

26.5. Запуск virt-manager

Чтобы начать сессию менеджера виртуальных машин, в меню приложений выберите Система, затем Virtual Machine Manager (virt-manager).
Появится главное окно менеджера виртуальных машин.
Запуск virt-manager
Рисунок 26.5. Запуск virt-manager

Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command:
ssh -X host's address[remotehost]# virt-manager
Using ssh to manage virtual machines and hosts is discussed further in Раздел 22.1, «Удаленное управление с помощью SSH».

26.6. Восстановление сохраненной машины

Все установленные в системе виртуальные машины показаны в главном окне менеджера. Исходная система обозначена как Domain0. Если список пуст, это значит, что в настоящий момент нет работающих машин.
Последовательность действий при восстановлении ранее сохраненной сессии:
  1. В меню Файл (File) выберите Восстановить сохраненную машину (Restore saved machine).
    Восстановление виртуальной машины
    Рисунок 26.6. Восстановление виртуальной машины

  2. Появится окно восстановления.
  3. Перейдите к каталогу, содержащему файл сохраненного сеанса, и выберите файл.
  4. Нажмите Открыть (Open).
Виртуальная система появится в главном окне менеджера.
Восстановленный сеанс виртуальной машины
Рисунок 26.7. Восстановленный сеанс виртуальной машины

26.7. Просмотр информации о виртуальной машине

С помощью менеджера виртуальных машин можно получить доступ к подробной информации о всех виртуальных машинах.
To view a virtual system's details:
  1. В главном окне выберите виртуальную машину.
    Выбор виртуальной машины
    Рисунок 26.8. Выбор виртуальной машины

  2. From the Virtual Machine Manager Edit menu, select Machine Details (or click the Details button on the bottom of the Virtual Machine Manager main window).
    Displaying the overview window
    Рисунок 26.9. Displaying the overview window

    On the Virtual Machine window, click the Overview tab.
    The Overview tab summarizes CPU and memory usage for the virtualized guest you specified.
    Обзор информации о виртуальной машине
    Рисунок 26.10. Обзор информации о виртуальной машине

  3. On the Virtual Machine window, click the Hardwaretab.
    Обзор информации об оборудовании
    Рисунок 26.11. Обзор информации об оборудовании

  4. Для просмотра или изменения числа виртуальных процессоров выберите Процессор (Processor).
    Панель распределения процессоров
    Рисунок 26.12. Панель распределения процессоров

  5. Для просмотра или изменения распределения ресурсов памяти выберите Память (Memory).
    Панель распределения ресурсов памяти
    Рисунок 26.13. Панель распределения ресурсов памяти

  6. Для просмотра или изменения дисковой конфигурации выберите Диск (Disk).
    Панель дисковой конфигурации
    Рисунок 26.14. Панель дисковой конфигурации

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Панель сетевой конфигурации
    Рисунок 26.15. Панель сетевой конфигурации

26.8. Мониторинг состояния

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. В меню Правка (Edit) выберите Параметры (Preferences).
    Изменение параметров гостевой машины
    Рисунок 26.16. Изменение параметров гостевой машины

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Настройка мониторинга состояния
    Рисунок 26.17. Настройка мониторинга состояния

26.9. Просмотр идентификаторов виртуальных машин

Порядок действий при просмотре идентификаторов для всех виртуальных машин в системе:
  1. В меню Вид (View) установите флажок ID домена (Domain ID).
    Выбор просмотра идентификаторов
    Рисунок 26.18. Выбор просмотра идентификаторов

  2. Менеджер покажет идентификаторы всех доменов в системе.
    Просмотр идентификаторов доменов
    Рисунок 26.19. Просмотр идентификаторов доменов

26.10. Displaying a guest's status

Порядок действий при просмотре состояния всех виртуальных машин в системе:
  1. В меню Вид (View) установите флажок Состояние (Status).
    Selecting a virtual machine's status
    Рисунок 26.20. Selecting a virtual machine's status

  2. Менеджер покажет состояние всех виртуальных машин в системе.
    Displaying a virtual machine's status
    Рисунок 26.21. Displaying a virtual machine's status

26.11. Просмотр виртуальных процессоров

Порядок действий при просмотре виртуальных процессоров для всех виртуальных машин в системе:
  1. В меню Вид (View) установите флажок Виртуальные процессоры (Virtual CPUs).
    Выбор просмотра виртуальных процессоров
    Рисунок 26.22. Выбор просмотра виртуальных процессоров

  2. Менеджер покажет список виртуальных процессоров для всех виртуальных машин.
    Просмотр виртуальных процессоров
    Рисунок 26.23. Просмотр виртуальных процессоров

26.12. Просмотр информации о занятости процессора

Порядок действий при просмотре информации о занятости процессоров:
  1. В меню Вид (View) установите флажок Использование процессора (CPU Usage).
    Выбор просмотра сведений о занятости процессора
    Рисунок 26.24. Выбор просмотра сведений о занятости процессора

  2. Менеджер покажет информацию о занятости ресурсов процессоров (в процентах) для всех виртуальных машин в системе.
    Просмотр информации о занятости процессора
    Рисунок 26.25. Просмотр информации о занятости процессора

26.13. Просмотр информации о занятости памяти

Порядок действий при просмотре информации о занятости ресурсов памяти:
  1. В меню Вид (View) установите флажок Использование памяти (Memory Usage).
    Выбор просмотра сведений о занятости памяти
    Рисунок 26.26. Выбор просмотра сведений о занятости памяти

  2. Менеджер покажет сведения о занятости ресурсов памяти (в процентах) для всех виртуальных машин в системе.
    Просмотр информации о занятости памяти
    Рисунок 26.27. Просмотр информации о занятости памяти

26.14. Управление виртуальной сетью

Порядок действий при настройке виртуальной сети в системе:
  1. В меню Правка (Edit) выберите Параметры хоста (Host Details).
    Selecting a host's details
    Рисунок 26.28. Selecting a host's details

  2. В открывшемся окне перейдите на вкладку Виртуальные сети (Virtual Networks).
    Окно параметров виртуальной сети
    Рисунок 26.29. Окно параметров виртуальной сети

  3. Доступные виртуальные сети будут перечислены в левой части окна. Выберите сеть для доступа к ее настройкам.

26.15. Создание виртуальной сети

Порядок действий при создании виртуальной сети:
  1. Open the Host Details menu (refer to Раздел 26.14, «Управление виртуальной сетью») and click the Add button.
    Окно параметров виртуальной сети
    Рисунок 26.30. Окно параметров виртуальной сети

    В открывшемся окне нажмите кнопку продолжения.
    Создание виртуальной сети
    Рисунок 26.31. Создание виртуальной сети

  2. Введите имя для новой сети нажмите Далее (Forward).
    Присвоение имени сети
    Рисунок 26.32. Присвоение имени сети

  3. Введите пространство адресов IPv4 для виртуальной сети и нажмите Далее (Forward).
    Выбор пространства адресов IPv4
    Рисунок 26.33. Выбор пространства адресов IPv4

  4. Укажите диапазон DHCP для вашей виртуальной сети, задав начальный и конечный адрес. Нажмите кнопку продолжения.
    Выбор диапазона DHCP
    Рисунок 26.34. Выбор диапазона DHCP

  5. Выберите способ подключения виртуальной сети к физической.
    Подключение к физической сети
    Рисунок 26.35. Подключение к физической сети

    Если вы выбрали Перенаправление в физическую сеть (Forwarding to physical network), в поле Назначение (Destination) выберите либо NAT на любое физическое устройство (NAT to any physical device), либо NAT на физическое устройство eth0 (NAT to physical device eth0).
    Нажмите кнопку продолжения.
  6. Все готово для создания сети. Проверьте настройки и нажмите Готово (Finish).
    Все готово для создания сети
    Рисунок 26.36. Все готово для создания сети

  7. Сведения о новой виртуальной сети можно получить на вкладке Виртуальные сети (Virtual Network) меню Параметры хоста (Host Details).
    Новая виртуальная сеть теперь доступна
    Рисунок 26.37. Новая виртуальная сеть теперь доступна

Глава 27. Обзор команд xm

xm позволяет управлять гипервизором Xen. И хоть большинство управляющих операций осуществляется с помощью libvirt, virt-manager или virsh, иногда может понадобиться прибегнуть к помощи xm. Однако не стоит этим злоупотреблять, так как xm не проверяет ошибки.
Существует несколько функций, которые на сегодняшний день недоступны менеджеру virt-manager, поэтому на помощь приходит xm. Стоит заметить, что некоторые параметры для других реализаций xm не будут работать в Red Hat Enterprise Linux 5. Ниже приведены действительные и рабочие параметры.

Предупреждение

Настоятельно рекомендуется пользоваться virsh или virt-manager, а не xm, так как xm не проверяет ошибки, в том числе в файлах конфигурации, а ошибки, в свою очередь, могут нарушить работу системы и виртуальных машин. Также стоит избегать редактирования файлов конфигурации Xen вручную. Приведенная в этой главе информация предназначена для ознакомления; мы не несем ответственность за последствия изменений файлов
Основные управляющие параметры
Наиболее распространенные команды xm:
  • xm help [--long] покажет доступные параметры и справку.
  • xm list покажет активные домены:
    $ xm list
    Name                                ID  Mem(MiB)   VCPUs      State      Time(s)
    Domain-0                            0     520       2         r-----     1275.5
    r5b2-mySQL01                       13     500       1         -b----       16.1
    
  • xm create [-c] DomainName/ID: start a virtual machine. If the -c option is used, the start up process will attach to the guest's console.
  • xm console DomainName/ID: attach to a virtual machine's console.
  • xm destroy имя_домена/ID останавливает работу виртуальной машины.
  • xm reboot имя_домена/ID перезагружает виртуальную машину, при этом корректно завершая работу и запуская процесс заново.
  • xm shutdown имя_домена/ID корректно завершает работу виртуальной машины.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Параметры управления ресурсами
Для управления ресурсами используются следующие команды xm:
  • xm mem-set
  • xm vcpu-list показывает список соответствий виртуальных процессоров физическим.
    $ xm vcpu-list
    Name                          ID  VCPUs   CPU State  Time(s)  CPU Affinity
    Domain-0                       0    0      0    r--   708.9    any cpu
    Domain-0                       0    1      1   -b-    572.1    any cpu
    r5b2-mySQL01                  13    0      1   -b-     16.1    any cpu
    
  • xm vcpu-pin
  • xm vcpu-set
  • xm sched-credit показывает параметры планировщика для заданного домена:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Параметры мониторинга и диагностики проблем
Для мониторинга и диагностики проблем используются следующие команды xm:
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • xm uptime показывает время работы виртуальных машин и узлов:
    $ xm uptime
    Name                       ID  Uptime
    Domain-0                    0  3:42:18
    r5b2-mySQL01               13  0:06:27
    
  • xm sysrq
  • xm dump-core
  • xm rename
  • xm domid
  • xm domname
Неподдерживаемые опции
xm vnet-list в настоящее время не поддерживается.

Глава 28. Настройка параметров загрузки ядра Xen

Программа GRUB (GRand Unified Bootloader) позволяет выбрать операционную систему или ядро для загрузки и передать параметры ядру. Файл конфигурации GRUB /boot/grub/grub.conf используется для создания меню доступных операционных систем. После установки пакета kernel-xen сценарий добавит запись kernel-xen в файл конфигурации GRUB. Таким образом, по умолчанию будет загружено ядро kernel-xen. Чтобы это изменить или добавить дополнительные параметры, отредактируйте файл grub.conf:
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Если вы настроили GRUB подобным образом, то будет загружен гипервизор, образ initrd и ядро Linux. Поскольку строка kernel находится в начале, ядро будет загружено в память первым. Загрузчик отправляет аргументы командной строки гипервизору и ядру Linux, а также их получает. Следующий пример демонстрирует, как можно ограничить объем памяти ядра домена Dom0 (800 мегабайт):
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5 dom0_mem=800M
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Параметры, которые можно использовать для настройки гипервизора виртуализации:
mem
Ограничивает объем памяти, выделяемый ядру гипервизора.
com1=115200, 8n1
Определяет использование первого последовательного порта в качестве последовательной консоли. В этом случае com2 назначается следующему порту и т.п.
dom0_mem
Ограничивает доступный гипервизору объем памяти.
dom0_max_vcpus
Ограничивает число доступных домену 0 процессоров.
acpi
Переключение между гипервизором ACPI и гипервизором c доменом 0. Может принимать значения:
/*   ****  Linux config options: propagated to domain0  ****/
/*   "acpi=off":      Disables both ACPI table parsing and interpreter.   */
/*   "acpi=force":    Overrides the disable blacklist.                    */
/*   "acpi=strict":   Disables out-of-spec workarounds.                   */
/*   "acpi=ht":       Limits ACPI from boot-time to enable HT.            */
/*   "acpi=noirq":    Disables ACPI interrupt routing.                    */
noacpi
Отключает ACPI для доставки прерываний.

Глава 29. Настройка ELILO

Загрузчик ELILO используется в EFI-системах, в частности Itanium®. Аналогично GRUB в системах x86 и x86-64, ELILO позволяет пользователю выбрать ядро для загрузки непосредственно в процессе загрузки системы и передать аргументы ядру. Файл конфигурации ELILO расположен в загрузочном разделе и ему соответствует символьная ссылка /etc/elilo.conf. Этот файл содержит список глобальных параметров и секции образов. При установке пакета kernel-xen сценарий пост-установки добавит соответствующую секцию в elilo.conf.

ELILO

Приведенная здесь информация о ELILO применима для архитектур Intel Itanium с ядром Xen.
Файл конфигурации ELILO состоит из двух секций:
  • Глобальные параметры, которые определяют поведение ELILO. Обычно в изменении стандартных значений нет необходимости.
  • Секции образов позволяют определять метод и параметры загрузки.
Here is a sample image stanza in elilo.conf:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="-- rhgb quiet"
The image parameter indicates the following lines apply to a single boot selection. This stanza defines a hypervisor (vmm), initrd, and command line arguments (read-only, root and append) to the hypervisor and kernel. When ELILO is loaded during the boot sequence, the image is labeled linux.
ELILO преобразует параметр read-only в аргумент командной строки ro, что позволяет подключить корневую файловую систему в режиме чтения, до тех пор пока initscripts не смонтирует ее в режиме чтения и записи. ELILO скопирует строку root в командную строку и объединит результат со значением параметра append:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
Для отделения параметров гипервизора от параметров ядра используется разделитель --. Сначала указываются аргументы гипервизора, затем --, а потом следуют аргументы ядра.

Техническое замечание

ELILO передаст гипервизору всю командную строку. Гипервизор, в свою очередь, разделит ее содержимое и передаст ядру предназначенные ему параметры.
Дополнительные параметры гипервизора можно указать перед разделителем --. Пример параметра памяти гипервизора (mem) и параметра ядра quiet:
append="dom0_mem=2G -- quiet"
Параметры гипервизора ELILO
ПараметрОписание
mem=Параметр mem определяет максимальный размер ОЗУ, доступный гипервизору. Дополнительная память в системе будет проигнорирована. Для указания единиц измерения можно использовать B (байты), K (килобайты), M (мегабайты), G (гигабайты). Если единицы не заданы, будет подразумеваться объем памяти, заданный в килобайтах.
dom0_mem=dom0_mem= задает размер ОЗУ, выделяемый домену dom0. Red Hat Enterprise Linux 5.2 в компьютерах Itanium® по умолчанию использует значение 4G.
dom0_max_vcpus=dom0_max_vcpus= определяет число процессоров, которое будет выделено гипервизору. По умолчанию Red Hat Enterprise Linux 5.2 в компьютерах Itanium® использует значение 4.
com1=<baud>,DPS,<io_base>,<irq>com1= позволяет определить параметры для первой последовательной шины. Пример: com1=9600,8n1,0x408,5. Параметры io_base и irq можно оставить как есть. Значение auto параметра baud позволит сохранить настройки загрузчика. com1 можно не заполнять, если конфигурация EFI или ELILO содержит его глобальные настройки.
com2=<baud>,DPS,<io_base>,<irq>Настройте параметры для второй последовательной шины (см. описание параметров com1 выше).
console=<specifier_list>console содержит перечень параметров консоли Xen, разделенных запятой. Параметры могут включать vga, com1, com2. Эту настройку следует опустить, так как гипервизор попробует унаследовать установки консоли EFI.

Подробнее о параметрах ELILO

Полный список параметров ELILO можно найти на странице XenSource.
Модифицированный пример приведенной выше конфигурации с добавлением параметров выделения процессоров и добавления памяти для гипервизора:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="dom0_mem=2G dom0_max_vcpus=2 --"
В этом примере удален параметр ядра «rhgb quiet», чтобы вывод ядра и initscript направлялся на консоль. Обратите внимание, что разделитель все так же используется для корректной интерпретации аргументов гипервизора.

Глава 30. libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
Таблица 30.1. libvirt configuration files
Item Description
pae
Specifies the physical address extension configuration data.
apic
Specifies the advanced programmable interrupt controller configuration data.
memory
Specifies the memory size in megabytes.
vcpus
Specifies the numbers of virtual CPUs.
console
Specifies the port numbers to export the domain consoles to.
nic
Specifies the number of virtual network interfaces.
vif
Lists the randomly-assigned MAC addresses and bridges assigned to use for the domain's network addresses.
disk
Lists the block devices to export to the domain and exports physical devices to domain with read only access.
dhcp
Enables networking using DHCP.
netmask
Specifies the configured IP netmasks.
gateway
Specifies the configured IP gateways.
acpi
Specifies the advanced configuration power interface configuration data.

Глава 31. Файлы конфигурации Xen

Red Hat Enterprise Linux uses libvirt configuration files for most tasks. Some users may need Xen configuration files which contain the following standard variables. Configuration items within these files must be enclosed in single quotes('). These configuration files reside in the /etc/xen directory.
The table below, Таблица 31.1, «Параметры файла конфигурации Xen», is formatted output from xm create --help_config.
Таблица 31.1. Параметры файла конфигурации Xen
Parameter
Description
vncpasswd=ПАРОЛЬ Пароль для доступа к консоли VNC в домене HVM.
vncviewer=no | yes Запуск vncviewer для прослушивания сервера vnc в домене. Адрес vncviewer будет передан домену с помощью параметра VNC_SERVER=<узел>:<порт>. VNC использует порт 5500 + DISPLAY. По возможности выбирается значение с незанятым портом. Возможно, если vnc=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=ИМЯ Уникальное имя домена.
bootloader=ФАЙЛ Путь к загрузчику.
bootargs=АРГУМЕНТЫ Аргументы для передачи загрузчику.
bootentry=АРГУМЕНТ Устаревший параметр. Его заменил bootargs.
kernel=ФАЙЛ Путь к образу ядра.
ramdisk=ФАЙЛ Путь к RAM-диску.
features=ВОЗМОЖНОСТИ Активируемые в гостевом ядре возможности.
builder=ФУНКЦИЯ Функция создания домена.
memory=ОБЪЕМ Объем памяти домена в мегабайтах.
maxmem=ОБЪЕМ Максимальный объем памяти в мегабайтах.
shadow_memory=ОБЪЕМ Объем теневой памяти домена в мегабайтах.
cpu=ПРОЦЕССОР Процессор, на базе которого создан виртуальный процессор VCPU0.
cpus=ПРОЦЕССОРЫ Процессоры, на которых будет выполняться домен.
pae=PAE Включить/отключить расширение ядресов PAE домена HVM.
acpi=ACPI Включить/отключить ACPI домена HVM.
apic=APIC Включить/отключить APIС домена HVM.
vcpus=ЧИСЛО Число виртуальных процессоров в домене.
cpu_weight=ВЕС Set the new domain's cpu weight. WEIGHT is a float that controls the domain's share of the cpu.
restart=onreboot | always | never Устаревший параметр, определявший, нужно ли перезапускать домен при выходе. Вместо него используйте on_poweroff, on_reboot, on_crash. Значения этого параметра: onreboot — перезапускать при выходе с кодом reboot; always — всегда перезапускать при выходе и игнорировать код завершения; never — не перезапускать при выходе и игнорировать код завершения.
on_poweroff=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'poweroff'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_reboot=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'reboot'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_crash=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'crash'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
blkif=no | yes Рассматривать домен как блочное устройство.
netif=no | yes Рассматривать домен как физическую основу для сетевого интерфейса.
tpmif=no | yes Рассматривать домен как физическую основу для интерфейса TPM.
disk=phy:DEV,VDEV,РЕЖИМ[,ДОМЕН] Добавление дискового устройства в домен. Физическое устройство (DEV) будет экспортироваться в домен как VDEV. Если переменная РЕЖИМ имеет значение r, то диск будет доступен только для чтения, а w — для чтения и записи. ДОМЕН определяет домен драйверов для диска. Эта опция может быть указана многократно для различных дисков.
pci=BUS:DEV.FUNC Добавление устройства PCI с заданными в шестнадцатеричном формате параметрами. Пример: pci=c0:02.1a. Параметр может быть указан многократно для добавления нескольких устройств PCI.
ioports=ОТ[-ДО] Добавление диапазона ввода/вывода с заданными границами (в шестнадцатеричном формате). Пример: ioports=02f8-02ff. Параметр может быть указан многократно для добавления нескольких диапазонов.
irq=IRQ Добавление прерывания. Пример: irq=7. Параметр может быть указан многократно для добавления нескольких прерываний.
usbport=ПУТЬ Добавление порта USB. Параметр может быть указан многократно для добавления нескольких портов.
vfb=type={vnc,sdl}, vncunused=1, vncdisplay=N,
vnclisten=ADDR, display=DISPLAY,
xauthority=XAUTHORITY, vncpasswd=PASSWORD,
keymap=РАСКЛАДКА
Make the domain a framebuffer backend. The backend type should be either sdl or vnc. For type=vnc, connect an external vncviewer. The server will listen on ADDR (default 127.0.0.1) on port N+5900. N defaults to the domain id. If vncunused=1, the server will try to find an arbitrary unused port above 5900. For type=sdl, a viewer will be started automatically using the given DISPLAY and XAUTHORITY, which default to the current user's ones.
vif=type=TYPE, mac=MAC, bridge=BRIDGE, ip=IPADDR,
script=СЦЕНАРИЙ, backend=ДОМЕН, vifname=ИМЯ
Добавление сетевого интерфейса с заданным мостом и адресом MAC. vif настраивается при вызове специального сценария конфигурации. Если тип не указан, будет использоваться netfront, а не ioemu. Если адрес MAC не задан, будет использоваться случайно выбранный адрес MAC. Если мост не определен, будет использоваться первый найденный мост. Если же не задан сценарий, будет использоваться стандартный сценарий. Если не задан параметр backend, будет использоваться стандартный домен драйверов, и если не задан параметр vifname, виртуальному интерфейсу будет присвоено имя vifD.N (где D — идентификатор домена, а N — идентификатор интерфейса). Этот параметр может быть указан многократно для добавления нескольких vif, что, в свою очередь, скажется на числе интерфейсов.
vtpm=instance=ЭКЗЕМПЛЯР,backend=ДОМЕН Добавление интерфейса TPM. Заданный экземпляр будет использоваться в качестве виртуального экземпляра TPM. Заданный номер представляет собой лишь предпочитаемый номер экземпляра. В ходе работы сценарий определит, какой номер экземпляра будет назначен домену. Соответствие между виртуальной машиной и номером экземпляра TPM можно найти в /etc/xen/vtpm.db.
access_control=policy=ПОЛИТИКА,label=МЕТКА Добавление метки безопасности и соответствующей политики безопасности. Локальное соответствие ssid будет рассчитано при запуске или возобновлении работы домена. На данном этапе политика проверяется в соответствии с активной политикой. Таким образом, облегчается процесс миграции с сохранением и последующим восстановлением доменов. Дополнительно, локальные метки будут автоматически созданы в системе, где домен запускается или возобновляет свою работу.
nics=ЧИСЛО Устаревший параметр, вместо него используются пустые записи vif. Определяет число сетевых интерфейсов. Используйте параметр vif для определения настроек интерфейса, в противном случае будут применены стандартные параметры. Указание нескольких vif увеличит число интерфейсов.
root=УСТРОЙСТВО Параметр root определяется в командной строке ядра. Укажите устройство для NFS root, например, /dev/sda1 или /dev/nfs.
extra=АРГУМЕНТЫ Дополнительные аргументы для включения в командную строку ядра.
ip=IP-адрес Определяет IP-адрес интерфейса ядра.
gateway=IP-адрес Определяет IP-адрес шлюза ядра.
netmask=МАСКА Определяет IP-адрес маски сети.
hostname=ИМЯ Определяет имя узла.
interface=ИНТЕРФЕЙС Определяет имя интерфейса.
dhcp=off|dhcp Параметр dhcp ядра.
nfs_server=IP-АДРЕС Адрес NFS-сервера для NFS root.
nfs_root=ПУТЬ Путь к корневому каталогу NFS.
device_model=ФАЙЛ Путь к программе модели устройства.
fda=ФАЙЛ Путь к fda.
fdb=ФАЙЛ Путь к fdb.
serial=ФАЙЛ Путь к pty или vc.
localtime=no | yes Использование локального времени часами RTC.
keymap=ФАЙЛ Раскладка клавиатуры.
usb=no | yes Эмуляция устройств USB.
usbdevice=ИМЯ Имя добавляемого устройства USB.
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Эмуляция системы ISA.
boot=a|b|c|d Загрузочное устройство, используемое по умолчанию.
nographic=no | yes Использование графического режима.
soundhw=АУДИО Использование аудиоустройств.
vnc Определяет, будет ли модель устройства использовать VNC.
vncdisplay Дисплей VNC.
vnclisten Адрес для прослушивания сервера VNC.
vncunused Попытаться найти незанятый порт для сервера VNC. Используется, если vnc=1.
sdl Использование SDL.
display=ДИСПЛЕЙ Дисплей X11.
xauthority=XAUTHORITY Центр авторизации X11.
uuid Уникальный идентификатор UUID. Если этот параметр не задан, идентификатор будет сгенерирован случайным образом подобно генерации MAC-адесов для виртуальных сетевых интерфейсов. Значение должно быть уникально в пределах кластера.

Таблица 31.3, «Стандартные значения параметров настройки» lists all configuration parameters available, the Python parser function which sets the value and default values. The setter function gives an idea of what the parser does with the values you specify. It reads these as Python values, then feeds them to a setter function to store them. If the value is not valid Python, you get an obscure error message. If the setter rejects your value, you should get a reasonable error message, except it appears to get lost somehow, along with your bogus setting. If the setter accepts, but the value is incorrect the application may fail.
Таблица 31.2. Функции Python для установки параметров
Функция Допустимые аргументы
set_bool
Допустимые значения:
  • yes
  • y
  • no
  • yes
set_float
Accepts a floating point number with Python's float(). For example:
  • 3.14
  • 10.
  • .001
  • 1e100
  • 3.14e-10
set_int
Accepts an integer with Python's int().
set_value
Принимает любое значение Python.
append_value
Принимает любое значение Python и добавляет его к предыдущему значению, сохраненному в массиве.

Таблица 31.3. Стандартные значения параметров настройки
Parameter Функция Стандартное значение
name setter default value
vncpasswd set_value None
vncviewer set_bool None
vncconsole set_bool None
name set_value None
bootloader set_value None
bootargs set_value None
bootentry set_value None
kernel set_value None
ramdisk set_value ''
features set_value ''
builder set_value 'linux'
memory set_int 128
maxmem set_int None
shadow_memory set_int 0
cpu set_int None
cpus set_value None
pae set_int 0
acpi set_int 0
apic set_int 0
vcpus set_int 1
cpu_weight set_float None
restart set_value None
on_poweroff set_value None
on_reboot set_value None
on_crash set_value None
blkif set_bool 0
netif set_bool 0
tpmif append_value 0
disk append_value []
pci append_value []
ioports append_value []
irq append_value []
usbport append_value []
vfb append_value []
vif append_value []
vtpm append_value []
access_control append_value []
nics set_int -1
root set_value ''
extra set_value ''
ip set_value ''
gateway set_value ''
netmask set_value ''
hostname set_value ''
interface set_value "eth0"
dhcp set_value 'off'
nfs_server set_value None
nfs_root set_value None
device_model set_value ''
fda set_value ''
fdb set_value ''
serial set_value ''
localtime set_bool 0
keymap set_value ''
usb set_bool 0
usbdevice set_value ''
stdvga set_bool 0
isa set_bool 0
boot set_value 'c'
nographic set_bool 0
soundhw set_value ''
vnc set_value None
vncdisplay set_value None
vnclisten set_value None
vncunused set_bool 1
sdl set_value None
display set_value None
xauthority set_value None
uuid set_value None

Часть VII. Советы и хитрости

Советы и хитрости по улучшению производительности

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

Содержание

32. Советы и хитрости
32.1. Автоматический запуск виртуальных машин
32.2. Переключение между гипервизорами KVM и Xen
32.2.1. Хеn на KVM
32.2.2. KVM на Xen
32.3. qemu-img
32.4. Overcommitting Resources
32.5. Редактирование /etc/grub.conf
32.6. Проверка расширений виртуализации
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Создание уникального MAC-адреса
32.10. Ограничение сетевой полосы пропускания для гостя Xen
32.11. Настройка соответствий процессоров в Xen
32.12. Изменение гипервизора Xen
32.13. vsftpd
32.14. Настройка постоянства LUN
32.15. Отключение SMART-мониторинга дисков для гостевых систем
32.16. Очистка старых файлов конфигурации Xen
32.17. Настройка VNC-сервера
32.18. Дублирование файлов конфигурации виртуальных машин
32.19. Дублирование существующей виртуальной машины и ее файла конфигурации
33. Создание специализированных сценариев libvirt
33.1. Использование файлов конфигурации с помощью virsh

Глава 32. Советы и хитрости

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

32.1. Автоматический запуск виртуальных машин

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Приведенный пример использует virsh для настройки автоматического запуска виртуальной машины TestServer во время загрузки размещающей системы.
# virsh autostart TestServer
Domain TestServer marked as autostarted
Автоматический запуск виртуальной машины настроен.
Чтобы отключить автоматическую загрузку, добавьте параметр --disable:
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
Автоматический запуск виртуальной машины теперь отключен.

32.2. Переключение между гипервизорами KVM и Xen

Здесь рассматривается переключение между гипервизорами KVM и Xen
Red Hat разрешает выполнение только одного гипервизора в заданный момент времени.

Перенос виртуальных машин между гипервизорами

В настоящее время нет специальных программ для переноса виртуальных машин с Xеn на KVM и наоборот. Они должны выполняться только на гипервизоре, тип которого не отличается от типа гипервизора, на котором виртуальная машина была изначально создана.

Предупреждение

Эта возможность доступна для Intel 64 и AMD64 только в версиях, начиная с Red Hat Enterprise Linux 5.4. Другие конфигурации или версии Red Hat Enterprise Linux не поддерживаются. KVM не доступен в версиях Red Hat Enterprise Linux, предшествующих 5.4.

32.2.1. Хеn на KVM

Далее будет рассмотрен процесс изменения гипервизора Xen на KVM. Подразумевается, что пакет kernel-xen уже установлен и работает.
  1. Установите пакет KVM

    Установите пакет kvm, если он еще не установлен.
    # yum install kvm
    
  2. Проверьте версию используемого ядра

    В системе может быть установлен пакет kernel-xen, поэтому проверьте версию работающего ядра с помощью команды uname:
    $ uname -r
    2.6.18-159.el5xen
    
    То есть выполняется ядро 2.6.18-159.el5xen. Если в результате выполнения команды вы получили версию ядра, которое используется по умолчанию, а именно 2.6.18-159.el5, можно сразу перейти к пункту 3.
    1. Изменение ядра Xen на стандартное ядро

      Выбор ядра для загрузки осуществляется в файле grub.conf. Чтобы изменить используемое по умолчанию ядро, внесите изменения в /boot/grub/grub.conf.
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Обратите внимание на выражение default=1, которое определяет порядок ядра в списке. Так, в этом случае GRUB использует вторую запись, то есть ядро Xen. Измените значение на 0, чтобы использовалось первое ядро в списке:
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Перезагрузите систему с новым ядром

    Перезагрузите систему. Модуль KVM загрузится автоматически вместе с ядром. Убедитесь, что он выполняется:
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    Если список содержит модуль kvm, а также kvm_intel или kvm_amd, то все работает нормально.

32.2.2. KVM на Xen

Далее будет рассмотрен процесс изменения гипервизора KVM на Xen. Подразумевается, что пакет kvm уже установлен и работает.
  1. Установите пакеты Xen

    Установите пакеты kernel-xen и xen, если они еще не установлены.
    # yum install kernel-xen xen
    
    Пакет kernel-xen вполне может быть уже установлен, но отключен.
  2. Проверьте версию используемого ядра

    Проверьте версию работающего ядра с помощью команды uname:
    $ uname -r
    2.6.18-159.el5
    
    То есть выполняется ядро 2.6.18-159.el5, которое используется по умолчанию. Если в результате выполнения команды вы получили версию ядра, в конце имени которого есть xen (например, 2.6.18-159.el5xen), можно сразу перейти к пункту 3.
    1. Изменение стандартного ядра на ядро Xen

      Выбор ядра для загрузки осуществляется в файле grub.conf. Чтобы изменить используемое по умолчанию ядро, внесите изменения в /boot/grub/grub.conf.
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Обратите внимание на выражение default=0, которое определяет порядок ядра в списке. Так, в этом случае GRUB использует первую запись, то есть стандартное ядро. Измените значение на 1, чтобы использовалось ядро Xen:
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Перезагрузите систему с новым ядром

    Перезагрузите систему с ядром Xen. Проверьте версию с помощью команды uname:
    $ uname -r
    2.6.18-159.el5xen
    
    Если в результате выполнения команды вы получили версию ядра, в конце имени которого есть xen, значит, выполняется ядро Xen.

32.3. qemu-img

Текстовая утилита qemu-img применяется для форматирования различных файловых систем, используемых Xen и KVM. Именно с ее помощью следует выполнять форматирование образов виртуализированных гостей, дополнительных устройств хранения и сетевых хранилищ. Ниже будут рассмотрены параметры и формат qemu-img.
Форматирование и создание новых устройств и образов
Команда создания нового образа диска:
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Если задан «базовый_образ», то полученный образ будет содержать только отличия. В этом случае размер можно не указывать. Базовый образ останется неизменным до тех пор, пока вы его не измените с помощью команды «commit».
Преобразование формата существующего образа
Для преобразования формата используется опция convert.
Формат команды:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Эта команда преобразует образ диска с именем файл1 в образ файл2 в формате полученный_формат. Полученный образ может быть дополнительно зашифрован (опция -e) или сжат (опция -c).
Следует отметить, что только формат qcow поддерживает сжатие и шифрование. В случае повторной перезаписи сжатого сектора записываемые данные уже не будут сжаты.
Шифрование выполняется в формате AES с использованием 128-разрядных ключей. Для усиления защиты рекомендуется увеличить длину пароля (больше 16 символов).
Одним из достоинств преобразования образов является возможность получения небольшого образа при использовании формата, допускающего рост (например, qcow или cow). При этом пустые сектора будут исключены из полученного образа.
Получение информации об образе
Опция info утилиты qemu-img позволяет получить сведения о дисковом образе. Формат команды:
# qemu-img info [-f format] filename
В результате будут показаны сведения о запрошенном образе, в том числе зарезервированный объем на диске, а также информация о снимках виртуальных машин (если они включены в состав образа).
Поддерживаемые форматы
Формат образа обычно определяется автоматически. Поддерживаются следующие форматы:
raw
Этот формат используется по умолчанию, его достоинствами являются простота и возможность экспортирования в другие эмуляторы. Если ваша файловая система поддерживает фрагментацию (ext2 или ext3 в Linux, NTFS в Windows), только непосредственно записанные секторы будут занимать место на диске. Действительный объем пространства, занимаемый образом, можно определить с помощью команд qemu-img info или ls -ls (в Linux).
qcow2
Формат QEMU. Это наиболее гибкий формат. Его рекомендуется использовать для небольших образов (в частности, если файловая система не поддерживает фрагментацию), дополнительного шифрования AES, сжатия zlib и поддержки множества снимков VM.
qcow
Устаревший формат QEMU. Используется только в целях обеспечения совместимости со старыми версиями.
cow
Формат COW (Copy On Write). Используется только в целях обеспечения совместимости со старыми версиями. Не работает в Windows.
vmdk
Формат образов, совместимый с VMware 3 и 4.
cloop
Формат CLOOP (Compressed Loop). Его единственное применение состоит в обеспечении повторного использования сжатых напрямую образов CD-ROM, например, Knoppix CD-ROM.

32.4. Overcommitting Resources

The KVM hypervisor supports overcommitting CPUs and memory. Overcommitting is the process of allocating more virtualized CPUs or memory than there are physical resources on the system. CPU overcommit allows under-utilized virtualized servers or desktops to run on fewer servers which saves power and money.

Поддержка Xen

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
Перераспределение памяти
Большинство операционных систем и приложений не использует 100% доступной оперативной памяти. Из этого можно извлечь пользу с помощью KVM, разрешив виртуальным машинам использовать больше памяти, чем им физически доступно.
When using KVM, virtual machines operate as Linux processes. Guests on the KVM hypervisor do not have blocks of physical RAM assigned to them, instead they function as processes. Each process in a Linux system is allocated memory when it requests more memory. In a similar way, KVM allocates memory for guests when the guest requests more or less memory. The guest only uses slightly more physical memory than the virtualized operating system appears to use.
When physical memory is nearly completely used or a process is inactive for some time, Linux moves the process's memory to swap. Swap is usually a partition on a hard disk drive or solid state drive which Linux uses to extend virtual memory. Swap is significantly slower than RAM.
As KVM virtual machines are Linux processes, memory used by virtualized guests can be put into swap if the guest is idle or not in heavy use. Memory can be committed over the total size of the swap and physical RAM. This can cause issues if virtualized guests use their total RAM. Without sufficient memory and swap space for the virtual machine processes, the system can run completely out of memory, leading to the failure of one or more virtual machine processes.

Предупреждение

Если области подкачки не хватает, работа гостевых операционных систем будет принудительно завершена. Поэтому всегда нужно помнить о том, что не стоит перераспределять больше памяти, чем доступно в области подкачки.
Раздел swap используется для размещения не используемой активно памяти на жестком диске с целью повышения производительности. Размер раздела подкачки рассчитывается на основе объема оперативной памяти и коэффициента перераспределения (обычно 0.5, то есть 50%). Рекомендуется его увеличить, если вы намереваетесь использовать возможности перераспределения памяти с KVM. Таким образом, формула расчета будет выглядеть так:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
База знаний Red Hat содержит статью о том, как эффективно определить размер раздела подкачки.
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This tradeoff is often beneficial in workloads with many smaller, similar guests.
Другой способ расчета коэффициента состоит в умножении числа виртуальных машин на 10. Но это будет работать только при определенной нагрузке (если виртуализация не использует 100% ресурсов). Значение коэффициента в большинстве случаев подбирается индивидуально в процессе тестирования.
Перераспределение ресурсов виртуализированных процессоров
Гипервизор KVM поддерживает возможности перераспределения виртуализированных процессоров при условии, что это позволяет нагрузка на гостевые системы. Соблюдайте осторожность, так как приближенные к 100% нагрузки могут привести к потере запросов и недопустимо долгому времени ответа.
Процессоры проще всего перераспределять, если каждой виртуальной машине назначен только один виртуальный процессор. В этом случае планировщик Linux будет особенно эффективен. KVM сможет без проблем перераспределять до пяти процессоров виртуальных машин с неполной загрузкой.
Нельзя перераспределять ресурсы симметричных многопроцессорных гостей на ядрах, число которых превышает физическое число процессорных ядер. Так, например, виртуальная машина с четырьмя VCPU не должна выполняться на узле с процессором с двойным ядром, так как в этом случае значительно пострадает производительность.
Допускается назначение числа виртуальных процессоров, которое не превышает число физических ядер. Например, виртуальные машины с четырьмя VCPU на узле с четырьмя ядрами будут работать нормально, особенно с неполной нагрузкой.

Семь раз отмерь...

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

32.5. Редактирование /etc/grub.conf

This section describes how to safely and correctly change your /etc/grub.conf file to use the virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen kernel entry make sure you copy all of the important lines or your system will panic upon boot (initrd will have a length of '0'). If you require xen hypervisor specific values you must append them to the xen line of your grub entry.
Ниже приведен пример записи из файла grub.conf для системы, в которой выполняется пакет kernel-xen. Обратите внимание на блок текста, начинающийся строкой title и заканчивающийся следующей пустой строкой.
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

Важно

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Глава 28, Настройка параметров загрузки ядра Xen for more information on using virtualization and grub.
Так, указав «dom0_mem=256M» в строке xen файла конфигурации grub.conf, вы выделите размещающей системе 256 мегабайт памяти во время загрузки. Файл будет выглядеть так:
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro
	root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.6. Проверка расширений виртуализации

В этой секции будет рассказано, как определить, обладает ли ваша система аппаратными расширениями виртуализации. Расширения виртуализации (Intel VT или AMD-V) потребуются для полной виртуализации.

Можно ли использовать виртуализацию без расширений?

Если нет аппаратных расширений виртуализации, можно организовать паравиртуализацию с помощью пакета kernel-xen.
  1. Следующая команда проверит наличие расширений виртуализации:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • Если вывод содержит запись vmx, это значит, что процессор Intell включает расширения Intel VT. Пример:
      flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush 
      	dts acpi mmx fxsr sse sse2 ss ht  tm syscall lm constant_tsc pni monitor ds_cpl
      	vmx est tm2 cx16 xtpr lahf_lm
      
    • Следующий вывод содержит запись svm, которая обозначает наличие процессора AMD с расширениями AMD-V:
      flags   :  fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush
      	mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16
      	lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
      
    If any output is received, the processor has the hardware virtualization extensions. However in some circumstances manufacturers disable the virtualization extensions in BIOS.
    Секция flags: может повторяться для каждого гиперпотока, ядра и процессора.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Процедура 35.1, «Активация расширений виртуализации в BIOS».
  3. For users of the KVM hypervisor

    If the kvm package is installed. I As an additional check, verify that the kvm modules are loaded in the kernel:
    # lsmod | grep kvm
    
    If the output includes kvm_intel or kvm_amd then the kvm hardware virtualization modules are loaded and your system meets requirements. sudo

Additional output

If the libvirt package is installed, the virsh command can output a full list of virtualization system capabilities. Run virsh capabilities as root to receive the complete list.

32.7. Accessing data from a guest disk image

There are various methods for accessing the data from guest image files. One common method is to use the kpartx tool, covered by this section, to mount the guest file system as a loop device which can then be accessed.
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.
The libguestfs and guestfish packages, available from the EPEL repository, allow advanced modification and access to guest file systems. The libguestfs and guestfish packages are not covered in this section at this time.

Предупреждение

Guests must be offline before their files can be read. Editing or reading files of an active guest is not possible and may cause data loss or damage.
Процедура 32.1. Accessing guest image data
  1. Install the kpartx package.
    # yum install kpartx
    
  2. Use kpartx to list partition device mappings attached to a file-based storage image. This example uses a image file named guest1.img.
    # kpartx -l /var/lib/libvirt/images/guest1.img
    loop0p1 : 0 409600 /dev/loop0 63
    loop0p2 : 0 10064717 /dev/loop0 409663
    guest1 is a Linux guest. The first partition is the boot partition and the second partition is an EXT3 containing the root partition.
  3. Add the partition mappings to the recognized devices in /dev/mapper/.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
    1. Test that the partition mapping worked. There should be new devices in the /dev/mapper/ directory
      # ls /dev/mapper/
      loop0p1
      loop0p2
      
      The mappings for the image are named in the format loopXpY.
  4. Mount the loop device which to a directory. If required, create the directory. This example uses /mnt/guest1 for mounting the partition.
    # mkdir /mnt/guest1
    # mount /dev/mapper/loop0p1 /mnt/guest1 -o loop,ro
  5. The files are now available for reading in the /mnt/guest1 directory. Read or copy the files.
  6. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/tmp
  7. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be started again.
Accessing data from guest LVM volumes
Many Linux guests use Logical Volume Management (LVM) volumes. Additional steps are required to read data on LVM volumes on virtual storage images.
  1. Add the partition mappings for the guest1.img to the recognized devices in the /dev/mapper/ directory.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
  2. In this example the LVM volumes are on a second partition. The volumes require a rescan with the vgscan command to find the new volume groups.
    # vgscan
    Reading all physical volumes . This may take a while...
    Found volume group "VolGroup00" using metadata type lvm2
  3. Activate the volume group on the partition (called VolGroup00 by default) with the vgchange -ay command.
    # vgchange -ay VolGroup00
    2 logical volumes in volume group VolGroup00 now active.
  4. Use the lvs command to display information about the new volumes. The volume names (the LV column) are required to mount the volumes.
    # lvs
    LV VG Attr Lsize Origin Snap% Move Log Copy%
    LogVol00 VolGroup00 -wi-a- 5.06G
    LogVol01 VolGroup00 -wi-a- 800.00M
  5. Mount /dev/VolGroup00/LogVol00 in the /mnt/guestboot/ directory.
    # mount /dev/VolGroup00/LogVol00 /mnt/guestboot
  6. The files are now available for reading in the /mnt/guestboot directory. Read or copy the files.
  7. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/
  8. Disconnect the volume group VolGroup00
    # vgchange -an VolGroup00
    
  9. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be restarted.

32.8. Setting KVM processor affinities

This section covers setting processor and processing core affinities with libvirt for KVM guests.
By default, libvirt provisions guests using the hypervisor's default policy. For most hypervisors, the policy is to run guests on any available processing core or CPU. There are times when an explicit policy may be better, in particular for systems with a NUMA (Non-Uniform Memory Access) architecture. A guest on a NUMA system should be pinned to a processing core so that its memory allocations are always local to the node it is running on. This avoids cross-node memory transports which have less bandwidth and can significantly degrade performance.
On a non-NUMA systems some form of explicit placement across the hosts’ sockets, cores and hyperthreads may be more efficient.
Identifying CPU and NUMA topology
The first step in deciding what policy to apply is to determine the host’s memory and CPU topology. The virsh nodeinfo command provides information about how many sockets, cores and hyperthreads there are attached a host.
# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       1000 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8179176 kB
This system has eight CPUs, in two sockets, each processor has four cores.
The output shows that that the system has a NUMA architecture. NUMA is more complex and requires more data to accurately interpret. Use the virsh capabilities to get additional output data on the CPU configuration.
# virsh capabilities
<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
        <cell id='1'>
          <cpus num='4'>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
  </host>

 [ Additional XML removed ]

</capabilities>
The output shows two NUMA nodes (also know as NUMA cells), each containing four logical CPUs (four processing cores). This system has two sockets, therefore we can infer that each socket is a separate NUMA node. For a guest with four virtual CPUs, it would be optimal to lock the guest to physical CPUs 0 to 3, or 4 to 7 to avoid accessing non-local memory, which are significantly slower than accessing local memory.
If a guest requires eight virtual CPUs, as each NUMA node only has four physical CPUs, a better utilization may be obtained by running a pair of four virtual CPU guests and splitting the work between them, rather than using a single 8 CPU guest. Running across multiple NUMA nodes significantly degrades performance for physical and virtualized tasks.
Decide which NUMA node can run the guest
Locking a guest to a particular NUMA node offers no benefit if that node does not have sufficient free memory for that guest. libvirt stores information on the free memory available on each node. Use the virsh freecell command to display the free memory on all NUMA nodes.
# virsh freecell
0: 2203620 kB
1: 3354784 kB
If a guest requires 3 GB of RAM allocated, then the guest should be run on NUMA node (cell) 1. Node 0 only has 2.2GB free which is probably not sufficient for certain guests.
Lock a guest to a NUMA node or physical CPU set
Once you have determined which node to run the guest on, refer to the capabilities data (the output of the virsh capabilities command) about NUMA topology.
  1. Extract from the virsh capabilities output.
    <topology>
      <cells num='2'>
        <cell id='0'>
        <cpus num='4'>
          <cpu id='0'/>
          <cpu id='1'/>
          <cpu id='2'/>
          <cpu id='3'/>
        </cpus>
      </cell>
      <cell id='1'>
        <cpus num='4'>
          <cpu id='4'/>
          <cpu id='5'/>
          <cpu id='6'/>
          <cpu id='7'/>
        </cpus>
      </cell>
      </cells>
    </topology>
  2. Observe that the node 1, <cell id='1'>, has physical CPUs 4 to 7.
  3. The guest can be locked to a set of CPUs by appending the cpuset attribute to the configuration file.
    1. While the guest is offline, open the configuration file with virsh edit.
    2. Locate where the guest's virtual CPU count is specified. Find the vcpus element.
      <vcpus>4</vcpus>
      The guest in this example has four CPUs.
    3. Add a cpuset attribute with the CPU numbers for the relevant NUMA cell.
      <vcpus cpuset='4-7'>4</vcpus>
  4. Save the configuration file and restart the guest.
The guest has been locked to CPUs 4 to 7.
Automatically locking guests to CPUs with virt-install
The virt-install provisioning tool provides a simple way to automatically apply a 'best fit' NUMA policy when guests are created.
The cpuset option for virt-install can use a CPU set of processors or the parameter auto. The auto parameter automatically determines the optimal CPU locking using the available NUMA data.
For a NUMA system, use the --cpuset=auto with the virt-install command when creating new guests.
Tuning CPU affinity on running guests
There may be times where modifying CPU affinities on running guests is preferable to rebooting the guest. The virsh vcpuinfo and virsh vcpupin commands can perform CPU affinity changes on running guests.
The virsh vcpuinfo command gives up to date information about where each virtual CPU is running.
In this example, guest1 is a guest with four virtual CPUs is running on a KVM host.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            3
State:          running
CPU time:       0.5s
CPU Affinity:   yyyyyyyy
VCPU:           1
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           2
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           3
CPU:            2
State:          running
CPU Affinity:   yyyyyyyy
The virsh vcpuinfo output (the yyyyyyyy value of CPU Affinity) shows that the guest can presently run on any CPU.
To lock the virtual CPUs to the second NUMA node (CPUs four to seven), run the following commands.
# virsh vcpupin guest1 0 4
# virsh vcpupin guest1 1 5
# virsh vcpupin guest1 2 6
# virsh vcpupin guest1 3 7
The virsh vcpuinfo command confirms the change in affinity.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            4
State:          running
CPU time:       32.2s
CPU Affinity:   ----y---
VCPU:           1
CPU:            5
State:          running
CPU time:       16.9s
CPU Affinity:   -----y--
VCPU:           2
CPU:            6
State:          running
CPU time:       11.9s
CPU Affinity:   ------y-
VCPU:           3
CPU:            7
State:          running
CPU time:       14.6s
CPU Affinity:   -------y

32.9. Создание уникального MAC-адреса

In some case you will need to generate a new and unique MAC address for a guest. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guests. Save the script to your guest as macgen.py. Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following:
$ ./macgen.py 
00:16:3e:20:b0:11
	
#!/usr/bin/python
# macgen.py script to generate a MAC address for virtualized guests on Xen
#
import random
#
def randomMAC():
	mac = [ 0x00, 0x16, 0x3e,
		random.randint(0x00, 0x7f),
		random.randint(0x00, 0xff),
		random.randint(0x00, 0xff) ]
	return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
Другой способ генерации нового MAC-адреса
Для генерации MAC-адреса и UUID также можно использовать встроенные модули python-virtinst:
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
Приведенный выше сценарий можно сохранить в отдельный файл:
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

32.10. Ограничение сетевой полосы пропускания для гостя Xen

In some environments it may be required to limit the network bandwidth available to certain guests. This can be used to implement basic Quality of Service on a host running multiple virtual machines. By default, the guest can use any bandwidth setting available which your physical network card supports. The physical network card must be mapped to one of virtual machine's virtual network interfaces. In Xen the “rate” parameter part of the VIF entries can throttle virtualized guests.
Список переменных
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
временной интервал
Вместе с rate= можно указать временной интервал.
Изначально интервал установлен в 50 миллисекунд.
Если его уменьшить, передача будет осуществляться не такими большими частями, но при этом вырастет задержка при ожидании ответа.
Интервал в 50 миллисекунд обеспечивает баланс между задержкой и пропусканием, поэтому в большинстве случае изменять это значение не требуется.
Примеры использования параметра rate:
rate=10Mb/s
Ограничивает исходящий сетевой трафик 10 мегабайтами в секунду.
rate=250KB/s
Ограничивает исходящий сетевой трафик 250 килобайтами в секунду.
rate=10MB/s@50ms
Ограничение полосы пропускания — 10 мегабайт в секунду, при этом виртуальная машина получает блоки данных размером 50 килобайт каждые 50 миллисекунд.
Запись VIF в файле конфигурации виртуальной машины может выглядеть приблизительно так:
vif = [ 'rate=10MB/s , mac=00:16:3e:7a:55:1c, bridge=xenbr1']
This rate entry would limit the virtual machine's interface to 10MB/s for outgoing traffic

32.11. Настройка соответствий процессоров в Xen

Xen позволяет сопоставить виртуальные процессоры реальным процессорам узла, что может использоваться для распределения ресурсов между виртуальными машинами. Такой подход помогает обеспечить оптимальное использование ресурсов процессора при реализации параллельных технологий, например, гиперпоточности, использования двух ядер и др. Планировщик Xen выполняет автоматическую балансировку виртуальных процессоров для оптимизации работы системы. Также возможен перенос процессоров с тем условием, что виртуальный процессор останется сопоставлен физическому.
При выполнении интенсивных задач ввода и вывода рекомендуется выделить отдельный гиперпоток или даже процессорное ядро для домена 0.
Обратите внимание, что это обязательно для KVM, так как KVM использует стандартный планировщик ядра Linux.
Соответствия процессоров можно настроить с помощью virsh или virt-manager:
To set CPU affinities using virsh refer to Настройка соответствий виртуальных процессоров for more information.
To configure and view CPU information with virt-manager refer to Раздел 26.11, «Просмотр виртуальных процессоров» for more information.

32.12. Изменение гипервизора Xen

Managing host systems often involves changing the boot configuration file /boot/grub/grub.conf. Managing several or more hosts configuration files quickly becomes difficult. System administrators often prefer to use the 'cut and paste' method for editing multiple grub.conf files. If you do this, ensure you include all five lines in the Virtualization entry (or this will create system errors). Hypervisor specific values are all found on the 'xen' line. This example represents a correct grub.conf virtualization entry:
# boot=/dev/sda/
default=0
timeout=15
#splashimage=(hd0, 0)/grub/splash.xpm.gz

hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0, 0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
    module /vmlinuz-2.6.17-1.2519.4.21el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img
For example, to change the memory entry on your hypervisor (dom0) to 256MB at boot time, edit the 'xen' line and append it with this entry: 'dom0_mem=256M'. This example is the grub.conf with the hypervisor's memory entry modified.
# boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grubs/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed =115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0,0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
    module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.13. vsftpd

vsftpd обеспечивает защищенный доступ к установочному дереву или другим данным для паравиртуализированных гостевых систем (например, для репозиториев Red Hat Enterprise Linux 5). Если вы не установили vsftpd в процессе установки сервера, можно установить соответствующий RPM-пакет из каталога Server установочного носителя с помощью команды rpm -ivh vsftpd*.rpm (при этом RPM-пакет должен находиться в вашем текущем каталоге).
  1. To configure vsftpd, edit /etc/passwd using vipw and change the ftp user's home directory to the directory where you are going to keep the installation trees for your para-virtualized guests. An example entry for the FTP user would look like the following:
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
    
  2. Команда chkconfig --list vsftpd позволяет убедиться, что vsftpd отключен.
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. Для автоматического запуска vsftpd на уровнях выполнения 3, 4 и 5 выполните команду chkconfig --levels 345 vsftpd on.
  4. Проверьте, запускается ли vsftpd во время загрузки системы:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. Для запуска vsftpd выполните команду service vsftpd start vsftpd:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Настройка постоянства LUN

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Обеспечение постоянства LUN без Multipath
Если ваша система не использует многопутевые возможности, сохранение постоянства LUN можно реализовать с помощью udev. Но сначала убедитесь в правильности полученных UUID. Затем настройте сохранение постоянства LUN в файле scsi_id, который расположен в каталоге /etc. Открыв файл в окне текстового редактора, отметьте следующую строку как комментарий:
# options=-b
Замените на параметр
# options=-g
Это заставит udev наблюдать за полученными UUID от всех SCSI-устройств. Команда scsi_id поможет определить идентификатор UUID:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Набор символов в выводе и есть идентификатор UUID. Он не изменяется при добавлении нового устройства в систему. Чтобы иметь возможность создания правил для устройств, получите UUID для каждого устройства. Создать правила можно в файле 20-names.rules в каталоге /etc/udev/rules.d. Формат правил присвоения имени устройству:
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Замените существующие UUID и имя_устройства полученными значениями. Правило будет выглядеть примерно так:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Так, устройства, удовлетворяющие шаблону /dev/sd*, смогут проверить заданный UUID. Если совпадение найдено, то будет создан узел устройства /dev/имя_устройства. Наконец, в файл /etc/rc.local добавьте строку:
/sbin/start_udev
Сохранение постоянства LUN с Multipath
Чтобы обеспечить сохранение постоянства LUN в многопутевом окружении, необходимо присвоить псевдонимы многопутевым устройствам. Их можно определить в файле multipath.conf, который расположен в каталоге /etc/:
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Здесь всего определено 4 LUN: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3, dev/mpath/oramp4. Все устройства будут расположены в каталоге /dev/mpath, при этом их имена не будут изменяться между перезагрузками.

32.15. Отключение SMART-мониторинга дисков для гостевых систем

SMART-мониторинг дисков можно отключить, поскольку мы работаем с виртуальными дисками, а физические накопители управляются размещающим узлом.
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. Очистка старых файлов конфигурации Xen

Over time you will see a number of files accumulate in /var/lib/xen, the usually named vmlinuz.****** and initrd.******. These files are the initrd and vmlinuz files from virtual machines which either failed to boot or failed for some other reason. These files are temporary files extracted from virtual machine's boot disk during the start up sequence. These files should be automatically removed after the virtual machine is shut down cleanly. Then you can safely delete old and stale copies from this directory.

32.17. Настройка VNC-сервера

Для настройки VNC-сервера в системном меню выберите Система > Параметры > Удаленный рабочий стол или же просто выполните команду vino-preferences.
Далее будет рассмотрен процесс настройки сессии VNC-сервера:
  1. Отредактируйте файл ~/.vnc/xstartup так, чтобы при запуске vncserver запускался сеанс GNOME. При первом запуске сценария vncserver будет запрошен пароль.
  2. Пример файла xstartup:
    #!/bin/sh
    # Uncomment the following two lines for normal desktop:
    # unset SESSION_MANAGER
    # exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    #xsetroot -solid grey
    #vncconfig -iconic &
    #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    #twm &
    if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    	eval `dbus-launch --sh-syntax –exit-with-session`
    	echo "D-BUS per-session daemon address is: \
    	$DBUS_SESSION_BUS_ADDRESS"
    fi
    exec  gnome-session
    

32.18. Дублирование файлов конфигурации виртуальных машин

You can copy an existing configuration file to create an all new guest. You must modify the name parameter of the guests' configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well by using the uuidgen command. Then for the vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the 'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the /etc/sysconfig/network file to match the new guest's hostname.
Измените адрес HWADDR в файле /etc/sysconfig/network-scripts/ifcfg-eth0, чтобы он соответствовал выводу команды ifconfig eth0. Если же вы используете статические IP-адреса, измените запись IPADDR.

32.19. Дублирование существующей виртуальной машины и ее файла конфигурации

This section outlines copying an existing configuration file to create a new guest. There are key parameters in your guest's configuration file you must be aware of, and modify, to successfully duplicate a guest.
name
Уникальное имя виртуальной машины, которое используется гипервизором и управляющими утилитами для обращения к ней.
uuid
Уникальный идентификатор, который можно сгенерировать с помощью команды uuidgen. Пример:
$ uuidgen 
a984a14f-4191-4d14-868e-329906b211e5
vif
  • The MAC address must define a unique MAC address for each guest. This is automatically done if the standard tools are used. If you are copying a guest configuration from an existing guest you can use the script Раздел 32.9, «Создание уникального MAC-адреса».
  • Если вы решили переместить или скопировать файл конфигурации существующей виртуальной машины на новый узел, не забудьте изменить запись xenbr так, чтобы она соответствовала локальным настройкам сетевого окружения. Для получения информации о мосте виртуализации выполните команду brctl show.
  • Измените записи устройств в секции disk=, чтобы они указывали на нужный гостевой образ.
Теперь измените системные настройки виртуальной машины:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • В качестве значения HWADDR укажите адрес, полученный в результате выполнения ifconfig eth0.
  • Если используется статический IP-адрес, измените запись IPADDR.

Глава 33. Создание специализированных сценариев libvirt

В этой секции приведена информация для программистов и системных администраторов, планирующих создавать собственные сценарии с помощью libvirt.
Глава 32, Советы и хитрости is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Использование файлов конфигурации с помощью virsh

virsh can handle XML configuration files. You may want to use this to your advantage for scripting large deployments with special options. You can add devices defined in an XML file to a running para-virtualized guest. For example, to add a ISO file as hdc to a running guest create an XML file:
# cat satelliteiso.xml
<disk type="file" device="disk">
	<driver name="file"/>
	<source file="/var/lib/libvirt/images/rhn-satellite-5.0.1-11-redhat-linux-as-i386-4-embedded-oracle.iso"/>
	<target dev="hdc"/>
	<readonly/>
</disk>
Run virsh attach-device to attach the ISO as hdc to a guest called "satellite" :
# virsh attach-device satellite satelliteiso.xml

Часть VIII. Диагностика проблем

Основы диагностики и решения проблем

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

Важное замечание

Если ваша конкретная проблема не упомянута в этом документе, обратитесь к Замечаниям к выпуску для соответствующей версии и архитектуры. Замечания обычно содержат самую последнюю информацию; их можно найти на сайте Red Hat по адресу www.redhat.com/docs/manuals/enterprise/.

Если уже ничто не помогает...

Обратитесь в глобальную службу поддержки Red Hat по адресу https://www.redhat.com/apps/support/. Наши специалисты будут рады вам помочь.

Содержание

34. Диагностика проблем Xen
34.1. Диагностика и отладка Xen
34.2. Обзор журналов
34.3. Описание журналов
34.4. Основные каталоги
34.5. Диагностика проблем с помощью журналов
34.6. Диагностика проблем с помощью последовательной консоли
34.7. Доступ к консоли паравиртуализированного гостя
34.8. Доступ к консоли полностью виртуализированного гостя
34.9. Типичные проблемы Xen
34.10. Ошибки создания виртуальных машин
34.11. Подробнее о последовательной консоли
34.11.1. Вывод на последовательную консоль
34.11.2. Вывод паравиртуализированных гостей на последовательную консоль
34.11.3. Вывод полностью виртуализированных гостей на последовательную консоль
34.12. Файлы конфигурации Xen
34.13. Интерпретация сообщений об ошибках
34.14. Каталоги с журналами
35. Диагностика проблем
35.1. Определение доступных накопителей и разделов
35.2. После перезагрузки виртуальных машин на основе Xen не работает консоль
35.3. Сетевые утилиты не могут найти виртуализированные устройства Ethernet
35.4. Ошибки петлевого устройства
35.5. Не удается создать домен из-за нехватки памяти
35.6. Ошибка: Неверный образ ядра
35.7. Ошибка: Неверный образ ядра — не-PAE ядро на платформе PAE
35.8. Не удается загрузить полностью виртуализированную 64-разрядную виртуальную машину
35.9. Отсутствие записи localhost приводит к сбою virt-manager
35.10. Ошибка микрокода в процессе загрузки виртуальной машины
35.11. Предупреждающие сообщения Python при запуске виртуальной машины
35.12. Как включить в BIOS аппаратные расширения виртуализации Intel VT и AMD-V?
35.13. Производительность сетевого окружения KVM
36. Диагностика проблем паравиртуализированных драйверов Xen
36.1. Журналы виртуализации Red Hat Enterprise Linux 5
36.2. Паравиртуализированная машина не загружает Red Hat Enterprise Linux 3
36.3. Предупреждение при установке драйверов в Red Hat Enterprise Linux 3
36.4. Загрузка паравиртуализированных драйверов вручную
36.5. Проверка успешной загрузки паравиртуализированных драйверов
36.6. Снижение пропускной способности при использовании паравиртуализированных драйверов

Глава 34. Диагностика проблем Xen

В этой главе будут описаны способы решения наиболее распространенных проблем Xen. Будут рассмотрены следующие вопросы:
  • диагностика проблем утилит Linux и виртуализации в целом;
  • способы идентификации проблем;
  • расположение файлов журналов и описание их содержимого.
Целью этой главы является предоставление читателю знаний, достаточных для безошибочного определения проблем, связанных с виртуализацией Red Hat Enterprise Linux. Их успешное исправление требует опыта и навыков, которые, к сожалению, нельзя почерпнуть из книги. Рекомендуется проверять полученные сведения на практике, экспериментировать и находить собственные пути решения проблем.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Раздел A.1, «Интернет-ресурсы» for a list of Linux virtualization websites.

34.1. Диагностика и отладка Xen

В данной секции собраны сведения о приложениях системного администратора, сетевых утилитах и инструментах отладки, которые смогут помочь при диагностике:
Команды и приложения
xentop
xentop показывает сведения о размещающем узле и его гостевых доменах в реальном времени.
xm
Использует dmesg и log
  • vmstat
  • iostat
  • lsof
Функциональность iostat, mpstat и sar предоставлена пакетом sysstat.
Расширенные инструменты отладки и журналирования:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Сетевые утилиты:
  • ifconfig
  • tcpdump
    The tcpdump command 'sniffs' network packets. tcpdump is useful for finding network abnormalities and problems with network authentication. There is a graphical version of tcpdump named wireshark.
  • brctl
    Сетевая утилита brctl осуществляет проверку и настройку моста Ethernet в ядре виртуализации Linux. Для выполнения приведенных ниже команд потребуются полномочия root.
    # brctl show 
    
    bridge-name    bridge-id          STP  enabled  interfaces  
    -----------------------------------------------------------------------------
    xenbr0             8000.feffffff       no        vif13.0
    xenbr1             8000.ffffefff       yes       pddummy0
    xenbr2             8000.ffffffef       no        vif0.0
    
    # brctl showmacs xenbr0
    
    port-no           mac-addr                  local?       aging timer
    
    1                 fe:ff:ff:ff:ff:           yes            0.00
    2                 fe:ff:ff:fe:ff:           yes            0.00
    
    
    # brctl showstp xenbr0
    xenbr0 
    bridge-id              8000.fefffffffff
    designated-root        8000.fefffffffff
    root-port              0                   path-cost             0
    max-age                20.00               bridge-max-age        20.00
    hello-time             2.00                bridge-hello-time     2.00
    forward-delay          0.00                bridge-forward-delay  0.00
    aging-time            300.01
    hello-timer            1.43                tcn-timer             0.00
    topology-change-timer  0.00                gc-timer              0.02
    
Ниже перечислены другие утилиты, которые могут помочь при анализе проблем виртуализации в Red Hat Enterprise Linux 5. Их можно найти в репозиториях Server дистрибутива Red Hat Enterprise Linux 5.
  • strace позволяет отслеживать полученные процессом системные вызовы и события.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver позволяет запустить удаленный рабочий стол на сервере и удаленно исполнять графические утилиты (например, virt-manager). Установить vncserver можно с помощью команды yum install vnc-server.

34.2. Обзор журналов

When deploying Red Hat Enterprise Linux 5 with Virtualization into your network infrastructure, the host's Virtualization software uses many specific directories for important configuration, log files, and other utilities. All the Xen logs files are standard ASCII files, and accessible with a text editor:
  • Основной каталог с настройками Xen, /etc/xen/, содержит демон xend и файлы конфигурации виртуальной машины. Файлы сетевых сценариев расположены в подкаталоге scripts.
  • Журналы Xen расположены в каталоге /var/log/xen.
  • Файловые образы находятся в каталоге /var/lib/libvirt/images.
  • Информация о ядре Xen хранится в каталоге /proc/xen/.

34.3. Описание журналов

Xen использует демон xend и процесс qemu-dm, многочисленные файлы журналов которых хранятся в каталоге /var/log/xen/:
  • xend.log содержит все данные, собранные демоном xend, будь то системные события или инициированные оператором задания. Он также будет регистрировать действия виртуальной машины (создание, отключение, удаление и т.д.). В случае проблем этот файл следует проверить в первую очередь.
  • xend-debug.log регистрирует ошибки, поступающие от xend и подсистем виртуализации (буфер кадров, сценарии Python и пр.).
  • xen-hotplug-log регистрирует события горячей замены. Если устройство или сетевой сценарий не подключаются, событие записывается в этот журнал.
  • qemu-dm.[PID].log создается процессом qemu-dm для каждого полностью виртуализированного гостя. Идентификатор процесса PID можно определить с помощью команды ps. Замените [PID] полученным идентификатором процесса qemu-dm.
В случае проблем с менеджером виртуальных машин можно обратиться к файлу virt-manager.log в каталоге /.virt-manager. Следует помнить, что при перезапуске менеджера этот файл будет перезаписан. Поэтому, если вы хотите его сохранить, создайте резервную копию, прежде чем перезапустить менеджер.

34.4. Основные каталоги

Существуют дополнительные утилиты и файлы журналов, которые стоит принять во внимание при анализе проблем Xen.
  • Образы виртуальных машин находятся в каталоге /var/lib/libvirt/images.
  • При перезапуске демона xend происходит обновление xend-database в каталоге /var/lib/xen/xend-db.
  • Дамп ядра, полученный с помощью команды xm dump-core, сохраняется в каталог /var/lib/xen/dumps.
  • Каталог /etc/xen содержит файлы конфигурации, используемые для управления системными ресурсами. Файл конфигурации xend-config.sxp позволяет применить изменения в масштабах всей системы. Не рекомендуется вручную изменять файлы в этом каталоге.
  • Каталоги proc являются дополнительным местом сбора информации о системе. Следующие записи proc находятся в каталоге /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Диагностика проблем с помощью журналов

When encountering installation issues with Xen, refer to the host system's two logs to assist with troubleshooting. The xend.log file contains the same basic information as when you run the xm log command. This log is found in the /var/log/ directory. Here is an example log entry for when you create a domain running a kernel:
[2006-12-27 02:23:02 xend] ERROR (SrvBase: 163) op=create: Error creating domain: (0, 'Error')
Traceback (most recent call list)
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvBase.py" line 107 in_perform val = op_method (op,req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py line 71 in op_create
raise XendError ("Error creating domain: " + str(ex))
XendError: Error creating domain: (0, 'Error')
Другой файл, xend-debug.log, играет незаменимую роль при анализе ошибок, поскольку содержит более подробную информацию по сравнению с xend.log. Пример описания той же ошибки создания домена:
ERROR: Will only load images built for Xen v3.0
ERROR: Actually saw: GUEST_OS=netbsd, GUEST_VER=2.0, XEN_VER=2.0; LOADER=generic, BSD_SYMTAB'
ERROR: Error constructing guest OS
Обращаясь в службу поддержки, не забудьте включить копии обоих файлов.

34.6. Диагностика проблем с помощью последовательной консоли

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
Команда sync_console поможет определить ошибку, приводящую к зависанию и асинхронному выводу консоли гипервизора. Параметр pnpacpi=off помогает избежать проблем с вводом последовательной консоли. Установка параметров console=ttyS0 и console=tty позволит направить ошибки ядра и на VGA, и на последовательную консоль. Можно настроить ttywatch так, чтобы данные регистрировались на удаленном узле, подключенном через стандартный кабель Null Modem. К примеру, на удаленном узле введите:

Последовательная консоль Itanium

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to Глава 29, Настройка ELILO.
ttywatch --name myhost --port /dev/ttyS0
Эта команда перенаправляет вывод с /dev/ttyS0 в файл /var/log/ttywatch/myhost.log

34.7. Доступ к консоли паравиртуализированного гостя

Para-virtualized guest operating systems automatically has a virtual text console configured to transmit data to the host operating system. Connect to a guest's virtual console with the following command:
# virsh console [guest name, ID or UUID]
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.8. Доступ к консоли полностью виртуализированного гостя

Fully virtualized guest operating systems automatically has a text console configured for use, but the difference is the kernel guest is not configured. To enable the guest virtual serial console to work with the Full Virtualized guest, you must modify the guest's grub.conf file, and include the 'console =ttyS0 console=tty0' parameter. This ensures that the kernel messages are sent to the virtual serial console (and the normal graphical console). To use the guest's serial console, you must edit the libvirt configuration file configuration file. On the host, access the serial console with the following command:
# virsh console
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.9. Типичные проблемы Xen

При попытке запуска xend ничего не происходит. В результате выполнения virsh list получена ошибка:
Error: Error connecting to xend: Connection refused. Is xend running?
Попробуйте выполнить команду xend start. Если ее результат подобен этому:
Error: Could not obtain handle on privileged command interfaces (2 = No such file or directory)
Traceback (most recent call last:)
File "/usr/sbin/xend/", line 33 in ?
from xen.xend.server. import SrvDaemon
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py" , line 26 in ?
from xen.xend import XendDomain
File "/usr//lib/python2.4/site-packages/xen/xend/XendDomain.py" , line 33, in ?
		
from xen.xend import XendDomainInfo
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line37, in ?
import images
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line30, in ?
xc = xen.lowlevel.xc.xc ()
RuntimeError: (2, 'No such file or directory' )
Это может означать, что вы перезагрузили компьютер с ядром, отличающимся от kernel-xen. В этом случае во время загрузки выберите ядро kernel-xen или назначьте его ядром по умолчанию в grub.conf.

34.10. Ошибки создания виртуальных машин

Если при попытке создания виртуальной машины вы получаете ошибку Неверный аргумент (Invalid argument), это может означать, что образ загружаемого ядра несовместим с гипервизором. Такая ситуация будет иметь место, если, например, вы пытаетесь выполнять не-PAE ядро FC5 на PAE-гипервизоре FC6.
Выполнив обновление yum и получив новое ядро, вы увидите, что текущим ядром в grub.conf опять станет исходное ядро вместо ядра виртуализации.
To correct this problem you must modify the default kernel RPM that resides in the /etc/sysconfig/kernel/ directory. You must ensure that kernel-xen parameter is set as the default option in your grub.conf file.

34.11. Подробнее о последовательной консоли

Ядро Linux способно передавать информацию последовательным портам. Эта возможность может использоваться при анализе ситуаций паники ядра и аппаратных проблем с видеоустройствами или удаленно управляемыми серверами. Ниже будет описан процесс настройки вывода на последовательную консоль для компьютеров с ядрами виртуализации Red Hat Enterprise Linux и их виртуальных машин.

34.11.1. Вывод на последовательную консоль

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Для получения информации о ядре через последовательный порт в файле /boot/grub/grub.conf потребуется настроить соответствующие параметры последовательного устройства.
Если последовательная консоль подключена к com1, добавьте параметры com1=115200,8n1, console=tty0, console=ttyS0,115200:
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com1=115200,8n1
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
				console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Если последовательная консоль подключена к com2, добавьте параметры com2=115200,8n1 console=com2L, console=tty0, console=ttyS0,115200:
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com2=115200,8n1 console=com2L
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
	console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Сохраните изменения и перезагрузите компьютер. Гипервизор направит данные через заданный порт (com1, com2 и т.п.).
Обратите внимание, что в примере, использующем порт com2, в строке vmlinuz указан параметр console=ttyS0. Этот параметр определяет специфичную для окружения Xen настройку.

34.11.2. Вывод паравиртуализированных гостей на последовательную консоль

Ниже рассматривается настройка виртуализированной последовательной консоли для паравиртуализированных гостей Red Hat Enterprise Linux.
Вывод паравиртуализированных гостей можно получить с помощью virsh console или в окне последовательной консоли virt-manager. Настроить это можно так:
  1. Авторизуйтесь в своей паравиртуализированной гостевой системе.
  2. Внесите изменения в файл /boot/grub/grub.conf:
    Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
    	root (hd0, 0) kernel /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=xvc0 
    	initrd /boot/initrd-2.6.18-92.el5xen.img
    
  3. Перезагрузите паравиртуализированную гостевую систему.
Теперь сообщения ядра должны появляться в окне последовательной консоли virt-manager и virsh console.
Журналирование вывода консоли паравиртуализированного домена
Можно настроить журналирование вывода последовательных консолей паравиртуализированных гостей для демона xend.
В файле /etc/sysconfig/xend измените запись
# Log all guest console output (cf xm console)
#XENCONSOLED_LOG_GUESTS=no
to:
# Log all guest console output (cf xm console)
XENCONSOLED_LOG_GUESTS=yes
Перезагрузите компьютер, чтобы включить функции журналирования.
Журналы вывода последовательной консоли будут хранится в файле /var/log/xen/console.

34.11.3. Вывод полностью виртуализированных гостей на последовательную консоль

Ниже рассматривается настройка последовательной консоли для полностью виртуализированных гостей.
Вывод паравиртуализированных гостей можно просмотреть с помощью команды virsh console.
Не стоит забывать об ограничениях последовательной консоли в полностью виртуализированных системах. Ограничения включают:
  • недоступно журналирование вывода с помощью xend;
  • вывод может быть искажен и частично потерян.
В Linux будет использоваться последовательный порт ttyS0, а в Windows — COM1.
Потребуется настроить перенаправление вывода виртуализированной операционной системы в виртуальный последовательный порт.
Для вывода информации о ядре из полностью виртуализированного гостя Linux в домен добавьте параметр console=tty0 console=ttys0,115200 в файл /boot/grub/grub.conf.
title Red Hat Enterprise Linux Server (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/volgroup00/logvol00
	console=tty0 console=ttys0,115200
	initrd /initrd-2.6.18-92.el5.img
Перезагрузите виртуальную машину.
Теперь сообщения можно просмотреть с помощью команды virsh console.

Замечание

/var/log/xen/console не регистрирует сообщения последовательной консоли из полностью виртуализированных доменов, так как они не являются паравиртуализированными гостями.

34.12. Файлы конфигурации Xen

When you create guests with the virt-manager or virt-install tools on Red Hat Enterprise Linux 5, the guests configuration files are created automatically in the /etc/xen directory.

Warning

Red Hat advises users not to manually edit Xen configuration files. Xen configuration files have limited error checking and many unsupported variables. Editing Xen configuration files may damage your guests, make guests unbootable or cause data loss.
The example below is a typical a para-virtualized guest configuration file:
name = "rhel5vm01"
memory = "2048"
disk = ['tap:aio:/var/lib/libvirt/images/rhel5vm01.dsk,xvda,w',]
vif = ["type=ieomu, mac=00:16:3e:09:f0:12 bridge=xenbr0', 
"type=ieomu, mac=00:16:3e:09:f0:13 ]
vnc = 1
vncunused = 1
uuid = "302bd9ce-4f60-fc67-9e40-7a77d9b4e1ed"
bootloader = "/usr/bin/pygrub"
vcpus=2
on_reboot = "restart"
on_crash = "restart"
Обратите внимание, что по умолчанию используется выражение serial="pty". Пример файла конфигурации для полностью виртуализированной гостевой системы:
name = "rhel5u5-86_64"
builder = "hvm"
memory = 500
disk = ['/var/lib/libvirt/images/rhel5u5-x86_64.dsk.hda,w']
vif = [ 'type=ioemu, mac=00:16:3e:09:f0:12, bridge=xenbr0', 'type=ieomu, mac=00:16:3e:09:f0:13, bridge=xenbr1']
uuid = "b10372f9-91d7-ao5f-12ff-372100c99af5'
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader/"
vnc = 1
vncunused = 1
apic = 1
acpi = 1
pae = 1
vcpus =1
serial ="pty" # enable serial console
on_boot = 'restart'

Файлы конфигурации Xen

Редактирование файлов конфигурации Xen не поддерживается. Для изменения файлов конфигурации libvirt используются virsh dumpxml, virsh create или virsh edit, которые обладают механизмами проверки ошибок.

34.13. Интерпретация сообщений об ошибках

Ошибка:
failed domain creation due to memory shortage, unable to balloon domain0
Эта ошибка связана с нехваткой памяти. Домен 0 не может быть уменьшен настолько, чтобы стало достаточно места для новой виртуальной машины. Проверьте файл xend.log на наличие ошибки:
[2006-12-21] 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 Kib free; 0 to scrub; need 1048576; retries: 20
[2006-12-21] 20:33:31 xend. XendDomainInfo 3198] ERROR (XendDomainInfo: 202
Domain construction failed
Проверьте объем используемой доменом 0 памяти с помощью команды xm list domain0. Если домен не был уменьшен, выполните virsh setmem dom0 новый_размер.
Ошибка:
wrong kernel image: non-PAE kernel on a PAE
Это обозначает, что вы пытаетесь выполнить неподдерживаемый образ ядра в гипервизоре. Примером может служить загрузка не-PAE ядра паравиртуализированного гостя на узле RHEL5. Пакет kernel-xen поддерживает только ядра с PAE и 64-разрядные архитектуры.
Выполните команду:
# xm create -c va-base

Using config file "va-base"
Error: (22, 'invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERRORs
(XendDomainInfo:202) Domain construction failed

Traceback (most recent call last)
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 195 in create vm.initDomain()
File " /usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1363 in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1449]
XendDlomainInfo.destroy: domain=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1457]
XendDlomainInfo.destroy:Domain(1)
Если вы хотите выполнять 32-рязрядное не-PAE ядро, виртуальная машина должна выполняться в качестве полностью виртуализированного гостя. Для паравиртуализированных гостей будет необходимо использовать 32-разрядный PAE-гипервизор, если требуется выполнять 32-разрядную гостевую систему PAE, а для выполнения 64-разрядных PAE-гостей понадобится 64-разрядный PAE-гипервизор. При полной виртуализации 64-разрядные гостевые системы должны работать с 64-разрядным гипервизором. 32-разрядный PAE-гипервизор, поставляемый с Red Hat Enterprise Linux 5 i686, поддерживает только выполнение 32-разрядных паравиртуализированных PAE-гостей и 32-разрядных полностью виртуализированных гостевых систем. 64-битный гипервизор поддерживает только 64-разрядные паравиртуализированные гостевые системы.
Такая проблема может возникнуть при перемещении полностью виртуализированного HVM-гостя в систему Red Hat Enterprise Linux 5. Могут возникнуть проблемы при загрузке гостевой системы; при этом на консоль будет выведено сообщение об ошибке. Проверьте запись PAE в файле конфигурации и убедитесь, что она выглядит так: «pae=1». Вы также должны использовать 32-разрядный дистрибутив.
Ошибка:
Unable to open a connection to the Xen hypervisor or daemon
Эта ошибка имеет место в случае неудачи при запуске virt-manager и означает, что в файле /etc/hosts нет записи localhost. Пример неверной записи:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Пример верной записи:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
localhost.localdomain. localhost
Ошибка в файле xen-xend.logfile:
Bridge xenbr1 does not exist!
This happens when the guest's bridge is incorrectly configured and this forces the Xen hotplug scripts to timeout. If you move configuration files between hosts, you must ensure that you update the guest configuration files to reflect network topology and configuration modifications. When you attempt to start a guest that has an incorrect or non-existent Xen bridge configuration, you will receive the following errors:
# xm create mySQL01

Using config file " mySQL01"
Going to boot Red Hat Enterprise Linux Server (2.6.18.-1.2747 .el5xen)
kernel: /vmlinuz-2.6.18-12747.el5xen
initrd: /initrd-2.6.18-1.2747.el5xen.img
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
Кроме этого, xend.log будет содержать ошибки:
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:143) Waiting for devices vif
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:149) Waiting for 0
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status

[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=2
[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(2)
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status
To resolve this problem, open the guest's configuration file found in the /etc/xen directory. For example, editing the guest mySQL01
# vim /etc/xen/mySQL01
Locate the vif entry. Assuming you are using xenbr0 as the default bridge, the proper entry should resemble the following:
# vif = ['mac=00:16:3e:49:1d:11, bridge=xenbr0',]
Ошибки Python:
# xm shutdown win2k3xen12
# xm create win2k3xen12

Using config file "win2k3xen12".

/usr/lib64/python2.4/site-packages/xenxm/opts.py:520: Deprecation Warning:
Non ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details

execfile (defconfig, globs, locs,)
Error: invalid syntax 9win2k3xen12, line1)
Python генерирует такие ошибки в случае использования неверного файла конфигурации. Исправьте ошибки или создайте файл заново.

34.14. Каталоги с журналами

Структура каталогов в окружении виртуализации Red Hat Enterprise Linux 5 будет выглядеть примерно так:
/etc/xen/
  • содержит файлы конфигурации, используемые демоном xend;
  • каталог scripts со сценариями для сетевого окружения виртуализации.
/var/log/xen/
  • каталог с журналами Xen.
/var/lib/libvirt/images/
  • каталог, в котором по умолчанию будут храниться образы виртуальных машин.
  • При использовании другого каталога для хранения образов виртуальных машин убедитесь, что это отражено в политике SELinux.
/proc/xen/
  • информация Xen в /proc.

Глава 35. Диагностика проблем

В этой главе будут рассмотрены основные проблемы виртуализации Red Hat Enterprise Linux и способы их решения.

35.1. Определение доступных накопителей и разделов

Убедитесь, что драйверы блочных устройств загружены, а устройства и разделы доступны гостевой системе. Для этого выполните команду cat /proc/partitions. Пример:
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. После перезагрузки виртуальных машин на основе Xen не работает консоль

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Чтобы это исправить, в файл /etc/inittab добавьте:
1:12345:respawn:/sbin/mingetty xvc0
Сохраните файл и перезагрузите систему.

35.3. Сетевые утилиты не могут найти виртуализированные устройства Ethernet

Если сетевые утилиты не могут определить сетевую карту Xen Virtual Ethernet в составе гостевой операционной системы, выполните следующую команду (в Red Hat Enterprise Linux 4 и Red Hat Enterprise Linux 5):
cat /etc/modprobe.conf
или в Red Hat Enterprise Linux 3:
cat /etc/modules.conf
Вывод должен содержать приведенную ниже строку, плюс каждому дополнительному интерфейсу должна соответствовать аналогичная строка
alias eth0 xen-vnif
Чтобы решить проблему, добавьте строки псевдонимов (например, alias eth0 xen-vnif) для каждого паравиртуализированного интерфейса.

35.4. Ошибки петлевого устройства

Если используются файловые образы гостевых систем, может понадобиться увеличить число петлевых устройств. По умолчанию можно настроить до восьми активных устройств, но это число можно изменить в файле /etc/modprobe.conf. Для этого добавьте строку:
                options loop max_loop=64
В этом примере мы использовали значение 64, но можно указать любое число. Возможно, в системе придется организовать гостевые ОС на основе петлевых устройств, для чего в паравиртуализированных системах используются команды phy: block device и tap:aio, а в полностью виртуализированных — phy: device и file: file.

35.5. Не удается создать домен из-за нехватки памяти

This may cause a domain to fail to start. The reason for this is there is not enough memory available or dom0 has not ballooned down enough to provide space for a recently created or started guest. In your /var/log/xen/xend.log, an example error message indicating this has occurred:
[2006-11-21 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 KiB free;
	0 to scrub; need 1048576; retries: 20.
[2006-11-21 20:33:52 xend.XendDomainInfo 3198] ERROR (XendDomainInfo:202) Domain construction failed
You can verify the amount of memory currently used by dom0 with the command “xm list Domain-0”. If dom0 is not ballooned down you can use the command “xm mem-set Domain-0 NewMemSize” where NewMemSize should be a smaller value.

35.6. Ошибка: Неверный образ ядра

Паравиртуализированные гости должны использовать только стандартное ядро, так как они не работают с ядром kernel-xen.
Attempting to boot any kernel other than the Xen kernel as a para-virtualized guest results in the following error message:
# xm create testVM
Using config file "./testVM".
Going to boot Red Hat Enterprise Linux Server (2.6.18-1.2839.el5)
kernel: /vmlinuz-2.6.18-1.2839.el5
initrd: /initrd-2.6.18-1.2839.el5.img
Error: (22, 'Invalid argument')
In the above error you can see that the kernel line shows that the system is trying to boot a non kernel-xen kernel. The correct entry in the example is ”kernel: /vmlinuz-2.6.18-1.2839.el5xen”.
Проверьте, установлено ли ядро kernel-xen в гостевой системе и является ли оно ядром, загружаемым по умолчанию (задается в /etc/grub.conf).
Если ядро kernel-xen действительно установлено, запустите виртуальную машину:
xm create -c GuestName
Where GuestName is the name of the guest. The previous command will present you with the GRUB boot loader screen and allow you to select the kernel to boot. You will have to choose the kernel-xen kernel to boot. Once the guest has completed the boot process you can log into the guest and edit /etc/grub.conf to change the default boot kernel to your kernel-xen. Simply change the line “default=X” (where X is a number starting at '0') to correspond to the entry with your kernel-xen line. The numbering starts at '0' so if your kernel-xen entry is the second entry you would enter '1' as the default,for example “default=1”.

35.7. Ошибка: Неверный образ ядра — не-PAE ядро на платформе PAE

If you to boot a non-PAE kernel, para-virtualized guest the error message below will display. It indicates you are trying to run a guest kernel on your Hypervisor which at this time is not supported. The Xen hypervisor presently only supports PAE and 64 bit para-virtualized guest kernels.
# xm create -c va-base 
Using config file "va-base".
Error: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERROR (XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 195, in  create vm.initDomain()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 1363, in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(1)
If you need to run a 32 bit or non-PAE kernel you will need to run your guest as a fully-virtualized virtual machine. The rules for hypervisor compatibility are:
  • Паравиртуализированные гостевые системы должны соответствовать типу архитектуры гипервизора. Так, для выполнения 32-разрядного гостя PAE необходим 32-разрядный гипервизор PAE.
  • Для выполнения 64-разрядной паравиртуализированной гостевой системы необходим 64-разрядный гипервизор.
  • Для полностью виртуализированных 32-разрядных гостевых систем (PAE и не-PAE) должен использоваться 32- или 64-разрядный гипервизор.
  • Для выполнения полностью виртуализированных 64-разрядных гостевых систем необходим 64-разрядный гипервизор.

35.8. Не удается загрузить полностью виртуализированную 64-разрядную виртуальную машину

If you have moved the configuration file to a Red Hat Enterprise Linux 5 causing your fully-virtualized guest to fail to boot and present the error, Your CPU does not support long mode. Use a 32 bit distribution. This problem is caused by a missing or incorrect pae setting. Ensure you have an entry “pae=1” in your guest's configuration file.

35.9. Отсутствие записи localhost приводит к сбою virt-manager

Если при попытке запуска virt-manager вы столкнулись с ошибкой «Unable to open a connection to the Xen hypervisor/daemon», скорее всего, ее причиной является отсутствие записи localhost в файле /etc/hosts. Проверьте файл, если необходимо, добавьте новую запись для localhost. Пример неверной записи:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Исправленная запись будет выглядеть так:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
localhost.localdomain localhost

35.10. Ошибка микрокода в процессе загрузки виртуальной машины

During the boot phase of your virtual machine you may see an error message similar to:
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error:
/sbin/service microcode_ctl stop
/sbin/chkconfig --del microcode_ctl

35.11. Предупреждающие сообщения Python при запуске виртуальной машины

Если Python генерирует ошибки, подобные приведенным ниже, это может быть вызвано ошибками в файле конфигурации. Наиболее часто причина состоит в том, что файл конфигурации содержит символы, отличные от ASCII. Исправьте файл или сгенерируйте новый.
Другой причиной может служить неверный файл конфигурации в текущем рабочем каталоге. Команда xm create сначала выполнит поиск файла в текущем каталоге, а затем в /etc/xen.
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. Как включить в BIOS аппаратные расширения виртуализации Intel VT и AMD-V?

Здесь будет рассказано, как правильно определить аппаратные расширения виртуализации и включить их в BIOS.
Расширения Intel VT могут быть отключены в BIOS. Некоторые производители ноутбуков отключают их по умолчанию.
Расширения виртуализации для процессоров AMD-V нельзя отключить в BIOS.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Раздел 35.12, «Как включить в BIOS аппаратные расширения виртуализации Intel VT и AMD-V?» for instructions on enabling disabled virtualization extensions.
Сначала проверьте, включены ли расширения в BIOS. Настройки BIOS для Intel® VT и AMD-V обычно расположены в меню Chipset или Processor, но иногда могут быть спрятаны в других меню, например, Security Settings.
Процедура 35.1. Активация расширений виртуализации в BIOS
  1. Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system.
  2. Select Restore Defaults or Restore Optimized Defaults, and then select Save & Exit.
  3. Выключите компьютер и отключите источник питания.
  4. Enabling the virtualization extensions in BIOS

    Note: BIOS steps

    Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system.
    1. Power on the machine and open the BIOS (as per Step 1).
    2. Open the Processor submenu The processor settings menu may be hidden in the Chipset, Advanced CPU Configuration or Northbridge.
    3. Enable Intel Virtualization Technology (also known as Intel VT) or AMD-V depending on the brand of the processor. The virtualization extensions may be labeled Virtualization Extensions, Vanderpool or various other names depending on the OEM and system BIOS.
    4. Enable Intel VTd or AMD IOMMU, if the options are available. Intel VTd and AMD IOMMU are used for PCI passthrough.
    5. Select Save & Exit.
  5. Выключите компьютер и отключите источник питания.
  6. Выполните команду cat /proc/cpuinfo | grep vmx svm. Если вывод команды пуст, это может означать наличие ошибок в настройках BIOS или отсутствие в системе расширений. Непустой вывод команды будет свидетельствовать о том, что расширения виртуализации включены.

35.13. Производительность сетевого окружения KVM

По умолчанию виртуальным машинам KVM назначен виртуальный контроллер сетевого интерфейса Realtek 8139 (rtl8139).
rtl8139 работает нормально в большинстве случаев. Однако его производительность может снизиться в некоторых сетях, например, 10 гигабит Ethernet.
Избежать этого можно, назначив другой тип виртуального контроллера, например, Intel PRO/1000 (e1000) или virtio (паравиртуализированный сетевой драйвер).
Чтобы начать использовать драйвер e1000:
  1. Завершите работу гостевой операционной системы.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    Команда virsh edit откроет текстовый редактор, заданный переменной $EDITOR.
  3. Перейдите к секции настройки сетевого интерфейса. Она выглядит примерно так:
    <interface type='network'>
      [output truncated]
      <model type='rtl8139' />
    </interface>
    
  4. Change the type attribute of the model element from 'rtl8139' to 'e1000'. This will change the driver from the rtl8139 driver to the e1000 driver.
    <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  5. Сохраните изменения и закройте окно редактирования.
  6. Перезапустите гостевую систему.
Или же при установке новых виртуальных машин можно использовать другой сетевой драйвер. Это может оказаться обязательным условием при выполнении сетевой установки. Для этого необходимо, чтобы с CD или DVD уже была создана как минимум одна виртуальная машина, которая будет служить шаблоном.
  1. Создайте шаблон XML, взяв за основу существующую виртуальную машину.
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Скопируйте XML-файл и измените в нем имя виртуальной машины, UUID, образ диска, MAC-адрес и другие уникальные характеристики системы. При этом строки UUID и MAC-адреса можно вообще удалить, тогда virsh сгенерирует новые значения.
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Добавьте строку модели в секцию описания интерфейса:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Создайте новую виртуальную машину:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
При наличии драйвера e1000 или virtio производительность сети должна улучшиться (BZ#517181).

Глава 36. Диагностика проблем паравиртуализированных драйверов Xen

В этой главе будет рассмотрен ряд проблем, с которыми могут столкнуться размещающие узлы Xen и полностью виртуализированные гостевые системы Red Hat Enterprise Linux, использующие паравиртуализированные драйверы.

36.1. Журналы виртуализации Red Hat Enterprise Linux 5

/var/log/xen/
Здесь хранятся все файлы журналов, генерируемые демоном xend и процессом qemu-dm.
xend.log
  • Журнал, используемый демоном xend для регистрации событий.
  • Здесь будут регистрироваться такие события как создание виртуальной машины, завершение ее работы, удаление и т.п.
  • Обычно анализ проблем начинается с изучения этого файла; в большинстве случаев причину можно найти именно здесь. Обратите особое внимание на записи, предшествующие сообщению об ошибке.
xend-debug.log
  • Используется для регистрации ошибок xend и его подсистем (буфера кадров, сценариев Python).
xen-hotplug.log
  • Используется для регистрации событий горячей замены (hotplug).
  • В этом файле будут регистрироваться события несостоявшейся активации устройства.
qemu-dm.PID.log
  • Этот файл будет создан процессом qemu-dm, который запускается для каждого полностью виртуализированного гостя.
  • PID будет заменен идентификатором процесса qemu-dm.
  • Идентификатор процесса для qemu-dm можно узнать, выполнив команду ps; при этом его аргументы помогут идентифицировать виртуальную машину, которой принадлежит процесс qemu-dm.
If you are troubleshooting a problem with the virt-manager application you can also review the logfile generated by it. The logfile for virt-manager will be in a directory called .virt-manager in the user's home directory whom ran virt-manager. This directory will usually be ~/.virt-manager/virt-manager.

Примечание

Файл журнала будет перезаписан при перезапуске virt-manager. Если вы пытаетесь устранить проблемы, связанные с virt-manager, прежде чем перезапустить его, создайте резервную копию файла.
/var/lib/libvirt/images/
Каталог, в котором обычно хранятся файловые образы гостевых систем.
/var/lib/xen/xend-db/
Каталог с базой данных xend, которая генерируется при каждом перезапуске демона.
/etc/xen/
Каталог с файлами конфигурации гипервизора Xen.
  • /etc/xen/xend-config.sxp является основным файлом конфигурации xend. Именно с его помощью можно включить и отключить миграцию и другие функции, которые не были настроены в libvirt.
/var/lib/xen/dump/
В этот каталог будет сохраняться дамп данных виртуальных машин, генерируемый автоматически или при выполнении команды xm dump-core.
/proc/xen/
Содержит следующие файлы с информацией о xen-kernel:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. Паравиртуализированная машина не загружает Red Hat Enterprise Linux 3

Red Hat Enterprise Linux 3 использует RPM-пакеты ядра для конкретной архитектуры. Так, несоответствие архитектуры ядра и RPM паравиртуализированного драйвера может служить причиной ошибки при попытке загрузки этого драйвера.
When the para-virtualized driver modules are inserted, a long list of unresolved modules will be displayed. A shortened excerpt of the error can be seen below.
# insmod xen-platform-pci.o 
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
xen-platform-pci.o: unresolved symbol __ioremap_R9eac042a
xen-platform-pci.o: unresolved symbol flush_signals_R50973be2
xen-platform-pci.o: unresolved symbol pci_read_config_byte_R0e425a9e
xen-platform-pci.o: unresolved symbol __get_free_pages_R9016dd82
[...]
The solution is to use the correct RPM package for your hardware architecture for the para-virtualized drivers.

36.3. Предупреждение при установке драйверов в Red Hat Enterprise Linux 3

В процессе установки паравиртуализированных драйверов в Red Hat Enterprise Linux 3 с ядром, версия которого предшествует 2.4.21-52, может быть показано предупреждение, сообщающее, что модули были скомпилированы с помощью ядра более новой версии.
Сообщение, подобное приведенному ниже, можно спокойно проигнорировать.
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
Warning: loading xen-platform-pci.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xen-platform-pci loaded, with warnings
Важная информация содержится в последней строке, где сообщается, что модуль загружен, но с предупреждениями.

36.4. Загрузка паравиртуализированных драйверов вручную

Если паравиртуализированный драйвер не был загружен автоматически, можно попробовать его загрузить вручную.
Это также позволит изменить настройки сетевых компонентов и накопителей и определить причину неудачи исходной загрузки драйвера. Приведенная далее последовательность действий поможет загрузить модули паравиртуализированных драйверов.
Сначала определите, где расположены модули паравиртуализированных драйверов в системе.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Загрузите модули вручную. Вместо {путь} укажите путь к модулям, который вы только что определили.
# insmod \
/lib/modules/'uname -r'/{LocationofPV-drivers}/xen_platform_pci.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_balloon.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vnif.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vbd.ko

36.5. Проверка успешной загрузки паравиртуализированных драйверов

Вы наверняка захотите убедиться, что загрузка драйверов была выполнена успешно.
After the para-virtualized drivers have been installed and the guest has been rebooted you can verify that the drivers have loaded. First you should confirm the drivers have logged their loading into /var/log/messages
# grep -E "vif|vbd|xen" /var/log/messages
                    xen_mem: Initialising balloon driver
                    vif vif-0: 2 parsing device/vif/0/mac
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    xen-vbd: registered block device major 202
You can also use the lsmod command to list the loaded para-virtualized drivers. It should output a list containing the xen_vnif, xen_vbd, xen_platform_pci and xen_balloon modules.
# lsmod|grep xen
xen_vbd                19168  1 
xen_vnif               28416  0 
xen_balloon            15256  1 xen_vnif
xen_platform_pci       98520  3 xen_vbd,xen_vnif,xen_balloon,[permanent]

36.6. Снижение пропускной способности при использовании паравиртуализированных драйверов

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Раздел 36.5, «Проверка успешной загрузки паравиртуализированных драйверов»). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Глоссарий содержит список терминов, которые вы встретите в этом руководстве.
Domains
domU and dom0 are both domains. A domain is a term for a guest or virtual machine on the Xen hypervisor. The term domains has a similar meaning to virtual machines and the two are technically interchangeable.
domU
domU refers to the guest operating systems which run on the host system (the dom0 domain).
Hardware Virtual Machine
See Full virtualization.
I/O
Аббревиатура для ввода и вывода. Этот термин используется для описания программ, действий или устройств, передающих данные из системы периферийным устройствам и обратно. Каждое действие передачи будет представлять собой вывод для одного устройства и ввод для другого. Клавиатура и мышь являются устройствами ввода, в то время как принтеры являются устройствами вывода. А например, записывающий CD-ROM — устройство ввода и вывода одновременно.
Itanium®
Архитектура процессоров Intel Itanium®.
Kernel SamePage Merging
KSM (Kernel SamePage Merging) — модуль, используемый гипервизором KVM для обеспечения совместного доступа к идентичным страницам памяти, будь то общие библиотеки или другие часто используемые общие данные. KSM позволяет повысить производительность виртуальных машин за счет хранения таких библиотек в кэше.
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) is a Full virtualization solution for Linux on AMD64 and Intel 64 hardware. VM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel. KVM can run multiple, unmodified virtualized guest Windows and Linux operating systems. KVM is a hypervisor which uses the libvirt virtualization tools (virt-manager and virsh).
KVM представляет собой набор модулей Linux для управления устройствами, памятью и управляющими API собственно модуля гипервизора. Виртуальные машины выполняются как процессы и потоки Linux под управлением этих модулей.
LUN
LUN (Logical Unit Number) — номер, назначенный логическому компоненту. Такой метод адресации используется протоколом SCSI.
MAC-адрес
MAC-адрес (Media Access Control) — аппаратный адрес контроллера сетевого интерфейса. Для виртуальных сетевых интерфейсов МАС-адреса должны быть сгенерированы, при этом адреса в локальном домене должны быть уникальны.
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
Security Enhanced Linux
SELinux (Security Enhanced Linux) использует специальные модули защиты Linux в ядре для создания набора минимальных привилегий, необходимых политике безопасности.
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
Universally Unique Identifier
UUID (Universally Unique Identifier) стандартизирует нумерацию устройств, систем и программных компонентов в распределенных вычислительных окружениях. Типы UUID включают идентификаторы файловых систем ext2 и ext3, идентификаторы устройств RAID, iSCSI и LUN, MAC-адреса и идентификаторы виртуальных машин.
Virtualized CPU
Число виртуальных процессоров в системе определяется числом ядер физического процессора. Эти процессоры могут быть предоставлены гостевым виртуальным машинам.
Xen
Red Hat Enterprise Linux supports the Xen hypervisor and the KVM hypervisor. Both hypervisors have different architectures and development approaches. The Xen hypervisor runs underneath a Red Hat Enterprise Linux operating system which acts as a host managing system resources and virtualization APIs. The host is sometimes referred to as dom0, or Domain0.
Базовое оборудование, «bare metal»
The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal is another way of referring to running an unmodified version of the operating system on the physical hardware. Examples of operating systems running on bare metal are dom0 or a normally installed operating system.
Виртуализация
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • Программная виртуализация (эмуляция) обеспечивает работу исходных операционных систем за счет двоичных преобразований и других способов эмуляции. Такой метод значительно медленнее по сравнению с аппаратной виртуализацией или паравиртуализацией.
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
Виртуальные машины
Виртуальная машина представляет собой программную реализацию физической машины или языка программирования (например, Java Runtime Environment или LISP). Виртуальные машины в контексте виртуализации — операционные системы, выполняемые на виртуализированном оборудовании.
Гипервизор
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
Гостевая система
Also known as guests, virtual machines, virtual servers or domU.
Домен 0 (dom0)
Also known as the host or host operating system.
dom0 refers to the host instance of Red Hat Enterprise Linux running the Xen hypervisor. Domain0 facilitates virtualized devices and virtualization for the guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems.
Миграция
Процесс переноса виртуальной машины с одного узла на другой. Миграция может быть выполнена в автономном режиме (работа машины останавливается перед переносом) или подключенном режиме (система продолжает работу во время переноса). Можно выполнять миграцию полностью виртуализированных, паравиртуализированных гостевых систем Xen и полностью виртуализированных гостей KVM.
Миграция является основополагающим аспектом виртуализации, так как на этом уровне программное обеспечение совершенно не зависит от оборудования. Основное назначение миграции:
  • Распределение нагрузки — виртуальные машины могут быть перенесены на узлы с наименьшей нагрузкой.
  • Обеспечение отказоустойчивости — в случае сбоя устройств размещающей системы можно осуществить перенос виртуальных машин, тем самым освободив поврежденный узел для диагностики.
  • Энергосбережение — виртуальные машины можно перенести на другие узлы, чтобы сократить затраты энергии в периоды низкой нагрузки.
  • Географический перенос — перенос виртуальных машин с целью сокращения задержек при обмене данными.
Для хранения гостевых образов используется общее хранилище. Без этого миграция будет невозможна.
При выполнении миграции в автономном режиме работа виртуальной машины останавливается, затем образы памяти переносятся в целевую систему.
Длительность автономной миграции зависит от полосы пропускания и сетевой задержки. Так, перенос гостевой системы с 2 гигабайтами памяти по 1 гигабит Ethernet займет несколько секунд.
A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. KVM estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until KVM predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
Длительность такой миграции зависит от полосы пропускания, сетевой задержки и активности гостевой системы. Нагрузка на процессор и большие объемы операций ввода и вывода также могут сказаться на длительности процесса.
Паравиртуализация
Para-virtualization uses a special kernel, sometimes referred to as the Xen kernel or the kernel-xen package. Para-virtualized guest kernels are run concurrently on the host while using the host's libraries and devices. A para-virtualized installation can have complete access to all devices on the system which can be limited with security settings (SELinux and file controls). Para-virtualization is faster than full virtualization. Para-virtualization can effectively be used for load balancing, provisioning, security and consolidation advantages.
Начиная с Fedora 9, нет необходимости в специальном ядре. После включения этой функциональности в основную версию Linux все последующие выпуски ядер Linux будут включать возможность виртуализации.
Паравиртуализированная
See Para-virtualization.
Паравиртуализированный драйвер
Драйвер устройства, работающий в полностью виртуализированных гостевых системах Linux. Такие драйверы значительно улучшают производительность сети и операций ввода/вывода для полностью виртуализированных гостей.
Полная виртуализация
Xen and KVM can use full virtualization. Full virtualization uses hardware features of the processor to provide total abstraction of the underlying physical system (bare metal) and create a new virtual machine in which the guest operating systems can run. No modifications are needed in the guest operating system. The guest operating system and any applications on the guest are not aware of the virtualized environment and run normally. Para-virtualization requires a modified version of the Linux operating system.
Полностью виртуализированная
See Full virtualization.
Размещающая система, узел
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.

Дополнительные ресурсы

Перечисленные ниже ресурсы предоставляют дальнейшую информацию о виртуализации Red Hat Enterprise Linux.

A.1. Интернет-ресурсы

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ — сайт проекта Xen™, на основе которого был создан пакет kernel-xen. Кроме прочей информации, там можно найти двоичные файлы, исходные коды, а также полезные сведения, обзоры архитектур, документацию и пр.
  • Сайт сообщества Xen
  • http://www.libvirt.org/ — официальный сайт API виртуализации libvirt.
  • http://virt-manager.et.redhat.com/ — сайт графического приложения менеджера виртуальных машин (virt-manager).

A.2. Установленная документация

  • /usr/share/doc/xen-<версия>/ — содержит большой объем информации о гипервизоре Xen и соответствующих управляющих инструментах, примеры конфигурации, информацию об оборудовании и последнюю документацию Xen.
  • man virsh и /usr/share/doc/libvirt-<версия>— содержат списки команд и параметров virsh, а также подробную информацию о API библиотеки виртуализации libvirt.
  • /usr/share/doc/gnome-applet-vm-<версия> — содержит описание апплета GNOME, используемого для управления и наблюдения за локальными виртуальными машинами.
  • /usr/share/doc/libvirt-python-<версия> — в этом файле приведены соответствия Python для библиотеки libvirt. Пакет libvirt-python позволяет разработчикам Python создавать программы, взаимодействующие с библиотекой libvirt.
  • /usr/share/doc/python-virtinst-<версия> — содержит описание команды virt-install, которая используется при установке дистрибутивов Fedora и Red Hat Enterprise Linux на виртуальных машинах.
  • /usr/share/doc/virt-manager-<версия> — документация по работе с менеджером виртуальных машин.

Издание

Это руководство создано в формате DocBook XML 4.3.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Благодарности:
  • Техническая редакция секции паравиртуализированных драйверов: Дон Дьютил
  • Техническая редакция секции паравиртуализированных драйверов: Барри Донахью
  • Техническая редакция секции описания менеджера виртуальных машин: Рик Ринг
  • Техническая редакция секций описания использования XML-файлов конфигурации с virsh и виртуализированными съемными носителями: Майкл Кери
  • Техническая редакция секции описания производительности и программной совместимости: Марко Григал
  • Техническая редакция секции описания управления виртуальными машинами с помощью virsh: Юджин Тео
Книга опубликована с помощью Publican. Автор: Джеффри Ферн
Команда локализации Red Hat:
  • Упрощенный китайский
    • Ли Ви Лиу
  • Традиционный китайский
    • Честер Ченг
    • Терри Чанг
  • Японский
    • Кийото Хашида
  • Корейский
    • Ун-Джу Ким
  • Французский
    • Сэм Фридман
  • Немецкий
    • Хедда Питерс
  • Итальянский
    • Франческо Валенте
  • Португальский (Бразилия)
    • Глаусия Де Фрейтес
    • Летисия Де Лима
  • Испанский
    • Анжела Гарсиа
    • Глэдис Герреро
  • Русский
    • Юлия Пояркова