search for: qmp_capabilities

...ck > and this is an extract of qemu output to my requests: > {"QMP": {"version": {"qemu": {"micro": 1, "minor": 8, "major": 2}, > "package": ""}, "capabilities": []}} > { "execute": "qmp_capabilities" } > {"return": {}} > { "execute": "query-commands" } > {"return": [{"name": "xen-set-global-dirty-log"}, {"name": > "xen-save-devices-state"}, {"name": "xen-load-devices-state"}, &g...

...observe the hang? How long it is anyway - assuming it goes away after some time. Or does it hang indefinitely? BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. Michal

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

...up (just after you connect) QMP sends: <- {"QMP": {"version": {"qemu": {"micro": 0, "minor": 14, "major": 0}, "package": " (qemu-kvm-0.14.0)"}, "capabilities": []}} The first command you *have* to send is qmp_capabilities (all other commands are ignored until you do this). It's unclear how capabilities negotiation is supposed to work, since there are currently no capabilities. -> { "execute": "qmp_capabilities" } <- {"return": {}} At shut down QMP sends an asynch event: &l...

...? How long it is anyway - assuming it goes away after some time. Or does it hang indefinitely? >> >> BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. >> >> Michal > > Virtlib logs end in the way you see, only when i kill the qemu process > then it starts logging and it is possible to connect remotely with > virsh. I see. There's nothing suspicious in the logs. The fact that libvirt waits for...

...domain.py", line 1321, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: cannot send monitor command '{"execute":"qmp_capabilities"}': Connection reset by peer the solution was to delete the /var/lib/libvirt/qemu/save directory. Anyone any idea of why? Lee

...ANUP_CMD_CLOSE struct command *cmd = guestfs_int_new_command (g); + int r, fd; + CLEANUP_FCLOSE FILE *fp = NULL; + CLEANUP_FREE char *line = NULL; + size_t allocsize = 0; + ssize_t len; + + guestfs_int_cmd_add_string_unquoted (cmd, "echo "); + /* QMP is modal. You have to send the qmp_capabilities command first. */ + guestfs_int_cmd_add_string_unquoted (cmd, "'{ \"execute\": \"qmp_capabilities\" }' "); + guestfs_int_cmd_add_string_unquoted (cmd, "'{ \"execute\": \""); + guestfs_int_cmd_add_string_unquoted (cmd, qmp_command...

...abilities.monitor.sock and this is an extract of qemu output to my requests: {"QMP": {"version": {"qemu": {"micro": 1, "minor": 8, "major": 2}, "package": ""}, "capabilities": []}} { "execute": "qmp_capabilities" } {"return": {}} { "execute": "query-commands" } {"return": [{"name": "xen-set-global-dirty-log"}, {"name": "xen-save-devices-state"}, {"name": "xen-load-devices-state"}, {"name": &qu...

...this is an extract of qemu output to my requests: >> {"QMP": {"version": {"qemu": {"micro": 1, "minor": 8, "major": 2}, >> "package": ""}, "capabilities": []}} >> { "execute": "qmp_capabilities" } >> {"return": {}} >> { "execute": "query-commands" } >> {"return": [{"name": "xen-set-global-dirty-log"}, {"name": >> "xen-save-devices-state"}, {"name": "xen-load-devices-...

...list, since libvirt can't drive it yet. As an addendum, here's a small QMP example to test QMP 'drive-backup' command: ----------------------------------------------------------------------- #!/bin/bash exec 3<>/dev/tcp/localhost/4444 echo -e "{ 'execute': 'qmp_capabilities' }" >&3 read response <&3 echo $response echo -e "{ 'execute': 'drive-backup', 'arguments': { 'device': 'drive-ide0-0-0', 'sync': 'full', 'target': '/var/lib/libvirt/images/backup-copy.qcow2&...

...ook into /usr/local/bin, but I might be wrong. Check whether 'virsh capabilities' tells you something about any emulator. You can try installing from source, but putting it in /usr/bin, you can also remove that installation, put back the one from the package and try running: { for i in qmp_capabilities query-commands quit; do echo "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults -no-user-config -M none -qmp stdio And see whether the QEMU process quits, what it outputs and if it gets stuck, you can attach gdb and see what it's waiting for....

...the hang? How long it is anyway - assuming it goes away after some time. Or does it hang indefinitely? > > BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. > > Michal Virtlib logs end in the way you see, only when i kill the qemu process then it starts logging and it is possible to connect remotely with virsh. Until the qemu process is active you can not use libvirt. In the following libvirt log file find all that happe...

...ng it is anyway - assuming it goes away after some time. Or does it hang indefinitely? >>> >>> BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. >>> >>> Michal >> >> Virtlib logs end in the way you see, only when i kill the qemu process >> then it starts logging and it is possible to connect remotely with >> virsh. > > I see. There's nothing suspicious in the logs....

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'

...---------- > default active yes > Downloads active yes > guest_images_lvm active yes > >$ > >> you can >> also remove that installation, put back the one from the package and try >> running: >> >> { for i in qmp_capabilities query-commands quit; do echo >> "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults >> -no-user-config -M none -qmp stdio >> >> And see whether the QEMU process quits, what it outputs and if it gets >> stuck, you can attac...

...t yet. > As an addendum, here's a small QMP example to test QMP 'drive-backup' > command: > > ----------------------------------------------------------------------- > #!/bin/bash > > exec 3<>/dev/tcp/localhost/4444 > echo -e "{ 'execute': 'qmp_capabilities' }" >&3 > read response <&3 > echo $response > echo -e "{ 'execute': 'drive-backup', 'arguments': > { 'device': 'drive-ide0-0-0', 'sync': 'full', 'target': > '/var/lib/libvir...

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

...Autostart ------------------------------------------- default active yes Downloads active yes guest_images_lvm active yes $ > you can > also remove that installation, put back the one from the package and try > running: > > { for i in qmp_capabilities query-commands quit; do echo > "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults > -no-user-config -M none -qmp stdio > > And see whether the QEMU process quits, what it outputs and if it gets > stuck, you can attach gdb and see what i...

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.

...t;> Downloads active yes >> guest_images_lvm active yes >> >> $ >> >>> you can >>> also remove that installation, put back the one from the package and >>> try >>> running: >>> >>> { for i in qmp_capabilities query-commands quit; do echo >>> "{'execute':'$i'}"; done } | qemu-system-x86_64 -nographic -nodefaults >>> -no-user-config -M none -qmp stdio >>> >>> And see whether the QEMU process quits, what it outputs and if it gets >>>...