https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250671
Robert Wing changed:
What|Removed |Added
Status|New |In Progress
CC|
: 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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250671
Peter Grehan changed:
What|Removed |Added
CC||gre...@freebsd.org
--- Comment #1 f
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
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 1
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 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046
Mateusz Piotrowski <0...@freebsd.org> changed:
What|Removed |Added
CC||0...@freebsd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046
Oleksandr Tymoshenko changed:
What|Removed |Added
CC||d...@freebsd.org
C
from Sean Bruno ---
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.
___
freebsd-virtualization@freebsd.org mailing list
https
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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046
Peter Grehan changed:
What|Removed |Added
CC||gre...@freebsd.org
--- Comment #2 f
from Sevan Janiyan ---
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.org mailing list
https://lists.freebsd.org/mailman
On Wed, Jun 3, 2015 at 9:18 AM, Andriy Gapon 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 things like bhyv
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 vm
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.
> >
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 t
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 if
gt;> 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
; 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
>> between r
g 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
>
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
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 des
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.
___
On 2015-06-02 07:20, Andriy Gapon wrote:
>
> 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
>
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 and
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
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."
__
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184046
Craig Rodrigues changed:
What|Removed |Added
CC||rodr...@freebsd.org
As
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 someth
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 cir
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 li
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 b
32 matches
Mail list logo
