DPM 2010 RC интересен (кроме того, что его выход означает – релиз уже близко!) тем, что он поддерживает бэкап виртуальных машин кластера Hyper-V 2 с Cluster Shared Volumes. Чисто случайно как раз такой кластер оказался под рукой, поэтому было принято решение – устанавливать

Развертывание DPM 2010 RC открыло несколько любопытных вещей, которыми я и хочу поделиться:

DPM 2010 Release Candidate поддерживает простой апгрейд с DPM 2010 Beta. Я тестировал его на двух системах – одна инсталляция была выполнена на Windows Server 2008 R2, вторая – на Windows Server 2008 x64.

Beta-версия DPM 2010, кстати, нормально апгрейдится с DPM 2007 SP1 - устанавливает новый SQL-сервер, и апгрейдит старую базу DPMDB. Все параметры и бэкапы при этом сохранились. Как работает апгрейд с DPM 2007 на DPM 2010 RC – сказать пока не могу, не пробовал.

Апгрейд DPM 2010 Beta, стоящего на R2, прошел без проблем и вопросов. А вот для апгрейда той Betы, которая стоит на Windows Server 2008, инсталлятор попросил меня скачать и установить два патча – с номерами 975759 и 962975. Причем, эти патчи недоступны через Windows Update и выдаются по запросу на сайте – нужно только ввести свой e-mail.

После инсталляции вышеуказанных патчей апгрейд DPM прошел на ура. Кстати интересно - RC использует другой instance своего SQL-сервера, и если для Beta он назывался MSDPMV3BETA1EVAL, то для версии RC дополнительно ставится SQL instance с названием MSDPM2010RCEVAL. Базу данных инсталлятор переносит и обновляет сам – но не забудьте перед апгрейдом все-таки сделать ее резервную копию , а также удостовериться, что на диске хватит места под еще один экземпляр SQL Server 2008 и базу данных MSDPM.

Итак, после установки Release Candidate версия DPM станет 3.0.7558.0, вместо версии 3.0.7336.0 у Beta.

После апгрейда самого сервера нужно сапгрейдить и агенты DPM – для этого открываем консоль DPM, заходим в Management -> Agents, и нажимаем на ссылку Update Available рядом с каждым сервером.

Кстати говоря, на некоторые серверы через DPM агент по неясным причинам обновляться отказался – так и оставался в состоянии Needs Updating. Пришлось запускать на сервере установку агента вручную – из папки Agents дистрибутива DPM. После установки агента вручную достаточно нажать Refresh на странице консоли DPM.

Больше ничего с существующими Protection Group делать не надо – все предыдущие настройки и бэкапы сохраняются и подключаются нормально.

А вот при попытке добавить в Protection Group виртуальную машину с кластера Hyper-V, DPM выдал любопытное сообщение:

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

• Для Windows Server 2008 – 948465 (это просто Service Pack 2), и 971394.
• Для Windows Server 2008 R2 – 975921 и 975354.

Эти обновления опять-таки необходимо загружать с Microsoft по запросу, указывая свой e-mail, на который и придет ссылка для скачивания файлов, вместе с паролем.

Вот такие любопытные нововведения продолжаем исследовать RC, и ждем релиз.

Недавно к нам обратилась одна компания с просьбой восстановить Exchange Server. В компании работает около 500 человек. Занимается компания бизнесом в Интернете. Можно себе представить насколько критичным для данной компании является сервис электронной почты, куда приходят все заказы от клиентов, и происходит общение между сотрудниками.

В тот момент, когда компания обратилась за помощью к нам, почта уже не работала 2 дня, руководство было в панике. Самое плохое, что всё это время системные администраторы пытались восстановить работоспособность почтового сервиса самостоятельно, и как всегда это бывает, лучше бы они ничего не делали! И почему за помощью к специалистам обращаются не начальном этапе, а когда уже всё находится в полной {nslookup 83.102.180.3}?)

