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,


2 Answers 2


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.

  • Thank you for both your answer and pointing me to libguestfs tools which I missed, inexplicably.
    – phep
    Jun 15, 2013 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.

  • 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, 2013 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, 2013 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, 2013 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. Jul 11, 2014 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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