From: Tony Krowiak <akrowiak@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: marcel.apfelbaum@gmail.com
Subject: [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary
Date: Tue, 31 Mar 2015 10:21:41 -0400 [thread overview]
Message-ID: <551AAD75.8090909@linux.vnet.ibm.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
Commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 removed the QemuOptDesc
elements from the
*desc* field of the *qemu_machine_opts *array defined in vl.c. Since
applying that patch to qemu
on my system, I can not start a guest from libvirt when certain machine
options are configured
for the guest domain. For example, if I configure the following for my
guest domain:
<memoryBacking>
...
<nosharepages>
...
</memoryBacking>
I get the following libvirt error when I try to start the guest:
error: unsupported configuration: disable shared memory is not
available with this QEMU binary
The *nosharepages *element generates the *-machine* option
*mem-merge=off* on the QEMU command line. The error is
thrown by libvirt because the QMP *query-command-line-options* command
does not return *mem-merge* in the machine
options parameter list. In fact, if I issue the
*query-command-line-options* command via virsh as follows:
virsh qemu-monitor-command guest_c2aa '{ "execute":
"query-command-line-options", "arguments": { "option": "machine" } }'
No machine option parameters are returned:
{"return":[{"parameters":[],"option":"machine"}],"id":"libvirt-11"}
I took a look at the *qmp_query_command_line_options* function in
*util/qemu-config.c*. The function derives the
option parameters to return with the the query response from the
QemuOptDesc elements contained in the
*desc* field of the *qemu_machine_opts *array defined in vl.c. It
appears that removing the
QemuOptDesc elements broke the *qmp_query_command_line_options*
function. If I restore the QemuOptDesc
elements removed by commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6, I
can start the guest with
*nosharepages* configured.
It would appear that a bug was introduced with commit
49d2e648e8087d154d8bf8b91f27c8e05e79d5a6,
what say you?
[-- Attachment #2: Type: text/html, Size: 2764 bytes --]
next reply other threads:[~2015-03-31 14:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-31 14:21 Tony Krowiak [this message]
2015-04-01 6:54 ` [Qemu-devel] [qemu devel] disable shared memory is not available with this QEMU binary Marcel Apfelbaum
2015-04-01 8:01 ` Paolo Bonzini
2015-04-01 8:06 ` Marcel Apfelbaum
2015-04-01 8:20 ` Paolo Bonzini
2015-04-01 8:42 ` Markus Armbruster
2015-04-01 9:07 ` Paolo Bonzini
2015-04-01 9:14 ` Marcel Apfelbaum
2015-04-01 9:23 ` Paolo Bonzini
2015-04-01 9:27 ` Marcel Apfelbaum
2015-04-01 8:28 ` Markus Armbruster
2015-04-01 14:51 ` Marcel Apfelbaum
2015-04-01 15:53 ` Markus Armbruster
2015-04-01 16:11 ` Marcel Apfelbaum
2015-04-01 16:20 ` Eric Blake
2015-04-01 16:31 ` Marcel Apfelbaum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=551AAD75.8090909@linux.vnet.ibm.com \
--to=akrowiak@linux.vnet.ibm.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).