search for: f2fs_expand

Hi, this small patch series exposes one of the utility in f2fs-tools, and use it to expand f2fs partitions in virt-resize. Thanks, Pino Toscano (2): New API: f2fs_expand resize: expand f2fs partitions daemon/Makefile.am | 1 + daemon/f2fs.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++ generator/actions_core.ml | 9 +++++++++ generator/proc_nr.ml | 1 + lib/MAX_PROC_NR | 2 +- resize/resize.ml | 12 ++++++++...

Use resize.f2fs (via f2fs_expand) to expand f2fs filesystems, if available. --- resize/resize.ml | 12 ++++++++++-- resize/virt-resize.pod | 10 ++++++++-- 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/resize/resize.ml b/resize/resize.ml index 1a21e4dff..8e4bb1b16 100644 --- a/resize/resize.ml +++ b/resize...

...urns the UUID of the LUKS device 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

...lumes." }; + ] diff --git a/generator/proc_nr.ml b/generator/proc_nr.ml index ca73aa361..2adf8a32f 100644 --- a/generator/proc_nr.ml +++ b/generator/proc_nr.ml @@ -513,6 +513,7 @@ let proc_nr = [ 503, "part_set_gpt_attributes"; 504, "part_get_gpt_attributes"; 505, "f2fs_expand"; +506, "lvm_scan"; ] (* 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 f573e999a..80e3e6eab 100644 --- a/lib/MAX_PROC_NR +++ b/lib/MAX_PROC_NR @@ -1 +1 @@ -505 +506 -- 2.18.0

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

...le documentation typos fixed (Yuri Chornoivan). Security See also guestfs-security(1). CVE-2018-11806 Qemu's slirp (userspace networking) had several buffer overflows which 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 ch...

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

...ntable|Mountable_or_Path), n) -> pr "guestfs_int_daemon_copy_mountable (%s)" n diff --git a/generator/proc_nr.ml b/generator/proc_nr.ml index d8e7e1282..30e42864f 100644 --- a/generator/proc_nr.ml +++ b/generator/proc_nr.ml @@ -514,6 +514,8 @@ let proc_nr = [ 505, "f2fs_expand"; 506, "lvm_scan"; 507, "luks_uuid"; +508, "cryptsetup_open"; +509, "cryptsetup_close"; ] (* End of list. If adding a new entry, add it at the end of the list diff --git a/gobject/Makefile.inc b/gobject/Makefile.inc index 84ad960ef..650f8ddac 1006...

...ntable|Mountable_or_Path), n) -> pr "guestfs_int_daemon_copy_mountable (%s)" n diff --git a/generator/proc_nr.ml b/generator/proc_nr.ml index d8e7e1282..30e42864f 100644 --- a/generator/proc_nr.ml +++ b/generator/proc_nr.ml @@ -514,6 +514,8 @@ let proc_nr = [ 505, "f2fs_expand"; 506, "lvm_scan"; 507, "luks_uuid"; +508, "cryptsetup_open"; +509, "cryptsetup_close"; ] (* End of list. If adding a new entry, add it at the end of the list diff --git a/gobject/Makefile.inc b/gobject/Makefile.inc index 84ad960ef..650f8ddac 1006...

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

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.