On 11.11.2014 17:12, Conrad Meyer wrote:
On Tue, Nov 11, 2014 at 10:40 AM, Michal Privoznik <mprivozn@xxxxxxxxxx> wrote:
On 11.11.2014 16:17, Conrad Meyer wrote:
On Tue, Nov 11, 2014 at 9:52 AM, Michal Privoznik <mprivozn@xxxxxxxxxx>
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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list