Vmware virtual disk scsi disk device что это
Друзья помогите пожалуйста с решением дурацкой ситуации. Давно знаю поговорку, что скупой платит дважды, но нужен был компактный ноутбук, а на авито как раз оказался отличный 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.
Приложите скриншот "Управления дисками"
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion — и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски — это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором — это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS — не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом — основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе — дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности — например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Как диски RDM выглядят на сервере VMware ESX / ESXi
Когда мы создаем виртуальную машину, при добавлении к ней виртуального диска мы выбираем следующий пункт:
Далее нам предлагают выбрать Target LUN для тома RDM. Обратите внимание, что VMFS-томов в списке таргетов для дисков RDM нет. Понятно дело, что ваша SAN-фабрика должна быть настроена так, чтобы хосты ESX видели этот LUN (а именно те хосты, для которой будут работать vMotion и HA).
Но будьте осторожны — создав RDM-том на одном из хостов, не отформатируйте его случайно под VMFS на другом (это, само собой, все данные этого диска уничтожит).
Далее выбираем VMFS-хранилище, где будет лежать mapping-файл:
Далее выбираем режим совместимости — Physical RDM или Virtual RDM:
После этого диск будет добавлен. Далее давайте посмотрим, что у нас теперь в папке с виртуальной машиной:
А тут у нас RDM-test.vmdk размером в 5 ГБ (такого размера у нас физический LUN, который мы примаппировали к виртуальной машине). Само собой, этот диск столько на нашем томе VMFS не занимает. Давайте глянем на папку из физической консоли сервера ESX:
На самом деле, как и для обычного диска, у нас есть заголовочный файл RDM-test.vmdk и mapping-файл RDM-test-rdmp.vmdk, который не занимает 5 ГБ (хотя так и показано), а занимает обычно 1-2 МБ. По сути файл -rdmp.vmdk — это что-то вроде символьной ссылки на устройство, который содержит его идентификатор, служебную информацию о режимах работы и позволяет использовать динамическое разрешение имен (об этом ниже).
Динамическое разрешение имен для RDM-дисков
Нам, как пользователям, сервер VMware ESX показывает mapping-файл в удобном символьном виде (RDM-test-rdmp.vmdk), которое не меняется после перезагрузки и других событий. На самом же деле в глубине закопаны всякие идентификаторы SCSI-устройств, пути и т.п. Dynamic name resolution позволяет скрыть от пользователя операции по замене путей и имен устройств, например, при отказе одного из коммутаторов SAN, замене HBA-адаптера и прочих событиях. Все это делается автоматически.
Кстати, для RDM-диска можно управлять путями из GUI клиента vSphere (как и путями к VMFS-хранилищам). Делается это здесь:
Как оказалось у нас на сайте нет инструкции по подключению локальных дисков сервера VMware ESXi в качестве RDM-дисков для виртуальных машин. Восполняем этот пробел. Как известно, если вы попытаетесь добавить локальный диск сервере ESXi в качестве RDM-тома для ВМ, вы там его не увидите:
Связано это с тем, что VMware не хочет заморачиваться с поддержкой дисков различных производителей, где будут размещены производственные виртуальные машины. Поэтому нам нужно создать маппинг-файл VMDK на локальное дисковое устройство, который уже как диск (pRDM или vRDM) подключить к виртуальной машине.
Для начала найдем имя устройства локального SATA-диска в списке устройств ESXi. Для этого перейдем в соответствующую директорию командой:
И просмотрим имеющиеся диски:
Нас интересуют те диски, что выделены красным, где вам необходимо найти свой и скопировать его имя, вроде t10.ATA___….__WD2DWCAVU0477582.
Далее переходим в папку с виртуальной машиной, которой мы хотим подцепить диск, например:
И создаем там маппинг VMDK-диск для создания RDM-тома, при этом можно выбрать один из режимов совместимости:
Для pRDM (Physical RDM):
Для vRDM (Virtual RDM):
После того, как vmdk mapping file создан, можно цеплять этот диск к виртуальной машине через Add Virtual Disk (лучше использовать для него отдельный SCSI Controller):
Второй способ, который работает не для всех дисков — это отключение фильтра на RDM-диски (это можно сделать и на сервере VMware vCenter). Для этого в vSphere Client для хоста ESXi нужно пойти сюда:
Configuration > Software > Advanced Settings > RdmFilter
Там и выставляется соответствующая галочка:
Однако, повторимся, этот метод (в отличие от первого) работает не всегда. Ну и учитывайте, что подобная конфигурация не поддерживается со стороны VMware, хотя и работает.
21.11.2019
itpro
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.
Если виртуальные диски в Windows подключены через точку монтирования (mount point), в выводе будет отсутствовать информация о назначенной букве диска и метке тома.
20.01.2020
itpro
VMWare
комментариев 13
Предупреждение ‘Virtual Machine disks consolidation is needed’ на вкладке Summary виртуальной машины в консоли VMWare vSphere означает, что при удалении снапшота (операция Delete или Delete All) не удалились корректно (остались на диске) файлы виртуальных vmdk файлов снапшотов или логи. В результате не удается выполнить резервное копирование виртуальной машины.
Самые распространённые причины появления ошибки «Virtual Machine disks consolidation is needed»:
Для исправления ошибки «Virtual machine Consolidation Needed status «необходимо щелкнуть ПКМ по виртуальной машине и выбрать в меню пункт ВМ -> Snapshots -> Consolidate.
Появится окно с запросом:
This operation consolidates all redundant redo logs on your virtual machine. Are you sure you want to continue?
Подтверждаем удаление избыточных логов. После этого vCenter выполнит консолидацию дисков и очистку логов. Процесс консолидации может занять несколько минут, в течении которых производительность ВМ может ухудшиться.
После этого предупреждение о необходимости консолидации ВМ исчезнет.
В некоторых случая при выполнении консолидации в консоли vSphere может появится ошибка:
Unable to access file since it is locked. An error occurred while consolidating disks: Failed to lock the file. Consolidation failed for disk node ‘scsi0:0’: Failed to lock the file.
VMware в этом случае рекомендует выполнить перезапуск агентов Management agents на сервере ESXi. Для этого нужно подключиться к хосту по SSH и выполнить команду:
Однако вы можете попробовать разблокировать файлы виртуальной машины так:
- Выключите виртуальную машины (если возможно);
- Создайте новый снапшот;
- Удалите свсе снапшоты ВМ с помощю пункта «Delete All»;
- Переместите ВМ на другой ESXi с помощью vMoteion;
- Попробуйте выполнить консолидацию снапшотов как указано выше.
Вы можете найти все виртуальные машины, которые требуют консолидации с помощью PowerCLI. Для этого подключитесь к своему серверу vCenter:
Теперь получим список всех ВМ со статусом «Virtual machine disks consolidation is needed»:
Теперь можно выполнить консолидацию дисков всех полученных машин:
Предыдущая статья Следующая статья
HPE ESXi: Низкая производительность дисков в кастомных образах HP
Интеграция сторонних драйверов в ISO образ VMWare ESXi 6.7
Установка и базовая настройка бесплатного VMware vSphere Hypervisor
Особенности VMware vSAN 6.5: FAQ и настройка кластера
Здравствуйте. Спасибо за статью. Помогло.
Интересует вопрос. Я удалил Snapshot. При удалении не поставил галочку «удалить из storage». В результате в хранилище остался VMware virtual disk file (.vmdk) с названием типа server-000002-sesparse (30ГБ). Могу я его удалить, что бы это не повлияло на работу данной VM?
Спасибо.
Извините за долгий ответ. Можно попробовать сделать storage vmotion на другое хранилище. Если sesparse файл останется в исходном каталоге — он лишний (переносятся только связанные файлы).
Также можно открыть vmsd файл на хосте и посмотреть есть ли в нем ссылки на файлы снапшотв.
Здравствуйте!
У меня есть три снапшота виртуальной машины. Сейчас работает третий, последний снапшот. Поздно понял, что снапшоты плодить — это очень плохая практика. Какой правильный вариант убрать все снапшоты так, чтобы в итоге состояние виртуальной машины осталось как сейчас. при работе третьего снапшота?
С уважением,
Денис
Просто удалите все снапшоты. ВМ останется в текущем состоянии.
Спасибо за быстрый ответ!
А ВМ при этом нужно выключать или должна работать?
Не важно 🙂 Но при выключенной ВМ консолидация и удаление снапшотов выполняется быстрее.
По-хорошему, указывать, что это перевод статьи xxx даже картинки их.
Ну вот тут вы не правы. оригинал как раз здесь — там автоматический перевод, причем кривой. Если хоть немного знакомы с английским, увидите множество ляпов.
ps. Удалил ссылку, нечего их пиарить.
Прошу прощения. Смотрел по дате публикации. Вверху слева указано 20.01.2020, я подумал это оно. А вот по комментариям вижу, что ещё в 2018 были отзывы.
Относительно перевода, сперва наткнулся на эту статью, и лишь позже увидел их. Начал было читать, и понял, что уже где-то видел. Поэтому и даже не стал более вникать в их «перевод».
Здравствуйте, возникла небольшая проблема со снапшотами. Veeam Backup хотел сделать резервную копию виртуальной машины но выдал ошибку в процессе работы. В виртуальной машине подключённые HDD заканчиваются на 000001 но в Snaphot Manager нет никаких снапшотов. Место на datastore заканчивается но новые диски с 000001 растут понемножку в объёме. И вот вопрос когда закончиться место на datastore виртуалки не запустятся как можно удалить эти снапшоты но так чтоб потом можно было запустить виртуалки. Поменять в настойках VM путь к нормальных дискам без 00001 но тогда навернека не будет видно последних изменений?
Вышеописанные способы не помогли(
Мне помогло:
1) Выключить VM;
2) Удалить ее из перечня (Remuve from Inventory);
3) Зарегистрировать ее повторно (зайти через vCenter в папку с VM; найти файл с расширением VMX и зарегистрировать);
4) Повторить консолидацию.
Читайте также: