Bug 628940 (LibvirtHMP)

Upstream libvirt has support for adding extra parameters, so you can add a HMP using something along the lines of:

   <qemu:commandline>
     <qemu:arg value='-chardev'/>
     <qemu:arg value='unix:/some/path,id=hmp'/>
     <qemu:arg value='-monitor'/>
     <qemu:arg value='readline,chardev=hmp'/>
   </qemu:commandline>

This functionality won't be available until RHEL-6.1, so will leave this bug open to track the addition.

We've discussed it today and turns out we need a solution for RHEL-6.0, I see two options:

1. Libvirt opens a default human monitor instance to some known location

2. We implement human monitor passthrough from QMP (this is going to be done upstream, for 0.14)

I think there's more work involved in 2, but 1 has security issues.

Option 1 is not desirable in libvirt, because that will set the precedent that libvirt will provide a HMP instance for QEMU guests which is not something we want todo. This is why we want to facilitate it via the command line arg XML extensions, which are clearly marked as unsupported & optional.

Option 2, monitor passthrough from QEMU via libvirt API is also something that is targetted for RHEL-6.1  and not practical for 6.0

(In reply to comment #4)

> Option 2, monitor passthrough from QEMU via libvirt API is also something that
> is targetted for RHEL-6.1  and not practical for 6.0

It's not via libvirt API, it's really via QMP itself. We're going to implement it upstream, something like:

{ "execute": "hmp_passthrough", "arguments": { "info roms" } }
{ "return": "addr=00000000fffe0000 size=0x020000 mem=rom name=\"bios.bin\""}

In theory, this could be used to debug running VMs too. Not really sure how practical this is, I'm just giving options :-)

This bug has to be resolved for _rhel6.0_ ASAP. It is impossible to debug KVM otherwise and without working KVM libvirt is useless for rhel6.

I agree with Luiz that the addition of HMP passthrough in QMP is the best approach to this problem. Since QEMU already allows to open multiple connections to the existing QMP monitor socket, I don't see that there's any additional work required in libvirt for this issue. It just needs the QEMU addition of the 'hmp_passthrough' command (or '__com.redhat.hmp_passthrough' if we don't want to wait for upstream).

(In reply to comment #7)
> I agree with Luiz that the addition of HMP passthrough in QMP is the best
> approach to this problem. Since QEMU already allows to open multiple
> connections to the existing QMP monitor socket, I don't see that there's any
> additional work required in libvirt for this issue. It just needs the QEMU
> addition of the 'hmp_passthrough' command (or '__com.redhat.hmp_passthrough' if
> we don't want to wait for upstream).

Doing hmp_passthrough is much more complex change for rhel6.0 z-stream than adding hmp from libvirt. For rhel6.1 rhevm will use cmd pass through.

Please in the future refrain from changing bug summary and component without agreement of all involved parties. It you think that hmp_passthrough for qmp is the way to go for 6.0 z stream open separate bug.

As you wish, bug 644819 opened for hmp_passthrough.

It is not simply a matter of complex, we have to consider the long term implications of adding the feature to libvirt. Exposing an 2nd monitor channel for guests is not something we have any desire to support as a solution, but once you add such a capability to RHEL we're stuck with it indefinitely. Since it is already agreed upstream that hmp_passthrough is the desirable solution for this problem, we should focus on that.

(In reply to comment #9)
> As you wish, bug 644819 opened for hmp_passthrough.
Thanks. I do not care how exactly the capability will be provides as long as it is provided in rhel6.0.

> 
> It is not simply a matter of complex, we have to consider the long term
> implications of adding the feature to libvirt. Exposing an 2nd monitor channel
> for guests is not something we have any desire to support as a solution, but
> once you add such a capability to RHEL we're stuck with it indefinitely. Since
> it is already agreed upstream that hmp_passthrough is the desirable solution
> for this problem, we should focus on that.
Provide it only when started by vdsm and drop it in rhel6.1 RHEL specific features where added to qemu-kvm too that will work differently in upstream if at all. This is not the end of the world. And BTW how supporting hmp_passthrough
is different from opening HMP from libvirt perspective?

(In reply to comment #9)
> As you wish, bug 644819 opened for hmp_passthrough.
> 
> It is not simply a matter of complex, we have to consider the long term
> implications of adding the feature to libvirt. Exposing an 2nd monitor channel
> for guests is not something we have any desire to support as a solution, but
> once you add such a capability to RHEL we're stuck with it indefinitely. Since
> it is already agreed upstream that hmp_passthrough is the desirable solution
> for this problem, we should focus on that.

We also have to consider what is the most appropriate for the Z-stream.

HMP passthrough is going to be a completely new feature, and it has all its implications: a number of code changes, upstream review cycle, testing, etc.

IMO, this is too much for the Z-stream. We should only do it if it's impossible to do something simpler.

If the only problem with opening a second monitor instance is the RHEL contract, let's put it on the table then.

How hard is to backport upstream's extra parameter support for 6.0.z ?
It seems to solve the problem, will be in 6.1, and seems to me as less work than hmp_passthrough.

Yes, libvirt supports tunneling arbitrary qemu commands using virsh qemu-monitor-command. So you can use it like this:

# virsh qemu-monitor-command rhel6 \
'{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}}'

Which will print qemu reply:

{"return":"kvm support: enabled\r\n"}

Upstream is going to gain a --hmp option for qemu-monitor-command so that the example above can be simplified to just

    virsh qemu-monitor-command --hmp DOM "info kvm"

which would print

    kvm support: enabled

I think this could simplify developers' lives and it's worth backporting for this BZ.

Patch implementing comment 28 sent to rhvirt-patches.

Failed to verify this bug as it seems related patch is not built in qemu-kvm now. So please change the bug to post status now
- qemu-kvm-0.12.1.2-2.144.el6.x86_64
- qemu-img-0.12.1.2-2.144.el6.x86_64
- libvirt-0.8.7-5.el6.x86_64
# virsh qemu-monitor-command rhel6 --hmp 'info kvm'
error: internal error unable to execute QEMU command 'human-monitor-command': The command human-monitor-command has not been found

That's weird. Are you sure your guest is running with the right version of qemu? According to qemu bug 647447 human-monitor-command is supported since qemu-kvm-0.12.1.2-2.132.el6

And it works just fine for me with

libvirt-0.8.7-5.el6.x86_64
qemu-kvm-0.12.1.2-2.144.el6.x86_64

After update kernel package, verify this bug passs
- qemu-kvm-0.12.1.2-2.144.el6.x86_64
- qemu-img-0.12.1.2-2.144.el6.x86_64
- libvirt-0.8.7-5.el6.x86_64
- kernel-2.6.32-115.el6.x86_64

# virsh qemu-monitor-command test '{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}}'
{"return":"kvm support: enabled\r\n"}

# virsh qemu-monitor-command --hmp test "info kvm"
kvm support: enabled

Verified this bug pass with libvirt-0.8.7-8.el6.x86_64
- kernel-2.6.32-117.el6.x86_64
- qemu-kvm-0.12.1.2-2.147.el6.x86_64

Test steps and actual result:

# virsh qemu-monitor-command rhel61_i386_1 '{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}}'
{"return":"kvm support: enabled\r\n"}

#  virsh qemu-monitor-command --hmp rhel61_i386_1 "info kvm" 
kvm support: enabled

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0596.html