> Rodney W. Grimes wrote: > > > There is a new version of the CPU topology review up at > > http://reviews.freebsd.org/D9930 > > > > I would like to ask that if people can test this and provide > > feedback that they do so. > > > > It has some undesired side effects on vm-bhyve and probably > > other down stream tools, I am in the process of contacting > > the vm-bhyve author to see what can be done to clean up > > this output (if you are here please respond to this thread): > > > > src-topo # vm list > > NAME DATASTORE LOADER CPU MEMORY VNC > > AUTOSTART STATE > > issd30g1 default bhyveload > > cpus=8,sockets=2,cores=4,threads=1 1024M - No > > Stopped > > > > Notice that due to the new CPU string being much more complicated than > > the normal int it makes the output format ugly. I have another change > > to vm-bhyve that I would like to see too, and that is to move the NAME > > to the end of the line and remove the 16 character limit. I have done > > that in my local copy already. This string and its parsing are designed > > to be Qemu compatible. > > > > Here is a sample of my local vm-bhyve vm list output (no topology used): > > /tmp # vm list > > DATASTORE LOADER CPU MEMORY VNC AUTOSTART > > STATE NAME > > default bhyveload 1 128M - No > > Stopped fb-bld-10-amd64 > > default bhyveload 1 128M - No > > Stopped fb-bld-11-amd64 > > 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 > > default bhyveload 2 256M - No > > Running (30227) fb-bld-head-amd64 > > > > Thoughts are to teach vm-bhyve to parse the string just as bhyve does > > and only output the vCPU count. Other thoughts I have are to have > > it parse the string and output either vCPU if cores/threads is 1, > > or a simple S/C/T string. > > > > If you are a downstream maintainer of one of the other vm management > > packages > > I am open to input. The implemntation I have done should allow any existing > > tool that treated -c as a string to use the new topology without changes. > > This includes the in base vmrun.sh. > > My general input on adding new features to bhyve is that it would be > nice to have a way to detect if the given bhyve version supports this > specific feature. > > In this specific case it looks like this could be checked by running > > bhyve -c gibberish > > and checking if the error message contains 'invalid cpu topology' > string. > > But generally it would be good to have some more convenient way of doing > that because running bhyve to probe each feature is pretty expensive.
I agree that this is a nice thing to have, but I can not think of any other command that implements that feature. In general command line interfaces are for human consumption. This one though is being used extensivly by other scripts and programs. > > By the way, looking at the DR, it seems that the usage output (bhyve -h) > wasn't updated, but maybe I'm missing that without context. Good catch, I infact did miss that. I'll update it and push a new patch to the review. Thank you. > > Also people using the sysctls: > > hw.vmm.topology.cores_per_package: 1 > > hw.vmm.topology.threads_per_core: 1 > > can continue to do so at this time, but there is work in process to > > deprecate these, that work includes making stable/11 emit a warning > > message if they are used, and remove them in head/12. > > > > If I can get some significant test results back I plan to commit > > D9930 to ^head and merge it back to stable/11 3 days later. > > > > Thanks, > > -- > > Rod Grimes > > rgri...@freebsd.org > > Roman Bogorodskiy Regards, -- Rod Grimes rgri...@freebsd.org _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"