RDM и vMotion ошибка миграции
Огреб в очередной раз в самый неподходящий момент проблему. И решил-таки докопаться до истины
При попытке мигрировать с хоста на хост VM с подключенным диском RDM можно наткнуться на ошибку
Virtual Disk "Hard Disk X" is a mapped direct-access LUN that is not acceptable
На первый взгляд всё может быть идентично - LUN id, Device id даже пути через которые этот LUN доступен
Однако, если не совпадает vml, прописанный в RDM файле с vml на хосте, на который пытаетесь смигрировать, то миграция будет невозможна
Сам vml id содержит и device id и LUN id (vml.0200xx0... - xx это LUN id в hex)
Посмотреть vml с которым лун подцеплен к машине можно в её свойствах
Чтобы узнать с каким vml на хосте виден девайс, в консоли пишем
esxcli storage core device list -d naa.60060...
В выводе команды последняя строчка
Other UIDs: vml.020000000060060e... это и есть тот самый vml id
Так вот этот самый Other UID формируется при подключении луна: при загрузке хоста, либо при презентации
Вроде бы все просто - отпрезентовать лун с неправильным LUN id и презентовать с правильным, но не всегда и не на всех массивах это банально (например если лун примаплен кластеру, то может не быть возможности отпрезентовать только один лун только от одного хоста)
Может получиться, что презентован лун был с одним номером, потом презентацию переделали по другим путям с другими LUN id. Так вот до перезагрузки vml останется старым и может казаться, что всё хорошо. Потом же, например, при массовом обновлении можем столкнуться с ситуацией когда машина не может мигрировать на уже обновленные хосты
Если мы все-таки измернулись и добавили пути с правильным LUN id и хостим, чтобы хост сформировал нужный нам vml, не обязательно ребутать хост, можно сделать mask path по всем путям и потом вернуть обратно. В этом случае хост увидит лун заново и сформирует новый vml id
Процедура такая:
1. Создаем claimrule для всех путей
esxcli storage core claimrule add -r 110 -t location -A vmhba0 -C 0 -T 1 -L 5 -P MASK_PATH
esxcli storage core claimrule add -r 111 -t location -A vmhba1 -C 0 -T 2 -L 5 -P MASK_PATH
2. Загружаем созданные правила
esxcli storage core claimrule load
3. Делаем reclaim для всех путей девайса (переопределяем какие плагины должны быть ассоциированы с путями)
esxcli storage core claiming reclaim -d naa.600600...
После этого девайс пропадет из списка
Теперь нужно вернуть как было
4. Удаляем созданные правила и применяем изменения
esxcli storage core claimrule remove -r 110
esxcli storage core claimrule remove -r 111
esxcli storage core claimrule load
5. Unclaim для скрытых путей (тут надо помнить какие -A -C -T и -L использовались, как посмотреть, если не записали не знаю)
esxcli storage core claiming unclaim -t location -A vmhba0 -C 0 -T 1 -L 5
esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 5
Девайс вернулся назад. Делаем rescan all, либо в консоли
esxcli storage core claimrule run
KB:
mask path: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009449
unmask path: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015252
Проблема с миграцией машины с RDM: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016210
Идентификаторы лунов: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014953
При попытке мигрировать с хоста на хост VM с подключенным диском RDM можно наткнуться на ошибку
Virtual Disk "Hard Disk X" is a mapped direct-access LUN that is not acceptable
На первый взгляд всё может быть идентично - LUN id, Device id даже пути через которые этот LUN доступен
Однако, если не совпадает vml, прописанный в RDM файле с vml на хосте, на который пытаетесь смигрировать, то миграция будет невозможна
Сам vml id содержит и device id и LUN id (vml.0200xx0... - xx это LUN id в hex)
Посмотреть vml с которым лун подцеплен к машине можно в её свойствах
Чтобы узнать с каким vml на хосте виден девайс, в консоли пишем
esxcli storage core device list -d naa.60060...
В выводе команды последняя строчка
Other UIDs: vml.020000000060060e... это и есть тот самый vml id
Так вот этот самый Other UID формируется при подключении луна: при загрузке хоста, либо при презентации
Вроде бы все просто - отпрезентовать лун с неправильным LUN id и презентовать с правильным, но не всегда и не на всех массивах это банально (например если лун примаплен кластеру, то может не быть возможности отпрезентовать только один лун только от одного хоста)
Может получиться, что презентован лун был с одним номером, потом презентацию переделали по другим путям с другими LUN id. Так вот до перезагрузки vml останется старым и может казаться, что всё хорошо. Потом же, например, при массовом обновлении можем столкнуться с ситуацией когда машина не может мигрировать на уже обновленные хосты
Если мы все-таки измернулись и добавили пути с правильным LUN id и хостим, чтобы хост сформировал нужный нам vml, не обязательно ребутать хост, можно сделать mask path по всем путям и потом вернуть обратно. В этом случае хост увидит лун заново и сформирует новый vml id
Процедура такая:
1. Создаем claimrule для всех путей
esxcli storage core claimrule add -r 110 -t location -A vmhba0 -C 0 -T 1 -L 5 -P MASK_PATH
esxcli storage core claimrule add -r 111 -t location -A vmhba1 -C 0 -T 2 -L 5 -P MASK_PATH
2. Загружаем созданные правила
esxcli storage core claimrule load
3. Делаем reclaim для всех путей девайса (переопределяем какие плагины должны быть ассоциированы с путями)
esxcli storage core claiming reclaim -d naa.600600...
После этого девайс пропадет из списка
Теперь нужно вернуть как было
4. Удаляем созданные правила и применяем изменения
esxcli storage core claimrule remove -r 110
esxcli storage core claimrule remove -r 111
esxcli storage core claimrule load
5. Unclaim для скрытых путей (тут надо помнить какие -A -C -T и -L использовались, как посмотреть, если не записали не знаю)
esxcli storage core claiming unclaim -t location -A vmhba0 -C 0 -T 1 -L 5
esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 5
Девайс вернулся назад. Делаем rescan all, либо в консоли
esxcli storage core claimrule run
KB:
mask path: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009449
unmask path: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015252
Проблема с миграцией машины с RDM: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016210
Идентификаторы лунов: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014953