similar to: Double fault panic in L2 upon v2v conversion

Thanks Richard for a fast reply. Yes, indeed, im working on a nested environment. I try to run v2v inside a VM (L1) and to create an L2 by the conversion process. And on Intel. As I wrote, it fails once in few times, mainly when there is a memory pressure on L0. Kashyap, can you please share your experience? Why should it crash during nested conversion. I'm not too familiar with libguestfs

Hi everybody, Wanted to hear your opinion and to receive a smart advice. I'm trying to use virt-v2v in order to convert ova image (exported from vmware) to run on libvirt/kvm - all this inside a VM of fedora. The converted image is also a fedora. During the conversion process, in some point of libguestfs activity, I get double fault panic from L2 (printed as part of libguest output) and the

There is a bug which is still not fixed:Bug 956580 -[ RFE ]Support for VMware & Citrix OVF image import into RHEV https://bugzilla.redhat.com/show_bug.cgi?id=956580 Best regards, Tingting Zheng（郑婷婷） ----- Original Message ----- From: "Rom Freiman" <rom@stratoscale.com> To: libguestfs@redhat.com Sent: Wednesday, January 15, 2014 10:35:29 PM Subject: [Libguestfs] Double fault

Hey everybody, Richard, you were right. I managed to reproduce the same crash without dealing with v2v (and libguestfs). Actually - it's reproducible really ease - I write a big file to /tmp on L0 (till it 100% full) and then run a L2 VM. Almost every time it crushes with double fault. Debugging, debugging and more debugging. Marcelo/Paolo, if you have any clue, I would like to hear from you.

Kashyap, just to be sure - it happens to you during the v2v conversion? on L2? While L1 and L0 works fine afterwords, right? Thanks On Fri, Jan 17, 2014 at 4:45 PM, Kashyap Chamarthy <kchamart@redhat.com> wrote: > On 01/17/2014 03:38 PM, Richard W.M. Jones wrote: >> On Fri, Jan 17, 2014 at 04:14:03PM +0200, Rom Freiman wrote: >>> How do you know that the problem is with

[Please keep libguestfs mailing list in CC] On Fri, Jan 17, 2014 at 04:14:03PM +0200, Rom Freiman wrote: > How do you know that the problem is with KVM/QEMU and not with libguestfs? The guestfsd daemon is simply running the regular 'mount' command. The mount command causes the kernel to panic. There should be no circumstances where running an ordinary command like that, albeit as

Hi, I currently have a MySQL database containing all Puppet storeconfigs. My intention is to migrate to PuppetDB on a PostgreSQL server, so the first step is to use the ''storeconfigs'' face to export all the DB to a file PuppetDB can later consume. But the ''puppet storeconfigs export'' command always ends up being killed, I suspect due to some sort of OOM

Warning - I'm fairly new to libvirt, lxc and systemd so there is a good chance I'm doing something terribly wrong here. However, instead of continuing to struggle, I figured I would mail the list for some advice. What I'm trying to accomplish is a libvirt-lxc, systemd-based container running on my system (Fedora 19). I've read that sharing the underlying OS filesystem with

Hello people, libvirtd (libvirt) 1.0.5.2 virsh 1.0.5.2 virt-manager 0.10.0 Host: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Guest1: Linux localhost 3.9.8-300.fc19.i686.PAE #1 SMP Thu Jun 27 19:29:30 UTC 2013 i686 (none) Guest2: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

https://bugs.freedesktop.org/show_bug.cgi?id=71438 Priority: medium Bug ID: 71438 Assignee: nouveau at lists.freedesktop.org Summary: Application Konqueror crashes when connecting to asus.com QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

On 03.07.2013 13:43, Daniel P. Berrange wrote: > On Tue, Jul 02, 2013 at 01:25:21PM +0200, poma wrote: >> Hello people, >> >> libvirtd (libvirt) 1.0.5.2 >> virsh 1.0.5.2 >> virt-manager 0.10.0 >> >> Host: >> Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC >> 2013 x86_64 x86_64 x86_64 GNU/Linux >> Guest1: >>

Reposting from virt-tools mailing list: Hi! I'm facing a problem that could be triggered by some lacking of support from libvirt on Open vSwitch (or could be my mistake). I have interests in researching on virtual networks and SDN. To keep things simple, I've decided to use libvirt/virt-tools to manage VM's since my focus is on the network, instead of using a full feature system

I don't get this. I am using a freshly installed copy of Fedora 19 and starting up glusterd for the first time. The goal is to have a replicated directory on two systems. But for right now, I can't even start up the glusterd daemon right out of the box. Trying to follow the Quick Start directions at http://gluster.org/community/documentation/index.php/QuickStart is, well, challenging.

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

I've sent a patch to libvirt that should fix our problem with 'raw' driver that is mentioned in [1]. The libvirt patch is here [2]. However, to realy fix things, there is at least one thing we have to change on our side. We have to be explicit about the driver in the JSON we generate. Note that the libvirt patch has not yet been reviewed nor merged, so this may not be the only thing

v7: - rebased because patch 1/3 has been pushed - changes to nsplit have been dropped (2/3) - addressed Richard's comments, notably the subfolder function was moved to mllib and renamed to subdirectory v6: - just rebase v5: - rebase, patches 1,3,5 were merged - 1/3: we still need to discuss whether to detect compressed discs - 2/3: - renamed argument noempty to keep_empty - tests were

Very recent versions of tar (most probably as a consequence of CVE-2016-6321) may refuse archive members with '..', like the relative paths to upper level directories. Since these are just tests, simply copy the files in the temporary directories where tar (or zip as well) is run, so all the files are in the same directory. --- v2v/test-v2v-i-ova-formats.sh | 9 +++++----

v6: - just rebase v5: - rebase, patches 1,3,5 were merged - 1/3: we still need to discuss whether to detect compressed discs - 2/3: - renamed argument noempty to keep_empty - tests were not run - 3/3: - using JSON module to generate JSON (as suggested by Pino) - all the other comments raised by Pino v4: - rebase to more recent master - 1/6: using just "quote" instead of

This series is related to the problem of inefficient import of OVA files. The needed enhancements of QEMU were merged into the codebase and should be available in QEMU 2.8. From there we can use 'size' and 'offset' options in raw driver to tell QEMU to use only subset of a file as an image. The patch set is more or less complete. The only outstanding issue is the missing detection

So far v2v did not read the model of network interfaces, resulting in "virtio" as the model for such interfaces. Start reading the model, if available, mapping only E1000 for now. There are also other models, e.g. PCNet32 or VmxNet3, but they are ignored for now: reading them as Source_other_nic would result in v2v rejecting OVAs previously converted. --- v2v/parse_ovf_from_ova.ml