search for: ldm_vol_

...(add_string (&ret, devs.gl_pathv[i]) == -1) - goto error; - } - - if (end_stringsbuf (&ret) == -1) goto error; - - globfree (&devs); - return take_stringsbuf (&ret); - - error: - globfree (&devs); - - return NULL; -} - -/* All device mapper devices called /dev/mapper/ldm_vol_*. XXX We - * could tighten this up in future if ldmtool had a way to read these - * names back after they have been created. - */ -char ** -do_list_ldm_volumes (void) -{ - struct stat buf; - - /* If /dev/mapper doesn't exist at all, don't give an error. */ - if (stat ("/dev/mapper&...

...ignored completely. This is a bit of a corner case that we probably shouldn't spend too much time on. Most ordinary Linux guests would also ignore these (they probably indicate nested VMs). > Yet another example is Windows dynamic disks aka LDM: > guestfs_list_filesystems returns both ldm_vol_ and ldm_part_ but > strongly speaking only volumes should be considered as mountables. I think this is a bug too. > And last example is again with Windows dynamic disks and their > physical counterparts: guestfs_list_filesystems filters out disks > with MBR type byte 0x42 but what abo...

...MSDOS partition. Also nothing stops you from creating partition table and partitions on logical volume (yes, it is probably uncommon but nevertheless). In this case such partitions are ignored completely. Yet another example is Windows dynamic disks aka LDM: guestfs_list_filesystems returns both ldm_vol_ and ldm_part_ but strongly speaking only volumes should be considered as mountables. And last example is again with Windows dynamic disks and their physical counterparts: guestfs_list_filesystems filters out disks with MBR type byte 0x42 but what about GPT? Patch #1 will add one more test to dem...

....ml index dc7b36f9c..19cd03e83 100644 --- a/daemon/ldm.ml +++ b/daemon/ldm.ml @@ -20,6 +20,9 @@ open Std_utils open Utils +external available : unit -> bool = + "guestfs_int_daemon_optgroup_lvm2_available" "noalloc" + (* All device mapper devices are called /dev/mapper/ldm_vol_*. XXX We * could tighten this up in future if ldmtool had a way to read these * names back after they have been created. diff --git a/daemon/ldm.mli b/daemon/ldm.mli index 789abb0b3..e6edfabd8 100644 --- a/daemon/ldm.mli +++ b/daemon/ldm.mli @@ -16,5 +16,7 @@ * 51 Franklin Street, Fifth Floo...

Previously posted as part of the mega utilities/inspection series here: https://www.redhat.com/archives/libguestfs/2017-June/msg00232.html What I've done is to extract just the parts related to rewriting daemon APIs in OCaml, rebase them on top of the current master, fix a few things, and recompile and test everything. Rich.

v2 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00008.html This series gets as far as a working (and faster) reimplementation of ‘guestfs_list_filesystems’. I also have another patch series on top of this one which reimplements the inspection APIs inside the daemon, but that needs a bit more work still, since inspection turns out to be a very large piece of code. Rich.

Hi, as a followup for the signature fix for mount_vfs [1], here it is a patch series to generate automatically most of the OCaml interfaces of daemon actions. Only the Lvm and Mount modules are left with hand-written interfaces. [1] https://www.redhat.com/archives/libguestfs/2018-April/msg00059.html Thanks, Pino Toscano (3): daemon: directly use Optgroups daemon: use the structs from the

I think this fixes everything mentioned: - Added the Optgroups module as suggested. - Remove command temporary files. - Replace command ~flags with ?fold_stdout_on_stderr. - Nest _with_mounted function. - Rebase & retest. Rich.

v1 was posted here: https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html This series now depends on two small patches which I posted separately: https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html v1 -> v2: - Previously changes to generator/daemon.ml were made incrementally through the patch

Hi, as a followup for the signature fix for mount_vfs [1], here it is a patch series to generate automatically all the OCaml interfaces of daemon actions. [1] https://www.redhat.com/archives/libguestfs/2018-April/msg00059.html Thanks, Pino Toscano (5): daemon: directly use Optgroups daemon: use the structs from the Structs module daemon: move Lvm.lv_canonical to new Lvm_utils module

Tested with 'make check-release'. tests/parallel (in check-slow) failed, although it does regularly and that seems to be because of libvirt. Rich.

This is a combination of: https://www.redhat.com/archives/libguestfs/2017-June/msg00046.html [PATCH 00/12] Refactor utility functions. plus: https://www.redhat.com/archives/libguestfs/2017-June/msg00023.html [PATCH v3 00/19] Allow APIs to be implemented in OCaml. with the second patches rebased on top of the utility refactoring, and some other adjustments and extensions. This passes

v6 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html and this requires the utilities refactoring posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html Inspection is now complete[*], although not very well tested. I'm intending to compare the output of many guests using old & new virt-inspector to see if I can find any

v5: https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html Since v5, this now implements inspection almost completely for Linux and Windows guests. Rich.

v7 was: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html https://www.redhat.com/archives/libguestfs/2017-June/msg00184.html I believe this addresses all comments received so far. Also it now passes a test where I compared about 100 disk images processed with old and new virt-inspector binaries. The output is identical in all cases except one which is caused by a bug in blkid

In the kernel and qemu communities it is routine for patches that will be backported to stable branches to be posted for review. I'm proposing we do the same for libguestfs stable branches. All of the attached have been tested with 'make check-release'. Rich.