similar to: Re: [libvirt] libvirt 1.2.10 and latest EL6 qemu-kvm

Kashyap Chamarthy <kchamart@redhat.com> schreef op 19 januari 2015 19:00:23 CET: >[Dropping libvir list and adding libvir-users list.] > >On Mon, Jan 19, 2015 at 04:12:46PM +0100, liedekef@telenet.be wrote: >> Hi all, >> >> I had libvirt 1.2.10 running without issues together with the qemu >package >> qemu-kvm-0.12.1.2-2.415.el6_5.14.x86_64.rpm >

On Tue, Jun 23, 2015 at 03:41:45PM +0200, Michal Privoznik wrote: > On 23.06.2015 14:16, Ivo Hora wrote: > > Dear Sir, > > > > I am facing the same problem you were discussing here: > > https://www.redhat.com/archives/libvirt-users/2015-January/msg00070.html > > > > I am getting this error: > > Starting install... > > ERROR internal error:

Dear Sir, I am facing the same problem you were discussing here: https://www.redhat.com/archives/libvirt-users/2015-January/msg00070.html I am getting this error: Starting install... ERROR internal error: unable to execute QEMU command 'qom-list': The command qom-list has not been found Domain installation does not appear to have been successful. If it was, you can restart your domain

(I'm sorry, I didn't find my original message but I provide the archive link: https://www.redhat.com/archives/libvirt-users/2015-January/msg00069.html ) I just tried the latest libvirt release (1.2.12), combined with the following qemu EL6 package from centos: qemu-kvm-0.12.1.2-2.448.el6_6.x86_64 Using 1.2.12 and this version of qemu-kvm, I still get the following error when trying to

On 04/27/2017 04:31 PM, Stefano Ricci wrote: > Here is the backtrace of the libvirt process just started [Just a side note, you shouldn't top post on technical lists. Gmail sucks at this.] > > https://pastebin.com/R66myzFp Looks like libvirtd is trying to spawn /usr/bin/qemu-system-x86_64 but it takes ages to init. In the debug logs you might see the actual command line that

At Thu, 03 Jul 2014 17:32:20 +0300, Gleb Voronich wrote: > > > > Actually, you should get more stats when using the virtio balloon > > driver in your guests. > I use the balloon but I can't get more stats. > I use python binding for libvirt and as far as I can see it calls > virDomainMemoryStats exactly. Which OS are you using in your guests? Of course, you need

Hi, since we're running more than 20 hosts per KVM server, we needed to update libvirt to at least 1.1.2 for virtlockd to be able to cope with this (due to an old hardcoded limit that was in there before). But where 1.1.0 compiles and runs just fine on a fully-patched CentOS 6.4 server, newer version have all kinds of issues: Every version of libvirt >= 1.1.2 crashes with a segfault on

On 04/29/2017 04:38 AM, Stefano Ricci wrote: > 2017-04-28 14:33 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: >> On 04/27/2017 04:31 PM, Stefano Ricci wrote: >>> Here is the backtrace of the libvirt process just started >> >> [Just a side note, you shouldn't top post on technical lists. Gmail >> sucks at this.] >> >>> >>>

This hotplug state will be used to remove a device without the guest cooperation. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> --- hw/acpi_piix4.c | 5 +++++ hw/pci.h | 1 + 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c index 585da4e..dfd5a9d 100644 --- a/hw/acpi_piix4.c +++ b/hw/acpi_piix4.c @@ -587,6 +587,11 @@

The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST feature bit. Whenever the bit is set, we must always tell the host before we free pages back to the allocator. Without this we might free a page (and have another user touch it) while the hypervisor is unprepared for it. But, if the bit is _not_ set, we are under no obligation to reverse the order. Furthermore, all modern qemus

The virtio balloon driver has a VIRTIO_BALLOON_F_MUST_TELL_HOST feature bit. Whenever the bit is set, we must always tell the host before we free pages back to the allocator. Without this we might free a page (and have another user touch it) while the hypervisor is unprepared for it. But, if the bit is _not_ set, we are under no obligation to reverse the order. Furthermore, all modern qemus

On Sun, 2014-09-21 at 15:03 +1000, Benjamin Herrenschmidt wrote: > The exception I mentioned is that I would really like the virtio device > to expose via whatever transport we chose to use (though capability > exchange sounds like a reasonable one) whether the "server" > implementation is bypassing IOMMUs or not instead on relying on client > side heuristics. > >

On Sun, 2014-09-21 at 15:03 +1000, Benjamin Herrenschmidt wrote: > The exception I mentioned is that I would really like the virtio device > to expose via whatever transport we chose to use (though capability > exchange sounds like a reasonable one) whether the "server" > implementation is bypassing IOMMUs or not instead on relying on client > side heuristics. > >

Hyper-V SynIC (synthetic interrupt controller) device implementation. The implementation contains: * msr's support * irq routing setup * irq injection * irq ack callback registration * event/message pages changes tracking at Hyper-V exit * Hyper-V test device to test SynIC by kvm-unit-tests Andrey Smetanin (7): standard-headers/x86: add Hyper-V SynIC constants target-i386/kvm: Hyper-V

Hyper-V SynIC (synthetic interrupt controller) device implementation. The implementation contains: * msr's support * irq routing setup * irq injection * irq ack callback registration * event/message pages changes tracking at Hyper-V exit * Hyper-V test device to test SynIC by kvm-unit-tests Andrey Smetanin (7): standard-headers/x86: add Hyper-V SynIC constants target-i386/kvm: Hyper-V

Hey folks, I've been experimenting with native NBD live migration w/ TLS and have a couple of questions. 1) It appears that in some cases modified default_tls_x509_cert_dir from qemu.conf is not respected, seems like virsh always expects a default location and does not check default_tls_x509_cert_dir: virsh # migrate vm1 qemu+tls://ratchet.lan/system --live --persistent --undefinesource

Hi, Since a few weeks I'm getting lot of messages in syslog in FC20 sent by libvirt. I've tried to find the reason using our best friend, but all I can find is some kind of bug related to CPU feature reporting. I'm not really interested what is the reason of the message (I'm sure it will be fixed in an upcoming release), but I would like to get rid of these annoying messages

On 23.06.2015 14:16, Ivo Hora wrote: > Dear Sir, > > I am facing the same problem you were discussing here: > https://www.redhat.com/archives/libvirt-users/2015-January/msg00070.html > > I am getting this error: > Starting install... > ERROR internal error: unable to execute QEMU command 'qom-list': The > command qom-list has not been found > Domain

Traditionally if you did live migration (KVM to KVM), you had to ensure that cache=none was set on all disks of the guest up front. This was because of quirks in how NFS works (I think the close-to-open consistency and the fact that during live migration both qemus have the file open), and we had to assume the worst case that a guest might be backed by NFS. Because of this when virt-v2v converts

I think it has to be something trivial, but I cannot start 2 windows servers at the same time on the same dom0. If I start server 2008 first I can''t start 2012, if I start 2012, I can''t start 2008. The failure is: libxl: error: libxl_device.c:470:libxl__wait_for_device_model Device Model not ready xl: fatal error: libxl_create.c:535, rc=-1: libxl__confirm_device_model_startup