Vmware virtual disk scsi disk device что это

Обновлено: 04.07.2024

Друзья помогите пожалуйста с решением дурацкой ситуации. Давно знаю поговорку, что скупой платит дважды, но нужен был компактный ноутбук, а на авито как раз оказался отличный 14 дюймовый дел, на core i5 с 1 Тб памяти и 4 гигами оперативки, за какие-то 16 тыр. Продавец сильно опоздал, еще и приехал не туда куда надо, еще и отдал по ошибке другой ноут, в общем когда я получил именно тот ноутбук, за которым приехал, то в спешке не проверил все внимательно и уже придя домой обнаружил, что один из дисков определяется, как msft virtual disk scsi disk device, в биосе вместо 1 Тб виден хард на 320 гигов, хотя в моем компьютере красуются 2 жестких диска на 297 и на 634 гига соответственно. Судя по всему меня красиво обманули, так как закидывая данные на виртуальный диск, уменьшается свободный объем системного. Вопрос такой. Как быть в такой ситуации, правдивы ли мои выводы, что это за виртуальный диск такой и как его снести? Однако продавец по телефону сказал, что не вкурсе всего этого, был ошарашен и готов встретиться и обсудить ситуацию

Оценить 1 комментарий

Друг,ты сможешь вспомнить этого жулика? меня на днях такой же развел с ноутом,ищу его.

msft virtual disk scsi disk device - это обычный виртуальный диск от Microsoft (.vhd или .vhdx - файл) , его действительно можно сделать больше чем физический жесткий диск.
Если при покупке Вы рассчитывали на 1Тб, а в BIOS указано 320, то Вас действительно обманули.

Вот пример отображения виртуального диска:

Самое интересное его нет в управлении дисками, вот что меня смущает, ведь виртуальный хард должен где-то отображаться. И самое главное где хранятся файлы, записанные на виртуальный диск на самом деле? Они ведь должны быть на реальном харде в определенной директории.

В управлении дисками он будет отображаться как обычны HDD. Пример выше.
А найти подобные файлы можно только на реальном HDD.
Приложите скриншот "Управления дисками"

Недавно я столкнулся с ситуацией, когда на виртуальном диске в виртуальной машине vSphere начало заканчиваться место, а типичная операция по расширению дискового пространства оказалась невозможной. В моем случае это было связано с интерфейсом подключения диска — IDE.

Статьи, которые можно найти в этой связи в Интернет, например:
VMware Knowledge Base
Аналог, с картинками
к сожалению неполны.

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

Отступления

1. Чтобы не загромождать статью, я буду везде опускать слово «виртуальный», которое будет применяться к диску и к машине.
2. Я буду использовать специфическую терминологию/названия, типичные для vSphere.
3. Невозможность расширения диска может быть вызвана несколькими причинами: наличие снапшотов данного диска (при этом в менеджере снапшотов они могут быть не видны), отсутствие места для расширения, включенное питание машины и т.д. Здесь описывается ситуация, когда снапшотов нет, место есть, питание выключено, но диск IDE.
4. Существует теоретическая/(не проверял) возможность конвертации диска с помощью VMware Converter. Я ее не использовал по двум причинам: это достаточно «тяжелый» софт и я встречал упоминания о невозможности загрузки машины после конвертации
5. Операции производились на vSphere + ESXi v4.1U2. Я не гарантирую работоспособности метода на других версиях (но в принципе должно работать, ничего сверхспецифичного).
6. Внутри машины установлена ~~неонка~~ WinXP 32bit, и часть действий на это рассчитана, если у вас стоит другая ОС имейте это в виду.
7. Формат диска Thick
8. У вас есть свежий бэкап данной машины (в процессе экспериментов я восстанавливался где-то раз 5).

Начали

Итак, наша машина выключена, у нас открыт vSphere Client.
Заходим в свойства машины, и добавляем SCSI Device. В качестве скази девайса у меня был сидиром, у которого рекомендуется сразу же поменять Virtual Device Node с SCSI(0:0) на SCSI(0:1), т.к. впоследствии на SCSI(0:0) мы повесим наш сконвертированный диск.
Скази девайс добавляется вместе со скази контроллером (SCSI Controller), у которого необходимо сменить тип с BusLogic Parallel на LSI Logic Parallel.

Сохраняем настройки и включаем машину.
Ставим драйвер для контроллера, который можно найти на сайте производителя: LSI Support.
Ищем драйвер для своей ОС, для LSI20320-R
После установки драйвера, хорошо бы проверить, что контроллер и скази девайс появились в оборудовании машины и установлены корректно.

Выключаем виртуальную машину.

