25 ноября 2008

Виртуализация: Red Hat vs Hyper-V vs VMWare

Краткое сравнение с точки зрения функций в таблицах.

Red Hat и Hyper-V:


К картинке можно добавить, что с точки зрения гостевых ОС, в Hyper-V поддерживаются только Windows и SLES 10 от Novell, а что касается Red Hat Enterprise Linux virtualization, то поддерживаются как Windows, так и Linux и UNIX-системы (включая NetBSD, FreeBSD и Solaris).

Red Hat и VMWare:

Выход Fedora 10



25 ноября 2008 года выходит десятая версия дистрибутива Fedora под кодовым названием "Cambridge".


Основные технологические улучшения:

NetworkManager — В NetworkManager появилась возможность создания общих соединений, что позволяет использовать систему с установленной Fedora в качестве общего хаба. При наличии единственного проводного или беспроводного подключения на втором беспроводном сетевом интерфейсе за несколько щелчков мыши пользователь может создать новую беспроводную ad-hoc сеть. Таким образом находящиеся вблизи устройства могут использовать данную сеть для доступа в Интернет.

PackageKit — PackageKit сделал очередной шаг в своем развитии и впервые расширил свои возможности функциями, направленными на улучшение открытого десктопа. Теперь PackageKit, используя информацию о зависимостях, расположенную в RPM пакетах, может искать кодеки для поддерживаемых форматов. Для этого PackageKit использует настроенные на хосте репозитории, и, после подтверждения пользователем, скачивает и устанавливает соответствующие пакеты. Примерно к моменту выхода Fedora 11 PackageKit должен получить дополнительные возможности по установке сходным образом шрифтов, а также приложений.

Plymouth/быстрая загрузка — Запуск устаревшей графической системы отображения процесса загрузки RHGB занимает продолжительное время, требует существенного объема памяти и дает значительную нагрузку на жесткий диск. Для RHGB требуется загрузка ряда графических компонент, которые всего лишь используются для вывода нескольких сообщений и отрисовки ползунка, демонстрирующего прогресс загрузки системы. Новый режим настройки ядра делает возможным ускорение и отображение процесса загрузки сопровождающегося графическими «спецэффектами». На момент выхода Fedora 10 по-настоящему насладиться графическими изысками Plymouth могут обладатели современных видеокарт от ATI. Однако, идет активная работа над тем, чтобы расширить базу поддерживаемых видеокарт.

RPM 4.6 — Первое серьезное обновление RPM за несколько прошедших лет содержит ряд существенных нововведений, исправлений ошибок и улучшений, таких как значительное сокращение размера пакетов, лучшая диагностика и проверка синтаксиса, экспериментальная поддержка более качественного алгоритма сжатия LZMA.

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

Appliance tools - The Appliance OS (AOS) и Appliance Creation Tool (ACT) вместе с новым знаком "FEDORA REMIX" позволяют независимым разработчикам создавать как новые, так и уже существующие сборки, используя удобные и хорошо задокументированные утилиты Fedora. Пользователи могут объединять как сторонние приложения, так и приложения, входящие в огромную вселенную свободного обеспечения Fedora, для создания своих инновационных решений. Знак Fedora Remix позволяет создателям независимых сборок показать взаимосвязь с проектом Fedora. Дополнительная информация — на сайте http://thincrust.net/

sectool — активно развивающийся инструмент аудита настроек безопасности и локальная IDS(система обнаружения вторжений) . Включает в себя ряд тестов для различных аспектов настройки системы, служб и т.д. В настоящий момент их около тридцати. Тесты независимы от языка программирования (Perl, Python, Bash, ...), и их можно писать самостоятельно (на сайте проекта доступна документация). Имеется как графический, так и интерфейс командной строки, гибкая система настроек, сравнение результатов проверок, отправка отчетов по электронной почте и т.д.

