Re: [Libguestfs] [PATCH] Add simple parsing logic for hostname file.

On Wed, Jul 20, 2022 at 01:36:25PM -0400, dzr...@gmail.com wrote: > On Wed, 2022-07-20 at 12:45 +0100, Richard W.M. Jones wrote: > > How about this instead? > > > > It actually changes the behaviour slightly.  Currently a > > /etc/hostname > > which contains the single character '\n' would return

Re: [Libguestfs] nbdkit test-checkwrite.sh failing occasionally on ppc64le

On Tue, Jul 19, 2022 at 04:45:53PM +0100, Richard W.M. Jones wrote: > > qemu-img has new(?) behaviour that breaks some things: > > $ nbdkit linuxdisk ~/d/nbdkit --filter=checkwrite --run 'qemu-img convert > "$uri" "$uri"' > nbdkit: linuxdisk.0: error: data written does not match expected >

Re: [Libguestfs] [p2v PATCH] virt-p2v-make-*.in: make @datadir@ and @libdir@ resolvable

On Wed, Jul 20, 2022 at 01:53:22PM +0200, Laszlo Ersek wrote: > ./configure expands @datadir@ and @libdir@ to "${prefix}/share" and > "${exec_prefix}/lib" by default (verbatim); $prefix and $exec_prefix are > supposed to be substituted by the shell when the generated shell scripts > are executed.

Re: [Libguestfs] [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute

On 07/20/22 14:00, Richard W.M. Jones wrote: > On Wed, Jul 20, 2022 at 01:09:13PM +0200, Laszlo Ersek wrote: >> We currently don't generate any @check attribute for the /domain/cpu >> element, which causes the following libvirtd behavior >>

Re: [Libguestfs] [p2v PATCH] virt-p2v-make-*.in: make @datadir@ and @libdir@ resolvable

On Wed, Jul 20, 2022 at 01:53:22PM +0200, Laszlo Ersek wrote: > ./configure expands @datadir@ and @libdir@ to "${prefix}/share" and > "${exec_prefix}/lib" by default (verbatim); $prefix and $exec_prefix are > supposed to be substituted by the shell when the generated shell scripts > are executed.

Re: [Libguestfs] [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute

On Wed, Jul 20, 2022 at 01:09:13PM +0200, Laszlo Ersek wrote: > We currently don't generate any @check attribute for the /domain/cpu > element, which causes the following libvirtd behavior > : > > > Once the domain starts, libvirt will

Re: [Libguestfs] [PATCH] Add simple parsing logic for hostname file.

On 07/20/22 13:45, Richard W.M. Jones wrote: > How about this instead? > > It actually changes the behaviour slightly. Currently a /etc/hostname > which contains the single character '\n' would return > inspect_get_hostname = "" (which seems wrong). This is the default > /etc/hostname for

Re: [Libguestfs] [PATCH] always 'max' for the appliance CPU model on all targes except ppc

On 07/20/22 13:51, Richard W.M. Jones wrote: > On Wed, Jul 20, 2022 at 10:14:00AM +0200, Laszlo Ersek wrote: >> On 05/27/22 10:21, Laszlo Ersek wrote: >>> On 05/25/22 15:30, Daniel P. Berrangé wrote: The current logic for selecting CPU model to use with the appliance selects 'max' for

[Libguestfs] [p2v PATCH] virt-p2v-make-*.in: make @datadir@ and @libdir@ resolvable

./configure expands @datadir@ and @libdir@ to "${prefix}/share" and "${exec_prefix}/lib" by default (verbatim); $prefix and $exec_prefix are supposed to be substituted by the shell when the generated shell scripts are executed. For this, capture the prefix and exec_prefix values at the time

Re: [Libguestfs] [PATCH] always 'max' for the appliance CPU model on all targes except ppc

On Wed, Jul 20, 2022 at 10:14:00AM +0200, Laszlo Ersek wrote: > On 05/27/22 10:21, Laszlo Ersek wrote: > > On 05/25/22 15:30, Daniel P. Berrangé wrote: > >> The current logic for selecting CPU model to use with the appliance > >> selects 'max' for all architectures except for ppc64le and aarch64.

[Libguestfs] [PATCH] Add simple parsing logic for hostname file.

There are some linux systems in the wild where the /etc/hostname file does not contain the configured hostname as sole line in that file. This file actually allows for comments [1] starting with "#" and the original logic would extract the comment line instead of the hostname on such systems. This

Re: [Libguestfs] [PATCH] Add simple parsing logic for hostname file.

How about this instead? It actually changes the behaviour slightly. Currently a /etc/hostname which contains the single character '\n' would return inspect_get_hostname = "" (which seems wrong). This is the default /etc/hostname for virt-builder images. I think this is because in the current

[Libguestfs] [v2v PATCH] output/create_libvirt_xml: generate @check='none' CPU attribute

We currently don't generate any @check attribute for the /domain/cpu element, which causes the following libvirtd behavior : > Once the domain starts, libvirt will automatically change the check > attribute to the best supported value

Re: [Libguestfs] [PATCH] always 'max' for the appliance CPU model on all targes except ppc

On 05/27/22 10:21, Laszlo Ersek wrote: > On 05/25/22 15:30, Daniel P. Berrangé wrote: >> The current logic for selecting CPU model to use with the appliance >> selects 'max' for all architectures except for ppc64le and aarch64. >> >> On aarch64, it selects 'host' if KVM is available which is