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've read mixed opinions about how safe it is to modify qemu disk image files.

There are two distinct situations I'm interested in.

1) let's take a raw or qcow2 disk image file not used by kvm (i.e. the virtual machine is not running), mount it using losetup and kpartx and modify its contents (e.g. edit some files, remove some, add some, ....). While I've done this with no problem until now (provided I don't go beyond the maximum size of the image), I'm not sure this is perfectly riskless; I especially wonder how the space-saving features of those image formats behave in such cases - i.e. are they only activated when the VM is running or is a feature of the disk image file by itself.

2) same situation (mounted disk image) but the virtual machine is running now. Is is safe to access the image file contents read-only and even to edit/add some file provided for sure I'm absolutely certain this won't interfer with processes running in the VM ?

Thanks in advance,


share|improve this question
up vote 3 down vote accepted

For scenario #1, everything should be fine if the guest isn't running. But I would use guestmount rather than losetup. Loop mounting is probably OK for raw volumes, but I am not sure how it handles qcow. guestmount does extra work to ensure things are loaded as they would be by a VM.

For scenario #2, read only will be fine, just make sure you really mount it read only. --ro will do this in guestmount. But read-write is guaranteed to cause corruption.

share|improve this answer
Thank you for both your answer and pointing me to libguestfs tools which I missed, inexplicably. – phep Jun 15 '13 at 13:43
  1. It's "safe" as long as you do the normal filesystem dismount and detach the image. "raw" has no "space saving" features, it's just a raw disk image. The qcow2 stuff should work as usual.

  2. Unless the file system was explicitly designed for Cluster Shared Storage environments (which very, very few are) then no, this will destroy the file system.

share|improve this answer
Thanks. As for the "space saving" feature, I hesitated on interpreting what the qemu-img says about using a raw file on filesystems that can deal with spare files (as ext2/ext3/...). I've made some more reading about it and I'm rather confident but it's still not quite clear for me. On the other hand, your answer for 2. is ambiguous (as my question was twofold, actually). A @AngerClown pointed out in its answer, while mounting a live VM read-write is promised to bad ends, it's perfectly safe to mount it read-only (as for libguestfs docs). – phep Jun 15 '13 at 13:40
That's "sparse" files, and a function of the underlying filesystem holding the raw file, not qemu doing anything. I'm not sure how my #2 is ambiguous, could you clarify? As for read-only, if both the "systems" are accessing the file read-only that would work, but not if any have write access. – Chris S Jun 16 '13 at 16:04
I wrote "ambiguous" since you firmly said "this will destroy the file system" and this is not true in the case it is mounted read-only. But as I acknowledged, the fault is mine since my question was itself ambiguous as I asked for both cases (rw and ro). You're right for "sparse", for sure - sorry, NNES. – phep Jun 21 '13 at 14:20
Would you both care to correct your questions and answers, please? I'd like to access the FS of a running VM in readonly mode from the host. And I'm quite confused now it that will destroy the image, or not. – user1129682 Jul 11 '14 at 18:52

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.