search for: qmp_capabl

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.] >> >>> >>>

On 04/30/2017 07:12 PM, Stefano Ricci wrote: > > The version used for backtrace is 3.2.0, now I have also tried the > current downloaded with git but the problem is always present. > This is the current version log file, set as shown on the DebugLogs page: > > https://drive.google.com/open?id=0By9lwQyveHENdEt4aEtZcUV3ZEU Couple of my findings: 2017-04-30 16:19:34.894+0000:

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

I was hoping that we could use QMP (now semi-stable since qemu 0.14) to hot plug disks. Unfortunately this is not yet possible. There is no drive_add QMP command which would be necessary for adding drives. We (Red Hat) hacked in a drive_add command into RHEL 6 (only for use by libvirt). This doesn't help us with upstream or Fedora. We could still use the human monitor, but obviously this

On 05/01/2017 09:57 AM, Stefano Ricci wrote: > 2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: >> On 04/30/2017 07:12 PM, Stefano Ricci wrote: >> >>> >>> The version used for backtrace is 3.2.0, now I have also tried the >>> current downloaded with git but the problem is always present. >>> This is the current version log

Hi qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64 qemu-kvm-tools-0.12.1.2-2.160.el6_1.2.x86_64 libvirt-java-javadoc-0.4.7-1.el6.noarch libvirt-client-0.8.7-18.el6.x86_64 fence-virtd-libvirt-qpid-0.2.1-8.el6.x86_64 ocaml-libvirt-0.6.1.0-6.2.el6.x86_64 libvirt-devel-0.8.7-18.el6.x86_64 libvirt-python-0.8.7-18.el6.x86_64 libvirt-java-0.4.7-1.el6.noarch libvirt-cim-0.5.11-3.el6.x86_64

This adds two extra tests using QMP (the QEMU Monitor Protocol). This allows us to get extra information about the qemu binary beyond what is available from the version number or ‘qemu -help’. --- lib/qemu.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 175 insertions(+), 2 deletions(-) diff --git a/lib/qemu.c b/lib/qemu.c index bdd9947a8..34775041f 100644

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.] > >> >> https://pastebin.com/R66myzFp > > Looks like libvirtd is trying to spawn

2017-04-29 7:24 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: > 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

On Tue, Oct 14, 2014 at 02:08:41PM -0600, Eric Blake wrote: > On 10/14/2014 11:52 AM, Jd wrote: > > Hi > > > > * Trying to get drive-backup command, getting permission denied. :( > > > > sudo virsh qemu-monitor-command --hmp my-instance --cmd > > drive_backup drive-virtio-disk0 /tmp/foo.vda.img > > Ouch. qemu-monitor-command is explicitly

On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >I've upgraded from Fedora 20; probably missed a merge of rpmnew with >existing .conf; permission problem, some other mistake along the way to >Fedora 25. > Yeah, probably some 'rpm -qV' (or whatever the command to verify all packages is) could help as well. >Is there a "how to" similar to [1]

2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: > On 04/30/2017 07:12 PM, Stefano Ricci wrote: > >> >> The version used for backtrace is 3.2.0, now I have also tried the >> current downloaded with git but the problem is always present. >> This is the current version log file, set as shown on the DebugLogs page: >> >>

2017-05-03 8:56 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: > On 05/01/2017 09:57 AM, Stefano Ricci wrote: >> 2017-05-01 7:32 GMT+02:00 Michal Privoznik <mprivozn@redhat.com>: >>> On 04/30/2017 07:12 PM, Stefano Ricci wrote: >>> >>>> >>>> The version used for backtrace is 3.2.0, now I have also tried the >>>> current

Attempting to take snapshots of VM using virsh with the following command, # virsh -c qemu:///system snapshot-create CentOS6-x86-001 Results in the following error, error: internal error unable to execute QEMU command 'savevm': The command savevm has not been found The VM's virtual disks are qcow2. Below is the XML file for this vm ------------ <domain type='kvm'

On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote: > > >On 06/05/2017 10:46 AM, Martin Kletzander wrote: >> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>> existing .conf; permission problem, some other mistake along the way to >>> Fedora 25.

On 10/15/14, 2:37 AM, Kashyap Chamarthy wrote: > On Tue, Oct 14, 2014 at 02:08:41PM -0600, Eric Blake wrote: >> On 10/14/2014 11:52 AM, Jd wrote: >>> Hi >>> >>> * Trying to get drive-backup command, getting permission denied. :( >>> >>> sudo virsh qemu-monitor-command --hmp my-instance --cmd >>> drive_backup

Package: xen-utils-common Version: 4.4.1-6 Severity: normal Dear Maintainer, (There appear to be several reports on the BTS with concerns relating to this report. Some unarchiving/merging may be necessary. Reassignment may be needed as well since I'm not sure which package this problem would fall under. Ultimately decided to file with xen-utils-common with 'xl' being the frontend

On 06/05/2017 10:46 AM, Martin Kletzander wrote: > On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >> existing .conf; permission problem, some other mistake along the way to >> Fedora 25. >> > > Yeah, probably some 'rpm -qV' (or whatever the command to verify all

The patch I posted last week to disable mandatory locking for readonly drives (https://www.redhat.com/archives/libguestfs/2017-September/msg00013.html) was wrong in a couple of respects. Firstly it didn't work, which I didn't detect because my tests were testing the wrong thing. Oops. Secondly it used a simple version number check to detect qemu binaries implementing mandatory locking.

On 06/06/2017 04:43 AM, Martin Kletzander wrote: > On Mon, Jun 05, 2017 at 07:52:58PM -0400, Michael C Cambria wrote: >> >> >> On 06/05/2017 10:46 AM, Martin Kletzander wrote: >>> On Sun, Jun 04, 2017 at 06:42:39PM -0400, Michael C Cambria wrote: >>>> I've upgraded from Fedora 20; probably missed a merge of rpmnew with >>>> existing .conf;