[libvirt] [PATCHv8 1/7] bhyve: Support /domain/bootloader configuration for non-FreeBSD guests.

Michal Privoznik mprivozn at redhat.com
Wed Nov 12 09:07:34 UTC 2014

On 11.11.2014 17:12, Conrad Meyer wrote:
> On Tue, Nov 11, 2014 at 10:40 AM, Michal Privoznik <mprivozn at redhat.com> wrote:
>> On 11.11.2014 16:17, Conrad Meyer wrote:
>>> On Tue, Nov 11, 2014 at 9:52 AM, Michal Privoznik <mprivozn at 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.


More information about the libvir-list mailing list