[Libguestfs] How does guestmount actually work?

[Sergey Ivanov]

Is there any articles that explain in detail how actually guestmount works
internally?
My main question is how does guestfs deal with backing disk changes.

So, I have a libvirt/qemu-kvm setup. Each vm has a lvm2 volume for a disk.
For example, I want to mount one of these volumes and read some data.
1. I mount the volume using guestmount (guestmount --ro -d <libvirt domain>
-m /dev/sda1 /mnt)
2. Files become available in /mnt
3. If I make changes to the filesystem from inside the VM, no changes are
visible in /mnt

In guestfs-faq, there is a diagram that shows how guestfs interacts with
the backing disk, and the description says that you can't see what's
happening in the underlying filesystem because of vm/appliance caches, and
it should work this way.

Now, I fill my host's RAM with garbage until I end up with like ~50mb
available. Then I
1. Mount the LV again
2. Go into guest OS and do some I/O operations like extracting some big
.tar.gz files, and then do fdatasync and drop all the caches
3. Read all the data from /mnt, where the VM's disk is mounted
4. See no changes again

Swap is not used. Overcommit is not enabled either. All the memory
allocated is actually in use.
There is virtually no RAM available at this moment, but the oom killer
still doesn't invoke. Buffers/cache column in `free` output shows that
approximately 2gb is used, which, I assume, are used not exclusively by
guestfs.
The LV is 20gb in size, 16 of which are used.
How does guestfs manage to preserve filesystem's state after mount? Is
there any chance that the changes made to the backing file will somehow
become visible in /mnt? Why is that supermin appliance needed to mount a
disk? How is it used and how does it interact with every other part?
I hope someone explains this to me, or at least that there is already an
article on that matter.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20181023/8502a914/attachment.htm>