Такие ошибки при запуске бэкапа могут возникать по причине наличия остатков в реестре от VSS-провайдеров, которые ранее были удалены из системы. В моем случае ошибки появлялись на хостовой машине Hyper-V на Windows Server 2008 R2 при запуске резервного копирования. Запустив команду vssadmin list providers я увидел, какие VSS-провайдеры зарегистрированы у меня в системе, и сравнил их с PID-ами тех, которые были в ошибках. Выяснилось, что ошибки возникали в отношении провайдеров, которые мне были не нужны и которых я ранее удалил из системы. Далее я удалил записи в реестре от этих провайдеров следующим образом:
1) Находим в реестре ключ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS\Providers\] 2) На всякий случай создаем резервную копию этого ключа 3) Удаляем ключи с соответствующим PID 4) Перезапускаем службу "Microsoft Software Shadow Copy Provider" 5) Запускаем бэкап и смотрим на наличие ошибок. Если ошибки появились вновь, перезагружаем систему.
Начиная с Windows Server 2012 компания Microsoft изменила процедуру сжатия (compact) файлов виртуальных жестких дисков (vhdx) - перед сжатием такого файла нужно вначале присоединить (mount) его к системе в режиме "Только чтение" (Read-only), а потом уже выполнять процедуру сжатия. Затем файл нужно отсоединить (dismount).
Присоединить и отсоединить vhdx-файл можно как с помощью оснастки "Управление дисками" (Disk Management), так и с помощью PowerShell.
Присоединяем vhdx:
Ставим галку "Read-only" (Только чтение):
Сжимаем vhdx используя Edit Disk в консоли Hyper-V:
Отсоединяем vhdx с помощью оснастки "Управление дисками":
Для PowerShell набор команд будет выглядеть следующим образом (запускать PowrerShell нужно с повышением):
При развертывании виртуальных машин в среде Hyper-V на сервере на базе материнской платы ASUS P7F-C/4L столкнулись с проблемой жутких тормозов при работе с сетью - вдомененные машины долго грузились, не могли авторизоваться на контроллере домена, не обрабатывались групповые политики, RDP работал невозможно медленно, иногда пропадали пакеты. При этом сеть на хостовой машине работала великолепно, никаких нареканий. Не буду долго описывать, как мы локализовали проблему, в общем проблема оказалась в некорректной работе интегрированных сетевых адаптеров Marvell 88E8056 при использовании виртуальных сетей Hyper-V. Обновление драйверов до самых последних с сайта производителя ни к чему не привело. После непродолжительного танца с бубном с настройками драйвера Marvell выяснилось, что проблема исчезает при отключении функции Large Send Offload (IPv4). Это, конечно, переведет исполнение этой функции на CPU, но по крайней мере решает проблему. Кстати, на сетевых картах Intel все хорошо работает и с включенной этой функцией.
Диспетчер задач не показывает сведения о ЦП для виртуальных машин Hyper-V. Чтобы просмотреть сведения о загрузке ЦП для виртуальных машин, можно воспользоваться Монитором производительности и стабильности системы. Он показывает данные, полученные со счетчиков производительности Hyper-V. Чтобы открыть монитор производительности и стабильности системы, нажмите кнопку Пуск, выберите команду Выполнить и введите perfmon. Данные, полученные с перечисленных ниже счетчиков производительности, можно просмотреть в управляющей операционной системе (в которой выполняется роль Hyper-V).
Логический процессор низкоуровневой оболочки Hyper-V — % времени гостевой работы: определяет объем ресурсов физического процессора, используемый для работы виртуальных машин. Этот счетчик не идентифицирует отдельные виртуальные машины или объем ресурсов, потребляемый каждой виртуальной машиной.
Виртуальный процессор низкоуровневой оболочки Hyper-V — % времени гостевой работы: определяет объем ресурсов виртуального процессора, потребляемый виртуальной машиной.
Между потреблением ресурсов виртуального и логического процессоров нет прямого соответствия, поскольку виртуальные процессоры можно назначить на любых логических процессорах.
Такая ошибка обычно возникает, когда нарушены разрешения безопасности на доступ к файлу конфигурации виртуальной машины или к подключенным к ней vhd-дискам. Сообщение об ошибке имеет примерно такой вид:
The application encountered an error while attempting to change the state of 'VIRTSERV'. 'Unnamed VM' failed to initialize. An attempt to read or update the virtual machine configuration failed because access was denied. 'Unnamed VM' failed to initialize. (Virtual machine 460113C2-D57D-4F67-8AFA-F6FE589D7410) 'Unnamed VM' failed to read or update the virtual machine configuration because access was denied: General access denied error (0x80070005). Check the security se ttings on the folder in which the virtual machine is stored. (Virtual machine 460113C2-D57D-4F67-8AFA-F6FE589D7410)
В таком случае можно воспользоваться командой icacls для изменения разрешений:
Замените 460113C2-D57D-4F67-8AFA-F6FE589D7410 на GUID виртуальной машины, которой надо предоставить доступ. Аналогичное надо проделать и с vhd-файлами, если это требуется, или удалить их из виртуальных машин и заново добавить.
Такая проблема возникает тогда, когда была попытка изменить размер VHD-файла, но при этом имеется снимок (snapshot) виртуальной машины, использующей данный VHD-файл. При создании снимка создается avhd-файл, в который начинают сохраняться изменения относительно родительского vhd-файла. При наличии дочерних avhd-файлов, изменять размер родительского vhd-файла нельзя! Иначе нарушается целостность цепочки vhd-avhd и виртуальная машина запускаться не будет с соответсвующей ошибкой. Официального решения данной проблемы нет, однако имеется сторонняя утилита vhdtool, позволяющая восстановить целостность нарушенной цепочки в случае подобного некорректного изменения. Используйте vhdtool с ключем /repair. Ссылка на сайт разработчика http://archive.msdn.microsoft.com/vhdtool
При использовании виртуализации на основе Hyper-V иногда возникает потребность сжать (compact) динамический VHD-файл. Как правило все проходит без проблем, но иногда при попытке сжатия возникает ошибка:
The requested operation could not be completed due to a file system limitation
Такая ошибка возникает тогда, когда динамический VHD-файл содержит внутри себя теневые копии. Для того, чтобы сжать такой файл, теневые копии необходимо удалить. Сделать это можно запустив в виртуальной машине, к которой относится этот файл, следующую команду:
vssadmin.exe delete shadows /all
Если после выполнения этой команды возникает ошибка
Snapshots were found, but they were outside your allowed context. Try removing them with the backup application which created them.
То следует воспользоваться командой diskshadow:
DiskShadow.exe DISKSHADOW>Delete Shadows All
Все команды необходимо запускать в командной строке, запущенной с правами администратора. Не забудьте после удаления теневых копий выключить виртуальную машину и можно запускать сжатие vhd-файла в оснастке Hyper-V.
Также сжатие vhd можно выполнить из командной строки с помощью diskpart, что может быть полезно в случае использования Hyper-V Server, у которого нет GUI: