Re: nbdkit on FreeBSD
On Wed, Jun 17, 2020 at 9:53 PM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > Does anybody use nbdkit on FreeBSD? It's a fancy NBD (Network Block > > Device) server. It runs fine on FreeBSD, but there's no port. If > anybody > > is interested, I'll make a port for it. However, if I'm the only one > then > > I won't bother. > > > > https://github.com/libguestfs/nbdkit/ > > I am not sure if this is what I looked at, but I was looking > for a way to do old style sun "nd", and this looks to be 1/2 > of that, in that I see a server, but no client for the kernel. > > I would be interested in NBD if we have both ends. > There's lots of 'other ends' including qemu for this. This is really cool! Warner ___ 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
On Thu, Nov 15, 2018 at 12:10 PM Rebecca Cran wrote: > 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()) > If I read that right, then the ConOut variable first has the video device listed, then the serial port (this wasn't the form I expected to see it in, so I'm not sure thats the case). In either event, we should get console output on both the serial and the video at least until the /etc/rc script starts... Warner ___ 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
On Wed, Nov 14, 2018 at 4:00 PM Kyle Evans wrote: > On Wed, Nov 14, 2018 at 4:55 PM Subbsd wrote: > > > > On Thu, Nov 15, 2018 at 1:33 AM Kyle Evans wrote: > > > > > > On Wed, Nov 14, 2018 at 4:30 PM Kyle Evans wrote: > > > > > > > > On Wed, Nov 14, 2018 at 4:23 PM Subbsd wrote: > > > > > > > > > > On Thu, Nov 15, 2018 at 1:05 AM Subbsd wrote: > > > > > > > > > > > > On Thu, Nov 15, 2018 at 12:21 AM Rebecca Cran < > rebe...@bluestop.org> wrote: > > > > > > > > > > > > > > On November 14, 2018 at 2:18:04 PM, Subbsd (sub...@gmail.com) > wrote: > > > > > > >> > > > > > > >> > > > > > > >> My current host: FreeBSD 13.0-CURRENT r340319 and the problem > is > > > > > > >> still present. > > > > > > > > > > > > > > Rod was asking about the guest OS version, not the host though. > > > > > > > > > > > > > > > > > > > > > > > > > > I apologize, it seemed to me that I wrote earlier) Guest version: > > > > > > > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso.xz > > > > > > > > > > Hm, it seems the problem is 'boot_serial' which is sets to YES by > default in gop > > > > > > > > > > set boot_serial=NO > > > > > boot > > > > > > > > > > solve this issue > > > > > > > > Huh? This is perhaps going to be a stupid question, but where is > > > > boot_serial=YES getting set? Loader will not set it by itself and > UEFI > > > > doesn't respect /boot.config, so this must be explicitly set in > > > > /boot/loader.conf or /boot/defaults/loader.conf, but it's not clear > to > > > > me what's putting it there. > > > > > > > http://src.illumos.org/source/xref/freebsd-head/usr.sbin/bhyveload/bhyveload.c#832 > > > is the only place I can see immediately that this might be happening, > > > but do UEFI boots go through bhyveload? I'm ignorant here. > > > > This is UEFI GOP methodvia bootrom/uefi-firmware, no bhyveload: > > > > bhyve -AHP -s 0:0,hostbridge -s 31:0,lpc -s > > 4:0,ahci-cd,/tmp/FreeBSD-13.0-CURRENT-amd64-20181101-r339979-disc1.iso > > -c 1 -m 1024M -s 29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768,wait -l > > bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd freebsd1 > > > > https://snag.gy/0MH7zU.jpg > > https://snag.gy/kF5cxZ.jpg > > https://snag.gy/htHMG0.jpg > > https://snag.gy/vK1ALN.jpg > > https://snag.gy/qKNPGU.jpg > > What does your /boot/loader.conf look like? > What is the ConOut evifar look like? We set serial when the UEFI env says to do so. Warner ___ 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: Heads up
I'll try virtualbox again, but it booted fine when I tried it before. I'll give bhyve a sping. I haven't tried it in quite some time, but it worked about 9 months ago. But since I don't even know what the errors you are seeing are, I can't tell you that it is similar to some other error reports or something completely new. Warner On Sun, Apr 24, 2016 at 11:49 AM, Ivan Klymenko <fi...@ukr.net> wrote: > On Fri, 15 Apr 2016 11:44:43 +0300 > Ivan Klymenko <fi...@ukr.net> wrote: > > > On Thu, 14 Apr 2016 16:42:33 -0600 > > Warner Losh <i...@bsdimp.com> wrote: > > > > > The CAM I/O scheduler has been committed to current. This work is > > > described in > > > https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the > > > default scheduler doesn't change the default (old) behavior. > > > > > > One possible issue, however, is that it also enables NCQ Trims on > > > ada SSDs. There are a few rogue drives that claim support for this > > > feature, but actually implement data corrupt instead of queued > > > trims. The list of known rogues is believed to be complete, but > > > some caution is in order. > > > > > > Warner > > > > Hi. > > Thanks for you work. > > But i have problem with VirtualBox if i use the kernel with option > > CAM_NETFLIX_IOSCHED > > http://imgur.com/JpcfW1h > > This problem is not over. > After the update on other hardware from r296979 to r298512 (!!! without > option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual > machine to a virtual disk I lost completely virtual machine with > permanent damage to the integrity of the file system in the inside of > the virtual machine. > > This is a serious bug! > > Who cares not to fall into the same situation - is testing yourself > and needed more testers. > Because there is a suspicion that the problem is also relevant for > bhyve VM. > With me on this no more neither the strength nor the desire nor > time. > > Thanks. > ___ 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: RFC: Enabling VIMAGE in GENERIC
On Nov 17, 2014, at 12:46 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, PROPOSAL == I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH == Index: sys/conf/NOTES === --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +optionsVIMAGE +optionsVNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly wishmaster artem...@ukr.net have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN === (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. And if these don’t get cleaned up? (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. And if this doesn’t happen? (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I don’t see that in the action plan. Without it, we’re enabling an option that has know, serious issue making 11 potentially a more unstable release. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
