3

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,

phep

phep
  • 414
  • 5
  • 15

2 Answers2

4

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.

AngerClown
  • 320
  • 1
  • 3
  • Thank you for both your answer and pointing me to libguestfs tools which I missed, inexplicably. – phep Jun 15 '13 at 13:43
  • scenario #2 is safe only as long as BOTH the guest and the host have mounted the image read only. (so adding files as mentioned in the question is not possible) – 9072997 Jul 20 '22 at 21:05
2

  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.

Chris S
  • 77,945
  • 11
  • 124
  • 216
  • 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