В компании был только один Exchange Server 2007 Standard Edition, на котором располагались все ящики пользователей. Ящики большего числа пользователей были распределены по 2-м базам данных, каждая по 250 ГБ. Было также ещё 2 MailBox Store для руководства и 1 Public Folder Store. Резервное копирование выполнялось при помощи Acronis True Image Echo Enterprise Server, который выполнял снимок всего диска.

Пролог

Итак, что же случилось? Хронология событий такая: В одну прекрасную ночь в офисе компании выключили свет, UPS продержал сервера 1 час, затем PowerChute начал завершать работу операционных систем, но Exchange Server завершить работу не успел, и UPS выключился. На утро системные администраторы включили сервера, и обнаружили, что Exchange Server не подмонтировал 2 самые большие базы данных, в которых находились ящики 250 пользователей. Попытки смонтировать БД вручную не увенчались успехом, ввиду их физического повреждения, несмотря на то, что БД размещались на массиве RAID 10 (плохо, что вместе с логами транзакций). Далее системные администраторы решили вытащить базы данных из резервных копий Acronis-а. Который сказал, что процесс восстановления будет завершён через 10 часов. Руководство сказало, что это слишком долго и нужно сделать так, чтобы пользователи смогли получать хотя бы новые письма, пока идёт процесс восстановления. Этот метод называется Dial-tone Recovery.

Но то ли системные администраторы не очень внимательно читали документацию, толи не так её поняли, но сделали они всё примерно так: Они решили создать новую БД, чтобы переместить в неё всех пользователей. Запустили Exchange Management Console перешли в раздел Server Configuration\Mailbox, создали новую БД и попытались её смонтировать, на что получили ошибку. Они долго разбирались в природе этой ошибки и затем поняли, что ошибка была вызвана тем, что они пытались смонтировать 6-ю БД в Exchange Server Standard, который поддерживает только 5! Следующим их действием стала попытка удалить повреждённую БД, которая тоже не увенчалась успехом, потому что в этой базе были ящики пользователей и её нельзя удалять (точнее Exchange не даёт этого сделать)! Эта ситуация вогнала системный администраторов в небольшой ступор (и лучше бы они в нём и оставались), так нет же, среди них нашёлся один знаток Active Directory, который вызвался помочь. Он взял и удалил базы данных сервера Exchange через ADSIedit.msc. Радостные и благодарные ему системные администраторы Exchange, создали 2 новые БД, и смонтировали их. Этот процесс естественно прошёл успешно.

Но их радость очень быстро закончилась! Когда администраторы попытались переместить пользователей в новые пустые БД, то столкнулись с новой «проблемкой». При открытии консоли Exchange Management Console > Recipient Configuration > Mailbox, при открытии любого ящика стала выдаваться ошибка The properties on User have invalid data. А командлеты Get-MailBox и Move-Mailbox выдавали ошибку Object Domain/OU/User has been corrupted and it is in an inconsistent state. Database is mandatory on user MailBox.

В этот момент системные администраторы поняли, что дела совсем плохи, надежд больше нет и лучше приложить все усилия к написанию нового резюме! В конце концов, руководство решило обратиться за помощью к сертифицированному партнёру Microsoft, в компанию «ЛанКей».

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

Восстановление.

Часов через 10 восстановились базы данных недельной давности, из Acronis-овского бэкапа. Но ни одна из них не стала монтироваться. Ещё раз убеждаемся в том, что Acronis не умеет резервировать Exchange Server и все БД были в состоянии Dirty Shutdown. Хотя базы данных были зарезервированы вместе с логами, но чтобы выполнить софт-рековери, логов в архиве не хватало. Пришлось восстанавливать базы данных при помощи eseutil /p. На каждую базу данных потребовалось ещё 5 часов восстановления. После этого базы смонтировались. На всякий случай, мы также запустили проверку логической структуры при помощи isinteg.

Теперь мы должны были разобраться с тем, что ящики пользователей нельзя было ни переместить, ни восстановить. Проанализировав ситуацию, мы выяснили, что у всех пользователей был удалён атрибут homeMDB, точнее был удалён не сам атрибут, а его значение. В тестовых целях, мы восстановили данный атрибут у одного из пользователей вручную через ADSIedit.msc. И теперь мы могли перемещать и восстанавливать ящик данного пользователя. Но восстанавливать значения этого атрибута у 500 пользователей было бы довольно трудоёмкой задачей. Поэтому мы решили как-то автоматизировать данный процесс. Первым в голову конечно же пришло использовать Power Shell. Но командлеты для управления Active Diretory появились только в Windows Server 2008 R2, здесь же вся инфраструктура была построена на Windows Server 2003. Но выход был найден, мы решили использовать PowerShell Commands for Active Directory от Quest Software http://www.quest.com/powershell/activeroles-server.aspx (спасибо Ярославу за подсказку).

Для задания атрибута homeMDB, использовался командлет:
Set-QADUser user_name -ObjectAttributes @{HomeMDB=’FQDN_базы’}

Теперь оставалось задать соответствующий атрибут каждому пользователю. Но не всё оказалось так просто. Ведь у нас было 2 базы данных и 250 пользователей, и нет никакой информации о том, какой пользователь в какой БД размещался. И соответственно непонятно какой атрибут, какому пользователю присваивать. Мы задались вопросом: как выяснить, какой пользователь, в какой базе находился? Ведь в Active Directory эта информация была стёрта. Единственное место, где эта информация осталась – это сами базы данных. И вытащить её оттуда можно было при помощи командлета Get-MailboxStatistics.

Поскольку Get-MailboxStatistics – является командлетом Exchange, а Set-QADUser – является командлетом Quest. Нужно было подгрузить обе оснастки в один сеанс PowerShell, для чего использовали командлет Add-PSSnapin. Итак, для задания атрибута homeMDB для пользователей из db1 использовали следующий скрипт:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\First Storage Group\db1 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db1,CN=First Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

Аналогичный скрипт для задания атрибута homeMDB для пользователей из второй БД:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Add-PSSnapin Quest.ActiveRoles.ADManagement
Get-MailboxStatistics -Database exchsrv\Second Storage Group\db2 | ForEach-Object -process {Get-QADuser $_.Displayname} | Set-QADUser -ObjectAttributes @{HomeMDB=’CN=db2,CN=Second Storage Group,CN=InformationStore,CN=exchsrv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOMAIN,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru’}

После перезапуска службы Information Store пользователи успешно подключились к своим ящикам, но ни получение ни отправка почты не работала. Мы обратили внимание на то, что служба HUB Transport не работает. После запуска её вручную, она сразу же останавливалась. Как мы выяснили, была повреждена база данных почтовой очереди, которая располагается здесь: C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que.
Чтобы не потерять почту, которая успела попасть в очередь, мы решили восстановить эту БД при помощи eseutil:

eseutil /p c:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que

После восстановления этой БД, служба HUB Transport запустилась и заработала. Пользователи начали получать новую почту.

PS1:

На самом деле процесс восстановления был немного сложнее, чем описано выше. Просто лень много писать, да и про метод Dial-tone Recovery подробно написано на technet. В кратце:

На время восстановления мы переместили всех пользователей во временные пустые БД, потом восстановили БД из резервных копий, заменили ими новые БД. Затем новые БД смонтировали в Recovery Storage Group и слили всю почту, полученную во время восстановления, с восстановленными из архива ящиками.

PS2:

Немножко размышлений:

• Как нам потом доложили, сбой почтовой системы вылился компании в 2 млн. рублей убытков. Интересно учитывал ли кто-нибудь эти деньги при проектировании почтовой системы и разработке политики резервного копирования? Было ли это прописано в SLA?
• Ведь спасти от такого сбоя могла простая SCR репликация, которая обошлась бы примерно в дополнительные 150 000 р. И восстановление заняло бы максимум пол часа. Хотя можно было бы подумать и о внедрении CCR кластера, который всё равно бы обошёлся раза в 2 дешевле, понесённых убытков.
• Резервировать Exchange Server 2007 нужно поддерживаемыми средствами резервного копирования, такими как Symantec BackUp Exec, Microsoft Data Protection Manager, ну или на худой конец ntbackup. Даже Windows  Backup из состава Windows Server 2008 уже поддерживает резервное копирование Exchange Server 2007 (sp2). Эти средства резервного копирования правильно подготавливают базу данных Exchange к процедуре резервирования, закрывают базу на запись, и после завершения резервного копирования, удаляют логи. Используемое в данном случае средство резервного копирования, неправильно резервировало БД Exchange, что привело к дополнительным 10 часам простоя.
• Также в данном случае большой ошибкой стало то, что логи транзакций размещались на одном и том же диске с базами данных, и поэтому было потеряно всё разом.
• Кроме того,  помимо еженедельного полного резервного копирования, было бы неплохо выполнять ежедневное добавочное. В данном случае произошла бы потеря почты только за один день, а не за неделю.

PS3:

История полностью вымышленная, любые сходства с реальным миром, простые совпадения!

Естественно, при создании группы защиты DPM спрашивает, каков срок хранения резервных копий для восстановления – recovery points. И, само собой, по истечении этого срока он должен удалять старые копии, чтобы на их место сохранять новые.

Но мы столкнулись с ситуацией, что старые резервные копии DPM не удаляет. Они так и копятся на диске – и, рано или поздно, наступает время, когда места под новую резервную копию уже не хватает, и DPM вываливается с ошибкой «Recovery Point Volume threshold exceeded».

Для удаления устаревших резервных копий в DPM есть скрипт PruneShadowCopies.ps1, который можно запустить и вручную. Но – данный скрипт не работает. Выдает ошибку:


Index operation failed; the array index evaluated to null.
At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:205 char:18
+     $replicaList[$ <<<< inactiveDs.ReplicaPath] =
$inactiveDs.RecoveryRangeinDays
Index operation failed; the array index evaluated to null.
At C:\Program Files\Microsoft DPM\DPM\bin\pruneshadowcopies.ps1:206 char:23
+     $latestScDateList[$ <<<< inactiveDs.ReplicaPath] = new-object DateTime


Поэтому, собственно, резервные копии и не удаляются автоматически – DPM должен каждую полночь запускать этот скрипт по расписанию, а скрипт завершается с ошибкой.

В июне 2009 года Microsoft выпустила обновление 970267 для Data Protection Manager, среди прочих решающее и эту проблему. Скачать его можно здесь. Процесс установки таков:

• Скачиваем три файла, нужной нам платформы – в зависимости от того, 32- или 64-битная версия DPM установлена у нас. Кстати, ставится это обновление на Data Protection Manager 2007 Service Pack 1.
• Запускаем файл DataProtectionManager2007-KB970867.exe и производим обновление сервера. Чтобы не перезагружать сервер после обновления – убедимся, что DPM Administrator Console и DPM Management Shell не запущены.
• Если база данных SQL, в которой хранится конфигурационная информация DPM, находится не на том же сервере, где сам DPM – запускаем на этом сервере файл SqlPrep-KB970867.msp. Если мы ставили SQL Express вместе с DPM на ту же машину - обновление запускать не нужно.
• Если мы используем DPM Management Shell не на том же сервере, где сам DPM – запускаем на этом сервере файл DPMManagementShell2007-KB970867.msp. Если все находится на одном сервере – обновление запускать не нужно.
• Заходим в DPM Administrator Console, выбираем Management – Agents, и обновляем все клиентские агенты DPM до новой версии – версия DPM и агентов после этого обновления становится 2.0.8844.0. При обновлении нужно указать Manual restart – потому что на самом деле перезагружать серверы не нужно.

