Работа с операционной системой Windows Server не бывает скучной, так как, порой, можно получить сюрприз с загадкой в самом неожиданном месте. Казалось бы, что можно ожидать от привычной функции, которую уже приходилось использовать десятки раз. С таким, абсолютно невозмутимым настроем, на одном из хостов виртуализации Hyper-V на базе Windows Server 2012 R2 я решил выполнить сжатие дискового тома NTFS (Shrink Volume) с ОС, чтобы освободить немного места на конце диска.
Стандартным способом, используя консоль Disk Management, я попытался выполнить сжатие выбранного NTFS тома.
Свободного места на томе было более чем достаточно, и было решено отрезать 10GB.
Однако, к моему удивлению, возникла ошибка, говорящая о нехватке доступного места для проведения операции "There is not enough space available on the disk(s) to complete this operation"
Повторная попытка провести операцию сжатия привела к той же ошибке.
Обратившись к консоли Event Viewer, было обнаружено, что в логе Windows Logs\Application в момент попытки сжатия фиксируется предупреждение с кодом 260 из источника Defrag с сообщением "Error: during volume shrink initiated on volume C: we failed to move a movable file extent". В этом событии в деталях диагностической информации фигурирует отсылка на некий файл last unmovable file, который, как я понял, и препятствует перемещению дискового кластера.
Возникло подозрение, что удаление указанного файла, возможно решило бы проблему с невозможностью сжатия диска. Но что это за tmp-файл такой, да ещё и в системном каталоге, понимания пока не было. Попытка вручную удалить файл завершилась ошибкой "Access is denied".
Стало понятно, что либо файл удерживается каким-то процессом, либо имеет какие-то хитрые разрешения. Прежде чем погружаться в дальнейшее изучение вопроса с проверкой прав доступа и вычислением процесса, блокирующего доступ к файлу, сделал быстрый заход в поисковую систему по маске имени файла vmg.tmp и тут же нашёл одну интересную ветку обсуждения. Намёк в сторону управляющего процесса Hyper-V, порождающего временные файлы типа vmg.tmp при работе с ISО-образом компонент интеграции, привёл меня в лог Microsoft\Windows\Hyper-V-VMMS\Storage, который оказался переполнен ошибками типа:
Log Name: Microsoft-Windows-Hyper-V-VMMS-Storage
Source: Microsoft-Windows-Hyper-V-VMMS
Event ID: 27000
Level: Error
User: SYSTEM
Computer: KOM-VM02.holding.com
Description: Failed to open attachment 'C:\Windows\system32\vmguest.iso'. Error: 'One or more arguments are invalid'.
Это напомнило мне ранее описанную ситуацию с невозможностью обновления ISO-образа компонент интеграции из-за того, что файл образа %windir%\system32\vmguest.iso был занят запущенной виртуальной машиной.
И действительно, просмотрев свойства виртуальных машин, запущенных на хосте, было обнаружено, что в одной из ВМ был подключен ISO-образ компонент интеграции.
Отключение данного ISO-образа из свойств виртуальной машины привело к исчезновению недоступного для удаления временного файла.
После чего была предпринята новая попытка сжатия диска, которая на этот раз прошла успешно.
В ходе выполнения операций сжатия в Application-логе событие из источника Defrag оповестило об успешной оптимизации перед непосредственным процессом усечения тома.
Log Name: Application
Source: Microsoft-Windows-Defrag
Event ID: 258
Level: Information
Keywords: Classic
Computer: KOM-VM02.holding.com
Description: The storage optimizer successfully completed shrink on SYSTEM (C:)
На этом дело о неработающем сжатии можно было считать закрытым, но при этом остался осадок изумления от самой возможности появления причинно-следственной связи между, казалось бы, несвязанными обстоятельствами – установленным в свойствах виртуальной машины образом компонент интеграции и неработающим сжатием системного тома NTFS.
Комичность всей описанной ситуации дополняет то, что в самом начале, когда я получил ошибку невозможности сжатия, в качестве профилактического мероприятия была выполнена дефрагментация тома и утилита дефрагментации с честными глазами сказала мне, что теперь на томе всё красиво.
RSS - Записи
Получается образ был подключен даже не к этой же виртуальной машине?
Не имеет значения к какой ВМ был подключён образ. Имеет значение то, насколько в момент подключения образа был заполнен системный диск хоста. Например, сначала системный диск хоста заполнен на 65GB из 70GB общего доступного объема. В этот момент подключаем образ компонент интеграции на любую ВМ, которая работает на этом хосте. После этого освобождаем место на диске хоста, например до уровня 30GB из 70GB и пытаемся выполнить сжатие диска хоста, например на 10GB... в этот момент получаем ошибку невозможности сжатия. Проблема возникает по той причине, что созданный в процессе монтирования ISO-образа временный файл на системном диске хоста фактически записан в конец диска, то есть где-то в диапазоне от 65 до 70GB.
Интересная логика работы Hyper-V. То есть это даже не баг а фича получается?
с первой версии hyper-v я не мог понять, ну к чему такие зависимости от какого-то образа, подключенного к виртуалке?! vmware молодцы, а MS - гребаные индусы.
Зачем же так об индусах. А в VMware, полагаю, есть свои не менее интересные проблемы.
@Алгыз, зачем холиваришь? В Варе своих косяков хватает тоже. И вообще нормальная практика отключать ISO от VM когда он больше не требуется - что в варе, что в hyper-v.