10:59 a.m.
On Sat, Nov 24, 2018 at 9:36 PM Nikolay Ivanets <stenavin(a)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