This will be my first post here. I can say, up to this point, the forums and the fact that Unraid is Linux based has been enough for me to skate by on what I already know. This problem seems a little deeper, or I am missing something entirely.

 

Long Story:

About a week ago I decided it was time to do maintenance on the Unraid server (files were all over the place, too many unnecessary shares, unused dockers, etc, etc). I got everything cleaned up, and in the process I noticed that my "system" share was being spread across every drive. I didn't like this. Moving or otherwise messing with docker.img and libvirt.img potentially lead to disaster, or so I found out. I shutdown all my VMs and dockers. I changed the settings for my "system" share to only use the disk that I wanted, and then manually moved the docker.img and libvirt.img files to the new share using the CLI. I rebooted the Unraid server, and to my dismay, all of my dockers disappeared, my virtual machines were OK at this point. Easy enough to restore my dockers so I did so. 

 

Short Story:

Fast forward to this morning. I notice that one of my disks is being pounded away at for seemingly no reason. I stop the array, and start it. Boom, all my virtual machines are gone from the GUI (the "domains" share still exists, and all of my VM files seem to be intact). OK, whatever, I can just recreate each VM and just point them to their corresponding virtual disks... or so I thought. I cannot get any of my Linux VMs to boot from their virtual disks. I was able to recreate a Windows 10 VM without issue. 

 

If I use OVMF bios, while booting I get dropped into a shell prompt.

If I use Seabios, the VM just stays at the boot screen and says "Booting from hard disk..."

 

I have also tried switching the disk mode to IDE and SATA, no difference.

 

I attached my diagnostics file and one of the VM configs that I am currently trying to restore.

Any thoughts?

screamingmimi-diagnostics-20180722-1148.zip

VM.xml

Edited July 24, 20187 yr by JimJamUrUnraid

It's good practice to make a backup of the libvirt.img file, that's were all the VM XMLs are stored, if it gets damaged or deleted restoring it will get all the VMs back (you also need the vdisks obviously).

So is this just a story of, you’re a dummy for not making a backup?

 

No one has any ideas about why these virtual disks can’t be booted from?

On 7/22/2018 at 3:02 PM, JimJamUrUnraid said:

If I use OVMF bios, while booting I get dropped into a shell prompt.

If I use Seabios, the VM just stays at the boot screen and says "Booting from hard disk..."

 

If the vm was created using seabios, you should only use seabios. Same for ovmf.

 

If you use ovmf and get the shell, type exit and press enter. Once in the ovmf bios, go to boot devices (or something similar) and attempt to boot from there.

So I messed around in the BIOS before, this time I got a little further.

 

The TIANO CORE BIOS has an option called "Boot Manager". This lists the available boot options, of course my disk didn't appear.

 

Ultimately I've done this to boot the VM, "Boot Maintenance Manager" -> "Boot Options" -> "Add Boot Option" then select "NO VOLUME LABEL, [PciRoot bla bla bla]. Then I select an option called "EFI", then a folder called "ubunu" and then a file called "grub64.efi". Now if I got back to the "Boot Manager" option in the BIOS, my manually added boot option is present and I can boot to the vdisk.

 

This only works once, if I reboot the VM, I have to do this all over. Any thoughts on how to get this to stick?

 

Edit 1:

After doing this again, moving my custom entry to the top of the boot order, and gracefully exiting the bios instead of selecting my custom boot option, the settings seem to have stuck.

 

Edit 2:

libvirt.img -> scheduled back via "user scripts" plugin to separate NAS created

vdisk.img -> scheduled backups of multiple vdisk.img's created via the same "user scripts" plugin.

 

Thanks for the extra push to the solution @1812 and thank you @johnnie.black for the push to backup the important details. I should have done this before, shame on me...

Edited July 24, 20187 yr by JimJamUrUnraid
found a solution, then an update on the status

glad you've got it sorted!