[Bug 250671] error reporting with bhyvectl could be improved

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250671 Robert Wing changed: What|Removed |Added Status|New |In Progress CC|

[Bug 250671] error reporting with bhyvectl could be improved

: Robert Wing AuthorDate: 2021-03-07 06:19:30 + Commit: Robert Wing CommitDate: 2021-03-07 06:19:30 + bhyvectl: print a better error message when vm_open() fails Use errno to print a more descriptive error message when vm_open() fails libvmm: preserve errno when

[Bug 250671] error reporting with bhyvectl could be improved

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250671 Peter Grehan changed: What|Removed |Added CC||gre...@freebsd.org --- Comment #1

[Bug 250671] error reporting with bhyvectl could be improved

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250671 Bug ID: 250671 Summary: error reporting with bhyvectl could be improved Product: Base System Version: 12.1-STABLE Hardware: Any OS: Any Status: New

Re: System (ps/top) & bhyvectl memory usage differences

Hi Matt, Is there a reason why the resident memory used by a bhyve guest is quite different when comparing ps/top & bhyvectl? Does bhyvectl take in account something in kernel space that top/ps doesn't see? USER PID %CPU %MEM VSZRSS TT STAT STARTED TIME COMMAND root 12670

System (ps/top) & bhyvectl memory usage differences

Hello, Is there a reason why the resident memory used by a bhyve guest is quite different when comparing ps/top & bhyvectl? Does bhyvectl take in account something in kernel space that top/ps doesn't see? USER PID %CPU %MEM VSZRSS TT STAT STARTED TIME COMMAND root 12670

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046 Mateusz Piotrowski <0...@freebsd.org> changed: What|Removed |Added CC|

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046 Oleksandr Tymoshenko changed: What|Removed |Added CC||d...@freebsd.org

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

|sbr...@freebsd.org --- Comment #4 from Sean Bruno <sbr...@freebsd.org> --- man bhyvectl(8) exists in -current, it appears to be in usr.sbin/bhyvectl/bhyvectl8 and is installed. -- You are receiving this mail because: You are the assignee for the bug. ___

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: sbruno Date: Mon Nov 27 16:28:28 UTC 2017 New revision: 326281 URL: https://svnweb.freebsd.org/changeset/base/326281 Log: Add vmm(4) man page PR:

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046 Peter Grehan changed: What|Removed |Added CC|

[Bug 184046] bhyve(4) manpage references non-existant manpages bhyvectl(8), vmm(4)

|se...@freebsd.org --- Comment #1 from Sevan Janiyan <se...@freebsd.org> --- We have an incomplete bhyvectl manual, vmmm manual is still missing. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-virtualization@freebsd

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

On 03/06/2015 02:04, John-Mark Gurney wrote: Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: I guess you are running bhyve through the shell script vmrun.sh? I am doing everything by hand. Correct: sh /usr/share/examples/bhyve/vmrun.sh -g 6444 -d mach10s.img -t tap0

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

Andriy Gapon wrote this message on Wed, Jun 03, 2015 at 10:10 +0300: On 03/06/2015 02:04, John-Mark Gurney wrote: Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: I guess you are running bhyve through the shell script vmrun.sh? I am doing everything by hand.

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

On 03/06/2015 18:53, John-Mark Gurney wrote: Andriy Gapon wrote this message on Wed, Jun 03, 2015 at 10:10 +0300: On 03/06/2015 02:04, John-Mark Gurney wrote: Andriy Gapon wrote this message on Tue, Jun 02, 2015 at 21:15 +0300: I guess you are running bhyve through the shell script vmrun.sh?

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

On Wed, Jun 3, 2015 at 9:18 AM, Andriy Gapon a...@freebsd.org wrote: On 03/06/2015 18:53, John-Mark Gurney wrote: JIMO, bhyveload(8) could be just merged into bhyve(8) and the latter should behave like vmrun.sh does. bhyve(8) should retain an option to run a preloaded kernel, so that

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even

bhyve: bhyveload, bhyve, bhyvectl --destroy

I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

Hi Andriy, I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

Are you running -CURRENT, 10-STABLE, or 10.1? I think there was talk recently of removing the requirement to destroy the VM before running bhyveload again. That's been the case in 10.1/STABLE and CURRENT for quite a while (the original change was r267216). later, Peter.

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

On 02/06/2015 17:51, Peter Grehan wrote: Hi Andriy, I am very new to bhyve, so sorry if I am asking something silly or obvious. I am using bhyve to speed up my testing and it seems that each time I need to restart a VM I need to go through the cycle of destroying it with bhyvectl --destroy

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

of destroying it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once

Re: bhyve: bhyveload, bhyve, bhyvectl --destroy

it with bhyvectl --destroy, then re-loading a kernel with bhyveload and then actually booting the VM with bhyve. It seems that I have to do this even if I don't change th kernel between reboots. My first naive impression was that the point of bhyveload was to load the kernel once. Seems it ain't so

bhyvectl man page?

Can someone write a man page for this tool? I'm willing to do the formating if someone writes the text... Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.

Re: bhyvectl

Hi Andrea, I just throw away at least one hour because I was running bhyvectl destroy --vm=something instead of bhyvectl --destroy --vm=something. Bhyvectl just silently ignored the wrong destroy instead of --destroy. Maybe it's worth printing out something in such circumstances

bhyvectl

I just throw away at least one hour because I was running bhyvectl destroy --vm=something instead of bhyvectl --destroy --vm=something. Bhyvectl just silently ignored the wrong destroy instead of --destroy. Maybe it's worth printing out something in such circumstances??? :-) Thanks

Re: svn commit: r256072 - in head: lib/libvmmapi sys/amd64/amd64 sys/amd64/include sys/amd64/vmm sys/amd64/vmm/amd sys/amd64/vmm/intel sys/amd64/vmm/io usr.sbin/bhyve usr.sbin/bhyvectl usr.sbin/bhyvel

Hi Aryeh, A few questions on this commit and the ones Peter did yesterday: * Does this mean bhyve can now run recursively (using a guest as a host)? No. * If not what new functionality does this allow? Neel's commit allows demand-paging/swapping of guest memory i.e. overcommit, just

Re: svn commit: r256072 - in head: lib/libvmmapi sys/amd64/amd64 sys/amd64/include sys/amd64/vmm sys/amd64/vmm/amd sys/amd64/vmm/intel sys/amd64/vmm/io usr.sbin/bhyve usr.sbin/bhyvectl usr.sbin/bhyvel

A few questions on this commit and the ones Peter did yesterday: * Does this mean bhyve can now run recursively (using a guest as a host)? * If not what new functionality does this allow? * The new arg for allowing ahci cd's and disks allows for cd and disk host devices to be passed to the guest