2

I am running several KVM guests on an Ubuntu 10.04 host. Due to carelessness, the qcow2 images of the running hosts have been deleted. They are still running and responding properly as well as reading/writing, etc. If you stop a guest, it will refuse to boot due to a missing image though.

I am curious to know where these files are written to and read from currently. Is it in memory? Bonus question is, is it possible to recover the data back into a qcow2 image? This is not mission critical data so I'm glad to experiment here. It would mostly just be a time-saver if I didn't have to rescue the data and re-create each guest.

roktechie
  • 83
  • 1
  • 2
  • 9

3 Answers3

5

Having an open file descriptor and having a directory entry are different, somewhat related things. As long as KVM has the qcow2 files open they still exist on the disk in the same blocks they did before. On Linux you can recover the files from /proc/[pid]/fd/[file descriptor] using the method described in this SuperUser question.

Community
  • 1
Gerald Combs
  • 6,331
  • 23
  • 35
  • 1
    The file can be modified during the copy, leaving the partition on the virtual disk on an incoherent state. It can be wise to freeze the virtual machine during the copy. But this is only possible if the VM was launched with the -monitor option – Gregory MOUSSAT May 11 '12 at 23:05
  • Gerald, you saved me quite a bit of time by not having to rebuild those VMs by hand. Thanks for your response. – roktechie May 14 '12 at 17:04
1

When the backend is gone, things are all cached either in memory or swap. So if you just want to recover data, you can still ssh, then rsync to some other server what is important for you.

You try to dd if and pipe to ssh to dd of to another image. It may or may not work. So the first order should be data saving, and then if you have time left, you can attempt replicating an image.

johnshen64
  • 5,747
  • 23
  • 17
1

I did something similar in esx some time ago. The answer from support was that the file still existed on disk and had been unlinked from the file system table. On closing the file the open handle drops and attempting to use the table to look up the file fails.

If I remember correctly we used lsof to track down the open handle and pull it from disk into a rebuilt file. This was a long time ago though.

Tim Brigham
  • 15,465
  • 7
  • 72
  • 113