admin.txt

… заметки IT’шника…

Хуже вируса только агенты от Mail.Ru?

Помните анегдтот про два типа вредоносных программ?
Так вот наткнулся на статейку:  http://habrahabr.ru/post/149636/

и дальше из комментов:
http://webcontext.ru/?p=422
http://roem.ru/2012/08/29/dispute53499/
http://roem.ru/2012/03/02/mail43740/
Я конечно давно негативно отношусь к мэйл.ру…. и всякие их агенты никогда не ставлю…. но то, что ситуация уже так далеко зашла я не знал.

11 сентября, 2012 Posted by | Antivirus, Заметки... | | Оставьте комментарий

Перезапуск зависшего iSCSI инициатора на ESXi

Иногда есть необходимость подключить к ESXi хосту временный датастор для проведения разных маневров. По большей части я стараюсь в таких случаях использовать NFS, но иногда приходится и iSCSI использовать.

Вот вчера столкнулся с девайсом от NetGear  — ReadyNAS Pro 6. Который как оказалось не работает сESXi 5.0 на прошивке 4.2.19 ( но поэто я уже потом нагуглил, когда столкнулся с проблемами: http://forum.netgear.ru/viewtopic.php?id=3295).

Суть в том что настройка программного iSCSI инициатора ESXi прошла просто, а вот переместить туда вируталку или скопировать какой-нибудь файл не получалось. Процесс копирования зависал, а графики показывали дикое время отклика (десяти тысяч миллисекунд). А через некоторое время выскочило сообщение что датастор на iSCSI луне стал недоступен. И никакие ресканы не помогали, процесс очень долго тупил и не мог успешно завершиться.

После поиска в гугле вышел на такое решение (Restarting the software iSCSI stack). Включаем SSH на ESXi хосте и  подключившись туда:

1.  Отключаем программный инициатор:

esxcfg-swiscsi -d

2. Убиваем процесс

esxcfg-swiscsi -k

А потом еще  находим ID процесса и убиваем его

2.а Что бы найти ID: ps | grep vmkiscsid

2.б Что бы убить процесс: kill <process ID>

3. Снова запускаем инициатор: esxcfg-swiscsi -e

4. Делаем рескан нужного адаптера, в моем случае это быо vmhba35: esxcfg-rescan vmhba35

После всего этого лун снова стал доступен. Еще немного поэксперементировав я повторно пришел к проблеме и повторил решение. После чего уже нагуглил пост о несовместимости этой прошивки девайса с пятой весией ESXi.

Пришлось отказаться от iSCSI в данном случае. Кстати отключать LUN iSCSI тоже нужно правильно: Unpresenting a LUN in ESXi 5.x

7 июня, 2012 Posted by | Заметки..., Uncategorized, Virtualization | , | Оставьте комментарий

Переименование шары в Windows с сохранением прав доступа.

Думаю многие сталкивались с ситуацией, когда надо поменять имя шары в винде… но винда не разрешает переменовывать шары.

В итоге, для сохранения прав доступа, в таком случае, приходится делать новую шару на  целевой папке (уже с нужным именем) и «повторять» все назначения пермишенов на шару. Когда на шару назначено всего несколько пермишенов — это пустяковое дело. А вот если там 20+ назначений? или множество шар должно быть переименованно?

Нам на помощь приходит permcopy.exe (идет в пакете Windows Server 2003 Resource Kit Tools ). Немного поругавшись пакет стал на мою Win7 SP1 x64. Вот хелп утилиты:


d:\Windows Resource Kits\Tools>permcopy.exe /?
Copies the permissions (ACLS) from one share to another.

PERMCOPY \\SourceServer ShareName \\DestinationServer ShareName

Замечу, что необходимы указывать UNC сервера и через пробел имя шары (а не UNC шары). Собственно на этом все, работает быстро и четко :)

ЗЫ

полезно будет ознакомиться с KB майкрософта: How to Copy Files and Maintain NTFS and Share Permissions

11 марта, 2011 Posted by | Windows | 1 комментарий

Импорт в ESXi всех виртуальных машин с датастора.

Импорт в онсастку ESX(i) вирутальных машин из датастора можно сделать из контекстного меню .vmx файла виртуальной машины (выбрав Browse Datastore,  и найдя нужный файл. Но если таких машин больше несколькоих десятков, а то и сотни — на выполнение этих рутинных операций в ручную можно потратить много часов времени.

Мне пришлось переустановить один сервер с ESX 3.5 на ESXi 3.5 сохранив все виртуальные машины на отдельных датасторах (это были локальные диски, но ситуация не отличилась бы и в слуачае NAS/SAN хранилища).  Замечу, для того что бы подключить к новой инсталяции ESXi 3.5 старые диски с сохранением существующих VMFS разделов нужно на новом хосте в конфигурации выбрав «Advanced Settings», в разделе «LVM» изменить опцию «LVM.EnableResignaturing» c нуля на единицу и сделать Rescan всех котроллеров систем хранения с опцией поиска новых VMFS разделов.

Собстевнно массовый импорт машин для ESX хоста описан тут: Mass Import VMs to New ESX Host by .VMX files, там приведено два способа.

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

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

Скрипт нужно сохранить, например, как massImport.sh, дать ему права на выполнение (chmod +x /path-to-script/massImport.sh) и выполнить. У этого решения свой недостаток — если в пути/имени виртуалки содержатся пробелы, то ничего не получится. Эта проблема решается во втором варианте.

Второй — одной строкой из консоли ESX:

find /vmfs/volumes -name “*.vmx” | while read LINE; do echo “registering VM $LINE”; vmware-cmd -s register $LINE

Но это решения дл ESX, а в моем случае был ESXi. Для ESXi комманды vmware-cmd нету, а на ESX я эти варианты не проверял… Немного погуглив я нашел список команд для работы через SSH/CLI с ESXi. Разрешив из локальной консоли доступ к  ESXi по  ssh, я нашел и протестировал работу аналога нужной команды.

vim-cmd solo/registervm /vmfs/vol/datastore/dir/vm.vmx
Registers vm in hypervisor inventory

т.к. у меня была куча виртуалкок в имени (и пути к VMX файлу) которых содержались пробелы, я решил «поправить» второй способ для работы в ESXi. Эта команда импортирует все виртуальные машины с выбранного датастора «Temp-IT-Drive(1TB)» в «корень» оснастки хоста. Вот что вышло:

find /vmfs/volumes/Temp-IT-Drive\(1TB\)/ -name "*.vmx"| while read LINE; do echo "registering VM $LINE"; vim-cmd solo/registervm "$LINE";done

Пришлось добавить к исходному варианту «;done» в конце и заключить $LINE в ковычки выполнении команды импорта, иначе виртуалки «с пробелами»  все же не обрабатывались.

Вот собственно и все, если есть что добавить — велком в коменты.

8 сентября, 2010 Posted by | Virtualization | , | 2 комментария

Смена настроек DNS на ESXi хостах средствами PowerCLI

Если есть необходимость смены настроек ДНС на сервереах виртуализации ESX(i), то можно пойти двумя путями.

1. В ручную изменить настройки на вкладке «Configuration», разделе «DNS and Routing» каждого хоста виртуализации. Все быстро и просто, пока работы охватывают пару-тройку хостов. А если нужно перенастриоть 10+ серверов нужно «идти в обход».

2. Когда хостов много, а времени на работу в вручную мало/жалко — пора использовать VMware PowerCLI. Я не обладая опытом работы за пару минут нашел способо изменить конфигурацию DNS на нужной мне группе хостов. Итак после загрузки последнего дистрибутива PowerCLI с сайта VMware можно сразу приступать к работе.

После запуска PowerCLI нужно подключиться к хосту, в простейшем случае (если ваш аккаунт имеет права в вашем vCenter) это делается одной командой:

Connect-VIServer -server vCenter-name

После подключения, нужно выполнить следующую команду. В данном примере будет смена адресов DNS сервреов всех хостов в датацентре «MyDataCenter»

Get-VMHost -Location (Get-Datacenter -Name MyDataCenter) | get-vmhostnetwork | set-vmhostnetwork -dnsaddress "192.168.0.1","192.168.0.2"

Ну и стоит отметить, что смена конфигурации DNS на хостах не приводит (по крайней мене в моем слуаче было так) к переключению хоста на новые настройки.  Новые настройки вступят в силу после перезагрузки хоста или после рестарта Management сервисов (services.sh restart из консоли хоста)

2 сентября, 2010 Posted by | Virtualization | , , | Оставьте комментарий

Windows 2008 теряет настройку шлюза по умолчнаию после ребута.

Уже несколько раз сталкивался с проблемой.

После деплоя из шаблона Windows2008 x64 есть проблемы с сетевыми настройками. После перезагрузки ОС теряется настройка шлюза по умолчанию. Если его вписать снова — то все работает до следующего ребута, а потом проблема повторяется… если мне не изменяет память, такое было и на Vista.

Я исправляю проблему так:

  1. Редактором реестра заходим в HKLM/System/CurrentControlSet/Services/Tcpip/Parameters/Interfaces/%CLSID% .
  2. Проверяем значения ключей DefaultGateway и DefaultGatewayMetric. Нужно удалить пустые строки и неверные записи. Можно ввести IP шлюза по умолчанию, если значение отсутсtвует.

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

Есть еще и второй способ, но я пока не проверил его, как нибудь в след раз попробую. Суть в сбросе всех настроек и ввводе их по новому. Для сброса параметров IPv4 нужно с правами администратора выполнить в командной строке: netsh int ipv4 reset

Можно даже так, если нужно сбросить все настройки:

Reset WINSOCK entries to installation defaults: netsh winsock reset catalog

Reset IPv4 TCP/IP stack to installation defaults. netsh int ipv4 reset reset.log

Reset IPv6 TCP/IP stack to installation defaults. netsh int ipv6 reset reset.log

________________

Windows 2008 x64 virtual machines lose their Gateway IP address after rebooting

TCP/IP stack repair options for use with Windows Vista.

20 мая, 2010 Posted by | Windows | | Оставьте комментарий