Все. После завершения обновления скрипт PruneShadowCopies.ps1 должен выполняться без ошибок.

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


$VerbosePreference = "continue"


После этого запускать скрипт.

Я более года пользовался Microsft Hyper-V  на своём домашнем сервере, и в принципе всем он меня удовлетворял, работал надёжно и без сбоев. Но всё же в предверии выхода Windows Server 2008 R2, перед апгрейдом решил попробовать VMware vSphere 4, всё-таки лидер рынка виртуализации. С первого раза вставать на мой домашний компьютер (ASUS P5E-VM HDMI\8GB RAM\Intel Q6600\3WARE 3650SE – RAID 10), VMware ESX отказался, не нашёл ни жёстких дисков, ни сетевых карт. Слава богу компания 3WARE сама написала драйверы для VMware http://www.3ware.com/kb/article.aspx?id=15548. Но вот сетевушки пришлось купить: Intel PRO/1000 PT Gigabit Adapter. В общем, в итоге ESX сервер установился и заработал.

Теперь собвственно встала задача развернуть виртуальные машины. Все образы операционных систем и куча всякого другого софта у меня была только на внешнем USB жестком диске.  И тут возникла проблема: VMware не предоставляет никаких средств доступа к USB накопителям! Через vSphere Client можно подмонтировать .iso образы с рабочей станции или размещённые на vmfs-хранилище, а также использовать физический CD-ROM сервера или рабочей станции, с которой запущен vSphere клиент.

Но для меня ни один из этих вариантов не являлся приемлемым. Я конечно мог подключить USB HDD к своему ноутбуку и подмонтировать .iso-шники к нему, но во-первых производить установку по Wi-Fi очень долго, во-вторых это ограничивает возможность удалённой работы, т.к., например ставить Windows Server 2008 r2 c DVD, через Интернет вообще не реально!

В общем всем известно, что VMware ESX 4 основан на Linux RedHat (что бы там не говорили про тонкий гипервизор и отсутсвие ОС), который, кстати, съедает памяти не меньше Windows Server 2008. Такчто задача заключалсь в том, чтобы подружить Linux и USB жесткий диск с файловой системой NTFS, а затем предоставить доступ к нему для VMware.

Сразу скажу, что я не являюсь специалистотм по Linux/Unix системам, и практически никогда с ними не работал, так что не надо меня сильно ругать! Ну не люблю я чёрные «готичные» текстовые экраны, где надо помнить кучи команд, где нет интуитивно понятного интерфейса и нет Vista Aero)

Открываем SSH

Сидеть за сервером неудобно, поидее у него вообще нет ни клавиатуры, ни мыши, ни монитора, поэтому первым делом открываем SSH, чтобы получить удалённый доступ к консоли. Для этого в главном окне vSphere Client переходим на вкладку Configuration, нажимаем слева внизу Security Profile, а затем справа вверху Properties. Там нужно будет отметить галку SSH Server.

Теперь к консоли VMware можно будет подключаться при помощи PuTTY по SSH. Казалось бы всё хорошо, но оказывается по умолчанию пользователю root запрещён вход по SSH. Чтобы разрешить пользователю root входить по SSH, нужно переконфигурировать демон SSH:
Логинимся на сервер VMware локально и редактируем файл /etc/ssh/sshd_config. В Linux есть страшный и ужасный редактор под названием VIM, который, для большей очевидности, запускаеся командой vi, в общем, чтобы отредактировать файл пишем:

vi /etc/ssh/sshd_config

В редакторе один раз нажимаем PageDown и находим строчку:
PermitRootLogin no
Нажимаем кнопку Ins, редактор переходит в режим редактирования, стираем no, пишем yes. Затем нажимаем ESC, нажимаем <Shift>+<:>, и пишем wq (это значит записать и выйти).
Теперь нужно либо перезагрузить сервер, либо перезапустить службу sshd:
[root@VMwareESX4 ~]# service sshd restart

