On 11.11.2014 17:12, Conrad Meyer wrote:
On Tue, Nov 11, 2014 at 10:40 AM, Michal Privoznik <mprivozn@redhat.com> wrote:
On 11.11.2014 16:17, Conrad Meyer wrote:
On Tue, Nov 11, 2014 at 9:52 AM, Michal Privoznik <mprivozn@redhat.com> wrote:
One of the things I'm worried about is, if the boot args are not specified we properly add memory configured in domain XML.
However, IIUC the memory amount can be overridden with boot args. Is that expected?
Yes. If you use bootloader_args, you get exactly what you ask for and no more.
Well, if one is modifying XML to change booloader_args already he can change the memory amount there too. What I'm trying to say is, we should add '-m def->mem.max_balloon' unconditionally. Or do you intend to give users so much freedom? I worried it can bite us later when libvirt fails to see the real amount of memory that domain has.
I think also bhyve(8) itself will be unhappy. The man page specifies:
""" -m size[K|k|M|m|G|g|T|t] Guest physical memory size in bytes. This must be the same size that was given to bhyveload(8). """
However, I think the messaging around bootloader_args for bhyve / bhyveload is and should remain: "if you need this, you're on your own and need to specify *everything* manually." We expect most users to not need <bootloader> for bhyve at all, especially in the medium-term future, and even fewer users to need <bootloader_args>.
IMO, as a user it is more surprising to get additional arguments prepended to the arguments I have specified than to have them passed through unmodified. And we would have to prepend or otherwise shove the -m flag in the middle somewhere. I think it is probably too much magic.
Okay, you've persuaded me that This patch is good as is. ACK then. Michal