<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 9:36 PM Nikolay Ivanets <<a href="mailto:stenavin@gmail.com" target="_blank">stenavin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> 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?<br>
<br>
Yes, that is right. You have to call inspect-os if you want to present<br>
disk (or I would rather say VM) content in the way the user expect it<br>
to be.<br>
<br>
>> 1. User: selects disk image, double-click. You: launch libguestfs<br>
>> instance, call list-filesystems and display them.<br>
><br>
> 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?<br>
<br>
Right. But I want to stress you again: you MUST to add ALL VM disks<br>
(preferably in the same order) if you want to present file system from<br>
the guest point of view. Otherwise you will be unable to present LVM,<br>
MD and Windows LDM partitions. You also should be prepared that<br>
guestfs might not be able to mount ALL found file systems and guestfs<br>
might not be found all mappings. Even more: you will not get mappings</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
if guetsfs unable to detect OS or there are no OS at all on the<br>
disk(s) you are browsing. </blockquote><div><br></div><div>Right, ack. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">And side question: are you ready to the<br>
situation where inspect-os find more then one OS? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> Maybe it's not that bad if it significantely improves the responsiveness...<br>
<br>
Anyway you need to prepared to display disk(s)/VM from guest(s) point<br>
of view as well as simply browsing found file systems.<br></blockquote><div><br></div><div>Yeah, so how about adding another level as you suggested before but of "file systems" and "operating systems"?</div><div>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.</div><div>Would that make sense?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
> 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.<br>
> What would be the risk in inspecting a single disk image in that case? shouldn't each disk image be a stand alone entity?<br>
<br>
Imagine: I have two disks and I have create physical volumes (PV), and<br>
volume group (VG) adding both PVs, and I've created logical volume<br>
(LV), and finally any file system atop (e.g. XFS). Any attempt to<br>
browse disks separately will not be successful. You must to add them<br>
both to a guestfs before launching. The similar things happens with<br>
soft array (MD) spread across multiple disks. I hope you've got an<br>
idea.<br></blockquote><div><br></div><div>Alright, I see.</div><div>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.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
And definitely I would not made an attempt to modify disks of live VM.<br></blockquote><div><br></div><div>So for a "libvirt" plugin - definitely.</div><div>But when exploring a specific disk, do I have a way to prevent this?</div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
--<br>
    +380979184774<br>
    Mykola Ivanets<br>
</blockquote></div></div></div>