Теперь вы можете подключаться к VMware через PuTTY, под учетной записью root.

Включаем поддержку NTFS

Включаем поддержку NTFS в VMware ESX 4, а точнее в Linux. По умолчанию Linux c NTFS не работает. Но немного погуглив, я нашёл драйверы, которые позволяют использовтаь NTFS в Linux. Например fuse-ntfs-3g. Для него требуется скачать 2 пакета:
fuse-2.6.3-1.el5.rf.x86_64.rpm
fuse-ntfs-3g-1.2310-1.el5.rf.x86_64.rpm
Все указанные в этой статье пакеты можно найти на www.rpmfind.net, ну или в www.google.ru)

Ещё у вас может возникнуть вопрос, каким образом эти пакеты запихнуть в VMware. Делается это так: Скачиваете пакеты и копируете их в какую-нибудь папку, например distr, затем в консоли vSphere Client переходите на вкладку Configuration, слева нажимаете Storage, справа выбираете VMFS раздел, нажимаете по нему правой кнопкой и выбираете Browse Datastore.

В Datastore Browser нажимаете кнопку Upload, выбираете Upload Folder, и закачиваете папку distr с пакетами на сервер.

Затем подключаетесь при помощи PuTTY к серверу VMware по SSH и устанавливаете пакеты:
Папку которую вы заливали при помощи Datastore Browser можно найти в консоли тут: /vmfs/volumes/VMFSpartition/distr, переходите в эту папку и ставите пакеты:

cd /vmfs/volumes/VMFSpartition/distr
rpm -i fuse-2.6.3-1.el5.rf.x86_64.rpm
rpm -i fuse-ntfs-3g-1.2310-1.el5.rf.x86_64.rpm

Монтируем USB HDD

Теперь монтируем наш USB жёсткий диск с файловой системой NTFS. Создаём папку монтирования:

mkdir /vmimages/usbhdd

И монтируем в неё наш жесткий диск:

mount -t ntfs-3g /dev/sda1 /vmimages/usbhdd

mount – команда монтирования; -t ntfs-3g задаёт тип файловой системы NTFS (драйвер которой мы поставили выше); /dev/sda – это устройство, которое мы монтируем, в моём случае жесткий диск висел именно на нём, в вашем случае может быть по другому, например sdb, sdc и т.д., возможно придется поискать; цифра 1 задаёт номер раздела на диске (1,2,3,4 – основные, 5,6,… – в Extended Partition).

Почему монтировали именно в папку /vmimages/usbhdd? Потомучто из консоли vSphere Client при загрузке образа в CD-ROM, выбрать .iso-шники можно токлько из папки /vmimages.

Монтируем .iso-шник в виртуальную машину через vSphere Client

Выбираете Connect to ISO image on a datastore…

Заходим в папку vmimages и видим там созданную нами папку usbhdd:

Входим в папку usbhdd и «вуаля», видим содержимое нашего USB-жесткого диска:

Выполняем резервное копирование виртуальных машин

Кроме того, что мы получили возможность монтировать .iso образы с USB HDD, теперь мы можем копировать виртуальные машины, причем как из VMware на USB жесткий диск, так и наоборот. Естественно виртуальные машины предварительно нужно остановить.

Устанавливаем Midnight Commander

Кстати, не знаю как вам, а мне не удобно строчить кучу команд в консоле, поэтому я решил установить файловый менеджер Midnight Commander:
Скачиваете пакет mc-4.6.2-3.pre1.fc9.x86_64.rpm, брать тамже на www.rpmfind.net, закачиваете его в VMware ESX, описанным выше способом, и устанавливаете:

rpm -i mc-4.6.2-3.pre1.fc9.x86_64.rpm

Теперь в консоле SSH будет работать веселее, набираем команду mc и наслаждаемся:

