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

На следующей картинке можно увидеть одновременную работу всех систем, на импортирование которых мы потратили столько труда. Для наглядности каждая из них запущена в отдельном окне. Конечно, можно было запустить их внутри разных вкладок родительского окна, но я решил, что так картинка будет выглядеть недостаточно эффектно. Добиться подобного вида можно, используя меню «File –> New –> New Window». Во вновь появившемся окне, следуя укоренившейся привычке, выбираем «File –> Open». Внимательный читатель может спросить, зачем все эти сложности. Мой ответ будет довольно прост. Такой подход позволяет разложить виртуальные машины в нужном порядке по виртуальным столам оконного менеджера. Лично мне это кажется весьма удобным.

У подобной методики работы есть один щекотливый момент. Если внутри любого окна создана вкладка с гостевой операционной системой, то эта система становится не доступна для запуска из другого окна. Все дело в том, что VMWare Workstation в момент открытия конфигурации виртуальной машины создает файл эксклюзивной блокировки. Называется такой файл обычно «имя гостевой системы.vmx.WRITELOCK». Причем файл создается еще до запуска гостевой системы и остается до тех пор, пока не будет закрыта вкладка гостевой системы или завершится работа VMWare Workstation. Получается, что конфигурация гостевой системы будет заблокирована в любом случае, вне зависимости от того, работает гостевая система или нет. Если попытаться открыть эту гостевую систему еще раз, то получим по рукам.

В свою очередь, признаком работы системы служит появление дополнительного файла блокировок файлов жестких дисков, называющегося «имя гостевой системы .vmdk.WRITELOCK». Видимо, разработчики VMWare Workstation не смогли придумать более надежного способа для проверки факта запуска той или иной гостевой системы. Кстати, если во время работы гостевой системы удалить все файлы WRITELOCK, то ее легко можно запустить повторно. Например, на следующем рисунке можно видеть два экземпляра гостевой системы Windows 98, запущенных из одного и того же файла и работающих одновременно довольно-таки стабильно.

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

Мы немного отвлеклись от темы нашего повествования. После переноса и успешного запуска всех гостевых систем настал момент проверить, насколько правильно работает наш макет. Для этого на Windows-машинах выполняем команду ipconfig /all и смотрим, какие настройки у нашей сетевой подсистемы. Например, на следующем снимке можно увидеть результат выполнения вышеуказанной команды на машине Win2000.

Так как все остальные системы, используемые в нашем макете, являются диалектами UNIX, то для просмотра состояния их сетевых интерфейсов нужно использовать команду ifconfig. Например, для машины FreeBSD вывод команды выглядел вот так:

lnc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX, MULTICAST> mtu 1500

     inet 192.168.40.2 netmask 0xffffff00 broadcast 192.168.40.255

     inet6 fe80::20c:29ff:fec7:b430%lnc0 prefixlen 64 scopeid 0x1