В вышеприведенных ссылках, рекомендуют заменить одну строчку в файле %vm-name%.vmdk (ddb.adapterType) чтобы в дальнейшем все заработало. У меня это не сработало (машина не загружается вообще — не виден даже MBR).
После определенных изысканий была найдена проблема — разная геометрия дисков IDE и SCSI.
Таким образом необходимо выяснить геометрию SCSI диска с точно таким же размером как наш IDE диск.
Это можно сделать разными способами, лично я использовал VMware vSphere PowerCLI (см. подвал).
Итак, подключаемся к ESX(i) хосту и выясняем размер диска машины:

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

Создаем скази диск, аналогичного размера:

PowerCLI > New-HardDisk -Datastore datastoreXX -StorageFormat Thick -CapacityKB 10485760 -Controller "SCSI controller 0" %vm-name%

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

Немного теории:
В VMware виртуальный диск в простейшем случае состоит из двух файлов:
%vm-name%.vmdk — файл описания диска
%vm-name%-flat.vmdk — собственно сам диск (содержимое)
Кстати, Datastore Browser представляет их в виде одного файла, но если этот файл скачать, например, на локальную машину, то фактически получим два файла, как и должно быть (в теории может быть и больше, если использовался split).

На данный момент нас интересуют файлы описания старого IDE диска и новосозданного SCSI диска. Я пользовался SSH и WinSCP для их извлечения.
Для моего размера диска увидим следующее:

Сначала обратим внимание на вторую строчку, на цифры после RW, это размер дисков (в моем случае в 512b блоках). Числа должны совпадать, если они не совпадают, нет смысла читать дальше.

Далее сразу же бросается в глаза различие цилиндров и головок. Ну и тип адаптера.
Теперь редактируем файл описания старого IDE диска, меняем соответственно число цилиндров, головок и тип адаптера. Не рекомендую просто переписывать файл описания, таковым от нового скази диска, т.к. информации у старого IDE диска в этом файле больше.

Все что нам нужно было от тестового скази диска мы получили, поэтому его можно удалить (например с помощью Remove-HardDisk).

Теперь заходим в свойства виртуальной машины и удаляем IDE диск из состава машины.
будьте предельно внимательны, диск удаляем только из виртуальной машины (Remove from virtual machine), но не удаляем файлы с диска!

Сохраняем изменения, и опять заходим в свойства виртуальной машины. Добавляем жесткий диск, выбираем пункт «Использование существующего диска» (Reuse existing virtual disk) и указываем на файл с нашим диском.

В дополнительных свойствах, проверяем что диск встал на SCSI(0:0).

В данный момент можно удалить скази сидиром, если он не нужен, и проверить настройки IDE сидирома (если он есть). IDE сидиром необходимо установить на канал IDE(0:0) или IDE(1:0) (мастером), иначе машина откажется запускаться.

В целом это все. Можно еще зайти в БИОС виртуальной машины, проверить порядок загрузки.
Виртуальную машину можно запустить, при первой загрузке будет установлен драйвер на диск.

Периодически я слышу от практикующих инженеров странное: VMDK, VHD и VHDX – абсолютно разные форматы виртуальных дисков, чуть ли не закрытые, а конвертировать из одного в другое – долго и больно. Сегодня наглядно покажу, что это не так, разберу, как эти форматы соотносятся друг с другом и как делать быструю конвертацию при миграции с Hyper-V на VMware и обратно.

Немного теории. C точки зрения свойств, виртуальные диски делятся на два типа:

тонкие (thin disk, dynamic disk) и
толстые (thick disk, fixed disk). Все остальное — разностные, thick provisioned lazy- zeroed – лишь вариации на тему.

Форматы дисков

RAW – «сырой» образ любого диска. Это обычный контейнер, который не содержит никаких специфических заголовков и футеров и представляет образ диска «как есть». Если мы откроем такой образ HEX-редактором, то сразу увидим заголовки GPT/MBR и/или файловой системы. Точно такой же образ получается через команду dd в Linux. RAW в этом плане абсолютно честен с нами.

Начало файла RAW.

Конец файла RAW.

VMDK. VMware ESXi – обыкновенный RAW, где геометрия диска описывается в обычном текстовом файле-описателе (дескрипторе). Именно его имя мы видим в vSphere Console, когда подключаем виртуальный диск к виртуальной машине или просматриваем содержимое каталога на Datastore. VMware ESXi ничего не делает с образом. Совсем. Диск покоится себе и расширяется по мере необходимости. В лучших традициях VMware формат описателя очень простой:

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

Ниже представлены некоторые стандартные значения всех разделов дескриптора:

Описание всех значений можно посмотреть в спецификации формата: VMware Virtual Disk Format 1.1

VHD. Толстый VHD – тот же самый RAW, но с 512-байтным футером, где описывается геометрия диска. Какого-то отдельного файла-описателя у виртуальной машины Microsoft Hyper-V нет. Описание геометрии диска занимает 4 байта. Собственно, отсюда ограничение на размер диска в 2 Тб.

Футер. Последние 512 байт диска.

Самое интересное, что если создать файл-описатель и подсунуть в ESXi VHD-диск с футером, то гипервизор VMware проигнорирует этот футер и примет VHD как родной.

При Storage vMotion с конвертацией диска в тонкий он просто отрежет этот футер, и на выходе мы получим тот же RAW без нулей в конце. А при конвертации в толстый диск – честный RAW. Это я и собираюсь продемонстрировать чуть позже.

VHDX. Вся информация о геометрии диска хранится в первых 4096 Кбайтах виртуального диска – в области заголовка.

Общая схема толстого диска VHDX.

Что представляет из себя эта область? В ней содержатся две копии заголовков со своими логами, BAT и область метаданных общие.

Логическая структура заголовка диска.

В единицу времени только одна копия заголовка активна. Это обеспечивает определенный уровень отказоустойчивости заголовка в случае незапланированных прерываний операций чтения/записи. После каждой операции I/O копия реплицируется, и происходит переключение на нее.

Макет области заголовка.

Для конвертации VHDX в RAW нам всего-то нужно отрезать первые 4096 KB.

Начало данных на 5 МБ.

Внимательный читатель, конечно же, скажет: ок, Женька, а слабо RAW конвертнуть в VHDX? На что я отвечу: зависит от файловой системы и от того, насколько она позволяет записывать данные в начало файла. Вручную на файловой системе NTFS это можно сделать, сместив в MFT начало файла на 4 Мб вперед и дописав в это место заголовок.

По этому же принципу работает утилита vhdxtool.exe. Однако при этом преобразовании мы не получим красивую картинку в виде 4 Мбайт заголовка и RAW. Диск будет виден и даже будет корректно работать как VHDX, но будет и много «мусора» из нулей, появившихся из-за манипуляций со смещениями (offsets). Диск будет не оптимизирован. ВМ с таким диском рекомендуется смигрировать на другой том или оптимизировать через командлеты Convert-VHD или Optimize-VHD. Если этого не сделать, диск будет занимать больше места, чем должен, и, возможно, медленнее работать.

Однако в сценариях миграции с VMware на Hyper-V эта утилита незаменима, так как позволяет провести преобразование на месте, без необходимости побайтового считывания исходного диска и создания рядом копии. Все шероховатости будут сглажены при первом же Storage Live Migration.

Вывод: толстые диски форматов VMDK, VHD, VHDX на деле мало чем отличаются друг от друга. В их основе RAW c различными добавками. Тем же HEX-редактором или функциями ОС для работы с файловой системой мы можем за пару секунд превратить 10 Тб VMDK или VHDХ в диск целевого гипервизора.

Давайте на практике посмотрим, как VMware Exsi справится с VHD.

OS Version: Windows Server 2019 Standard,
Disk Type: Fixed,
Disk Layout: GPT,
Disk Size: 30GB.

Если не хочется фокусов, то можно воспользоваться инструментами ниже.

Исходный формат	Целевой формат	Инструменты	Пример команды
VHD	VHDX	vhdxtool.exe	vhdxtool upgrade -f <имя файла>.vhd
VMDK (RAW)	VHD	vhdtool.exe	vhdtool /convert <имя файла flat>.vmdk
VMDK (RAW)	VHDX	vhdtool.exe vhdxtool.exe	vhdtool /convert <имя файла flat>.vmdk

Подведем итоги. Различные форматы толстых виртуальных дисков не такие уж разные. В основе всего RAW с различными “добавками”.

Конвертация форматов виртуальных дисков — это не страшно, и, как я показал, иногда можно обходиться даже без нее.

Основной профит всего этого — сокращение времени миграции с Hyper-V на VMware и обратно и времени простоя ВМ при миграции. В DataLine мы такое практикуем с простоем ВМ менее 30 минут. Рекорд же — 40 секунд простоя ВМ при миграции между гипервизорами.

Только помните, что при миграции между разными гипервизорами одной конвертации недостаточно. Как минимум нужно предварительно поставить компоненты интеграции целевого гипервизора, удалить или отключить запуск компонентов исходного гипервизора, удалить виртуальные устройства исходного гипервизора и т.д. Но это уже совсем другая история, о которой я тоже могу рассказать.

21.11.2019

PowerShell, VMWare, Windows Server 2016

комментария 3

При увеличении размера или удалении диска в VMWare для виртуальных машин с Windows, иногда сложно понять какой VMware virtual disk соответствует определенном диску в Windows ВМ. Если дисков не много и все они отличаются по размеру, найти нужный диск просто. Но что делать, если для ВМ создано несколько VMDK (или RDM) дисков одинакового размера, или для ВМ создано несколько виртуальных SCSI контроллеров? Как не ошибиться и выбрать именно тот диск, который требует расширить (или уменьшить) администратор Windows.

В этой статье мы рассмотрим, как сопоставить диски Windows с виртуальными дисками (VMDK) на ВМ VMWare.

Проверяем номер SCSI устройства в Windows и VMWare

Откройте консоль управления дисками Disk Manager (diskmgmt.msc) в Windows (в нашем примере это Windows Server 2016). В списке дисков не отображается имя SCSI контроллера и номер SCSI устройства на нем. Чтобы определить номер SCSI устройства, щелкните по диску и выберите Properties. Как вы видите, на вкладке General в поле Location указано информация о порте устройства VMWare Virtual disk SCSI Disk Device.

Location 160 = SCSI Bus Controller 0
Target ID 1 = номер SCSI ID устройства 1

Объединяем полученные данные и получаем адрес диска SCSI(0:1).

Теперь откройте свойства виртуальной машины VMWare в vSphere Client. Найдите диск, у которого Virtual Device Node соответствует полученному ID. В нашем примере это SCSI(0:1) Hard Disk 2.

Если в виртуальной машине настроено множество виртуальных дисков с разными SCSI контроллерами (вы можете добавить в ВМ до 4 SCSI контроллеров по 16 дисков в каждом), найти номер SCSI устройства вручную довольно сложно. Кроме того, имейте в виду, что номера SCSI контроллеров в Windows и VMWare могут отличаться.

Как сопоставить диски Windows с VMDK файлами по UUID/SerialNumber через PowerShell?

Другой способ сопоставления виртуальных дисков VMWare с дисками внутри гостевой ВМ – сравнить их по уникальному идентификатору диска. Со стороны VMWare этот атрибут называется UUID (Unique ID), а в Windows – Serial Number. Рассмотрим, как получить значения UUID и SerialNumber виртуальных дисков через PowerShell.

По-умолчанию у всех ВМ VMWare включен параметр disk.EnableUUID=TRUE , это означает, что гостевая ОС должна видеть идентификаторы виртуальных дисков.

Для получения информации о дисках в Windows вы можете использовать командлеты модуля Storage, или WMI запросы. Т.к. в нашем случае ещё остались ВМ с Windows Server 2008 R2, в которых отсутствует модуль Storage, мы будем использовать WMI.

Чтобы получить номер SCSI контроллера, номер SCSI устройства на нем, серийный номер виртуального диска (SerialNumber/UUID), размер и номер диска в Windows, выполите команду PowerShell:

В нашем примере мы определили, что Windows видит три диска:

PHYSICALDRIVE0: SCSI Port 0, SCSI Target 0, Serial 6000c2939b153417dedbdce371ed497b
PHYSICALDRIVE1: SCSI Port 0, SCSI Target 1, Serial 6000c2950ee961954909259642bb03bf
PHYSICALDRIVE1: SCSI Port 4, SCSI Target 10, Serial 6000c2995fc3c4728de8b0596bb02ce3

Теперь попробуем получить номера SCSI контроллеров и UUID дисков, которые указаны в настройках виртуальной машины VMware. Для получения параметров ВМ нужно воспользоваться PowerCLI.

Данный скрипт подключится к серверу vCenter (или ESXi) и для указанной ВМ получит список дисков. После выполнения скрипта вы получите список виртуальных дисков для ВМ. Результат должен содержать имя DataStore, путь к vmdk файлу, номера диска, его размер и UUID.

Теперь по полученным UUID вы можете вручную сопоставить диски, которые видны в гостевой Windows с виртуальными дисками VMWare.

Если у вас есть права администратора в виртуальной машине, для которой нужно сопоставить диски Windows и vmdk файлы в VMWare, можно воспользоваться более простым в использовании PowerShell скриптом. Скрипт обращается к гостевой Windows по сети, собирает информацию о локальных дисках и показывает соответствие с дисками VMWare.

Полный код PowerShell скрипта:

Дополнительно возвращается информацию о буквах дисках и метках томов Windows.

Теперь вы можете без проблем разобраться какому виртуальному диску соответствует диск в Windows.

Читайте также: