search for: lvm_scan

...commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this > stopped working because lvmetad now ignores plain vgscan commands > without the --cache option. > > We documented that vgscan would rescan PVs, VGs and LVs, but without > activating them. > > I have introduced a new API (lvm_scan) which scans or rescans PVs, VGs > and LVs. It has an optional activate parameter allowing activation of > any new LVs that are found. > > With lvmetad this nicely maps to the single command: > > pvscan --cache [--activate ay] > --- lvm_scan seems basically vgscan + activa...

...n we switched to using lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this stopped working because lvmetad now ignores plain vgscan commands without the --cache option. We documented that vgscan would rescan PVs, VGs and LVs, but without activating them. I have introduced a new API (lvm_scan) which scans or rescans PVs, VGs and LVs. It has an optional activate parameter allowing activation of any new LVs that are found. With lvmetad this nicely maps to the single command: pvscan --cache [--activate ay] --- common/options/decrypt.c | 4 +-- daemon/lvm.c...

[This email is either empty or too large to be displayed at this time]

v2: - Changes as suggested by Pino in previous review.

...ine...so looks like the pv,vg,lv is detected properly while in initrd, but somehow dracut has difficulties enabling the root,swap LVs ? - While in o/s, I rebuild initrd by using: 'dracut -f -v -a lvm' Note, I have to use '-a lvm' as for some reason, if don't, the lvm utils (lvm,lvm_scan) are not being included to the initrd, not sure why this happens. After rebooting, same thing happens, I have to manually boot the system via dracut shell. I'm a bit stuck at this point, any clues what I'm doing wrong in here ? As I previously said, this is a new installation, so I could...

...e C<device>." }; + ] diff --git a/generator/proc_nr.ml b/generator/proc_nr.ml index efa8c5d21..11a557076 100644 --- a/generator/proc_nr.ml +++ b/generator/proc_nr.ml @@ -514,6 +514,7 @@ let proc_nr = [ 504, "part_get_gpt_attributes"; 505, "f2fs_expand"; 506, "lvm_scan"; +507, "luks_uuid"; ] (* End of list. If adding a new entry, add it at the end of the list diff --git a/lib/MAX_PROC_NR b/lib/MAX_PROC_NR index 80e3e6eab..055b6671a 100644 --- a/lib/MAX_PROC_NR +++ b/lib/MAX_PROC_NR @@ -1 +1 @@ -506 +507 -- 2.21.0

...h could be triggered from the guest or network side. API New APIs "f2fs_expand" Expand an f2fs filesystem (Pino Toscano). "inspect_get_osinfo" Get the libosinfo short ID for the inspected guest (Pino Toscano). "lvm_scan" This rescans all PVs, VGs and LVs, optionally activating them. Other API changes "part_get_mbr_part_type" was reimplemented in OCaml (Nikolay Ivanets). "list_filesystems" now filters out MBR extended partitions (Nikolay Ivanets)....

...ected > properly > while in initrd, but somehow dracut has difficulties enabling the > root,swap > LVs ? > > - While in o/s, I rebuild initrd by using: 'dracut -f -v -a lvm' > Note, I have to use '-a lvm' as for some reason, if don't, the lvm utils > (lvm,lvm_scan) are not being included to the initrd, not sure why this > happens. > After rebooting, same thing happens, I have to manually boot the system > via > dracut shell. > > I'm a bit stuck at this point, any clues what I'm doing wrong in here ? > > As I previously said, t...

...ine...so looks like the pv,vg,lv is detected properly while in initrd, but somehow dracut has difficulties enabling the root,swap LVs ? - While in o/s, I rebuild initrd by using: 'dracut -f -v -a lvm' Note, I have to use '-a lvm' as for some reason, if don't, the lvm utils (lvm,lvm_scan) are not being included to the initrd, not sure why this happens. After rebooting, same thing happens, I have to manually boot the system via dracut shell. I'm a bit stuck at this point, any clues what I'm doing wrong in here ? As I previously said, this is a new installation, so I could...

This combined patch series enables to decrypt LUKS devices on inspection by allowing the UUID of the LUKS device with the --key syntax. I opted for reusing the option instead of adding another one, as I think that device names and UUIDs are different enough that can be properly distinguished. A test for this (patch #4) can be applied only when the patches for common are applied, and the

...the C<key> parameter. - -This creates a new block device called F</dev/mapper/mapname>. -Reads and writes to this block device are decrypted from and -encrypted to the underlying C<device> respectively. - -If this block device contains LVM volume groups, then -calling C<guestfs_lvm_scan> with the C<activate> -parameter C<true> will make them visible. - -Use C<guestfs_list_dm_devices> to list all device mapper -devices." }; - - { defaults with - name = "luks_open_ro"; added = (1, 5, 1); - style = RErr, [String (Device, "device");...

...the C<key> parameter. - -This creates a new block device called F</dev/mapper/mapname>. -Reads and writes to this block device are decrypted from and -encrypted to the underlying C<device> respectively. - -If this block device contains LVM volume groups, then -calling C<guestfs_lvm_scan> with the C<activate> -parameter C<true> will make them visible. - -Use C<guestfs_list_dm_devices> to list all device mapper -devices." }; - - { defaults with - name = "luks_open_ro"; added = (1, 5, 1); - style = RErr, [String (Device, "device");...

As part of the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1626503 I'm proposing to add two new APIs to fetch information about the list of network interfaces of an existing guest. These two patches outline the proposed API but with no implementation or tests. However they can be applied and compiled. Please see the second patch for the proposed API. I have a mostly working

The proposed API is the same as v1, but this includes an implementation (for /etc/sysconfig/network-scripts/ifcfg-*) and modifications to virt-inspector. This compiles and works. If you look in patch 5 you can see proposed output as virt-inspector XML for a guest (although this guest has not been booted, so a real guest would hopefully have a hwaddr="MAC" attribute too). Rich.

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.