Libguestfs - Oct 2018 - How does guestmount actually work?

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.

[Hi, sorry this email arrived when everyone was at the
KVM Forum last week]

On Tue, Oct 23, 2018 at 09:10:20PM +0300, Sergey Ivanov
wrote:
> Is there any articles that explain in detail how actually guestmount works
> internally?
guestmount is libguestfs + FUSE.  The internals of libguestfs
are covered here:

http://libguestfs.org/guestfs-internals.1.html

I was fairly sure I had a diagram on my blog explaining the many
layers of software that unfortunately are involved when you combine
libguestfs with FUSE, but I cannot find it right now.
> My main question is how does guestfs deal with backing disk changes.
Simple answer: no.

Think of guestfs as an automated way to attach a disk image to qemu.
What would happen (forgetting entirely about guestfs) if you attached
a disk to qemu, then wrote to the disk?  Both qemu and the kernel
running inside qemu would get very confused.

There is a way to do this which is to close the libguestfs connect and
reopen it.  This is much easier to do if you are using the guestfs API
directly rather than using guestmount, but in either case there's the
overhead of launching the handle.
> 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.
I hope the diagram in the first link above explains why this is a bit
more complex.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html