similar to: Re: virt-v2v stuck EDAC sbridge

On Mon, Sep 11, 2017 at 04:27:30PM +0000, Seth Tanner wrote: > Rich, > Here you go > I also noticed that if I use the direct backend rather than libvirt, the conversion gets farther, but still does not complete, when pulling directly from vSphere. please let me know if you would like the output of direct as well. > starting version 233 > + udevadm trigger > + udevadm settle

On Fri, Sep 08, 2017 at 06:33:58PM +0000, Seth Tanner wrote: > [fedora@virt-v2v-fedora ~]$ virt-v2v -ic vpx://AXIA-EFT%5cstanner@192.168.28.9/Axia/galleon.axia-eft.local/?no_verify=1 "Axia-DEV" -o glance -on Axia-DEV Some of the debug info is missing here. Can you run it with ‘-v -x’ added to the virt-v2v the command line. Rich. -- Richard Jones, Virtualization Group, Red Hat

On Wed, Sep 13, 2017 at 02:39:05PM +0000, Seth Tanner wrote: > Rich, > Thank you for your assistance. Switching to bare metal resolved the issues we were having. > > If you want me to continue testing in nested virt, I am happy do so. If not thanks again for the help. Glad it works now. Nested virt testing is useful, but it's not really a virt-v2v or libguestfs concern,

Hi,Tomas:      here is the  test info:   Thanks for your kind help .     ************************************************************      *                    IMPORTANT NOTICE    

On Tue, Feb 14, 2023 at 08:02:59PM +0200, Yonatan Shtarkman wrote: > The attached code snippet?reproduces the issue when running: > python3 libugestfs_segfault_repro.py > > With: > guestfs version: 1.48.6 > guestfs-python version: 1.48.6 Can confirm with {python3-,}libguestfs-1.51.1-1.fc39.x86_64 The stack trace is roughly the same as yours. Rich. > Stacktrace: > #0

Hi all, Sorry for bothering you in this dev mailing list, I'm using libguestfs to customize some vm using as bases the ubuntu cloud images. But I noticed that it takes a lot and then fails when trying to install a packet. Same behaviour on Ubuntu 18.04 and Centos 7.5 Ubuntu: virt-customize 1.36.13 libvirtd (libvirt) 4.0.0 Centos: virt-customize 1.36.10rhel=7,release=6.el7_5.2,libvirt

Hi all, I encountered the following error when I tried to run virt-sysprep on a qcow2 image. virt-sysprep: error: no operating systems were found in the guest image The version I used for libguest is as follows: [libguestfs-1.36.5] The same issue happened on other versions such as libguestfs-1.32.7. # ./run ./sysprep/virt-sysprep -v -x -a

Hi,     I have use  kvm ? virsh ? virt   for almost half year ?all things goes well ?     but recently? I use virt-copy-in  found some problem ? I  have   do  nothing  with my server  ?but the problem appear .         

https://bugs.freedesktop.org/show_bug.cgi?id=92971 --- Comment #8 from Philippe Condé <conde.philippe at skynet.be> --- Hello, I desactivated kscreenlocker which resolve the reactivate problem. But the problem of corrupt screen when starting different programs remains and is worst since the last zypper dup. I found this error still related to nouveau when the two screen got corrupted ov

> On 7 Nov 2016, at 22:16, Derek Atkins <derek@ihtfp.com> wrote: > > Hi, > > My last VM imported in 2 minutes. This one has been sitting for three > hours. I think this is a bug. well, some time it does take a long time. Are you sure it was hung? No I/O going on? adding libguestfs list Thanks, michal > > Just in case it helps, here's a larger piece of

Improve readability of commandrvf() by replacing bare int values for file descriptors with their symbolic names STD{IN,OUT,ERR}_FILENO. Also add PIPE_READ and PIPE_WRITE for referencing relevant ends of a pipe. --- daemon/guestfsd.c | 79 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 42 insertions(+), 37 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c

When the COMMAND_FLAG_FOLD_STDOUT_ON_STDERR flag is passed to command*(), indicate that as stdout=e in debugging message. --- daemon/command.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/daemon/command.c b/daemon/command.c index 73fce56..2423a4e 100644 --- a/daemon/command.c +++ b/daemon/command.c @@ -185,6 +185,7 @@ commandrvf (char **stdoutput, char **stderror,

Hello, I upgraded to CentOS 5.1 and everything went smoothly (Thanks for the awesome work!). But after rebooting, I get the following error: EDAC MC: Ver: 2.0.1 Nov 30 2007 EDAC e7xxx: error reporting device not found:vendor 8086 device 0x2541 (broken BIOS?) I found http://edacbugs.buttersideup.com/show_bug.cgi?id=21 with google but no solution. Is it safe to ignore the error or remove

What does the following EDAC problem means? The machine is a AMD 64bit box running Centos 5. It looks like some problems aroung AMD DRAM Memory controller. But what does it really mean b/c most of my AMD boxes has these messages in /var/log/messages. Please help. ... Aug 1 23:29:40 ccn128 kernel: EDAC MC: Ver: 2.0.1 Jun 12 2007 Aug 1 23:29:40 ccn128 kernel: EDAC MC0: Giving out device to

Hi List, We had the following error thrown on console on a PowerEdge server running CentOS 5 (64 bit). Googling around didn't yield any particular insights. The server crashed a few minutes after this message. Running memtester, just to check, didn't find anything; and the box has been running for months before this without issue. I'm wondering if anyone has run across this

CentOS Errata and Bugfix Advisory 2014:0768 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0768.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: f9238919a8e55753462b1690cc36a16b0a0c29260663dd5fe3e9ee0ae7a187c9 edac-utils-0.9-15.el6.i686.rpm

Hi All, We have installed CentOS 5.3 x86_64 in an HP DL585 server with AMD Opteron 64 bit processor and 16 GB RAM. The kernel version is 2.6.18-128.el5 . Now this has thrown an error message in /var/log/message, Jul 3 21:41:11 db1 kernel: EDAC k8 MC0: general bus error: participating processor(local node origin), time-out(no timeout) memory transaction type(generic read), mem or i/o(mem

I've got a production system running CentOS 4 that was rock solid until I upgraded from 2.6.9-55 to 2.6.9-78.0.13 (now running 2.6.9-89.0.11). The system now crashes intermittently after a few weeks. I finally caught the panic message : EDAC MC0: INTERNAL ERROR: channel-b out of range (4 >= 4) Kernel panic - not syncing: MC0: Uncorrected Error Looking at the kernel changelog, I see that

I haven't yet done as much experimentation as Andreas Pflug has, but I can confirm I'm also running into this bug with Xen 4.4.1. I've only tried Linux kernel 3.16.43, but as Dom0: EDAC MC: Ver: 3.0.0 AMD64 EDAC driver v3.4.0 EDAC amd64: DRAM ECC enabled. EDAC amd64: NB MCE bank disabled, set MSR 0x0000017b[4] on node 0 to enable. EDAC amd64: ECC disabled in the BIOS or no ECC

Am 21.01.16 um 17:41 schrieb Jan Beulich: >>>> On 20.01.16 at 16:01, <andreas.pflug at web.de> wrote: >> Initially reported to debian >> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810964), redirected here: >> >> With AMD Opteron 6xxx processors, half of the memory controllers are >> missing from /sys/devices/system/edac/mc >> Checked