May 2024 - Libguestfs - libguestfs List Archives

Re: [External] Re: [PATCH] VxFS Filesystem support to libguestfs
by Richard W.M. Jones 01 Jul '24

01 Jul '24

I think the last version was posted in November. I don't think it made it to the mailing list, but I've attached a copy of the patch. A concrete way to proceed here is to: (1) Fork the project on github and add your patch to your fork. (2) Make sure it is up to date with the current branch. (3) Make sure it compiles and all the tests pass. (4) Post a link to the github repo here and we can look at it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

2 1

[nbdkit PATCH] tests: Fix CI on Fedora 40
by Eric Blake 03 Jun '24

03 Jun '24

Fedora 40 recently changed to move malloc debugging out of glibc into glibc-utils (https://issues.redhat.com/browse/RHEL-35971) Reflect that in our CI, to avoid spurious test failures from tons of messages like: ERROR: ld.so: object 'libc_malloc_debug.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. by regenerating with https://gitlab.com/libvirt/libvirt-ci/-/merge_requests/491 Also, change configure.ac to gracefully skip malloc debugging when glibc-utils is not installed. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- I plan on pushing this once my libvirt-ci merge request is accepted (this may need tweaking based on reviews on that side of things) configure.ac | 9 +++++++-- README.md | 1 + ci/buildenv/fedora-39.sh | 1 + ci/buildenv/fedora-40-cross-mingw32.sh | 1 + ci/buildenv/fedora-40-cross-mingw64.sh | 1 + ci/buildenv/fedora-40.sh | 1 + ci/buildenv/fedora-rawhide.sh | 1 + ci/containers/fedora-39.Dockerfile | 1 + ci/containers/fedora-40-cross-mingw32.Dockerfile | 1 + ci/containers/fedora-40-cross-mingw64.Dockerfile | 1 + ci/containers/fedora-40.Dockerfile | 1 + ci/containers/fedora-rawhide.Dockerfile | 1 + ci/lcitool/projects/nbdkit.yml | 1 + 13 files changed, 19 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index aaff4aae..89187b45 100644 --- a/configure.ac +++ b/configure.ac @@ -622,14 +622,19 @@ AS_IF([test "x$is_windows" = "xyes"],[ dnl See if getaddrinfo requires an external library. AC_SEARCH_LIBS([getaddrinfo], [network socket]) -dnl Does this platform require libc_malloc_debug.so.0 (glibc >= 2.34)? +dnl Does this platform support libc_malloc_debug.so.0 (glibc >= 2.34)? AC_MSG_CHECKING([if this is glibc >= 2.34]) AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ #include <limits.h> #if !defined(__GLIBC__) || __GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 34) #error "not glibc 2.34" #endif - ]])], [is_glibc_234=yes], [is_glibc_234=no] + ]])], + [if (LD_PRELOAD=libc_malloc_debug.so.0 /bin/true) 2>&1 | grep -v .; then + is_glibc_234=yes + else + is_glibc_234='missing suitable libc_malloc_debug.so.0' + fi], [is_glibc_234=no] ) AC_MSG_RESULT([$is_glibc_234]) AM_CONDITIONAL([HAVE_GLIBC_234], [test "x$is_glibc_234" = "xyes"]) diff --git a/README.md b/README.md index 2f9452c8..02ed7644 100644 --- a/README.md +++ b/README.md @@ -184,6 +184,7 @@ For non-essential enhancements to the test suite: * hexdump * ip, ss (from iproute package) * jq +* libc_malloc_debug.so.0 (from glibc-utils) * losetup (from util-linux) * mke2fs (from e2fsprogs) * nbdcopy, nbdinfo, nbdsh (from libnbd) diff --git a/ci/buildenv/fedora-39.sh b/ci/buildenv/fedora-39.sh index 98ee274f..638badbd 100644 --- a/ci/buildenv/fedora-39.sh +++ b/ci/buildenv/fedora-39.sh @@ -25,6 +25,7 @@ function install_buildenv() { gcc-c++ \ genisoimage \ git \ + glibc \ glibc-langpack-en \ gnutls-devel \ golang \ diff --git a/ci/buildenv/fedora-40-cross-mingw32.sh b/ci/buildenv/fedora-40-cross-mingw32.sh index 8de2a5dd..b1638bfa 100644 --- a/ci/buildenv/fedora-40-cross-mingw32.sh +++ b/ci/buildenv/fedora-40-cross-mingw32.sh @@ -22,6 +22,7 @@ function install_buildenv() { genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ golang \ gzip \ iproute \ diff --git a/ci/buildenv/fedora-40-cross-mingw64.sh b/ci/buildenv/fedora-40-cross-mingw64.sh index e7013c38..2965e0e7 100644 --- a/ci/buildenv/fedora-40-cross-mingw64.sh +++ b/ci/buildenv/fedora-40-cross-mingw64.sh @@ -22,6 +22,7 @@ function install_buildenv() { genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ golang \ gzip \ iproute \ diff --git a/ci/buildenv/fedora-40.sh b/ci/buildenv/fedora-40.sh index 98ee274f..5f90faa4 100644 --- a/ci/buildenv/fedora-40.sh +++ b/ci/buildenv/fedora-40.sh @@ -26,6 +26,7 @@ function install_buildenv() { genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ gnutls-devel \ golang \ gzip \ diff --git a/ci/buildenv/fedora-rawhide.sh b/ci/buildenv/fedora-rawhide.sh index 88a8dfdc..e11fe698 100644 --- a/ci/buildenv/fedora-rawhide.sh +++ b/ci/buildenv/fedora-rawhide.sh @@ -27,6 +27,7 @@ function install_buildenv() { genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ gnutls-devel \ golang \ gzip \ diff --git a/ci/containers/fedora-39.Dockerfile b/ci/containers/fedora-39.Dockerfile index bf9f8ff4..0908b026 100644 --- a/ci/containers/fedora-39.Dockerfile +++ b/ci/containers/fedora-39.Dockerfile @@ -36,6 +36,7 @@ exec "$@"\n' > /usr/bin/nosync && \ gcc-c++ \ genisoimage \ git \ + glibc \ glibc-langpack-en \ gnutls-devel \ golang \ diff --git a/ci/containers/fedora-40-cross-mingw32.Dockerfile b/ci/containers/fedora-40-cross-mingw32.Dockerfile index 963b836b..e90b7492 100644 --- a/ci/containers/fedora-40-cross-mingw32.Dockerfile +++ b/ci/containers/fedora-40-cross-mingw32.Dockerfile @@ -33,6 +33,7 @@ exec "$@"\n' > /usr/bin/nosync && \ genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ golang \ gzip \ iproute \ diff --git a/ci/containers/fedora-40-cross-mingw64.Dockerfile b/ci/containers/fedora-40-cross-mingw64.Dockerfile index 58554b97..90f8f752 100644 --- a/ci/containers/fedora-40-cross-mingw64.Dockerfile +++ b/ci/containers/fedora-40-cross-mingw64.Dockerfile @@ -33,6 +33,7 @@ exec "$@"\n' > /usr/bin/nosync && \ genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ golang \ gzip \ iproute \ diff --git a/ci/containers/fedora-40.Dockerfile b/ci/containers/fedora-40.Dockerfile index 1b37f724..2aba9a66 100644 --- a/ci/containers/fedora-40.Dockerfile +++ b/ci/containers/fedora-40.Dockerfile @@ -37,6 +37,7 @@ exec "$@"\n' > /usr/bin/nosync && \ genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ gnutls-devel \ golang \ gzip \ diff --git a/ci/containers/fedora-rawhide.Dockerfile b/ci/containers/fedora-rawhide.Dockerfile index 034f621f..e08dc12b 100644 --- a/ci/containers/fedora-rawhide.Dockerfile +++ b/ci/containers/fedora-rawhide.Dockerfile @@ -38,6 +38,7 @@ exec "$@"\n' > /usr/bin/nosync && \ genisoimage \ git \ glibc-langpack-en \ + glibc-utils \ gnutls-devel \ golang \ gzip \ diff --git a/ci/lcitool/projects/nbdkit.yml b/ci/lcitool/projects/nbdkit.yml index 1f2fe259..979ab23a 100644 --- a/ci/lcitool/projects/nbdkit.yml +++ b/ci/lcitool/projects/nbdkit.yml @@ -23,6 +23,7 @@ packages: - hexdump - ip - jq + - libc-malloc-debug - libcurl - libguestfs - liblzma -- 2.45.1

2 1

nbdkit | Failed pipeline for master | 768fc0f1
by GitLab 31 May '24

31 May '24

Pipeline #1313448757 has failed! Project: nbdkit ( https://gitlab.com/nbdkit/nbdkit ) Branch: master ( https://gitlab.com/nbdkit/nbdkit/-/commits/master ) Commit: 768fc0f1 ( https://gitlab.com/nbdkit/nbdkit/-/commit/768fc0f1524ea41f23b7f91f13e12bb0d… ) Commit Message: tests: Require bzip2 on OpenSUSE OpenSUSE has ... Commit Author: Eric Blake ( https://gitlab.com/ebblake ) Pipeline #1313448757 ( https://gitlab.com/nbdkit/nbdkit/-/pipelines/1313448757 ) triggered by Eric Blake ( https://gitlab.com/ebblake ) had 1 failed job. Job #6989728236 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6989728236/raw ) Stage: builds Name: x86_64-fedora-40 -- You're receiving this email because of your account on gitlab.com.

1 0

nbdkit | Failed pipeline for master | a5b3b69e
by GitLab 30 May '24

30 May '24

Pipeline #1312406986 has failed! Project: nbdkit ( https://gitlab.com/nbdkit/nbdkit ) Branch: master ( https://gitlab.com/nbdkit/nbdkit/-/commits/master ) Commit: a5b3b69e ( https://gitlab.com/nbdkit/nbdkit/-/commit/a5b3b69e5a05a14334505038d3739eed3… ) Commit Message: ci: Pull in bzip2 development for CI Update CI... Commit Author: Eric Blake ( https://gitlab.com/ebblake ) Pipeline #1312406986 ( https://gitlab.com/nbdkit/nbdkit/-/pipelines/1312406986 ) triggered by Eric Blake ( https://gitlab.com/ebblake ) had 5 failed jobs. Job #6983603583 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6983603583/raw ) Stage: builds Name: x86_64-opensuse-tumbleweed Job #6983603580 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6983603580/raw ) Stage: builds Name: x86_64-opensuse-leap-15 Job #6983603601 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6983603601/raw ) Stage: builds Name: mingw64-fedora-40 Job #6983603598 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6983603598/raw ) Stage: builds Name: mingw32-fedora-40 Job #6983603568 ( https://gitlab.com/nbdkit/nbdkit/-/jobs/6983603568/raw ) Stage: builds Name: x86_64-fedora-40 -- You're receiving this email because of your account on gitlab.com.

1 0

Re: [External] Re: [PATCH] VxFS Filesystem support to libguestfs
by Richard W.M. Jones 21 May '24

21 May '24

On Tue, May 21, 2024 at 10:16:48AM +0000, Ravi Singh wrote: > Hi Richard, > > Just checking if this change has been merged yet as a patch to libguestfs? Not at the moment, no. I need to look at it again. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

2 1

Fw: [External] Re: [PATCH] VxFS Filesystem support to libguestfs
by Ravi Singh 21 May '24

21 May '24

adding guestfs(a)lists.libguestfs.org<mailto:guestfs@lists.libguestfs.org> ________________________________ From: Mitul Kothari <Mitul.Kothari(a)veritas.com> Sent: Tuesday, May 21, 2024 3:35 PM To: Ravi Singh <Ravi.Singh(a)veritas.com>; Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, Just checking if this change has been merged yet as a patch to libguestfs? Regards, Mitul From: Ravi Singh <Ravi.Singh(a)veritas.com> Date: Thursday, 2 November 2023 at 11:15 PM To: Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>, Aswad Kulkarni <aswad.kulkarni(a)veritas.com>, Shailesh Marathe <Shailesh.Marathe(a)veritas.com>, Sumit Dighe <Sumit.Dighe(a)veritas.com>, Mitul Kothari <Mitul.Kothari(a)veritas.com>, Brad Boyer <brad.boyer(a)veritas.com>, Saket Pusalkar <Saket.Pusalkar(a)veritas.com>, Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>, Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>, John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, I wanted to inform you that we have implemented the changes as per your suggestion to move the logic for starting the Veritas Filesystem related services from the daemon file to appliance/init script. We have thoroughly tested the updated version on our end to ensure its functionality and reliability. Additionally, we have made the necessary modifications to the copyright, following the recommendations provided by our legal team. Please let us know if you require any further assistance. Thank you for your continued collaboration. We look forward to your response. Thanks, Ravi/Gaurang ________________________________ From: Ravi Singh <Ravi.Singh(a)veritas.com> Sent: Thursday, September 21, 2023 9:36 PM To: Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Mitul Kothari <Mitul.Kothari(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, Thank you for making these changes. We appreciate your insights. We will promptly address the issues you have mentioned, thoroughly test them. We will keep you updated and send you the patch once we have completed the testing. Thanks, Ravi/Gaurang ________________________________ From: Richard W.M. Jones <rjones(a)redhat.com> Sent: Tuesday, September 19, 2023 4:30 PM To: Ravi Singh <Ravi.Singh(a)veritas.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Mitul Kothari <Mitul.Kothari(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. A new patch is attached. This is only build tested so far. To build with this patch I had to do: ./configure --enable-werror \ --with-supermin-packager-config=$PWD/localyum.conf where localyum.conf contains: ---------------------------------------------------------------------- [local] name=local baseurl=file:///root/dvd1-redhatlinux/rhel9_x86_64/rpms/ enabled=1 gpgcheck=0 ---------------------------------------------------------------------- (adjust the path to point to the Veritas DVD mount point) I made various changes in this patch: - Add copyright and license notice to list_vxvm.ml & vxfs.c. Please ensure all files have copyright and license notices, and if necessary get them checked by your legal. - Change vm.ml{,i} -> list_vxvm.ml{,i} - In packagelist.in, move package names to their own section. - Remove perl/python packages as perl/python is not present in the appliance. - Fix commit message. - Line length under 80 columns in a few places. - Function names at start of line. - List SOURCES_MLI alphabetically. - daemon/listfs.ml: Remove comment about has_vxvm. - do_vxfs_start -> vxfs_start (since do_* is reserved prefix in daemon). - Skip vxfs_start if !vxdisk available, to save start up time. - Add a prototype for vxfs_start. - Don't use reply_with_error in vxfs_start, as we're not called during protocol context. - Use only one *err. - Add daemon/list_vxvm.mli & daemon/vxvm_type.mli to .gitignore vxfs_start has several issues which need to be addressed: - Why does it return if a service (eg. veki) is not available? That would prevent all further initialization. - I think this would be better done as part of appliance/init, and delete this function completely. Rich. -- Richard Jones, Virtualization Group, Red Hat https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.red…<http://people.redhat.com/~rjones> Read my programming and virtualization blog: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Frwmj.wordp…<http://rwmj.wordpress.com/> libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibguestfs…<http://libguestfs.org/>

1 0

Re: [External] Re: [PATCH] VxFS Filesystem support to libguestfs
by Ravi Singh 21 May '24

21 May '24

+guestfs(a)lists.libguestfs.org<mailto:guestfs@lists.libguestfs.org> ________________________________ From: Mitul Kothari <Mitul.Kothari(a)veritas.com> Sent: Tuesday, May 21, 2024 3:35 PM To: Ravi Singh <Ravi.Singh(a)veritas.com>; Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, Just checking if this change has been merged yet as a patch to libguestfs? Regards, Mitul From: Ravi Singh <Ravi.Singh(a)veritas.com> Date: Thursday, 2 November 2023 at 11:15 PM To: Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>, Aswad Kulkarni <aswad.kulkarni(a)veritas.com>, Shailesh Marathe <Shailesh.Marathe(a)veritas.com>, Sumit Dighe <Sumit.Dighe(a)veritas.com>, Mitul Kothari <Mitul.Kothari(a)veritas.com>, Brad Boyer <brad.boyer(a)veritas.com>, Saket Pusalkar <Saket.Pusalkar(a)veritas.com>, Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>, Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>, John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, I wanted to inform you that we have implemented the changes as per your suggestion to move the logic for starting the Veritas Filesystem related services from the daemon file to appliance/init script. We have thoroughly tested the updated version on our end to ensure its functionality and reliability. Additionally, we have made the necessary modifications to the copyright, following the recommendations provided by our legal team. Please let us know if you require any further assistance. Thank you for your continued collaboration. We look forward to your response. Thanks, Ravi/Gaurang ________________________________ From: Ravi Singh <Ravi.Singh(a)veritas.com> Sent: Thursday, September 21, 2023 9:36 PM To: Richard W.M. Jones <rjones(a)redhat.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Mitul Kothari <Mitul.Kothari(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs Hi Richard, Thank you for making these changes. We appreciate your insights. We will promptly address the issues you have mentioned, thoroughly test them. We will keep you updated and send you the patch once we have completed the testing. Thanks, Ravi/Gaurang ________________________________ From: Richard W.M. Jones <rjones(a)redhat.com> Sent: Tuesday, September 19, 2023 4:30 PM To: Ravi Singh <Ravi.Singh(a)veritas.com> Cc: libguestfs(a)redhat.com <libguestfs(a)redhat.com>; Aswad Kulkarni <aswad.kulkarni(a)veritas.com>; Shailesh Marathe <Shailesh.Marathe(a)veritas.com>; Sumit Dighe <Sumit.Dighe(a)veritas.com>; Mitul Kothari <Mitul.Kothari(a)veritas.com>; Brad Boyer <brad.boyer(a)veritas.com>; Saket Pusalkar <Saket.Pusalkar(a)veritas.com>; Gaurang Agnihotri <Gaurang.Agnihotri(a)veritas.com>; Satyajit Gorhe parlikar <Satyajit.Gorheparlik(a)veritas.com>; John Cronin <john.cronin(a)veritas.com> Subject: Re: [External] Re: [Libguestfs] [PATCH] VxFS Filesystem support to libguestfs CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you believe this is a phishing email, use the Report to Cybersecurity icon in Outlook. A new patch is attached. This is only build tested so far. To build with this patch I had to do: ./configure --enable-werror \ --with-supermin-packager-config=$PWD/localyum.conf where localyum.conf contains: ---------------------------------------------------------------------- [local] name=local baseurl=file:///root/dvd1-redhatlinux/rhel9_x86_64/rpms/ enabled=1 gpgcheck=0 ---------------------------------------------------------------------- (adjust the path to point to the Veritas DVD mount point) I made various changes in this patch: - Add copyright and license notice to list_vxvm.ml & vxfs.c. Please ensure all files have copyright and license notices, and if necessary get them checked by your legal. - Change vm.ml{,i} -> list_vxvm.ml{,i} - In packagelist.in, move package names to their own section. - Remove perl/python packages as perl/python is not present in the appliance. - Fix commit message. - Line length under 80 columns in a few places. - Function names at start of line. - List SOURCES_MLI alphabetically. - daemon/listfs.ml: Remove comment about has_vxvm. - do_vxfs_start -> vxfs_start (since do_* is reserved prefix in daemon). - Skip vxfs_start if !vxdisk available, to save start up time. - Add a prototype for vxfs_start. - Don't use reply_with_error in vxfs_start, as we're not called during protocol context. - Use only one *err. - Add daemon/list_vxvm.mli & daemon/vxvm_type.mli to .gitignore vxfs_start has several issues which need to be addressed: - Why does it return if a service (eg. veki) is not available? That would prevent all further initialization. - I think this would be better done as part of appliance/init, and delete this function completely. Rich. -- Richard Jones, Virtualization Group, Red Hat https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpeople.red…<http://people.redhat.com/~rjones> Read my programming and virtualization blog: https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Frwmj.wordp…<http://rwmj.wordpress.com/> libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Flibguestfs…<http://libguestfs.org/>

1 0

[PATCH nbdkit 0/3] Add tls-* parameters to nbdkit URIs & more
by Richard W.M. Jones 16 May '24

16 May '24

I pushed some preliminary patches for this series already since they were all neutral refactorings. These three patches are the guts of it. They pass tests, I would push them ... but is this secure? I can't imagine a way that it's not secure, but maybe there's something about copying file locations from the nbdkit command line into the --run script which is problematic. Anyway ... The first patch modifies $uri in the --run script to add &tls-certificates=... or &tls-psk-file=... so that TLS connections work (with libnbd anyway, I didn't check qemu). The second patch adds these as variables as well. The third patch updates a test to use this. A final point is that this doesn't work well with PSK. PSK has an implicit username (passed in the URI as nbds://user@...). The same username has to appear in the PSK file. We don't set a username at all right now, so libnbd uses the LOGNAME, which may or may not be what you want. The way to fix this would be to add a --tls-username parameter to nbdkit, but it would only be useful for URIs and might confuse things otherwise (eg. it could be used with --tls-psk but would have no apparent effect, thus confusing users). Rich.

2 7

what size should NBD_OPT_INFO report?
by Eric Blake 16 May '24

16 May '24

I noticed during integration testing that nbd-server blindly reports a size of 0 for all NBD_OPT_INFO requests, unless I pass a size argument on the command line to nbd-server. At first, I thought it was a side effect of me trying to use nbd-server on a block device (an LVM partition), as it is a common bug to rely on stat().st_size which only works for regular files (a block device has to use lseek(SEEK_END)); but then I noticed it happening when using nbd-server to serve regular files as well. I then turned to the source code, where I see that client->exportsize is set in just these places: commit_client() - exportsize = OFFT_MAX, then try setupexport() setupexport() - default to client->server->expected_size (if one was provided), further validating that actual size is large enough when actual size can be computed - if neither treefile or F_WAIT is set, compute actual size by opening one or more files and using size_autodetect() (which does the right thing for block devices, so my earlier thought about over-reliance on stat() was wrong) but these functions are only reached for NBD_OPT_EXPORT_NAME and NBD_OPT_GO, not NBD_OPT_INFO. The upshot is that for NBD_OPT_GO, there are some scenarios (treefile, F_WAIT) where nbd-server advertises a size of 9223372036854775807 (0x7fffffff_ffffffff) meaning unknown, but a size of 0 there is only possible if the file was successfully opened and really is zero bytes in length. Conversely, NBD_OPT_INFO is always advertising a size of 0, which means most of the time, the size changes between NBD_OPT_INFO and NBD_OPT_GO. For comparison, both nbdkit and qemu as an NBD server always advertise the same size for both NBD_OPT_INFO and NBD_OPT_GO (but it should also be noted that neither of these has the complexity of multifile like nbd-server). Should we tweak the NBD standard to recommend that a server advertise a size of OFFT_MAX for NBD_OPT_INFO if it is prohibitive to determine an actual size, rather than 0? Furthermore, is it worth adding code to make NBD_OPT_INFO try harder to provide a sensible value when possible (if expected_size was set, or if we are not multifile or F_WAIT, then a stat() is enough to get the size for serving a regular file; and if stat() says we have a block device, we can still try the open/lseek/close)? Also, is it worth trying to specify that since no known NBD servers allow exports with sizes larger than OFFT_MAX, a server MUST NOT report a size equal or larger than 9223372036854775808 (0x80000000_00000000)? There are definitely a few places that I could simplify in libnbd if we have a protocol guarantee that a valid export size will never have the most significant bit set, and therefore we don't have to worry about whether size is represented as a signed or unsigned value (which also implies that libnbd's function nbd_get_size() returning ssize_t instead of size_t is acceptable). But if we do that, then maybe 0x80000000_00000000 or even 0xffffffff_ffffffff would serve as a better recommended sentinel than 0x7fffffff_ffffffff for representing an indeterminate size. -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org

3 6

[PATCH v1] appliance: only wait for resolv.conf update if dhcpcd succeeded
by Olaf Hering 15 May '24

15 May '24

In case network was requested, but the host lacks both dhclient and dhcpcd, skip the loop which waits for a resolv.conf update. This reduces boot time by 10 seconds. Signed-off-by: Olaf Hering <olaf(a)aepfle.de> --- Not runtime tested. appliance/init | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/appliance/init b/appliance/init index cb200d5bf..128a3c20e 100755 --- a/appliance/init +++ b/appliance/init @@ -119,8 +119,7 @@ if test "$guestfs_network" = 1; then rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved if dhclient --version >/dev/null 2>&1; then dhclient $iface - else - dhcpcd $iface + elif dhcpcd $iface; then # https://github.com/NetworkConfiguration/dhcpcd/issues/258 for i in `seq 0 10`; do if grep nameserver /etc/resolv.conf; then break; fi

2 1