Re: Debugging UEFI code in Bhyve
On Wed, Apr 3, 2019, 8:35 AM Rebecca Cran via freebsd-virtualization < freebsd-virtualization@freebsd.org wrote: > I was wondering, has anyone done any work on supporting debugging UEFI > code under Bhyve? If not, I can take a look at adapting DebugPkg > (https://code.bluestop.org/w/tianocore/debugging-with-gdb/). > > > > -- > Rebecca Cran > > > > ___ > 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" > Hi Rebecca, That would be super helpful, I did some debugs on edk2 in the past with virtio-scsi and virtio-nvme, it wasn't user friendly, mostly I needed to put edk2's printf all over the place and capture it via console to be able to debug boot issues with those two drivers. Would be great to have a debug method on edk2 and perhaps a howto with examples how to debug it. Best, > ___ 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"
Re: Updating uefi-edk2-bhyve
On Sat, Mar 30, 2019, 4:14 PM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net wrote: > > On 3/29/19 9:29 PM, Rodney W. Grimes wrote: > > > > > > That, iirc, would be the SMBIOS version of ed2k, which yes should > > > be updated if infact the newer ed2k has a new SBIOS implementation, > > > if it is still 1.00 implementaton then this needs to be left > > > alone. > > > > > > Under OVMF "smbiosview -t 0" shows: > > I do not know what the above is, could you elaborate for me? > What is OVMF and what is its relation to bhyve? > Mind blowing Hahahaha > > > > > Vendor: EFI Development Kit II / OVMF > > > > BiosVersion: 0.0.0 > > > > BiosReleaseDate: 02/06/2015 > > > > > > Whereas, we have: > > > > > > Vendor: BHYVE > > > > BiosVersion: 1.00 > > > > BiosReleaseDate: 03/14/2014 > > I have to assume this is with ed2k loaded, but I do not > know you are showing me the SMBIOS string value or some > other bios version value. THere are compliance levels > associated with SMBIOS. > > The SMBIOS versions must match what it is that is implemented, > and infact I have pending code in review that specifically > implements features as SMBIOS version 1.0, though I would > rather be implementing this in the newer SMBIOS spec (at least > 2. something and preferable 3.2, but as discsussed in email > with jgb that would require a complete audit and upgrade of > our current code to be at that spec level, a none trivial, > but worthwhile effort I defered for later. > > -- > 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" > ___ 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"
Re: Updating uefi-edk2-bhyve
Em sex, 22 de mar de 2019 às 08:45, D Scott Phillips < d.scott.phill...@intel.com> escreveu: > Hi freebsd-virtualization, > > Recently I wanted to be able to do UEFI HTTP Boot in bhyve, so I've > rebased the bhyve firmware up to the latest upstream tag, > edk2-stable201903. You can find the firmware here: > > > https://gitlab.com/scott-ph/edk2/tree/wip/2019-03/v2-bhyve-rebase-edk2-stable201903 > > and a ports patch to help with testing here: > > > https://gitlab.com/scott-ph/freebsd-ports/tree/wip/2019-03/v2-uefi-edk2-bhyve > > I've successfully run FreeBSD, Linux, and Windows with this firmware, > and of course HTTP Booting is working. If you're interested you can give > it a try, and I'd be glad to hear any reports of bugs you find with the > new firmware. Hopefully after some testing we can stabilize this and > push it as an update to the port. Thanks, > > Scott > ___ > 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" > This is a fantastic news!!! I think after more tests done by the community, you should make a PR to this repo: https://github.com/freebsd/uefi-edk2 and then I can update the ports. Well done job, thanks! -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: NVMe and Bhyve
If you have Nvme devices or you want store disks in ram yes, otherwise no. BR, On Tue, Feb 12, 2019, 9:05 PM Victor Sudakov Jason Tubnor wrote: > > > > > What's that disk0_type="nvme" thing? > > > > > > I'm curious. In 11.2-RELEASE there is nothing about nvme in bhyve(8). > > > Should I be running CURRENT or what? > > > > > > > > > > > It is valid on hosts 12.0-RELEASE and newer. > > Is it worth it? I mean upgrading from 11.2-RELEASE to 12.0-RELEASE for > the sake of nvme, is it useful for running FreeBSD, Linux (Mint, > Centos) and Windows10 guests? > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > 2:5005/49@fidonet http://vas.tomsk.ru/ > ___ 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"
Re: UEFI GOP: screen goes blank during boot after loader is finished
Hi, I have the same issue on FreeBSD-HEAD as host and with FreeBSD-HEAD as guest. Em sex, 16 de nov de 2018 às 03:10, Rebecca Cran via freebsd-virtualization escreveu: > On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote: > > > What is the ConOut evifar look like? We set serial when the UEFI env says > > to do so. > > Booting with: > > sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci- > cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s > 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait -l > bootrom,/usr/local/share/uefi- > firmware/BHYVE_UEFI.fd -u vm5 > > dh in the shell shows: > > 7D: ConsoleOut SimpleTextOut GraphicsOutput(GraphicsOutput) > PCIIO DevicePath(PciRoot (0x0)/Pci(0x1D,0x0)) > > 84: StdErr ConsoleOut ConsoleIn SimpleTextOut SimpleTextInEx SimpleTextIn > DevicePath(t(115200,8,N,1)/VenVt100Plus()) > > 89: SimpleTextOut SimpleTextInEx SimpleTextIn > DevicePath(Uart(115200,8,N,1)/ > VenPcAnsi()) > > -- > Rebecca > > > ___ > 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" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: bhyve on reboot loses tap(4) configuration
Em ter, 16 de out de 2018 às 00:06, Bjoern A. Zeeb < bzeeb-li...@lists.zabbadoz.net> escreveu: > Hi, > > I tried to use bhyve with the tap(4)/vtnet(4) solution as documented in > the handbook (tap needs autoopen). > However, I am using no bridge(4) interface but a “point-to-point” > configuration. > > Example: > guest configures vtnet0 to 192.0.2.2/24 > host configures tap0 to 192.0.2.1/24 > > When rebooting the guest inside the bhyve, it seems bhyve loses the > outside tap0 configuration. I assume that is because the tap0 interface > is closed and re-opened on the “warm restart”. > > Apart from using devd and possibly tracking tap interfaces to come up > and track things there, is there are better solution for not having to > reconfigure the host interface on every guest reboot? > Not sure if I understood well your case, but have you tried to set this sysctl: net.link.tap.up_on_open? Best, -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: on bhyve statistics
On Tue, Aug 28, 2018, 9:54 PM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Tue, Aug 28, 2018, 9:38 PM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > > >> Currently, bhyve does not expose any of these statistics. All the
> > > stats
> > > > > available through bhyvectl --get-stats seem to be coming from the
> VMM,
> > > > > not from the userspace emulation.
> > > >
> > > > >That is correct, byhvectl is a diagnostics tool for getting
> > > > information from the kernel/vmm module.
> > > >
> > > > bhyvectl provide stats related to processor vmx/svm from vmm.ko and
> is
> > > the
> > > > first thing you want to run for performance regression. It will be
> nice
> > > to
> > > > include it as part of bhyve perf tool/dashboard that you are
> intended to
> > > > build.
> > >
> > > From conversations with Peter Grehan he expressed that bhyvectl is
> > > purely a diagnostics tool that should not be depended on by any
> > > other tools.
> > >
> > > If you want to do similiar things you should program to the libvmmapi
> > > interface, not bhyvectl.
> > >
> >
> > The libvmmapi is more an internal library for usage with bhyvectl and
> > bhyveload than for other purposes, of course it won't stop anybody to
> > extend it to achieve other goals.
>
> That is not my understanding at all, libvmmapi is the external and
> stable/maintained interface to vmm.ko, it is not at all strickly
> for use by bhyvectl or bhyveload or bhyve.
>
You need something between userland and vmm.
>
> And as such this "api" should be very carefully maintained as
> it needs to be caried forward for ever.
>
I won't call it as an API provider as such you cannot do all operations
from creating to launch a guest!
> > > > -Anish
> > > >
> > > > On Mon, Aug 27, 2018 at 8:20 AM Rodney W. Grimes <
> > > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > > >
> > > > > > Hi list,
> > > > > >
> > > > > > I'm currently looking at getting the libvirt prometheus
> exporter[1]
> > > to
> > > > > > work with libvirt+bhyve. In its current state this doesn't work
> > > because
> > > > > > at least one of the API calls exposed by libvirt isn't
> implemented by
> > > > > > the libvirt bhyve driver - so I started looking at implementing
> it.
> > > > > >
> > > > > > The first API call in question is virDomainBlockStats[2], which
> > > returns
> > > > > > statistics (number of read and written bytes and ops,
> respectively).
> > > > > >
> > > > > > Currently, bhyve does not expose any of these statistics. All the
> > > stats
> > > > > > available through bhyvectl --get-stats seem to be coming from the
> > > VMM,
> > > > > > not from the userspace emulation.
> > > > >
> > > > > That is correct, byhvectl is a diagnostics tool for getting
> > > > > information from the kernel/vmm module.
> > > > >
> > > > > > OTOH, I did see that there are *some*
> > > > > > stats being collected in bhyverun.c (see struct bhyvestats {...}
> > > > > > stats;). I can't see how these are exposed though - a grep of
> > > /usr/src
> > > > > > turned up no other uses. Which brings me to the following
> questions:
> > > > > >
> > > > > > - are the stats in struct bhyvestats {...} stats exposed or used
> in
> > > any
> > > > > > non-obvious way?
> > > > >
> > > > > Not that I am aware of.
> > > > >
> > > > > > - architecturally, what would be the best ways to get stats out
> of
> > > the
> > > > > > user-space emulations? Off of the top of my head, I could
> think of
> > > the
> > > > > > following possibilities:
> > > > > > - prometheus exporter
> > > > > > - having some socket or pipe to request them
> > > > > > - DTrace probes
> > > > > >
> > > > > > I wouldn't mind implementing any of the above, and so would like
> to
> > > know
> > > > > > which of these (or other options) would be the most acceptable,
> and
> > > > > > would appreciate some guidance.
> > > > >
> > > > > I differ to others on what may be the best way to do this.
> > > > >
> > > > > > CC'ing novel@ for the libvirt side, and grehan@ for the
> > > architectural
> > > > > > bhyve questions.
> > > > >
> > > > > You should replace @grehan with @jhb,@tychon as Peter has moved on,
> > > > > and John and Tycho are now the bhyve maintainers. I was going to
> > > > > add them, and remove Peter, but I see no cc: anyway, so I am sure
> > > > > that they are on the virtualization list though.
> > > > >
> > > > > > Fabian
> > > > > >
> > > > > > [1] https://github.com/kumina/libvirt_exporter
> > > > > > [2]
> > > > >
> > >
> https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockStats
> > > > > --
> > > > > Rod Grimes
> > > > > rgri...@freebsd.org
> > >
> > > --
> > > 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 "
> > >
Re: on bhyve statistics
On Tue, Aug 28, 2018, 9:38 PM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > >> Currently, bhyve does not expose any of these statistics. All the
> stats
> > > available through bhyvectl --get-stats seem to be coming from the VMM,
> > > not from the userspace emulation.
> >
> > >That is correct, byhvectl is a diagnostics tool for getting
> > information from the kernel/vmm module.
> >
> > bhyvectl provide stats related to processor vmx/svm from vmm.ko and is
> the
> > first thing you want to run for performance regression. It will be nice
> to
> > include it as part of bhyve perf tool/dashboard that you are intended to
> > build.
>
> From conversations with Peter Grehan he expressed that bhyvectl is
> purely a diagnostics tool that should not be depended on by any
> other tools.
>
> If you want to do similiar things you should program to the libvmmapi
> interface, not bhyvectl.
>
The libvmmapi is more an internal library for usage with bhyvectl and
bhyveload than for other purposes, of course it won't stop anybody to
extend it to achieve other goals.
> > -Anish
> >
> > On Mon, Aug 27, 2018 at 8:20 AM Rodney W. Grimes <
> > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > > Hi list,
> > > >
> > > > I'm currently looking at getting the libvirt prometheus exporter[1]
> to
> > > > work with libvirt+bhyve. In its current state this doesn't work
> because
> > > > at least one of the API calls exposed by libvirt isn't implemented by
> > > > the libvirt bhyve driver - so I started looking at implementing it.
> > > >
> > > > The first API call in question is virDomainBlockStats[2], which
> returns
> > > > statistics (number of read and written bytes and ops, respectively).
> > > >
> > > > Currently, bhyve does not expose any of these statistics. All the
> stats
> > > > available through bhyvectl --get-stats seem to be coming from the
> VMM,
> > > > not from the userspace emulation.
> > >
> > > That is correct, byhvectl is a diagnostics tool for getting
> > > information from the kernel/vmm module.
> > >
> > > > OTOH, I did see that there are *some*
> > > > stats being collected in bhyverun.c (see struct bhyvestats {...}
> > > > stats;). I can't see how these are exposed though - a grep of
> /usr/src
> > > > turned up no other uses. Which brings me to the following questions:
> > > >
> > > > - are the stats in struct bhyvestats {...} stats exposed or used in
> any
> > > > non-obvious way?
> > >
> > > Not that I am aware of.
> > >
> > > > - architecturally, what would be the best ways to get stats out of
> the
> > > > user-space emulations? Off of the top of my head, I could think of
> the
> > > > following possibilities:
> > > > - prometheus exporter
> > > > - having some socket or pipe to request them
> > > > - DTrace probes
> > > >
> > > > I wouldn't mind implementing any of the above, and so would like to
> know
> > > > which of these (or other options) would be the most acceptable, and
> > > > would appreciate some guidance.
> > >
> > > I differ to others on what may be the best way to do this.
> > >
> > > > CC'ing novel@ for the libvirt side, and grehan@ for the
> architectural
> > > > bhyve questions.
> > >
> > > You should replace @grehan with @jhb,@tychon as Peter has moved on,
> > > and John and Tycho are now the bhyve maintainers. I was going to
> > > add them, and remove Peter, but I see no cc: anyway, so I am sure
> > > that they are on the virtualization list though.
> > >
> > > > Fabian
> > > >
> > > > [1] https://github.com/kumina/libvirt_exporter
> > > > [2]
> > >
> https://libvirt.org/html/libvirt-libvirt-domain.html#virDomainBlockStats
> > > --
> > > Rod Grimes
> > > rgri...@freebsd.org
>
> --
> 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"
>
___
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"
Re: on bhyve statistics
Hi Fabian,
2018-08-27 22:14 GMT+08:00 Fabian Freyer
:
> Hi list,
>
> I'm currently looking at getting the libvirt prometheus exporter[1] to
> work with libvirt+bhyve. In its current state this doesn't work because
> at least one of the API calls exposed by libvirt isn't implemented by
> the libvirt bhyve driver - so I started looking at implementing it.
>
> The first API call in question is virDomainBlockStats[2], which returns
> statistics (number of read and written bytes and ops, respectively).
>
> Currently, bhyve does not expose any of these statistics. All the stats
> available through bhyvectl --get-stats seem to be coming from the VMM,
> not from the userspace emulation. OTOH, I did see that there are *some*
> stats being collected in bhyverun.c (see struct bhyvestats {...}
> stats;). I can't see how these are exposed though - a grep of /usr/src
> turned up no other uses. Which brings me to the following questions:
>
> - are the stats in struct bhyvestats {...} stats exposed or used in any
> non-obvious way?
>
They are most used inside bhyverun by the name "stats" and the purpose is
not really to collect statistics about the guest vm.
>
> - architecturally, what would be the best ways to get stats out of the
> user-space emulations? Off of the top of my head, I could think of the
> following possibilities:
> - prometheus exporter
> - having some socket or pipe to request them
> - DTrace probes
>
I don't know what kind of stats do you need to collect, but based on the
assumptions you listed above, maybe you can take a look at this project:
https://github.com/freenas/bhyve-vm-goagent
bhyve-vm-goagent can easily be extended to collect other information from
guest. Although I'm not sure if it will be useful for your case, looks like
you are looking for something less intrusive than bhyve-vm-goagent.
>
> I wouldn't mind implementing any of the above, and so would like to know
> which of these (or other options) would be the most acceptable, and
> would appreciate some guidance.
>
> CC'ing novel@ for the libvirt side, and grehan@ for the architectural
> bhyve questions.
>
> Fabian
>
> [1] https://github.com/kumina/libvirt_exporter
> [2] https://libvirt.org/html/libvirt-libvirt-domain.html#
> virDomainBlockStats
> ___
> 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"
>
--
--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^
Power To Server. .\. /_)
___
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"
Re: Checking bhyve supported features (sysctls)
2018-08-17 0:07 GMT+08:00 Fabian Freyer : > On 16 Aug 2018, at 12:16, Matt Churchyard wrote: > >> I'm looking for better ways to check for bhyve support / available >> features without trying to scan through dmesg output. >> > > There’s a few patches floating around for checking features [1,2] - > however none of these are yet committed. > For [2], there’s also an RFC mailing list thread [3]. > > CC’ing novel@, as he wrote those patches. > > The hackish way libvirt checks for features right now is to parse error > messages from invalid invocations of bhyve(8). > Hi, I have committed r338210 the solution [1] that seemed to be the simplest one comparing with [2]. Thank you and novel@ to keep working on bhyve libvirt support, appreciate it. Best, > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210111 > [2] https://reviews.freebsd.org/D15992 > [3] https://lists.freebsd.org/pipermail/freebsd-virtualization/ > 2018-June/006536.html > > ___ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubs > cr...@freebsd.org" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: Checking bhyve supported features (sysctls)
want to maintain full compatibility a similiar stratergy may
> > >be in order.
> > >
> > >Why is it that vm-bhyve specifically needs to know if the kernel has
> > >vmm support or not?
> > >Cant it just be written to handle the errors returned if the
> > >supported functions do not exist?
> >
> > I think the question vm-bhyve wants to answer is: does the CPU have
> > the required features to run a multicore VM.
>
> >Why does it need to know that? If it tries to start a multicore/thread
> VM and the system can not support it an error is returned and the bhyve
> command fails.
>
> >Actually determining that specific issue is non-trivial iirc as some vmm
> supported CPU's can only run a single VM with a single thread in that VM
> (early core cpu's).
>
> >
> > These or similar sysctls do seem to be the correct way to communicate
> > that support.
>
> >I do not believe any of those sysctl's communicate that your on a broken
> cpu or to what extent you can run vm's with multiple threads.
>
> So cap.unrestricted_guest from the vmm "capabilities" set of sysctls is
> not a valid way to determine if the host has unrestricted guest support
> (required for non-freebsd or multicore freebsd guests, and as you say
> missing from some early VT-x capable processors)?
>
> >I went and looked at why vm-bhyve is groveling around in
> /var/run/dmesg.boot and found that it is simply trying to determine if the
> host CPU is vmm capable,
> >specifically:
> >util::check_bhyve_support(){
> >...
>
> >These checks are already built into the kernel.
> >This can all go in the bit bucket, if you try to start a VM on an
> unsupported system an error is returned, recoding this in shell is just
> setting yourself up for "future" bugs.
>
> The kernel knows what features are supported but does not expose these, so
> all I can do is similar to libvirt and run bhyve with different options to
> see what errors pop up.
> I think I'll just remove all checking for now and let users discover the
> issue for themselves if bhyve won't run. Hopefully the vmx.initialized /
> cap.* sysctls will at some point become a defined way of seeing if vmm is
> ready / testing for vmm features, as apparently these serve no purpose at
> the moment.
>
> Matt
>
> ___
> 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"
>
>
>
> >This is something that is in my long to-do list, I will try to get back
> to this in couple weeks.
>
> >I think the way how you are dealing with it nowadays is the best way to
> try to discover the CPU capabilities, better in this way than let the users
> blind.
>
> >Best,
>
> Thanks Marcelo,
>
>
>
> It’s not exactly critical. I just saw another project using
> vmx.initialized and it seemed a much cleaner way to determine support by
> seeing if vmm loads rather than probing log files. I asked here expecting
> someone to just say “yes if that’s 1 then the host will run guests”, or “no
> you can’t tell if guests will run just by that sysctl”.
>
>
>
> Matt
>
Could you share with me what project is using vmx.initialized?
Best,
--
--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^
Power To Server. .\. /_)
___
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"
Re: Checking bhyve supported features (sysctls)
er.
> > >
> > >Why is it that vm-bhyve specifically needs to know if the kernel has
> > >vmm support or not?
> > >Cant it just be written to handle the errors returned if the
> > >supported functions do not exist?
> >
> > I think the question vm-bhyve wants to answer is: does the CPU have
> > the required features to run a multicore VM.
>
> >Why does it need to know that? If it tries to start a multicore/thread
> VM and the system can not support it an error is returned and the bhyve
> command fails.
>
> >Actually determining that specific issue is non-trivial iirc as some vmm
> supported CPU's can only run a single VM with a single thread in that VM
> (early core cpu's).
>
> >
> > These or similar sysctls do seem to be the correct way to communicate
> > that support.
>
> >I do not believe any of those sysctl's communicate that your on a broken
> cpu or to what extent you can run vm's with multiple threads.
>
> So cap.unrestricted_guest from the vmm "capabilities" set of sysctls is
> not a valid way to determine if the host has unrestricted guest support
> (required for non-freebsd or multicore freebsd guests, and as you say
> missing from some early VT-x capable processors)?
>
> >I went and looked at why vm-bhyve is groveling around in
> /var/run/dmesg.boot and found that it is simply trying to determine if the
> host CPU is vmm capable,
> >specifically:
> >util::check_bhyve_support(){
> >...
>
> >These checks are already built into the kernel.
> >This can all go in the bit bucket, if you try to start a VM on an
> unsupported system an error is returned, recoding this in shell is just
> setting yourself up for "future" bugs.
>
> The kernel knows what features are supported but does not expose these, so
> all I can do is similar to libvirt and run bhyve with different options to
> see what errors pop up.
> I think I'll just remove all checking for now and let users discover the
> issue for themselves if bhyve won't run. Hopefully the vmx.initialized /
> cap.* sysctls will at some point become a defined way of seeing if vmm is
> ready / testing for vmm features, as apparently these serve no purpose at
> the moment.
>
> Matt
> ___
> 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"
>
This is something that is in my long to-do list, I will try to get back to
this in couple weeks.
I think the way how you are dealing with it nowadays is the best way to try
to discover the CPU capabilities, better in this way than let the users
blind.
Best,
--
--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^
Power To Server. .\. /_)
___
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"
Re: Checking bhyve supported features (sysctls)
2018-08-17 0:53 GMT+08:00 Allan Jude : > On August 16, 2018 5:28:05 PM GMT+01:00, "Rodney W. Grimes" < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > >> > >> Text manually wrapped to 80, any broken quoting is my fault - rwg > >> > >> > > Hello, > >> > > > >> > > I'm looking for better ways to check for bhyve support / > >available > >> > > features without trying to scan through dmesg output. > >> > > >> > >Yes, it would be very good to remove that, as it usually tries > >> > >to grep a non-existent file /var/run/dmesg.boot that is not > >> > >created until after vm_bhyve has been called from > >/usr/local/etc/rc.d > >> > >when you have things set to autostartup >in /etc/rc.conf > >> > > >> > > >> > > > >> > > I notice that the following 2 sysctl's appear to be set to 1 as > >soon > >> > > as the vmm module is loaded > >> > > > >> > > hw.vmm.vmx.initialized: 1 > >> > > hw.vmm.vmx.cap.unrestricted_guest: 1 > >> > > > >> > > Will these be available on both Intel & AMD processors as a way > >> > > to determine if the module has loaded successfully and can run > >guests? > >> > > > >> > > I also see the below sysctl related to iommu. > >> > > > >> > > hw.vmm.iommu.initialized > >> > > > >> > > Again, will this be set to 1 as soon as the module is loaded if > >> > > iommu is supported, or only when it is used? > >> > > There also seems to be a vmm.amdvi.enable sysctl. > >> > > Would both these need checking or is vmm.iommu enough to > >> > > determine support on any processor. > >> > > >> > >Probalby the safest way for a shell script to decide if bhyve is > >> > >up and running is to stat /dev/vmm, if that exists then the > >modules > >> > >have loaded and initialized and bhyve should be ready to process > >guests. > >> > > >> > Hmm, I don't get /dev/vmm unless I actually have running guests. > >> > >> I'll investigate that, I was pretty sure that you should get this > >> as soon as the vmm.ko module is finished initialzing, but you might > >> be right in that it takes a first vm to cause its creation. > >> Confirmed, /dev/vmm does not exist until the first vm > >> is created. > >> > >> > > >> > >sysctl's mentiond above would be a poor way to make this > >determination. > >> > > >> > It would be nice if sysctls were better documented. > >> > >> Agreed. > >> > >> > If vmx.initialized is set once vmm has successfully loaded, I can't > >see a better way of checking for bhyve support (assuming it's not Intel > >specific). This entry definitely exists and is set to 0 if you load the > >module on a non-supported system, and set to 1 as soon as vmm loads on > >my Intel test system. > >> > >> Given its undocumented status you would be relying on an > >> undocumented feature that could change in either name or > >> behavior, and that is not desirable. > >> > >> Let me see if I can come up with something else. > > > >I looked at the code for bhyvectl, bhyveload and > >byhve. They do not actually try to decide if vmm > >is supported or not, they simply process the error > >from a vm_create() or vm_open() call and exit > >with an error code if they can not handle it > >(some of the code can handle a vm_create failure > >if infact we are trying to create a vm that > >already exists). > > > >If you want to maintain full compatibility a similiar > >stratergy may be in order. > > > >Why is it that vm-bhyve specifically needs to know > >if the kernel has vmm support or not? > >Cant it just be written to handle the errors returned > >if the supported functions do not exist? > > I think the question vm-bhyve wants to answer is: does the CPU have the > required features to run a multicore VM. > > These or similar sysctls do seem to be the correct way to communicate that > support. > You are correct! The question in case as I understood was about CPU feature supported, actually vmm(8) knows all this information! Some examples such like CPU with VMX unrestricted mode support (UG) that is necessary for guest VMs running with multiple vCPU or like VT-d necessary for
Re: RFC: bhyve supported features reporting
Hi Roman,
I think it is doable, my only concern is the complexity and
maintainability, as along the way we will add more devices and would be
nice to have something transparent for those additions or at least
something easy to be extended.
As an example this patch that you made:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210111
It has much less complexity, and seemed for me to be much easier to
maintain, however doesn't give us a detailed information like the latest
one you are proposing, I'm not sure if we really need so extensive details,
I didn't see any bhyve device changing its options along the past years,
but that doesn't means it would not in the future.
I do believe if we remove the complexity or at least makes it easy to be
extend, IMHO it is a good idea.
Best,
2018-06-24 18:13 GMT+08:00 Roman Bogorodskiy :
> Bhyve evolves over time, and new features get added, such as new
> devices support, new guest configurations and so on. However, it's not
> really straight-forward to figure out what features a given bhyve binary
> supports. This makes it harder to develop tools on top of bhyve,
> specifically error reporting.
>
> For example, libvirt's bhyve driver [1] probes bhyve capabilities [2]
> using:
>
> * Running 'bhyve -h' and parsing output,
> * For detecting devices, it runs 'bhyve -s 0,dev' and parses error
>output to see if the device is supported.
>
> It's not very effective because 'bhyve' binary has to be executed
> multiple times just to check things. Additionally, it's harder to check
> things on a deeper level, e.g. specific device parameters. Also, this is
> error-prone because help output generally is not designed for
> machine-parsing, and this could easily break on slight formatting
> change.
>
> I would like to discuss introducing a general way of reporting features
> bhyve supports. To start a discussion, I've created a simple draft/PoC
> which adds '-f' (as for features) command line switch to bhyve. This
> switch makes bhyve print its supported features. I'll use JSON as
> example, however, as it's done using libxo, XML is also supported.
> Example JSON output with inline comments below:
>
> "bhyve": {
>
> // 'features' schema version using the common versioning pattern:
> //major version increments on incompatible changes,
> //minor version increments on compatible changes (extensions).
> "schema_version": "1.0",
>
> // there could also go some general properties like max_cpus etc
>
> // list of specific features, mostly should be self-descriptive
> "features": {
> "rtc_utc": {
> "description": "RTC keeps UTC time",
> "cmd": {
> "switch": "-u"
> }
> },
> "wire_guest_memory": {
> "description": "Wire guest memory",
> "cmd": {
> "switch": "-S"
> }
> },
> "devices": {
> "description": "Devices support",
> "cmd": {
> "switch": "-s",
> "arguments": [
>
> // Probably, it'd be better to make this more
> organized,
> // e.g. instead of a string with all arguments and
> arg/value paris,
> // use a list of objects which would include
> possible values,
> // required/optional, etc
>
> {"options": "virtio-net,tapN,mac=xx:xx:xx:xx:xx:xx",
>"description": "Virtio network device"
> },
> {"options": "virtio-blk,path,nocache,
> direct,ro,sectorsize=logical/physical",
>"description": "Virtio block device"
> },
> {"options": "fbuf,rfb,rfb=IP:port,w=width,
> h=heigh,vga=vgaconf,wait,password=password",
> "description": "Framebuffer device"
> }
>]
> }
> }
> }
> }
>
> Sample code is here: https://reviews.freebsd.org/D15992. At this point
> it's just an excuse to start a discussion; it needs some macros to make
> items creation easier, and it needs to have all the other
> features/devices populated.
>
> 1: https://libvirt.org/drvbhyve.html
> 2:
> https://github.com/libvirt/libvirt/blob/master/src/bhyve/
> bhyve_capabilities.c
>
> Roman Bogorodskiy
>
--
--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^
Power To Server. .\. /_)
___
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"
Re: Trouble getting OpenBSD running on bhyve
Hi Christian, 2018-06-14 17:25 GMT+08:00 Christian Stærk : > Hi, > I'm trying to get OpenBSD running on bhyve, but am not getting very far. > > I am trying with the following command line: > > /usr/sbin/bhyve -c 1 -m 1G -w -H -s 0,amd_hostbridge -s > 4,ahci-hd,/home/xi/leech/install63.fs -s 5,ahci-hd,disk.img -s > 6,virtio-net,tap2 -s 29,fbuf,tcp=0.0.0.0:5901,w=800,h=600,wait -s 31,lpc > -l com1,stdio -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd > vulcan > I didn't try recently the latest OpenBSD version, I will give a try tomorrow. But I would like to point you out to this page in case you don't know about it: https://wiki.freebsd.org/bhyve/OpenBSD > > I see the boot loader, and then the following output: > > cannot open hd0a:/etc/random.seed: No such file or directory > booting hd0a:/6.3/amd64/bsd.rd: 3418091+1467392+3891704+0+598016 > [363465+90+433440+288010]=0x9fc160 > entry point at 0xf000158 > > Then after a few seconds, bhyve exits. > > I have run "bhyvectl --get-all" for the vm when it has reached this state, > and the output is here: > https://borderworlds.dk/~xi/bhyve-get-all-vulcan.txt > > Any suggestions? > > Best regards > Christian > > ___ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubs > cr...@freebsd.org" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: ARMv8 development board with GICv3
2018-06-13 14:54 GMT+08:00 Alexandru Elisei : > Hello, > > I have been working on porting bhyve to ARMv8 and the hypervisor is > able to successfully boot a FreeBSD virtual machine on the Foundation > Emulator provided by ARM. > > I plan to submit the project for review, but before that I need to > validate the hypervisor on a hardware platform. > > Can anyone be so kind as to recommend a development board for testing? > The board needs to have an ARMv8 CPU with virtualization extensions > implemented (Exception Level 2 needs to be available) and a GIC > version 3 compliant interrupt controller. > > Thank you, > Alexandru Elisei > ___ > 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" > Hello Alexandru, Excited to see your work! I have Cc manu@ as I know he works a lot with embedded devices and probably he can give you some suggestions. I'm sure he is on freebsd-arm@ mailing list, but even though I'm Cc'ing him. Best, -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: pci_virtio_block.c Assertion failed: line 216
2018-06-01 17:38 GMT+08:00 Harry Schmalzbauer :
> Am 15.11.2017 um 15:19 schrieb Harry Schmalzbauer:
>
>> Bezüglich Peter Grehan's Nachricht vom 03.01.2017 20:36 (localtime):
>>
>>> Hi Harry,
>>>
>>> trying to use bhyve(8) with virtio-blk and Windows guest results in core
>>>> dump:
>>>> Assertion failed: (n >= 2 && n <= BLOCKIF_IOV_MAX + 2), function
>>>> pci_vtblk_proc, file usr.sbin/bhyve/pci_virtio_block.c, line
>>>> 216.
>>>> Abort trap (core dumped)
>>>>
>>>> Unfortunately this is on a production-test machine which lacks gdb etc.
>>>> Will try to reproduce on antoher machine, but maybe someone already
>>>> knows that problem?
>>>>
>>> virtio-blk isn't currently supported with Windows guests. You'll need
>>> to use ahci-hd for now.
>>>
>>> However, I do have a fix that can hopefully be committed shortly.
>>>
>> …
>>
>> Mising in another reply:
>>
>> Wiadomość napisana przez Harry Schmalzbauer >>> <mailto:free...@omnilan.de>> w dniu 03.01.2017, o godz. 20:33:
>>>>
>>> …
>>
>>> Will try to reproduce on antoher machine, but maybe someone already
>>>> knows that problem?
>>>>
>>> I've seen that problem and fixed it, will upstream the patch later today.
>>>
>>> JFYI, fixing
>>> commit:
>>>
>> https://github.com/freenas/os/commit/0e4d6e1826f8aa7041cbeeb
>> 4365c797eeec5c5f4
>>
>> Thanks Jakub for the info.
>>
>> I can confirm that increasing BLOCKIF_IOV_MAX from 33 to 128, like the
>> diff shows, solved the problem for me.
>> I've successfully done some performace tests on Windows7 (virtio-blk vs.
>> ahci,hd:) and also migrated one Server 2012R2 to bhyve using virtio-blk.
>>
>> Peter, is your mentioned fix different from just increasing
>> BLOCKIF_IOV_MAX?
>> If not, would you commit that please?
>>
>
> I hope that I don't bug people knowing better, but this simple diff makes
> virtio-blk usable for Windows 7.
> Is there any reason not to commit?
>
There were some discussion[0] about this possible fix, but seems the fix is
not that so simple.
I got distracted with other things and I didn't further investigated this
issue.
Maybe Peter has something news about this issue.
[0] https://reviews.freebsd.org/D10581
Best,
>
> Index: src/usr.sbin/bhyve/block_if.h
> ===
> --- usr.sbin/bhyve/block_if.h (Revision 325745)
> +++ usr.sbin/bhyve/block_if.h (Arbeitskopie)
> @@ -39,7 +39,7 @@
> #include
> #include
>
> -#define BLOCKIF_IOV_MAX 33 /* not practical to be
> IOV_MAX */
> +#define BLOCKIF_IOV_MAX128 /* not practical to be
> IOV_MAX */
>
> struct blockif_req {
> struct iovecbr_iov[BLOCKIF_IOV_MAX];
>
>
> Thanks,
>
> -harry
> ___
> freebsd-virtualization@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to "freebsd-virtualization-unsubs
> cr...@freebsd.org"
>
--
--
Marcelo Araujo(__)ara...@freebsd.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^
Power To Server. .\. /_)
___
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"
Re: Issue encountered booting FreeBSD STABLE and CURRENT snapshots with EFI
2018-03-16 9:55 GMT+08:00 Kyle Evans <kev...@freebsd.org>: > On Thu, Mar 15, 2018 at 8:46 PM, Marcelo Araujo <araujobsdp...@gmail.com> > wrote: > > > > > > 2018-03-16 7:07 GMT+08:00 Kyle Evans <kev...@freebsd.org>: > >> > >> On Thu, Mar 15, 2018 at 5:01 PM, Kyle Evans <kev...@freebsd.org> wrote: > >> > On Thu, Mar 15, 2018 at 4:09 PM, Peter Grehan <gre...@freebsd.org> > >> > wrote: > >> >>> I believe the problem may have been introduced with this commit: > > > >> >>> https://svnweb.freebsd.org/base/stable/?view=log=329114 > >> >> > >> >> Any chance of being able to work out where in that list of commits > in > >> >> CURRENT the loader stopped working ? > >> >> > >> > > >> > Indeed- if you could work out the exact commit in that range from head > >> > that caused it, I wouldn't think it to be a tough fix. After tonight > >> > I'm out until Sunday, but should have time Sunday or Monday to try and > >> > diagnose it further. > >> > >> Can one of you try this with boot1.efi+loader.efi built from today's > >> head stand/? I'm not sure what I'm expecting here since these are > >> among my first times trying bhyve, but this is what I'm seeing now > >> (vs. from the mentioned head snapshot where I noted similar behavior > >> as originally mentioned): > >> > >> 1.) Get to loader.efi, menu is good > >> 2.) Break into loader prompt > >> 3.) `lsdev`- pager is restricted to the line the prompt is on, so the > >> output is useless > >> 4.) `boot` > >> 5.) "Unhandled ps2 mouse command 0xe1" > >> > >> At this point, the boot looks screwed until I VNC into it- it booted > >> fine here, but the console stopped working after the kernel handoff. > >> > >> Thanks, > >> > >> Kyle Evans > >> ___ > >> 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" > > > > > > Hi Kyle, > > > > I will do that today and report back as soon as I have something. > > > > Thanks! If it's still failing, I think capturing the output of "lsdev" > and "show currdev" prior to a failed boot might be most helpful just > to make sure there's not something obviously sketchy happening. > Hi, I think we had two bad snapshots! I just finished the tests with HEAD and 11-STABLE latest snapshots: 1) HEAD: FreeBSD-12.0-CURRENT-amd64-20180315-r331001-disc1.iso 2) Stable: FreeBSD-11.1-STABLE-amd64-20180315-r330998-bootonly.iso I have installed it using ZFS and tested using AHCI and virtio-blk. So everything worked fine. Seems those broken snapshots have missed some commits related with EFI. Thank you all. -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: Issue encountered booting FreeBSD STABLE and CURRENT snapshots with EFI
2018-03-16 7:07 GMT+08:00 Kyle Evans <kev...@freebsd.org>: > On Thu, Mar 15, 2018 at 5:01 PM, Kyle Evans <kev...@freebsd.org> wrote: > > On Thu, Mar 15, 2018 at 4:09 PM, Peter Grehan <gre...@freebsd.org> > wrote: > >>> I believe the problem may have been introduced with this commit: > > > >>> https://svnweb.freebsd.org/base/stable/?view=log=329114 > >> > >> Any chance of being able to work out where in that list of commits in > >> CURRENT the loader stopped working ? > >> > > > > Indeed- if you could work out the exact commit in that range from head > > that caused it, I wouldn't think it to be a tough fix. After tonight > > I'm out until Sunday, but should have time Sunday or Monday to try and > > diagnose it further. > > Can one of you try this with boot1.efi+loader.efi built from today's > head stand/? I'm not sure what I'm expecting here since these are > among my first times trying bhyve, but this is what I'm seeing now > (vs. from the mentioned head snapshot where I noted similar behavior > as originally mentioned): > > 1.) Get to loader.efi, menu is good > 2.) Break into loader prompt > 3.) `lsdev`- pager is restricted to the line the prompt is on, so the > output is useless > 4.) `boot` > 5.) "Unhandled ps2 mouse command 0xe1" > > At this point, the boot looks screwed until I VNC into it- it booted > fine here, but the console stopped working after the kernel handoff. > > Thanks, > > Kyle Evans > ___ > 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" > Hi Kyle, I will do that today and report back as soon as I have something. Best, -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: Question about bhyve
Hi, You can give a try using devel/libhyve-remote, it is a VNC server based on libvncserver, clipboard works there. Best, 2018-01-12 10:13 GMT+08:00 Paul Webster via freebsd-virtualization < freebsd-virtualization@freebsd.org>: > I believe if you used TightVNC server on the windows box and the likewise > client on freebsd you can sync clipboards over it > > On 12 January 2018 at 01:51, Manish Jain <bourne.ident...@hotmail.com> > wrote: > > > Hi, > > > > I have a Win 10 vm under bhyve on my FreeBSD 11.1 box. Is there some way > > I can share clipboards between FreeBSD X and Windows ? > > > > Thanks for any help. > > -- > > Manish Jain > > ___ > > 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" > > > ___ > 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" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: bhyve uses all available memory during IO-intensive operations
2017-12-01 17:53 GMT+08:00 Shane Ambler <free...@shaneware.biz>: > On 01/12/2017 13:43, Allan Jude wrote: > > On 2017-11-30 22:10, Dustin Wenz wrote: > >> I am using a zvol as the storage for the VM, and I do not have any ARC > >> limits set. However, the bhyve process itself ends up grabbing the vast > >> majority of memory. > >> > >> I’ll run a test tomorrow to get the exact output from top. > >> > >>   - .Dustin > >> > >> On Nov 30, 2017, at 5:28 PM, Allan Jude <allanj...@freebsd.org > >> <mailto:allanj...@freebsd.org>> wrote: > >> > >>> On 11/30/2017 18:15, Dustin Wenz wrote: > >>>> I'm using chyves on FreeBSD 11.1 RELEASE to manage a few VMs (guest > >>>> OS is also FreeBSD 11.1). Their sole purpose is to house some > >>>> medium-sized Postgres databases (100-200GB). The host system has 64GB > >>>> of real memory and 112GB of swap. I have configured each guest to > >>>> only use 16GB of memory, yet while doing my initial database imports > >>>> in the VMs, bhyve will quickly grow to use all available system > >>>> memory and then be killed by the kernel: > >>>> > >>>>   kernel: swap_pager: I/O error - pageout failed; blkno 1735,size > >>>> 4096, error 12 > >>>>   kernel: swap_pager: I/O error - pageout failed; blkno 1610,size > >>>> 4096, error 12 > >>>>   kernel: swap_pager: I/O error - pageout failed; blkno 1763,size > >>>> 4096, error 12 > >>>>   kernel: pid 41123 (bhyve), uid 0, was killed: out of swap space > > That's the type of errors I see when wired jumps high. I'm not seeing > this from bhyve but when your watching top, keep an eye on the wired > amount. > > -- > FreeBSD - the place to B...Sharing Devices > > Shane Ambler > > ___ > 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" > As Allan said, it is likely to be your ARC cache holding memory and unfortunately right now all these swap out doesn't play well with the combination of zfs + bhyve. Try to tune your vfs.zfs.arc_max to a minimum where you give memory space enough to your VM. What I'm doing now is, launch a VM get the amount of memory and remove it from vfs.zfs.arc_max, as soon as the VM stops, I give the memory back to vfs.zfs.arc_max. Best, -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: VNC and non-US keymap in bhyve
Hi all, I'm the one working on this patch! What happened is, I first always try to bring the changes first on FreeBSD[1] and then to FreeNAS/TrueNAS/TrueOS, but after waiting for a while for reviews and etc on FreeBSD; I could not do the same on FreeNAS/TrueNAS side, lots of people opened tickets and I needed to handle it properly, so yes, unfortunately there is this patch on FreeNAS/TrueNAS/TrueOS and not yet on FreeBSD. There are few things that need to be fixed to let us include this patch officially on bhyve, but I spent lots of time to create libhyve-remote + bhyve patch + tests with different OSS; that I'm afraid I can't spend again any more time on it. I'm a bit overloaded with work, but I will try. What you can do for now is: Install devel/libhyve-remote and choose BHYVE at port configuration (you can do make config inside the port) it will apply the patch that is under review[1] and will rebuild your bhyve. To use bhyve with libvncserver you just need to add vncserver at the same line of fbuf, such like: -s 2,fbuf,tcp=0.0.0.0:5937,w=800,h=600,password=1234567,*vncserver*,wait Any doubt or suggestion, just ping me back! And sorry for the confusion about this topic. [1] https://reviews.freebsd.org/D11768 2017-11-05 4:53 GMT+08:00 Farid Joubbi <djfa...@gmail.com>: > Thanks for the reply! > > I'm running 11.1 Release. The fix is not there yet at least. > > I read the whole bug report and understood that he was involved on both > sides. > My question was a bit more general about the changes coming from FreeNAS to > FreeBSD and the other way around. > > Is there a way for me to see when this particular change, or some other > change that I might be interested about in the future will be available in > FreeBSD release, stable or current? > > > On Sat, Nov 4, 2017 at 6:42 PM, Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > Hello, > > > > > > I use bhyve and have a problem with non-US keymap and the VNC server. > > > This is a bug that was reported at least to FreeNAS and was fixed a few > > > weeks ago according to the bug report here: > > > https://bugs.freenas.org/issues/24450 > > > > > > When will this fix come into FreeBSD? > > > How does the process work for changes into FreeNAS and then into > FreeBSD? > > > > For this specific instance Marcelo, the person working the bug from the > > FreeNAS side, is also a member of the FreeBSD developers group working > > on bhyve so he tends to make sure his fixes get brought over. > > > > > > > Or is it that the change was first made into FreeBSD and then from > there > > > found its way into FreeNAS? > > > > I am unclear in this case, but from reading the full text of the > > bugs.freenas.org report it is clear that he is working on both > > FreeBSD and FreeNAS to resolve the issue. > > > > > I could not find this information anywhere other than that FreeNAS is > > based > > > on FreeBSD. > > > > I think if you read the bug report carefully you should find the > > following text excerpt: > > -- begin excerpt -- > > > > Updated by Marcelo Araujo 5 months ago > > > > Priority changed from No priority to Important > > Status changed from Unscreened to Investigation > > Target version set to 49 > > > > Hi all, > > > > It is a know issue with bhyve, I'm working to import libvncserver to > > replace the current implementation of rfb on FreeBSD. It will take a bit > of > > time as I need first commit it on FreeBSD and then merge it to FreeNAS. > > > > The process to commit on FreeBSD can take a bit of time, because we have > a > > review process and a merge process as well. > > > > But I will keep you guys updated about my progress. > > > > Best, > > -- end excerpt -- > > -- begin excerpt -- > > Updated by Marcelo Araujo about 1 month ago > > > > Target version changed from 11.2 to 11.1 > > Status changed from Fix In Progress to Ready For Release > > > > I added libhyve-remote and all the bits necessary to improve VNC server. > > Python bits were reviewed by williamgr and C bits by kris. > > -- begin excerpt -- > > > > In this second one 11.2 and 11.1 are refering to FreeBSD releases, > > I do believe this is fixed in FreeBSD 11.1. > > > > -- > > 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" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
Re: VNC stuff
Hi Zane, Are you talking about the authentication? If yes, probably it will land there right after the RELEASE. Br, 2017-06-12 17:16 GMT+08:00 Zane C. B-H. <vve...@vvelox.net>: > Any idea when the RFB/VNC stuff is going to be hitting 11-STABLE if ever? > ___ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to "freebsd-virtualization-unsubs > cr...@freebsd.org" > -- -- Marcelo Araujo(__)ara...@freebsd.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) ___ 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"
