force stoping a VM means having to re create it??

[RenatoEurope]

Hi,

 I just upgraded to 6.11.1 from 6.9.2, in hope to find a solution to a weired problem: Most of the times (not all of the times) forcing to stop a VM in 6.9.2 mean having to re-create the VM template because the one used would not work anymore, the VM would allegedly start but than never work. The only  way to re-launch that VM would be to re-create the VM template, assigning the same HD, video card, etc.  Launching the "old" template with VNC and than connecting to the VM via VNC showed a "The system has not initialized the display"  window. Recreating the Vm template, by clowning it , allowed the VM to restart correctly.

 

Is there a work around to this problem?

 

 

Thank you in advance for helping. 

[Robin R]

Curious about a few things:

1) If you reboot your Unraid system, does the original template work? (obviously this isn't a solution, but if it helps it might indicate the nature of the issue)

2) I am wondering if your NVRAM some how gets corrupted (assuming you even have something like this in your XML)

 

  <os>
    <type arch='x86_64' machine='pc-i440fx-6.2'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi-tpm.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/035e02d8-04d3-050c-b905-ae0700080009_VARS-pure-efi-tpm.fd</nvram>
  </os>

 

 

Recreating a VM from a template would re-create a new nvram entry if you are using nvram.

 

This might not help (and I'm not an expert, as I'm just a normal user of unraid), but I'd check those two things out.

 

[RenatoEurope]

Hi Robin,

 

 Thank you for helping.  In relation to your questions:

1) Rebooting the Unraid system does not change the situation.

2) in relation to nvram, I normally just modify in form mode the standard templates for Linux and Windows 10, I never messed around with the nvram settings, I went to check in the XML view one Windows 10 derived template and indeed found :

 

<os>
    <type arch='x86_64' machine='pc-q35-5.1'>hvm</type>
    <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
    <nvram>/etc/libvirt/qemu/nvram/0d25bedb-67e7-0d1f-a1cd-c570768c2f85_VARS-pure-efi.fd</nvram>
  </os>

 

As an ignorant on the subject, and not knowing the first think about nvram, what it is and what it does, I can observe the nvram files seem to have the creation timestamp of the VM they belong to and hence I could speculate, to test your theory,  I could save those files  on an hd and try to restore them  when a VM I force to stop, fails to restart and see whether, with the restored file, the VM can come to life again.