Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer
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

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.