So this colleague of mine had a test VM server that they ran several VMs on. She accidentally deleted the folder that held the VMs drive files. This was potentially catastrophic. All the VMs, however were still powered on and functional, and it took her a couple of days to notice. This was a very good sign, as it meant that the VMs had a copy of their harddrive files open in /proc. There was no way to directly restore the files, but using lsof and ls i was able to identify the hdd file for each vm, then shutdown that VM, copy it back to it’s original location, and start it. The syntax I used is:
lsof lsof | grep -i <filename>
This returned a lot of stuff:
qemu-syst 3428354 libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2971727 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2972943 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2972945 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2972946 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2972947 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2972948 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2973398 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 2973578 worker libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428358 qemu-syst libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428362 IO\x20mon libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428363 CPU\x200/ libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428364 CPU\x201/ libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428365 CPU\x202/ libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428366 CPU\x203/ libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
qemu-syst 3428354 3428368 SPICE\x20 libvirt-qemu 17u REG 9,0 133607587840 13 /mnt/VMs/<filename> (deleted)
I chose the one labelled qemu-syst as i believed this would be the main process. I was right. After that I issued a ls command based on the following formula.
/proc/ (all the files are in proc when open) + 3428358 (the task id of the task labeled qemu-syst) + "/FD/" the folder under (3428358 that holds the file) + 17 (the number after the user running the app, in this case libvirt-qemu)
That looked like:
ls -l /proc/3428358/fd/17
This returned the following:
lrwx------ 1 libvirt-qemu libvirt-qemu 64 May 4 08:36 /proc/3428358/fd/17 -> '/mnt/VMs/<filename> (deleted)'
i then ran forcibly shutdown the vm, then copied the file back using the following:
cp /proc/3428358/fd/17 /mnt/VMs/<filename>
and after about 20 minutes of copying, it finished, i restarted the VM, it forced a chkdisk, and then booted right into windows.
I’d like to see Hyper-V and Windows do that!