none
Event 19100 Hyper-V-VMMS - background disk merge failed to complete - a lot of avhd files RRS feed

  • Dotaz

  • Hello everybody,
    please our company run 3 Hyper-V hosts in cluster on OS Windows 2019, but on some virtual machines folders
    I found a lot of :-( avhd files like in the screenshot below:

    When I shutdown machine- merging is failing and in the event log is this error 19100:
    Microsoft-Windows-Hyper-V-VMMS/Admin
    'VIEDOCX_TEST' background disk merge failed to complete: An internal error occurred. (0x8007054F). (Virtual machine ID 9363D76B-DA0C-4946-B573-F00588C9B764)

    Restart of service "Hyper-V Virtual Machine Management" didn't help, trick with icacls didn't help too (command succeeded):
    icacls "C:\ClusterStorage\Volume1\VIEDOCX_TEST" /grant "NT VIRTUAL MACHINE\9363D76B-DA0C-4946-B573-F00588C9B764":(OI)F

    Blocking of applying GPO to Hyper-V host didn't help, (first I added "NT virtual machine\virtual machines" into Log on as a service key).

    Not every virtual machine has this "avhd problem", only some smaller part of VMs.

    In Hyper-V in CheckPoints window there is not seen any Checkpoints:
    ("The selected virtual machine has no checkpoints" - which is not true)

    When I open setting of virtual machine - disk option - there is correct info:
    ("Edit is not available because checkpoints exist for this virtual machine")

    Could You please advice, how to fix it (I mean automatic merging of avhd (not manual = a lot of avhd files)), when it is failing with error 19100 above? And how to prevent of creation of many avhd files in the future? (probably new avhd files created by backup software Veeam, but failed and not deleted)

    Thank You very much!

    Jiri

    úterý 3. srpna 2021 13:04

Všechny reakce

  • Pis cesky v ceskem foru.

    Vypada to, ze nektery soubor je drzeny nekym/necim jinym, nebo se poskodily prava. Milion AVHDx vetsinou vede na nejaky problem se zalohovanim - neuklizi po sobe. Cim zalohujes?

    Predpokladam, ze mista na disku mas dost a Hypervizor si restartnul.

    Zkus postup viz
    https://www.theictguy.co.uk/background-disk-merge-failed-to-complete/

    středa 4. srpna 2021 10:48
  • Zálohujeme přes Veeam, místo na shared disku jsem včera zvětšoval, bylo pod 1 TB.
    Spojovat manuálně mnoho avhd souborů je pro mě až ta poslední možnost.
    Hyper-V hosty jsem zatím nerestartoval, asi budu muset naplánovat restart.
    Práva přes icacls jsem zkoušel, nepomohlo to.
    (Psal jsem v angličtině a chtěl to dát do AJ fóra, ale nemohl jsem vybrat z menu servery tak jako v češtině, takže to skončilo zde)

    středa 4. srpna 2021 11:04
  • Přesun VMs an jiný host, restart Hyper-V host a vrácení zpět nepomohlo - auto merging failed.
    středa 4. srpna 2021 13:12
  • Hmm....

    Tak v to vidim na nejaky poskozeny AVHD.

    Potom asi jedine lumparna - obnovit ze zalohy a stare VMko smazat.

    středa 4. srpna 2021 13:52
  • resim ted neco podobneho u zakaznika. 

    desitky avhdx souborů. 

    evet manager:

    Failed to get VHD ('C:\ClusterStorage\SCv3020\XXXVirtual Hard Disks\XXX_E2_35CD518B-55F8-4239-BDB4-0E66A8797779.avhdx') parent: 'The system cannot find the file specified.'('0x80070002'). 

    Dokonce jsme ten disk E: i z VM odstranili a pridali novej (byl stejne na backupy) ale stejne to nepomohlo. 

    icals - nepomohlo

    reboot hostu - nepomohlo 

    VM dokonce nejde ani pres live migration prestehovat na jiny host v ramci clusteru, musime ji vzdy vypnout a nasledne quick migration a power on :( 



    středa 18. srpna 2021 14:12
  • Dobrý den, doufám, že mi v tomto Google překladač dobře poslouží.

    Přesně stejný problém se vyskytuje u mnoha virtuálních počítačů běžících na Hyper-V 2019 v klastru. Veeam používáme k zálohování virtuálních počítačů denně a replikaci pomocí replikace Hyper-V na sekundární web.

    Jste první příspěvek na fóru, který jsem našel s přesně stejnou chybou, kterou dostáváme, což je '0x8007054F'. Zjistili jsme, že jediný způsob, jak tento problém vyřešit, je exportovat virtuální počítač a poté znovu importovat virtuální počítač na místě, což umožní sloučení všech virtuálních pevných disků do jednoho souboru.

    Jednou z dalších metod, které jsme našli, je odebrání virtuálního pevného disku z konfigurace virtuálního počítače a ruční sloučení pomocí nástrojů PowerShell nebo Hyper-V, poté znovu připojíme příslušný disk a odstraníme všechny soubory VHD.

    Kontaktujte společnost Microsoft se zárukou malé nápovědy s blokováním „zkuste znovu vytvořit konfiguraci virtuálního počítače“, u které se problém vrátil. Veeam uvádí, že problém je na straně Microsoftu.

    Pozastavení replikace Hyper-V během procesu zálohování nepomůže, ale zdá se, že ovlivňuje pouze naše virtuální počítače, které jsou replikovány.

    Pokračujte prosím sem, rád bych slyšel, jak se vám daří.
    Zdá se, že tento problém neovlivňuje Hyper-V 2016, podle mých znalostí pouze 2019.


    Original

    Hello, I hope google translate does me well in this.

    We're experiencing the exact same problem with many virtual machines running on Hyper-V 2019 in a cluster. We use Veeam to backup the VM's daily and replicate using Hyper-V replication to a secondary site.

    You're the first forum post I've found with the exact same error we get, which is '0x8007054F'. We've found that the only way to resolve this issue is to Export the Virtual Machine and then re-import the VM 'in-place' which will allow all the VHDs to merge into a single file.

    One other method we've found is to detatch the Virtual Hard Disk from the Virtual Machine configuration and manually merge using PowerShell or Hyper-V tools, we then re-attach the affected disk and delete all the VHD files.

    Contact Microsoft warranted little help barring "try recreating the Virtual Machine Configuration" of which the issue did return. Veeam state that the issue is on Microsoft's side.

    Pausing Hyper-V replication during the backup process does not help, but it does appear to only affect our Virtual machines which are replicated.

    Please do keep heading back here, I'd love to hear how you get on.
    This issue does not appeart to affect Hyper-V 2016, only 2019 to my knowledge.

    pátek 20. srpna 2021 11:14
  • Poskozena VM nesla ani zazalohovat ani replikovat... 
    tak nakonec jsme to vyresili tak, ze jsem do VM nainsatloval veeam agenta, zastavil pro jistotu oracle DB a spustil backup do veeam repository, VM jsme vypli a provedli jsme instant recovery do clusteru, nasledne migrate to production a zda se byt vse OK. VM je mnohonasobne rychlejsi a hlavne bez .axhdx souborů ! Ano a potvrzuji, jedna se o bug ve WS 2019, na WS 2016 i WS2012R2 hyperv hostech sem se s timto problemem nesetkal. 
    pondělí 23. srpna 2021 8:43
  • Dear Dickins,
    thank You for Your experience! I hope, perhaps next week I would try to solve that problem.
    Jiqa

    pondělí 23. srpna 2021 18:54
  • Tomáši, díky moc za sdílení zkušeností!
    Snad se k tomu příští týden dostanu, abych se avhdx zbavil.

    Díky

    Jiqa

    pondělí 23. srpna 2021 19:01