Curent Centos 7 and bhyve

[Matt Churchyard]

> > Rodney W. Grimes wrote:
> 
> [dd]
> 
> > > > > > 
> > > > > > Though it has a lot of features, it also has some short 
> > > > > > comings, like you can not spec a vm to be wired in memory, 
> > > > > > which IMHO is the only way to insure consistent VM performance.
> > > > > 
> > > > > Well, we have "bhyve_options" configuration option in the vm 
> > > > > config, why not put "-S" there, is that what you mean by 
> > > > > wiring the vm in memory?
> > > > 
> > > > I believe that fails as that only adds the -S to bhyve, and you 
> > > > must specify it both on bhyveload and bhyve for it to work.
> > > 
> > > I think it is totally doable becase vm-bhyve is nothing but a suit 
> > > of scripts. A PR with a feature request would be appropriate.
> > 
> > I made several attempts to contact the author at the email address 
> > provided at the git hub while making other bhyve changes to try and 
> > coordinate with him.  I got no response after 3 attempts,
> > so have stopped trying to contact them.   (This was while I was
> > adding the -c cpu topology modifications.)
> 
> > You can add yourself to
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230580
> > maybe something useful comes out of it.
> 
> I've already commented on the bug, although I'll reply here as well.
> If "-S" is found in bhyve_options it does currently affect both commands. I have decided that a specific wired_memory option is useful though and will add this to the next release.
> 
> The name limit has been increased to 32 since v1.2

>This is better, but still an artificial limit, the implementation of bhyve allows this string to be any valid filename, the scripts should be designed to allow for that as the valid limit.

As far as I'm aware bhyve is currently limited to 32 characters, although this obviously may change. We use the name in various situations (interface descriptions, console names, etc) so it's beneficial to make sure it's not excessively long, or contains characters that could cause problems when used in other places.

if(name == NULL || strlen(name) >= VM_MAX_NAMELEN)
       return (EINVAL);

#define VM_MAX_NAMELEN  32


>I modified the script so that the vm name is the last column, and removed the length check all togeather, this allows for the string to be what ever length and not mess with column widths.

>root at x230a:# vm list
>DATASTORE       LOADER      CPU    MEMORY    VNC                  AUTOSTART    STATE            NAME
>default         bhyveload   1      128M      -                    No           Stopped          fb-bld-10-amd64
>default         bhyveload   4      2048M     -                    No           Stopped          fb-bld-11-amd64
>default         bhyveload   4      1024M     -                    No           Stopped          fb-bld-11-i386
>default         bhyveload   1      128M      -                    No           Stopped          fb-bld-11.0-p1-amd64
>default         bhyveload   1      128M      -                    No           Stopped          fb-bld-11.0-p1-i386
>default         bhyveload   4      512M      -                    No           Stopped          fb-bld-11.1-amd64
>default         bhyveload   4      512M      -                    No           Stopped          fb-bld-11.1-i386


>> I didn't realize the changes for cpu topology had actually made it 
>> into head, although I don't believe it's actually in a release yet?

>Yes, they are in head, the MFC has been delayed for other reasons.
>It is in the 12.0-ALPHA1 snapshot, and many before that.  

>> I will plan to support configuration and display of these before 12 
>> release.

>Thanks.  I think mostly just extract the NCPU's from the topology string.  The code actually works now, but due to fixed column width assumptions the output looks bad.

I've added some additional cpu_ settings to control the new cpu fields. "vm list" just shows the original cpu setting so this remains unmodified. "vm info" shows full settings.

> 
> Matt
> 
> > --
> > Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> > AS43859
> > _______________________________________________
> > freebsd-virtualization at freebsd.org mailing list 
> > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> > To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"
> 
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org
_______________________________________________
freebsd-virtualization at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"