Полный список нововедений с технической точки зрения - https://fedoraproject.org/wiki/Releases/10/FeatureList

Новейшие возможности

Тема оформления "Solar" — как и предыдущие темы создана командой Fedora Artwork с использованием свободного и открытого инструментария.

GNOME 2.24 — Для полного списка нововведений обратитесь к Замечаниям к релизу. Вот лишь пара из них:
  • Новый апплет для планирования времени и более функциональная панель рабочего стола
  • Полностью обновленное приложение для телефонии и видеконференций Ekiga 3.0

KDE 4.1.2 - Для полного списка нововведений обратитесь к Замечаниям к релизу KDE 4.1.2. Нововведения включают в себя:

  • Восстановленный и интегрированный в систему KDE-PIM, приложение для управления личной информацией
  • Новые функции в файловом менеджере Dolphin и веб-браузере Konqueror
  • Улучшения композитного менеджера окон
  • Приложение для работы с картами, интегрированное с OpenStreetMap

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

22 ноября 2008

"День рождения" Russian Fedora в МИФИ (дополнение о respin)

Я не хотел озвучивать ответ на вопрос, который волновал многих, узнавших о проекте Russian Fedora, и узурпировать право рассказать о Fedora Respin у Аркадия Шейна. Поэтому я просто дам ссылку на сообщение в его блоге.

20 ноября 2008

"День рождения" Russian Fedora в МИФИ

Сегодня в МИФИ состоялись пресс-конференция и мероприятия, посвященные запуску проекта Russian Fedora. Десятая версия Fedora выходит через пять дней. К моменту ее выхода будет публично доступна инфраструктура (CMS, wiki, система контроля версий), относящаяся непосредственно к нашей локальной Russian Fedora. На сайте проекта и будет более подробно рассказано о конкретных шагах, которые уже сделаны и которые еще будут сделаны в ближайшее время. Это и локальный respin, и предстоящие мероприятия в ВУЗах, и Install Party, etc. Конечно, обо всем я постараюсь писать в этом блоге. Ну а сегодня есть силы только выложить фото :) После официальной части у нас было достаточно времени на живое общение за кружечкой Гиннеса с Максом Спеваком, который, нужно отметить, в России впервые :)

1) Пресс-конференция. Кстати, на слайде кратко - отличия Fedora от Ubuntu :)

2) Какой "день рождения" без торта

3) Основной спикер - Макс Спевак (Лидер Fedora Project с 2006 по 2008 год, в настоящее время отвечает в Red Hat за стратегию работы с коммьюнити)

4) Актовый зал МИФИ. Правда, часть из присутствующих студентов как раз перед фото сорвалась на лекции. Не успел сфотографировать зал до того :)

15 ноября 2008

Настройка Device-Mapper Multipath в RHEL 5

В данном посте я хочу описать шаги для настройки Multipath при помощи dm-multipath. Device Mapper Multipathing (DM-Multipath) позволяет "собрать" несколько маршрутов ввода/вывода между сервером и дисковым массивом в единое целое, и рассматривать доступный по нескольким путям массив как одно мета-устройство. Например, если сервер с двумя двух-портовыми HBA подключен к одному и тому же массиву, то сервер, в самом простейшем случае, будет "видеть" четыре устройства /dev/sd{a,b,c,d}. При помощи dm-multipath можно собрать из них агрегирующее все четыре пути мета-устройство /dev/dm-N, обеспечив прозрачную для операционной системы и приложений конфигурацию, отказоустойчивую в случае выхода из строя HBA, кабеля или коммутатора (если каждый HBA подключен через свой коммутатор).

Хотя, по информации, приведенной в этом посте, можно повторить все шаги и настроить dm-multipath, но информация будет явно не достаточна для понимания всех деталей работы и команд. Для дальнейшего изучения материала рекомендую обратиться к официальной документации Red Hat - книге "Device-Mapper Multipath Configuration and Administration", доступной на сайте Red Hat как в виде PDF, так и HTML.

