search for: ldm_part_

...e an error. */ - if (stat ("/dev/mapper", &buf) == -1) { - if (errno == ENOENT) - return empty_list (); - reply_with_perror ("/dev/mapper"); - return NULL; - } - - return get_devices ("/dev/mapper/ldm_vol_*"); -} - -/* Same as above but /dev/mapper/ldm_part_*. See comment above. */ -char ** -do_list_ldm_partitions (void) -{ - struct stat buf; - - /* If /dev/mapper doesn't exist at all, don't give an error. */ - if (stat ("/dev/mapper", &buf) == -1) { - if (errno == ENOENT) - return empty_list (); - reply_with_perror...

...letely. 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 about GPT? Again...

...ion. 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 demonstrate one o...

The main goal of these patch series is to implement a new API that allows to retrieve created device-mapper devices for volumes and partitions back after they have been created. As part of this patch: - required libdevmapper version was bumped to 1.02. I think it is safe because it was released more then 10 years ago; - newer version of libdevmapper allowed to simplify code base a little bit; -

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.

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

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 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

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.

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