[Libguestfs] Integration with muCommander

[Arik Hadas]

On Sat, Nov 24, 2018 at 9:36 PM Nikolay Ivanets <stenavin at gmail.com> wrote:

> > Well, I don't need any information about the operating system itself but
> ideally, when browsing the disk image the user sees the file system(s) as
> if the user would have connected (e.g., via ssh) to the guest. So let's say
> that I browse a disk image with two partitions, the root that is mounted to
> "/" and another one that is mounted to "/boot". I think it makes sense to
> show the content of the disk in a way that the second partition is mounted
> to "/boot", and it seems that this mapping is only returned by inspect-os,
> right?
>
> Yes, that is right. You have to call inspect-os if you want to present
> disk (or I would rather say VM) content in the way the user expect it
> to be.
>
> >> 1. User: selects disk image, double-click. You: launch libguestfs
> >> instance, call list-filesystems and display them.
> >
> > Right, adding another level of file-systems is possible. The downside
> though is that I then stop seeing the directory-structure from the guest
> point of view, right?
>
> Right. But I want to stress you again: you MUST to add ALL VM disks
> (preferably in the same order) if you want to present file system from
> the guest point of view. Otherwise you will be unable to present LVM,
> MD and Windows LDM partitions. You also should be prepared that
> guestfs might not be able to mount ALL found file systems and guestfs
> might not be found all mappings. Even more: you will not get mappings

if guetsfs unable to detect OS or there are no OS at all on the
> disk(s) you are browsing.


Right, ack.

And side question: are you ready to the
> situation where inspect-os find more then one OS?


> > Maybe it's not that bad if it significantely improves the
> responsiveness...
>
> Anyway you need to prepared to display disk(s)/VM from guest(s) point
> of view as well as simply browsing found file systems.
>

Yeah, so how about adding another level as you suggested before but of
"file systems" and "operating systems"?
That way, if the user enters "file systems" we can display them quickly and
when the user enters "operating systems" he will be presented with all the
detected VMs.
Would that make sense?


>
> > But on the other hand, I do want to enable the user to browse a single
> disk image even if it was attached to the VM along with few others.
> > What would be the risk in inspecting a single disk image in that case?
> shouldn't each disk image be a stand alone entity?
>
> Imagine: I have two disks and I have create physical volumes (PV), and
> volume group (VG) adding both PVs, and I've created logical volume
> (LV), and finally any file system atop (e.g. XFS). Any attempt to
> browse disks separately will not be successful. You must to add them
> both to a guestfs before launching. The similar things happens with
> soft array (MD) spread across multiple disks. I hope you've got an
> idea.
>

Alright, I see.
The thing is that when exploring a specific image, I don't have the context
of the VM that includes its additional disks, right? so I think it's ok not
to support such cases when browsing a specific image.
To support such cases, maybe it worth thinking of another plugin for
"libvirt" - where we query all the VMs and when entering a particular VM,
we attach all its disks and do our best to reflect the tree structure from
the guest's perspective.


>
> And definitely I would not made an attempt to modify disks of live VM.
>

So for a "libvirt" plugin - definitely.
But when exploring a specific disk, do I have a way to prevent this?
I saw a similar warning in the documentation of libguestfs, but I wonder -
if qemu opened the disk with write permissions, wouldn't libguestfs fail to
open it with write permissions at the same time?


>
> --
>     +380979184774
>     Mykola Ivanets
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20181126/48d1fa95/attachment.htm>