Далее рассмотрим настройку dm-multipath для конфигурации представленной на рисунке:Имеется iSCSI-target, доступная по двум интерфейсам в двух сетях: 192.168.0.0/24 и 192.168.1.0/24. Соответственно на сервере vm01 есть два сетевых интерфейса, каждый из которых подключен к одной из двух сетей. На сервере установлен iSCSI-инициатор, и сервер может обращаться к доступному ему целевому устройству по двум различным путям. Попробуем организовать конфигурацию, устойчивую к отказу одного из путей, при помощи dm-multipath.

Для начала убедимся, что на vm01 установлен пакет device-mapper-multipath, и загружены модули ядра dm_multipath и dm_round_robin:

[root@vm01 ~]# rpm -qa | grep multipath
device-mapper-multipath-0.4.7-12.el5
[root@vm01 ~]# lsmod | grep dm_
dm_round_robin 7617 0
dm_multipath 21577 1 dm_round_robin
dm_snapshot 20709 0
dm_zero 6209 0
dm_mirror 28869 0
dm_mod 58201 9 dm_multipath,dm_snapshot,dm_zero,dm_mirror

При необходимости установите пакет. Если модули не загружены, то воспользуйтесь командой modprobe. Далее запускаем процесс обзора для поиска iSCSI-целей. При необходимости можно обратиться к моему посту "Настройка iSCSI target и initiator в RHEL/Fedora" или к любой другой доступной документации.

