search for: extra_env

If I have something like this in my node file: daemontools_service::setup { ''carbon-cache'': service_name => ''carbon-cache'', .... extra_envs => { "GRAPHITE_STORAGE_DIR" => "/mnt/statsd-data/graphite-storage" "SOMETHING_ELSE" => "12345" "FOO" => "bar" };...

Part 2 fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1842440 Actually this fix on its own should be sufficient, but probably we want the nbdkit fixes too. Note this uses actual OCaml 4.05 features! ("let open" and the Unix.tcgetattr functions). I checked that both features are available on RHEL 7's OCaml. Rich.

...v2v/nbdkit_sources.ml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/v2v/nbdkit_sources.ml b/v2v/nbdkit_sources.ml index 979c37734d..402dfd0e55 100644 --- a/v2v/nbdkit_sources.ml +++ b/v2v/nbdkit_sources.ml @@ -118,11 +118,11 @@ let common_create ?bandwidth ?extra_debug ?extra_env plugin_name plugin_args = let args = match bandwidth with | StaticBandwidth rate -> - [ "rate=", rate ] + [ "rate", rate ] | DynamicBandwidth (None, filename) -> - [ "rate-file="...

...--- v2v/nbdkit_sources.ml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/v2v/nbdkit_sources.ml b/v2v/nbdkit_sources.ml index 979c3773..e97583a5 100644 --- a/v2v/nbdkit_sources.ml +++ b/v2v/nbdkit_sources.ml @@ -97,9 +97,13 @@ let common_create ?bandwidth ?extra_debug ?extra_env plugin_name plugin_args = let cmd = Nbdkit.add_filter_if_available cmd "retry" in (* Adding the readahead filter is always a win for our access - * patterns. However if it doesn't exist don't worry. + * patterns. If it doesn't exist don't worry. However it +...

...- v2v/nbdkit_sources.ml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/v2v/nbdkit_sources.ml b/v2v/nbdkit_sources.ml index f5e919116..7c177e358 100644 --- a/v2v/nbdkit_sources.ml +++ b/v2v/nbdkit_sources.ml @@ -99,12 +99,12 @@ let common_create ?bandwidth ?extra_debug ?extra_env password (* Adding the readahead filter is always a win for our access * patterns. If it doesn't exist don't worry. However it - * breaks VMware servers (RHBZ#1832805). + * breaks VMware servers (RHBZ#1832805, RHBZ#1848862). *) let cmd = - if plugin_name <> &q...

..."PATH TO UNZIPPED DIRECTORY" **(i.e. it assumes you tar balled up a whole project directory so if X.tar.gz is the archive then X is the directory [this name is not the best but I might be remembering things incorrectly]), "config" : { "Release" : { "extra_env" : { "EXTRA_ENV_VAR" : "EXTRA_ENV_VALUE", ... }, "extra_args" : [ ], }, "Debug" : { SAME AS RELEASE } } } }, { NEXT_PROJECT ... } ] } Note that currently it only does make and Xcode-...

I'm still testing this fix, so let's hold off the review for the moment. Also it may be better to specifically identify problematic servers rather than disabling this for every curl source. eg. I suspect that the problem is the Java server used by VCenter, so we might think about only disabling readahead for that single case. Rich.

Trivial fix. We really need a regression test for all v2v inpus related to nbdkit. There is actually nothing at all at the moment. Of course if it was easy to test inputs over the network from a ‘make check’ rule then we'd be doing it already. I thought about adding something like a ‘-it file’ option which would use nbdkit-file-plugin for test only. However I'm rather cautious about

Hi, I was looking at LNT's "compile" tests, listed here: $ lnt-sandbox/bin/lnt showtests Available tests: compile - Single file compile-time performance testing nt - LLVM test-suite compile and execution tests When trying to run it, I get Python exceptions in the code trying to parse the output of 'ifconfig' in order to infer my MAC address (this is on 64-bit

This is the simplest solution to this problem. There are two other possible fixes I considered: Increase the documented limit (see http://libguestfs.org/virt-v2v-input-vmware.1.html#vddk:-esxi-nfc-service-memory-limits). However at the moment we know the current limit works through extensive testing (without readahead), plus I have no idea nor any way to test if larger limits are supported by

Patch 1 was previously posted here: https://www.redhat.com/archives/libguestfs/2020-June/msg00086.html to handle this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1848862 I was able to observe this bug and for me at least disabling readahead seems to cure it. Patches 2 and 3 are simplifications, removing a now-undocumented feature of virt-v2v-copy-to-local and thus simplifying greatly the