Кстати, для нормального отображения Midnight Commander в консоли PuTTY, нужно выбрать кодировку UTF-8. Нажимаем правой кнопкой по заголовку окна PuTTY, выбираем Change Settings, раскрываем раздел Window, переходим в Translation и справа выбираем UTF-8.

Устанавливаем SAMBA

Осталось только одно неудобство, которого не было в Hyper-V. Да я теперь могу с лёгкостью монтировать .iso-шники и ставить ОС, Office и т.д., но как быть с кучей софта, который распространяется не в .iso? Как этому софту в любой удобный для меня момент попадать с USB HDD внутрь виртуальной машины? В Hyper-V я мог просто расшарить папку с диском, а потом с виртуалок заходить на сервер \\hyper-v\usbhdd и получать доступ к софту.

Чтобы реализовать тоже самое на VMware пришлось установить сервер SAMBA. Но это оказалось сделать не так уж и просто. VMware использует очень обрезанную версию Linux RedHat, и кроме того все пакеты которые там стоят имеют очень старую версию. И почему ещё я не люблю Linux, так это из-за этой зависимости пакетов. Пытаешься установить один .rpm, который для своей установки требует 5 других, каждый из которых требует 5 ещё каких-то пакетов и т.д., какая-то цепная реакция), некторые из пакетов вообще требуют одновременной установки. В общем даю список пакетов, которые мне пришлось поставить, чтобы установить сервер SAMBA:

rpm -i –nodeps –force cups-libs-1.2.4-11.8.el5.x86_64.rpm
rpm -i –nodeps –force popt-1.13-4.fc10.x86_64.rpm
rpm -i –nodeps –force samba-common-3.0.33-0.fc8.x86_64.rpm
rpm -i –nodeps –force samba-3.0.33-0.fc8.x86_64.rpm

В общем-то сборник какой-то мути получился и наверняка можно было сделать всё иначе, но честно-говоря мне надоело разбираться с пакетами. И я стал использовать ключи –force и –nodeps (что наверное в общем-то не очень рекомендуется). Но тем не менее сервер samba установился и заработал.

Настройка:
Теперь у нас есть midnight commander и всё стало проще, запускаем mc, переходим в папку \etc\samba\, находим там файл smb.conf, нажимаем F4 и редактируем:

[Global]
security = user
passdb backend = tdbsam
encrypt password = yes
smb passwd file = /etc/samba/smbpasswd
domain master = no
domain logons = no

[share]
comment = root
path = /
browseable = yes
writable = yes

В 3-х словах: в этом файле мы указали путь к файлу паролей пользователей сервера samba – smbpasswd, создали общую папку «share», которая ссылается на корень раздела VMware. Т.е. по сути открыли доступ ко всем системным файлам!!, а аткже подмонтированным разделам, напр. нашему USB диску - /vmimages/usbhdd, а также разделу с виртуальными машинами - /vmfs/volumes/VMFSPartition.

Теперь нужно создать файл с паролями samba, его можно проимпортировать из системы, выполнив:

cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd

Теперь нужно задать пароль для пользователей samba, мне нужен был доступ только для root, поэтому выполнил команду:

smbpasswd -a root

Как я думал, что всё готово. Но нет. Оказывается протокол SMB (порт TCP-139), был закрыт на файерволле VMware ESX. Открываем его следующей командой:

esxcfg-firewall –openPort 139,tcp,in,Samba

Если SAMBA сервер не запуститься автоматически, то запустить его можно выполнив команду: smbd

Ну в общем-то всё, открываем, заходим и используем:

Конечно можно сделать автоматическое монтирование внешнего HDD, подредактировав файл fstab, как наверное можно настроить автозапуск smbd, но мне это было не нужно (или лень возиться). Т.к. я всегда могу запустить нужные мне команды через SSH.

Вродебы всё!

PS: Я делал все эксперементы на тестовой машине, которую не жалко; Не повторяйте это в продуктивной среде!