[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.114:3260
192.168.0.114:3260,1 iqn.2003-12.net.markelov:disk1
[root@vm01 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.1.114:3260
192.168.1.114:3260,1 iqn.2003-12.net.markelov:disk1

Перезапускаем демон iscsi и проверяем вывод команды fdisk -l для того, чтобы убедиться, что сервер "видит" подключенную цель:

[root@vm01 ~]# service iscsi restart
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sda doesn't contain a valid partition table

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Disk /dev/sdb doesn't contain a valid partition table

Как видно, помимо локального /dev/xvda, появились два новых устройства - /dev/sda и /dev/sdb - одинакового размера. Можно убедиться, что это одно и тоже устройство, сравнив идентификаторы:

[root@vm01 ~]# scsi_id -g -s /block/sda
16465616462656166313a3100000000000000000000000000
[root@vm01 ~]# scsi_id -g -s /block/sdb
16465616462656166313a3100000000000000000000000000

Теперь приступаем к правке конфигурационного файла демона multipathd - /etc/multipath.conf. Необходимо закомментировать секцию, определяющую, для каких устройств multipathing выключен:

#blacklist {
# devnode "*"
#}

По умолчанию он был выключен для всех устройств - devnode "*". Далее необходимо раскомментировать секцию с комментариями:
## This is a template multipath-tools configuration file
## Uncomment the lines relevent to your environment
В этом шаблоне есть практически все, что нам нужно. Единственное, что мы изменим, это в path_grouping_policy пропишем failover. В следующей секции описан blacklist, который определяет такие устройства, как floppy-дисководы и IDE-диски. Его также можно раскомментировать. При необходимости добавьте свои устройства. Теперь можно запустить демон multipathd:

[root@vm01 ~]# chkconfig multipathd on
[root@vm01 ~]# service multipathd start

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

[root@vm01 ~]# fdisk -l

...

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-2 doesn't contain a valid partition table

Цель iqn.2003-12.net.markelov:disk1, очевидно, не содержит таблицы разделов. Создадим ее. Однако, команду fdisk нельзя использовать для работы с разделами на устройствах /dev/dm-*. Вместо этого мы создадим разделы на /dev/sda или /dev/sdb:

[root@vm01 ~]# fdisk /dev/sda
... создаем, например, два раздела...
[root@vm01 ~]# partprobe
[root@vm01 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes

...

Disk /dev/sda: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 509 2619283 83 Linux
/dev/sda2 510 1018 2619314 83 Linux

Disk /dev/sdb: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 509 2619283 83 Linux
/dev/sdb2 510 1018 2619314 83 Linux

Disk /dev/dm-2: 5368 MB, 5368709120 bytes
166 heads, 62 sectors/track, 1018 cylinders
Units = cylinders of 10292 * 512 = 5269504 bytes

Device Boot Start End Blocks Id System
/dev/dm-2p1 1 509 2619283 83 Linux
/dev/dm-2p2 510 1018 2619314 83 Linux
[root@vm01 ~]#

Наконец осталось создать из наших разделов устройства /dev/dm-*, для того, чтобы с ними далее можно было работать:

[root@vm01 ~]# kpartx -a /dev/dm-2

После этого появятся два новых устройства - /dev/dm-3 и /dev/dm-4, - которые и являются нашими двумя ранее созданными разделами. Можно создать файловую систему и смонтировать ее:

[root@vm01 ~]# mkfs.ext3 /dev/dm-3
[root@vm01 ~]# mkdir /mnt/dm3
[root@vm01 ~]# mount /dev/dm-3 /mnt/dm3/

Далее можно работать с разделом /dev/dm-3 обычным образом. Просмотреть состояние multipathed-устройств можно командой:

[root@vm01 ~]# multipath -ll
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [active][ready]

По выводу:

[root@vm01 ~]# dmsetup ls --target multipath
mpath0 (253, 2)

можно сопоставить устройство /dev/mapper/mpath0 и /dev/dm-2. Теперь промоделируем выход из строя одного из маршрутов:

[root@vm01 ~]# multipath -ll
sdb: checker msg is "readsector0 checker reports path is down"
mpath0 (16465616462656166313a3100000000000000000000000000) dm-2 IET,VIRTUAL-DISK
[size=5.0G][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
\_ 0:0:0:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 1:0:0:1 sdb 8:16 [failed][faulty]

Тем не менее наше устройство доступно, что легко проверить, записав какую-нибудь информацию в /mnt/dm3. После этого можно "поднять" интерфейс eth1 и провести тот же эксперимент с eth0.

Выступление Макса Спевака (Fedora Project) в МИФИ 20 ноября


Я уже писал в блоге об анонсе проекта Russian Fedora. В течение этого месяца в ходе обсуждений инициатива обросла конкретными идеями, и были сделаны первые шаги в их воплощении. Инициатива Russian Fedora распадается на два направления - техническое и организационное. В качестве одного из шагов во втором направлении 20 ноября состоится пресс-конференция, а после нее - встреча с лидером Fedora Project (с 2006 по 2008) Максом Спеваком (Max Spevack). В настоящее время Макс отвечает за стратегию Red Hat по работе с комьюнити. Также на встрече будет проанонсирован ряд конкретных шагов (в том числе в техническом плане), осуществление которых планируется в рамках Russian Fedora, и направленных на то, чтобы сделать Fedora дистрибутивом, подходящим для российских пользователей «из коробки», а также инициативы в плане локализации. На встрече помимо Макса Спивака планируются выступления руководителей Европейского Red Hat и компании VDEL.
О подробностях регистрации на мероприятие читайте на opennet.ru.

12 ноября 2008

Статья "Создание сервера сетевой установки Fedora/RHEL"


В ноябрьском номере журнала "Системный администратор" выходит моя статья "Создание сервера сетевой установки Fedora/RHEL".

"Дистрибутив Fedora использует для установки весьма мощную и многофункциональную программу Anaconda, поддерживающую различные режимы работы и сценарии инсталляции. Вместе с рядом других технологий, в частности Spacewalk-сервером, вы можете значительно облегчить процесс развертывания и обслуживания вашей Linux-инфраструктуры.
Однако сегодня мы оставим Spacewalk-сервер в стороне, и рассмотрим, как можно автоматизировать самую начальную стадию жизненного цикла серверов/рабочих станций – их развертывание. При этом в процессе установки мы постараемся обойтись без вмешательства оператора при помощи так называемого сервера сетевой установки.

Для организации такого сервера мы используем следующие технологии:
  • PXE (Pre-Boot Execution Environment)
  • DHCP-сервер
  • TFTP-сервер
  • Kickstart-файлы
  • Сетевой репозиторий"
Примерно через месяц с разрешения редакции статья будет выложена на сайте markelov.net.

11 ноября 2008

Новые версии Red Hat Network Satellite 5.2 и Spacewalk 0.3

В начале этого месяца вышла новая версия open source решения для управления Linux-инфраструктурой - Spacewalk. Также обновился основанный на Spacewalk продукт Red Hat Network Satellite Server. К сожалению, планы по поводу возможности установки Spacewalk на Fedora перенесены на следующую версию - 0.4, которая должна появится в середине декабря. Пока что в качестве базовой ОС необходимо использовать Red Hat Enterprise Linux (или CentOS и т.п.). Из нововведений можно отметить новый API, возможность синхронизации серверов Spacewalk между собой, улучшенную систему поиска, исправление более четырех десятков различных ошибок.

Что касается новой версии Red Hat Network Satellite 5.2, основное - это возможность использовать в качестве базовой ОС Red Hat Enterprise Linux 5 вместо 4 (я в октябре экзамен сдавал еще на "четверке") и, раз перешли на RHEL 5, то в качестве СУБД - Oracle Database 10g Release 2 Standard Edition и Enterprise Edition, вместо девятой версии.

09 ноября 2008

Настройка iSCSI target и initiator в RHEL/Fedora

Как известно, при использовании существующей сетевой инфраструктуры iSCSI представляет собой недорогую альтернативу FC, а для целей обучения и тестирования вообще не заменим, поскольку, в ряде случаев, можно обойтись без дорогостоящего оборудования. Безусловно, существует и множество "боевых" конфигураций, когда по тем или иным причинам стоит отдать предпочтение iSCSI. В этом посте я хочу кратко описать настройку iSCSI target и iSCSI initiator в Red Hat Enterprise Linux и Fedora. Нужно отметить, что до версии RHEL 5.2 поддержка iSCSI target присутствовала в статусе Technology Preview. Поддержка же iSCSI initiator присутствует в полном объеме еще с Red Hat Enterprise Linux 4.

Для тестов используем две машины: vm01, которая будет экспортировать раздел /dev/xvda5, и vm02, на которой настроим инициатор.

1) Настройка iSCSI target

Для начала устанавливаем пакет scsi-target-utils и запускаем демон tgtd:
[root@vm01 ~]# yum install scsi-target-utils
...
[root@vm01 ~]# service tgtd start
[root@vm01 ~]# chkconfig tgtd on

Теперь создаем наше целевое устройство. В качестве имени я выбрал iqn.2003-12.net.markelov:disk1

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2003-12.net.markelov:disk1

В моем случае я добавляю к целевому устройству свежесозданный раздел /dev/xvda5:

[root@vm01 ~]# tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/xvda5

Теперь разрешим доступ хосту vm02 с IP-адресом 192.168.0.109:

[root@vm01 ~]# tgtadm --lld iscsi --op bind --mode target --tid 1 -I 192.168.0.109

Проверяем:

[root@vm01 ~]# tgtadm --lld iscsi --op show --mode target
Target 1: iqn.2003-12.net.markelov:disk1
System information:
Driver: iscsi
Status: running
I_T nexus information:
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0
Backing store: No backing store
LUN: 1
Type: disk
SCSI ID: deadbeaf1:1
SCSI SN: beaf11
Size: 964M
Backing store: /dev/xvda5
Account information:
ACL information:
192.168.0.109
[root@vm01 ~]#

Под конец не забудьте прорубить "дырку" в брандмауэре для порта 3260/tcp, который используется по умолчанию.

2) Настройка iSCSI initiator

Устанавливаем пакет iscsi-initiator-utils и запускаем демон iscsi:
[root@vm02 ~]# yum install iscsi-initiator-utils
...
[root@vm02 ~]# service iscsi start
iscsid is stopped
Turning off network shutdown. Starting iSCSI daemon: [ OK ]
[ OK ]
Setting up iSCSI targets: iscsiadm: No records found!
[ OK ]
[root@vm02 ~]# chkconfig iscsi on

При запуске мы получаем совершенно справедливое сообщение, что не сконфигурирована ни одна из целей. Запускаем процесс обзора для поиска целей на хосте vm01 c IP-адресом 192.168.0.100:

[root@vm02 ~]# iscsiadm -m discovery -t sendtargets -p 192.168.0.100:3260
192.168.0.100:3260,1 iqn.2003-12.net.markelov:disk1

В итоге будут созданны две поддиректории с информацией о цели и хосте:

[root@vm02 ~]# ls /var/lib/iscsi/nodes/
iqn.2003-12.net.markelov:disk1
[root@vm02 ~]# ls /var/lib/iscsi/send_targets/
192.168.0.100,3260

Просмотреть информацию можно командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260
node.name = iqn.2003-12.net.markelov:disk1
node.tpgt = 1
...

Теперь, используя содержимое /var/lib/iscsi/nodes/ и /var/lib/iscsi/send_targets/, демон iscsi при каждом перезапуске будет подключать наши ранее обнаруженные цели. Также процессом подключения/отключения можно управлять при помощи утилиты iscsiadm:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -l
Login session [iface: default, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]
[root@vm02 ~]#

Теперь команда fdisk покажет наш раздел /dev/sda, экспортированный с vm01:

[root@vm02 ~]# fdisk -l

Disk /dev/xvda: 17.1 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
...
Disk /dev/sda: 1011 MB, 1011677184 bytes
32 heads, 61 sectors/track, 1012 cylinders
Units = cylinders of 1952 * 512 = 999424 bytes

Disk /dev/sda doesn't contain a valid partition table

После команды

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -u
Logout session [sid: 2, target: iqn.2003-12.net.markelov:disk1, portal: 192.168.0.100,3260]

в выводе fdisk мы увидим только /dev/xvda. Однако, после рестарта демона iscsi, цель снова появиться в списке устройств. Для удаления всей информации о цели воспользуйтесь командой:

[root@vm02 ~]# iscsiadm -m node -T iqn.2003-12.net.markelov:disk1 -p 192.168.0.100:3260 -o delete
[root@vm02 ~]# ls /var/lib/iscsi/nodes/
[root@vm02 ~]#

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

Для того, чтобы лучше понять лог выполненных команд, рекомендую ознакомиться со следующими источниками:
  • /usr/share/doc/scsi-target-utils-*
  • tgtadm(8)
  • iscsiadm(8)

07 ноября 2008

AMD и Red Hat: живая миграция виртуальных машин между ЦП AMD и Intel

Достаточно интересный пятиминутный ролик на youtube.com , показывающий процесс "живой миграции" виртуальной машины между серверами, работающими на платформах AMD и Intel. Насколько я знаю, у VMware такой возможности нет, а у Microsoft, собственно, нет и "живой миграции" :) Помимо прочего, можно посмотреть как выглядит интерфейс управления системы виртуализации с открытым исходным кодом oVirt. Как ожидается, к промышленному применению система виртуализации будет готова к концу года, а тестировать ее можно уже и сейчас.
Пресс релиз.

03 ноября 2008

EX401 is done!

По сравнению с предыдущими лабами EX401 показался относительно простым. 3,5 часа - "внедрение", 1,5 часа - задачи виртуализации. 3/5 от RHCA - сделано :)