Содержание
Возможность одновременно запускать на одном компьютере две независимо работающие операционные системы полезна как минимум трём категориям лиц.
Первой являются системные администраторы, которые получают возможность отлаживать взаимодействие сервера и рабочих станций, располагая единственным компьютером. Зачастую имеются в виду Unix-сервер и рабочая станция под управлением Windows, потому что вариант Unix+Unix или Windows+Windows можно почти полностью отладить и в рамках одной системы.
Ко второй категории относятся разработчики сетевых или кроссплатформенных приложений, исходные тексты которых требуется компилировать и отлаживать на нескольких архитектурах одновременно.
В третью категорию входят пользователи, решающие попробовать установить новую систему, но не желающие оставаться с нею один на один. Многим, кто слышал о Линуксе и мечтает с ним познакомиться, но боится порвать пуповину, связывающую их с изделиями Microsoft, можно посоветовать этот вариант.
Мне по ряду причин приходится программировать как под Windows, так и под Линукс, причём эти программы не взаимосвязаны. Жёсткий диск поделен на два логических раздела, на которых установлены Windows 2000 Professional и ALT Linux Master 2.2. Возможность быстро переключаться из одной системы в другую привлекает меня тем, что позволяет с лёгкостью менять занятие: встретилось препятствие в Visual Studio.NET - начинаю составлять Spec-файл для RPM. Надоел rpmbuild - возвращаюсь в FAR и пишу сценарий на VBS.
По моему мнению, лучшей программой для запуска одной операционной системы внутри другой является программа VMWare.
Первые несколько лет после появления VMWare я испытывал определённый скептицизм по поводу «компьютера в компьютере», полагая, что ни скорости процессора, ни количества памяти в моём Пентиуме, а потом Celeron'e для таких задач недостаточно. Не убеждали в обратном даже периодически появлявшиеся в Интернете снимки экрана, на которых StarCraft или Duke3D представали запущенными внутри KDE или GNOME.
Рисунок 1. Внутри Windows запущены две виртуальных машины с ALTLinux Master и Knoppix Linux; Веб-браузер в Knoppix'e загружает страницы с Веб-сервера, запущенного в ALTLinux'e
Как обстоят дела в действительности? Не считая памяти, выделяемой под виртуальную машину (её размер вы устанавливаете сами) VMWare for Windows версии 4.0.5 занимает всего-навсего 35 мегабайт ОЗУ:
- 9 мегабайт занимает оболочка;
- 18 мегабайт занимает виртуальная машина;
- три сервиса, занимающихся поддержкой виртуальной локальной сети, занимают в сумме 8 мегабайт.
Инсталляция VMWare на диске требует 29 мегабайт. Конфигурация одной виртуальной машины занимает на диске меньше мегабайта.
Скорость выполнения в виртуальной среде поможет охарактеризовать следующая таблица:
| Действие или данные | Без VMWare | Под VMWare |
|---|---|---|
| grep bogomips /proc/cpuinfo | 2660 | 2614 |
| архивация 100 мегабайт данных в /usr/share/doc | 31 секунда | 40 секунд |
Разумеется, для серьёзной оценки подобных измерений не может быть достаточно, но рядовому пользователю важнее субъективное впечатление, а оно у меня таково, что VMWare практически не съедает производительности ни внутренней, гостевой системы, ни внешней.
Сами разработчики характеризуют свой продукт, как тонкую программную прослойку между оборудованием и операционными системами, эффективная работа которой достигается благодаря полному использованию возможностей процессора Intel. VMWare аппаратными средствами перехватывает обращения из виртуальной среды к портам ввода-вывода, через которые производится обмен данными с оборудованием, а также вызовы привилегированных команд процессора, требующих выполнения в ring-0. Пройдя через VMWare, эти запросы превращаются в вызовы подпрограмм внешней ОС.
Схема «гостевая ОС - аппаратная виртуализация средствами Intel - программная виртуализация средствами VMWare - внешняя ОС» в принципе не может работать с такой же скоростью, как и запуск гостевой ОС непосредственно, но в целом минимизация накладных расходов, которой удалось добиться разработчикам VMWare, впечатляет, особенно с учётом того перечня возможностей, которые VMWare предоставляет гостевой ОС.
Какую систему внутри какой запускать? Я остановился на схеме «Linux внутри Windows», потому что Linux лучше, чем Windows, подходит для запуска в виртуальной среде по следующим причинам:
- Линукс можно запустить без графического интерфейса;
- в Линуксе легче варьировать количество запускаемых сервисов, уменьшая таким образом размер ОЗУ и скорость процессора, требуемые для комфортной работы;
- Линукс-приложения имеют более модульную структуру и лучше приспособлены для запуска в среде с малым количеством ресурсов;
- в Линуксе проще отключить использование тех или иных физических устройств, которые в виртуальной среде не нужны, отсутствуют или имеют другие параметры.
Важно, что, в отличие от Windows, для Линукса всё перечисленное может быть выполнено в момент загрузки почти или полностью автоматически. Для этого используются:
- механизм т.н. уровней выполнения, или runlevels;
- утилиты типа chconf.
У Windows, да не проклянут меня приверженцы Линукса, есть некоторые преимущества в качестве внешней ОС:
- в отличие от Линукса, в котором при инсталляции VMWare требуется компилировать драйверы устройств, если только конкретный дистрибутив и конкретная версия ядра не поддерживаются VMWare «из коробки» (ALTLinux не поддерживается), при инсталляции под Windows такой необходимости нет;
- в Windows лучше реализован переход в т.н. спящий режим (suspending mode), что делает её более удобной для задач типа «включил - проверил почту - выключил» (примечание: то же самое VMWare умеет делать и с Линуксом!);
- VMWare требует, чтобы внешняя ОС работала в графическом режиме.
Как соотносятся возможности ОС с последним требованием?
- Windows имеет более привычный, «зализанный» и быстрый графический интерфейс, но не способна работать без его загрузки;
- Линукс имеет сравнительно более медленную, громоздкую и разношёрстную графику, но способен работать и без неё.
Таким образом, текстовый интерфейс внутри быстрой графической системы (Линукс в VMWare в Windows) по сравнению с графическим - внутри медленной (Windows в VMWare в Линуксе) оказывается проще, компактнее и быстрее. При этом в Линуксе остаётся доступной и графика, которую можно по мере необходимости загружать командой startx.
Уровни выполнения служат для обозначения некоторых ситуаций, возникающих в процессе работы Юникс-подобной операционной системы. При возникновении той или иной ситуации система должна выполнить соответствующий набор действий. Всего уровней выполнения, как правило, семь:
- 0 - завершение работы и выключение компьютера;
- 1 - Single mode, т.е. однопользовательский режим для системного администратора, используемый в нештатных ситуациях, например, при восстановлении данных;
- 2 - загрузка в текстовый режим без поддержки сети;
- 3 - загрузка в текстовый режим;
- 4 - не используется;
- 5 - загрузка в графический режим;
- 6 - завершение работы и перезагрузка компьютера.
Переключением системы с одного уровня на другой занимается утилита init, а списки команд, которые должны выполняться на разных уровнях, находятся в файле /etc/inittab.
Далее, для каждого физического устройства и постоянно работающего приложения, а также в некоторых других случаях, имеются файлы-сценарии в каталоге /etc/init.d. Их запуск, остановку, проверку состоянии, перечитывание настроек и прочие действия принято выполнять командой service.
В каталогах /etc/rc«номер-уровня».d находятся ссылки (symbolic links) на те сценарии, которые нужно выполнять при переходе соответствующий уровень. Для управления ими служит утилита chkconfig.
Следовательно, для загрузки Линукса в виртуальной среде можно использовать незанятый уровень 4, на котором командой chkconfig необходимо отключить ненужные драйверы устройств и сервисы. Это не означает, что в ходе работы их нельзя будет запустить вручную командой service, просто они не станут загружаться автоматически при старте системы. Я отключил загрузку USB, Kudzu, PCMCIA, Apache и XFS (X Font Server).
Если в дополнение к этому потребуется отключить те сервисы, которые init запускает не с помощью сценария /etc/rc.d/rc (этот сценарий, собственно, и отвечает за запуск команд из каталога /etc/rc«runlevel».d), а непосредственно, отредактируйте /etc/inittab. В конфигурации по умолчанию таких пунктов нет, но в качестве примера можно привести mgetty, запускаемый для приёма входящих звонков через модем.
Каким образом сообщить Линуксу, на какой уровень ему следует загрузиться? Ответ: через параметры, передаваемые ядру загрузчиком. В настоящее время в составе операционной системы ALT Linux поставляется два загрузчика: GRUB (Grand Unified BootLoader) и LiLo (Linux Loader). В зависимости от того, каким из них вы пользуетесь, вам потребуется отредактировать файл /boot/grub/menu.lst или /etc/lilo.conf. Кроме того, после редактирования lilo.conf не забудьте запустить утилиту lilo, которая запишет настройки в загрузочный сектор.
В файле настройки найдите секцию, отвечающую за запуск Линукса. Скопируйте её в конец файла, исправьте заголовок, добавьте в список параметров номер уровня «4» и удалите из него параметр «vga=nnn». Пример для LiLo:
image=/boot/vmlinuz-up label=vmware-linux root=/dev/hda4 initrd=/boot/initrd-up.img append=" 4" read-only
Пример для GRUB:
title Linux text-mode, for virtual environment kernel (hd0,3)/boot/vmlinuz-up root=/dev/hda4 4 initrd (hd0,3)/boot/initrd-up.img
Обратите внимание, что это именно примеры, а не готовые образцы для Cut'n'Paste: значения параметра root, содержащего имя раздела с корневой файловой системой, на вашем компьютере, скорее всего, будут другими!
Как и все параметры, которое ядро не в состоянии распознать, указанный номер «4» будет передан утилите init, которую ядро запускает по завершении инициализации. На основании этого числа init начнёт загрузку нужных команд из /etc/inittab.
Удаление параметра «vga=nnn» в первую очередь выразится в том, что текстовая консоль tty1 станет действительно текстовой и с неё исчезнет эмблема-пингвин: в виртуальной среде подобные красивости излишни.
Теперь для запуска Линукса непосредственно вы должны выбирать в меню загрузчика первоначальный пункт, а для запуска в VMWare - тот, который создали только что.
Уровни выполнения предоставили нам возможность выбирать, какие драйверы и сервисы должны загружаться автоматически при старте Линукса внутри VMWare, а какие - при аппаратном старте. Однако остаётся ещё одна проблема - проблема устройств, которые присутствуют и в физической конфигурации, и в среде VMWare, но в обоих случаях имеют разный тип. Дело в том, что VMWare не предоставляет запускаемой операционной системе прямого доступа ко всему физическому оборудованию, поскольку оно уже используется внешней системой и не может быть поделено. Вместо этого в среде VMWare присутствуют т.н. виртуальные устройства, т.е. программные имитации устройств физических. Вот как выглядит таблица соответствий на моём собственном ПК:
| Вид устройства | Реально установлено в компьютере | Эмулируется в VMWare |
|---|---|---|
| Звуковая карта | Cirrus Logic Crystal CS4281 PCI Audio | Ensoniq ES1371 [AudioPCI-97] |
| Сетевая карта | Realtek RTL-8139 | AMD 79c970 [PCnet LANCE] |
| Видеокарта | NVidia GeForce2 DDR | VMWare PCI SVGA (FIFO) |
| USB | VIA Technologies VT82C586B PIPC Bus Master IDE | Intel 82371AB PIIX4 USB |
| Hard-диск и CDROM | Maxtor 6Y080L0, CW088D ATAPI CD-R/RW | VMWare Virtual IDE Hard/CDROM Drive |
Таким образом, например, графическая система Юникса, X Window, должна использовать тот или иной драйвер видеокарты и разрешение экрана в зависимости от того, в каком окружении она запускается. Это же относится и к работе в сети, и к воспроизведению звука, и ко всему остальному.
Кстати, в документации к VMWare говорится, что в виртуальной среде эмулируется SoundBlaster, а вовсе не ES1371, и приведён образец файла /etc/modules.conf. В «фирменном» варианте звук у меня не заработал, а обнаруженный Kudzu Ensoniq играет без проблем.
Поддержка USB-устройств требует небольшого разбирательства. Во-первых, существует два типа USB-шин и соответственно два Линукс-драйвера для их поддержки: usb-uhci и ehci-hcd. В виртуальной машине эмулируется только шина первого типа, поэтому загрузка второго драйвера будет приводить к сообщениям об ошибках:
Loading USB interface (usb-uhci): [ OK ]
/lib/modules/2.4.20-alt11-up/kernel/drivers/usb/hcd/ehci-hcd.o: init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.
You may find more information in syslog or the output from dmesg
/lib/modules/2.4.20-alt11-up/kernel/drivers/usb/hcd/ehci-hcd.o: insmod /lib/modules/2.4.20-alt11-up/kernel/drivers/usb/hcd/ehci-hcd.o failed
/lib/modules/2.4.20-alt11-up/kernel/drivers/usb/hcd/ehci-hcd.o: insmod usb-interface1 failed
Disabling USB interface (ehci-hcd): [ OK ]
Mounting USB filesystem: [ OK ]
Эти сообщения можно игнорировать, потому что на работоспособности устройств они не сказываются. Их можно убрать, стерев из /etc/modules.conf все строки, в которых упоминается ehci-hcd, например:
alias usb-interface1 ehci-hcd
Во-вторых, USB-сервис Линукса при запуске в виртуальной среде не обязательно загружать автоматически, потому что USB-устройство подключается VMWare только по явному указанию пользователя: sudo chkconfig --level 4 usb off. Рассмотрим правильную последовательность действий на примере работы с флэш-накопителем:
- подключите USB-устройство к компьютеру и дождитесь, пока внешняя Windows его распознает;
- в меню оболочки VMWare выберите пункт Edit->Removable Devices->USB Port 1/2;
- дождитесь, пока Windows отключит USB-устройство (это сделает VMWare, чтобы обеспечить себе монопольный доступ к нему) и значок устройства появится в строке статуса окна VMWare;
- запустите в гостевом Линуксе поддержку USB: service usb start;
- начинайте работать с USB-устройством, например: mount /dev/sda1 /mnt/disk.
По умолчанию, если в момент физического подключения USB-устройства фокус ввода находится в окне VMWare, первые три шага будут выполнены автоматически. Эта опция задаётся в свойствах виртуальной машины.
Жёсткий диск, floppy-дисководы и CD-ROM относятся к тем типам устройств, которые стандартизованы настолько, что в подавляющем большинстве случаев работают в любой ОС без всякой специальной настройки. Различные режимы оптимизации для IDE-устройств наподобие Ultra-DMA и PIO>=3, задаваемые в /etc/sysconfig/harddisks, можно оставить в виртуальной среде без изменений, потому что VMWare, скорее всего, будет их либо поддерживать, либо просто игнорировать. Также к числу стандартизованных устройств можно отнести COM-, LPT- и PS/2-порты.
Стандартность дискового устройства означает, что в виртуальную среду без перенастройки гостевой ОС можно подключать как настоящий физический диск, так и образ диска, расположенный в файле.
Рассмотрим вариант с настоящим физическим диском. В меню GRUB должны присутствовать следующие пункты:
- для запуска Линукса;
- для запуска Windows;
- для запуска Линукса внутри VMWare (runlevel=4).
Последовательность наших действий такова:
- при загрузке компьютера в меню GRUB выбираем Windows;
- в Windows запускаем VMWare;
- в VMWare запускаем Линукс-машину, причём в её настройках в качестве жёсткого диска используем настоящий физический диск;
- внутри виртуальной машины повторно запускается GRUB, расположенный в загрузочной записи жёсткого диска;
- в меню GRUB на этот раз выбираем пункт Linux/runlevel=4.
Рисунок 3. GRUB загрузился с физического диска внутри VMWare и готов запустить ALTLinux в текстовом режиме
Образ диска в файле полезен в следующих случаях:
- проба LiveCD-дистрибутива или Bootable-CD без записи на болванку (именно таким образом я запустил BLin, включив в VMWare BIOS bootable CD-ROM);
- подготовка образа физического диска с установкой ПО для последующего клонирования на другой компьютер;
- организация корневого раздела для гостевой системы без переразбиения физического диска.
Обращаться из виртуальной машины к физическим дискам следует крайне осторожно. Хотя VMWare и использует в этом случае драйверы внешней ОС, работа с диском производится не на уровне файловой системы, а на уровне физических секторов, поскольку именно на этом уровне VMWare перехватывает обращения драйвера гостевой ОС к диску. Из этого вытекают следующие ограничения:
- гостевая ОС не будет получать уведомлений, когда файловая система изменяется внешней ОС;
- теоретически возможно, но не проверялось мною, что внешняя ОС получает уведомление, когда VMWare модифицирует данные на диске на нижнем уровне и файловая система должна быть перечитана;
- внешняя ОС должна блокировать обращения из VMWare к критически важным файлам, но в случае с Windows 2000 этого не происходит, потому что Windows производит блокировку таких файлов не на уровне секторов, а на уровне файловой системы (например, попробуйте открыть из VMWare файл /mnt/windows/winnt/system32/config/system).
На практике в VMWare существует ещё одно ограничение: изменения в файлах, сделанные во внешней ОС после запуска гостевой, не видны в гостевой системе даже после перемонтирования соответствующей файловой системы. В конце концов эту проблему я предпочёл решить так: открыл в Windows нужные папки в сетевой доступ (не забыв указать $ в конце сетевого имени и назначив максимально строгие права доступа!), а в Линуксе подключился к ним smbmount'ом через виртуальную локальную сеть.
После нескольких неприятных случаев порчи и пропажи данных выяснился и такой факт: даже если в свойствах виртуальной машины выбрана прямая работа с физическим диском, это ещё не означает, что при записи из гостевой системы данные действительно будут попадать на диск. Вместо этого по умолчанию VMWare записывает их в служебный файл-образ, имеющий расширение RAW или VMDK. Такое решение преследует две цели:
- уберечь данные на физическом носителе от возможной порчи;
- предоставить пользователю возможность восстанавливать (revert-back) состояние диска на любой из моментов времени, в которые делался «снимок» системы (snapshot).
Нетрудно видеть, что такая возможность будет полезна многим специалистам. Например, вирусолог с её помощью сможет не только отслеживать изменения, которые производит вирус, но и повторять интересующие его ситуации многократно.
Чтобы заставить VMWare писать данные непосредственно на диск, в свойствах виртуальной машины на закладке диска выберите Advanced, затем Independent и Persistent. Именно этот вариант показан на соответствующем снимке экрана.
При инсталляции VMWare добавляет во внешнюю ОС несколько логических сетевых интерфейсов, не имеющих привязки ни к какой физической сетевой карте. Эти интерфейсы предназначены для связи с гостевыми ОС. Как только что говорилось, в гостевой среде VMWare имитирует сетевую карту AMD 79xxx. Сеть TCP/IP между гостевой и внешней ОС (далее - гостевая сеть) может иметь один из трёх типов:
- изолированная, то есть гостевая ОС видна только из внешней, и видит только внешнюю;
- защищённая, то есть гостевая ОС может обращаться в наружную сеть через NAT во внешней ОС, и при этом видна только из внешней ОС, но не из наружной сети;
- прозрачная, то есть через IP-мост (bridge) в гостевую сеть транслируются все IP-пакеты из наружной сети, а из гостевой сети - в наружную.
В первых двух режимах VMWare предоставляет в гостевую сеть сервис DHCP, чтобы гостевая ОС могла автоматически загружать настройки TCP/IP. В третьем режиме гостевая система сможет пользоваться любым незанятым IP-адресом из наружной сети: внешняя ОС модифицирует свою ARP-таблицу, добавляя в неё IP-адрес виртуальной сетевой карты из гостевой системы. Благодаря этому гостевая система станет «видна» в настоящей сети.
VMWare позволяет гибко манипулировать виртуальными сетями, создавая т.н. Custom-интерфейсы, добавляя больше одной сетевой карты в гостевую среду и т.д. Эти настройки производятся в меню Edit->Virtual Network Settings. На практике подавляющему большинству пользователей будет достаточно одного из трёх стандартных режимов.
Рисунок 7. Внешняя ОС открывает гостевой FTP-сервер в наружную сеть с помощью перенаправления портов
В состав VMWare входят т.н. VMWare Tools - пакет ПО, предназначенный для инсталляции в гостевой ОС. Доступны пакеты для Линукса, FreeBSD, Windows и Novell Netware. Пакеты имеют ISO-формат, то есть в виртуальной среде выглядят расположенными на CD-диске, после того как соответствующий ISO-образ подключен к CD-приводу. VMWare Tools состоят из следующих компонентов:
- драйвер сетевой карты VMXnet;
- драйвер видеокарты для XFree86 версий 3.x, 4.x и 4.2;
- утилита для редактирования настроек виртуальной среды из гостевой системы и синхронизации буфера обмена между внешней и гостевой ОС;
- демон синхронизации времени;
- средства двойной загрузки, аналогичные chconf-vmware.
Драйверы не обязательны, но полезны. Во-первых, они повышают производительность, потому что в этом случае ядру VMWare не приходится тратить время на низкоуровневую эмуляцию соответствующих устройств. Во-вторых, видеодрайвер обеспечивает более высокое разрешение и цветность, чем стандартный SVGA-драйвер, который входит в состав X Window.
Более подробное описание VMWare Tools заслуживает отдельной статьи, пока же важно то, что без них при начальном ознакомлении можно обойтись. Единственная действительно необходимая вещь - это переключение аппаратных и прочих настроек при запуске Линукса напрямую и в виртуальном окружении, но с этой задачей успешно справляется chconf-vmware.
Утилита chconf предназначена для переключения настроек Юникс-системы. При её написании подразумевалось, что в Юниксе почти любое изменение настроек может быть сведено к копированию/удалению/изменению некоторых файлов и выполнению команд, которые заставляют систему перечитать эти файлы заново. Действия, которые chconf должен выполнить при переключении на некую конфигурацию, описываются в специальном файле-профиле.
Для chconf, начиная с версии 1.2, существует два готовых шаблона для создания следующих профилей:
- профиль сетевых настроек для переносного компьютера или коммутируемого выхода в Интернет;
- профиль для загрузки Линукса непосредственно или внутри VMWare.
Эти шаблоны находятся во вспомогательных RPM-пакетах, называемых chconf-network и chconf-vmware соответственно.
По сравнению с dualconf из VMWare Tools, chconf-vmware имеет следующие преимущества:
- переключается не только аппаратная конфигурация, но и логическая - меняется IP-адрес сетевой карты и т.д.;
- информация об аппаратной конфигурации состоит не из готовых значений (которые, как в случае со звуком, могут оказаться неработоспособными), а определяется с помощью внешних утилит, таких как Kudzu;
- переключение настроек способно использоваться не только для поддержки работы под VMWare, но и в любых других требуемых целях;
- chconf несравнимо меньше по размеру и проще в установке.
Если у вас установлен ALTLinux версии 2.2 или выше, имеется выход в Интернет и настроено подключение к моему APT-репозитарию, установка выполняется следующими командами:
sudo apt-get update sudo apt-get install chconf-vmware
В противном случае вам потребуется скачать RPM-пакеты chconf, chconf-network и chconf-vmware или ZIP-архив chconf с домашней страницы проекта вручную.
Кроме заготовки профиля, chconf-vmware содержит сценарий определения, запущен ли Линукс под VMWare или нет. Этот сценарий запускается автоматически при установке RPM-пакета и создаёт из заготовки первый профиль. Этот же сценарий регистрируется в /etc/init.d для запуска при старте системы. Когда вы перезагрузите систему во втором варианте, он запустит Kudzu и проинициализирует второй профиль. В дальнейшем при загрузке системы сценарий будет выбирать тот или иной профиль в зависимости от окружения.
Несколько слов о Kudzu. Kudzu представляет из себя мощную утилиту поиска и настройки периферийных устройств, написанную на языке Python. Это один из тех инструментов, которые развеивают флер «автомагического» поведения, присущий компонентам Windows, в данном случае - Мастеру установки оборудования.
Какой смысл запускать chconf-vmware при старте системы до Kudzu (их порядковые номера в ордере загрузки равны соответственно 01 и 05), и сразу же запускать из него Kudzu перед инициализаций профиля? Дело в том, что при уже существующем профиле его активация должна происходить перед запуском Kudzu, чтобы Kudzu не имел повода сообщать о рассогласовании аппаратной конфигурации с файлами настроек. При создании же профиля, наоборот, требуется, чтобы файлы настроек и аппаратная конфигурация были синхронизированы Kudzu до того, как профиль будет заполнен файлами.
Как следует отвечать на вопросы Kudzu об «исчезнувшем» или обнаруженном устройстве? Существует три варианта:
- Remove или Configure -- обновить системные настройки, удалив или добавив в них информацию об этом устройстве;
- Keep или Ignore -- не менять системных настроек, но вопрос об этом устройстве при следующих запусках Kudzu больше не задавать;
- Do nothing -- не менять системных настроек, но при следующем запуске задать этот вопрос снова.
Рекомендуемые ответы:
- Remove, если «исчезнувшее» устройство принадлежит другой конфигурации, а chconf-профиль текущей конфигурации пока пуст и будет сформирован после выхода из Kudzu;
- Keep, если «исчезнувшее» устройство принадлежит другой конфигурации, а профиль текущей конфигурации уже сформирован;
- Configure, если устройство, наоборот, считается вновь обнаруженным.
К сожалению, невозможность провести более тщательное тестирование собственными силами не позволяет мне пока гарантировать их 100-процентную правильность.
Kudzu хранит информацию о найденном «железе» в файле /etc/sysconfig/hwconf. Флаг detached для каждого устройства равен 1, если оно не обнаружено при последнем запуске и на вопрос о нём вы ответили Keep.
Соображения и рекомендации, изложенные в статье, опираются на мой собственный опыт знакомства с VMWare. В ходе этого знакомства я практически не пользовался Интернетом, поэтому значительная часть идей может оказаться не новой. Не все предположения проверены до конца, поэтому не следует немедленно принимать их на веру. Наконец, утилита chconf была разработана только потому, что в тот момент я ещё не знал, как и с какой целью следует устанавливать VMWare Tools. С этими утилитами я познакомился уже в момент работы над статьёй. Тем не менее, заменять chconf на dualconf на своей системе я не планирую и надеюсь, что полученный мною опыт, затронутый круг вопросов и уровень изложения окажутся интересными как новичкам, так и специалистам.