similar to: Fwd: needinfo requested: [Bug 1828289] virt-v2v: error: libguestfs error: mountpoints: stat: /dev/centos/home: No such file or directory

On Mon, Nov 06, 2017 at 03:45:14PM +0100, Pino Toscano wrote: > - move the space needed by mountpoint mapping to an own function, > outside of the checking loop > - remove the minimum limit of 100M on partitions, since existing > partitions that we check (e.g. /boot) may be smaller than that > - in case /boot is not on a separate mountpoint, enforce the space check > on the

- move the space needed by mountpoint mapping to an own function, outside of the checking loop - remove the minimum limit of 100M on partitions, since existing partitions that we check (e.g. /boot) may be smaller than that - in case /boot is not on a separate mountpoint, enforce the space check on the root mountpoint instead, since it is where /boot is in that case --- v2v/v2v.ml | 55

We've split off virt-v2v components into a separate repository: http://gitorious.org/virt-v2v/ (Previously they were part of the libguestfs repository). So virt-v2v stuff will disappear from the libguestfs repository shortly. You can get it from the link above instead. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones libguestfs lets you edit virtual

libguestfs is a set of tools for reading and modifying disk images and virtual machines. virt-v2v and virt-p2v are tools for converting guests from foreign hypervisors (especially VMware, Xen), or physical machines, to run on KVM (eg. virt-manager, OpenStack/RHOS or oVirt/RHEV). This is just a heads-up about some changes to the way libguestfs and related packages will be packaged in RHEL 7.2.

Should we do this yet? It would of course only be for upstream. It also requires an associated patch to common which I will post separately. Rich.

On Tuesday, 10 March 2020 14:07:41 CET Richard W.M. Jones wrote: > Should we do this yet? It would of course only be for upstream. Not sure why it should be "upstream only". In any case, the big issue in this case is that you cannot build virt-v2v with libguestfs from git. So until that is done, bumping the version requirements means that almost noone (unless they install

This patch removes virt-v2v from libguestfs.git repo, because it has moved to a new repository here: https://github.com/libguestfs/virt-v2v I didn't post this with git send-email because it's filtered with filterdiff to remove the huge - but mechanical - changes to v2v/ and a couple of other directories, leaving only the interesting parts for reviewing. After applying the patch you

If you are running RHEL 7.2 betas or snapshots (or RHEL 7.2 when it comes out next month) then you may be interested in trying out the newer RHEL 7.3 preview versions of: - libguestfs - virt-v2v (Supported since RHEL 7.2) - virt-p2v (Technical Preview in RHEL 7.2, Supported in RHEL 7.3) I intend to release upstream 1.32 towards the end of this year, and rebase libguestfs to that version. For

----- Forwarded message from Transifex <admin at transifex.com> ----- Date: Tue, 05 Mar 2013 08:36:55 -0000 Subject: Failure of automatic update of source file: virt-v2v: virt-v2v.pot Hello rjones, this is Transifex at https://www.transifex.com. We have not been able to update the source file of the resource 'virt-v2v.pot' of the project 'virt-v2v' from the URL

On Tue, Jun 12, 2018 at 04:51:57AM -0700, zhujinhe wrote: > If dd does not support status=progress, copy process will abort at the end. This is totally misguided. > We can use -q as a workaround in this circumstance, but it is frightening to newbee like me. Maybe we should improve this. > > suspicion： > ``` > if shell_command cmd <> 0 then > error

On Tue, Jun 12, 2018 at 04:51:57AM -0700, zhujinhe wrote: > If dd does not support status=progress, copy process will abort at the end. This is totally misguided. > We can use -q as a workaround in this circumstance, but it is frightening to newbee like me. Maybe we should improve this. > > suspicion： > ``` > if shell_command cmd <> 0 then > error

On Tue, Jun 16, 2020 at 04:34:15PM +0200, Tomáš Golembiovský wrote: > On Wed, 10 Jun 2020 11:31:33 +0100 > "Richard W.M. Jones" <rjones@redhat.com> wrote: > > > I finally got access to the container. This is how it's configured: > > > > * / => an overlay fs. > > > > There is sufficient space here, and there are no "funny"

This message got caught in moderation because the attachment was large. I put the attachment here: http://oirase.annexia.org/tmp/2023-lgarrett-virt-v2v-debug-output.txt ----- Forwarded message from Lee Garrett <lgarrett at rocketjump.eu> ----- Date: Sun, 10 Sep 2023 00:09:17 +0200 From: Lee Garrett <lgarrett at rocketjump.eu> To: libguestfs at redhat.com Subject: virt-v2v creating

On Wednesday, 10 June 2020 12:31:33 CEST Richard W.M. Jones wrote: > I finally got access to the container. This is how it's configured: > > * / => an overlay fs. > > There is sufficient space here, and there are no "funny" restrictions, > to be able to create the libguestfs appliance. I proved this by > setting TMPDIR to a temporary directory under / and

I finally got access to the container. This is how it's configured: * / => an overlay fs. There is sufficient space here, and there are no "funny" restrictions, to be able to create the libguestfs appliance. I proved this by setting TMPDIR to a temporary directory under / and running libguestfs-test-tool. There appears to be quite a lot of free space here, so in fact the

On Wed, 10 Jun 2020 11:31:33 +0100 "Richard W.M. Jones" <rjones@redhat.com> wrote: > I finally got access to the container. This is how it's configured: > > * / => an overlay fs. > > There is sufficient space here, and there are no "funny" restrictions, > to be able to create the libguestfs appliance. I proved this by > setting TMPDIR to a

On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > Previously we placed large files in g#get_cachedir () (usually > /var/tmp). However the problem is this ties the libguestfs appliance > and the virt-v2v overlay files to the same location. > > When virt-v2v is run in a container, or any other situation where > local storage is limited, it's helpful to be

On Mon, Apr 06, 2020 at 10:19:10AM +0100, Richard W.M. Jones wrote: > v1 was here: > https://www.redhat.com/archives/libguestfs/2020-April/msg00007.html > > There's a BZ for this now which I forgot to add to the commit message: > https://bugzilla.redhat.com/show_bug.cgi?id=1814611 and https://bugzilla.redhat.com/show_bug.cgi?id=1820282 > For v2: > > - Fix incorrect

On Tue, Apr 07, 2020 at 01:18:47PM +0100, Richard W.M. Jones wrote: > Another issue, incidental to this but related, is that we cannot use > the fixed appliance because docker/podman have broken support for > sparse files. (It's possible to configure libguestfs to use qcow2 for > fixed appliances, but we don't do this now, we never really tested it, > and it both greatly

On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > Previously we placed large files in g#get_cachedir () (usually > > > /var/tmp). However the problem is this ties the libguestfs appliance > > > and the