Displaying 20 results from an estimated 5000 matches similar to: "[v2v PATCH v2 0/3] improve UX when running as root and we can't chown"
2023 Jun 29
1
[v2v PATCH v2 2/3] lib/utils: make "chown_for_libvirt_rhbz_1045069" fail hard
Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we
suppress the exception (we log it in verbose mode only, even).
That's not proved helpful: it almost certainly leads to later errors, but
those errors are less clear than the original (suppressed) exception.
Namely, the user sees something like
> Failed to connect to '/tmp/v2v.sKlulY/in0':
2023 Jun 29
1
[v2v PATCH v2 2/3] lib/utils: make "chown_for_libvirt_rhbz_1045069" fail hard
On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote:
> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we
> suppress the exception (we log it in verbose mode only, even).
>
> That's not proved helpful: it almost certainly leads to later errors, but
> those errors are less clear than the original (suppressed) exception.
> Namely, the
2023 Jun 29
1
[v2v PATCH v2 2/3] lib/utils: make "chown_for_libvirt_rhbz_1045069" fail hard
On 6/29/23 14:54, Richard W.M. Jones wrote:
> On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote:
>> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we
>> suppress the exception (we log it in verbose mode only, even).
>>
>> That's not proved helpful: it almost certainly leads to later errors, but
>> those errors are
2023 Jun 29
1
[v2v PATCH v2 2/3] lib/utils: make "chown_for_libvirt_rhbz_1045069" fail hard
On Thu, Jun 29, 2023 at 05:39:34PM +0200, Laszlo Ersek wrote:
> On 6/29/23 14:54, Richard W.M. Jones wrote:
> > On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote:
> >> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we
> >> suppress the exception (we log it in verbose mode only, even).
> >>
> >> That's
2023 Jun 29
1
[v2v PATCH v2 2/3] lib/utils: make "chown_for_libvirt_rhbz_1045069" fail hard
On 6/29/23 17:48, Richard W.M. Jones wrote:
> On Thu, Jun 29, 2023 at 05:39:34PM +0200, Laszlo Ersek wrote:
>> On 6/29/23 14:54, Richard W.M. Jones wrote:
>>> On Thu, Jun 29, 2023 at 02:34:42PM +0200, Laszlo Ersek wrote:
>>>> Currently "chown_for_libvirt_rhbz_1045069" is best effort; if it fails, we
>>>> suppress the exception (we log it in
2023 Jun 29
1
[v2v PATCH v2 1/3] lib/utils: fix typo
Fix a small comment typo from commit 4e7f20684373 ("lib: Improve security
of in/out sockets when running virt-v2v as root", 2022-03-23).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
Notes:
v2:
- new patch
lib/utils.mli | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
2023 Jun 29
1
[v2v PATCH v2 3/3] docs/virt-v2v: document libvirt system instance startup
It has frequently tripped us up that on RHEL / Fedora, installing the
right set of libvirt RPMs (such as the one pulled in by
"libvirt-daemon-kvm") does not result in an immediately running libvirt
system instance. Document the need, and the simplest method, for starting
libvirt up manually.
Thanks: Daniel Berrang?
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024
2023 Jun 28
1
[v2v PATCH] docs/virt-v2v: document libvirt system instance startup
On 6/28/23 12:05, Richard W.M. Jones wrote:
> On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote:
>> It has frequently tripped us up that on RHEL / Fedora, installing the
>> right set of libvirt RPMs (such as the one pulled in by
>> "libvirt-daemon-kvm") does not result in an immediately running libvirt
>> system instance. Document the need, and the
2023 Jun 28
1
[v2v PATCH] docs/virt-v2v: document libvirt system instance startup
On Wed, Jun 28, 2023 at 01:31:53PM +0200, Laszlo Ersek wrote:
> On 6/28/23 12:05, Richard W.M. Jones wrote:
> > On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote:
> >> It has frequently tripped us up that on RHEL / Fedora, installing the
> >> right set of libvirt RPMs (such as the one pulled in by
> >> "libvirt-daemon-kvm") does not result
2023 Jun 28
1
[v2v PATCH] docs/virt-v2v: document libvirt system instance startup
On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote:
> It has frequently tripped us up that on RHEL / Fedora, installing the
> right set of libvirt RPMs (such as the one pulled in by
> "libvirt-daemon-kvm") does not result in an immediately running libvirt
> system instance. Document the need, and the simplest method, for starting
> libvirt up manually.
>
2018 Jun 05
4
[PATCH 0/3] v2v: Various refactorings.
Use -ip instead of --password-file, and various refactorings.
It strikes me that we should probably deprecate and eventually remove
virt-v2v-copy-to-local. With the introduction of the new SSH and VDDK
transports, and with RHEL 5 Xen becoming more irrelevant, it's no
longer needed.
Rich.
2017 Dec 08
4
[PATCH v2 0/2] v2v: Add -it vddk and -it ssh flags.
The first patch was previously posted here:
https://www.redhat.com/archives/libguestfs/2017-December/msg00018.html
That patch hasn't changed except that I made the ‘input_transport’
variable type-safe.
The second patch adds a significant new mode for liberating data from
VMware: the ability to copy VMs over SSH directly from ESXi
hypervisors. Although this requires enabling SSH access (a
2016 Dec 07
2
[PATCH v2] v2v: Rename RHEV to RHV throughout.
v2:
- Fix virt-p2v messages too.
Rich.
2014 Aug 21
2
[PATCH] v2v: adding input -i ova
Shahar:
This is the same patch as you posted, but I have rebased it on top of
current HEAD.
You'll have to do save the next email to a file, and do:
git reset --hard HEAD^
git pull
git am /path/to/saved_email
There are no changes in this patch, except what is needed to make it
compile. Will follow-up with comments.
Rich.
2015 Nov 19
4
[PATCH 0/4] v2v: Add a new tool virt-v2v-copy-to-local to handle Xen and ESXi
It turns out that RHEL 5 Xen conversions don't work if the source disk
is located on a block device. See patch 1/4 for the gory details.
This patch series proposes a new tool called virt-v2v-copy-to-local
which essentially is a way to make new virt-v2v work like the old
virt-v2v, ie. copy first, convert after. Of course this is very slow
and would only be used as a last resort, but I
2014 Aug 21
3
Re: [PATCH] v2v: adding input -i ova
On Thu, Aug 21, 2014 at 01:50:18PM +0100, Richard W.M. Jones wrote:
> + (* extract ova (tar) file *)
> + let cmd = sprintf ("tar -xf %s -C %s") (ova) (dir) in
Lots of extra parentheses here :-) The same command can be written
more naturally without any of them:
let cmd = sprintf "tar -xf %s -C %s" ova dir in
However I think what you might have meant is to call
2019 Dec 17
6
[v2v PATCH 0/3] Various dist/build fixes
Fix one dist issue, and almost all the builddir!=srcdir issues.
(For the record, only 3 tests still fail in that setup.)
Pino Toscano (3):
libvirt-ocaml: add libvirt_c.h as source
tests: fix path to sources of fake-virtio-win.iso
tests: fix srcdir references
bundled/libvirt-ocaml/Makefile.am | 1 +
test-data/fake-virtio-win/Makefile.am | 2 +-
tests/rhbz1232192.sh
2020 May 25
1
[v2v PATCH] -i libvirt: print URI without connecting
Pass (again) around the libvirt URI string in the various input_libvirt
subclasses so that input_libvirt#as_options does not need to connect to
print the connection URI.
As related change: pass input_conn as non-optional string parameter in
classes that require one (all but input_libvirt_other, basically). This
avoids the need for extra checks.
---
v2v/input_libvirt.ml | 10
2023 Mar 07
6
[V2V PATCH v2 0/5] Bring support for virtio-scsi back to Windows
Discussion on v1:
https://listman.redhat.com/archives/libguestfs/2023-February/030849.html
https://listman.redhat.com/archives/libguestfs/2023-March/030917.html
v1 -> v2:
* Adapt the patch suggested by Richard, splitting it up into 3:
https://listman.redhat.com/archives/libguestfs/2023-March/030975.html
Now we have "--block-driver" command line option which regulates the
2019 Jul 11
11
[PATCH v2 00/11] v2v: Change virt-v2v to use nbdkit for input in several modes.
Originally posted here:
https://www.redhat.com/archives/libguestfs/2019-April/thread.html#00054
https://www.redhat.com/archives/libguestfs/2019-April/msg00076.html
https://www.redhat.com/archives/libguestfs/2019-April/msg00126.html
This is a rebase on top of current master branch with no other
changes. The first patch in the old series was pushed a while back,
and the last "TEMPORARY"