Category Archives: Oracle VirtualBox

Anything related to Oracle VirtualBox

UEFI, GPT, Windows 10, FreeBSD 10, and rEFInd

Over the last few days have I experimented with UEFI and GPT in VirtualBox 4.3.26. The goal was to multiboot various operating system, in this case Windows 10 Enterprise Technical Preview 9926 x64 and FreeBSD/amd64 stable/10.

First, I thought of persuading the UEFI firmware to always present its boot menu. It sure beats remembering to press F12 each time I want to boot a different operating system. This proved impossible for a number of reasons.

Next, I came across The rEFInd Boot Manager. After a quick glance I saw this is exactly what I want, a UEFI boot manager. Continue reading UEFI, GPT, Windows 10, FreeBSD 10, and rEFInd

Configuring X.org on FreeBSD guests running in VirtualBox

Configuring X11 is more or less a dark art, and you must almost be a wizard of the Slytherine House to get modern X.org 1.14.7 working on a FreeBSD guest in VirtualBox.

Nonetheless, through lots of experimentation this evening, have I finally arrived at this configuration file:

Section "InputClass"
  Identifier      "Keyboard Defaults"
  Driver          "keyboard"
  MatchIsKeyboard "on"
  Option          "XkbLayout" "no"
EndSection

Section "InputClass"
  Identifier      "Mouse Defaults"
  Driver          "mouse"
  MatchIsPointer  "on"
EndSection

Section "InputDevice"
  Identifier      "Mouse0"
  Driver          "vboxmouse"
  Option          "CorePointer" "on"
EndSection

Somehow, you need both the InputClass and the InputDevice sections to get the mouse working as it did in previous versions of X.org. The option CorePointer is also key to the success.

Not only have I achieved Norwegian keyboard layout, the mouse sends its events to the X Server, and the mouse cursor is able to leave the FreeBSD guest whenever I want.

Maybe I’m the next Voldemort afterall. :P

VirtualBox 4.3.18 and AHCI

Update 2014-11-30

Upgrading to Oracle VirtualBox 4.3.20 removed the timeout messages shown below.

The bug was acknowledged in the change log as

Storage: fixed an interrupt acknowledge issue causing hanging guests or slower I/O (4.3.18
regression)


Since upgrading Oracle VirtualBox from 4.3.16 to 4.3.18 on my Windows 7 x64 host, most of my FreeBSD guests from time to time shows kernel messages like the ones below.

ahcich2: Timeout on slot 7 port 0
ahcich2: is 00000008 cs 00000000 ss 00000000 rs 00000080 tfd 50 serr 00000000 cmd 1000c717
(ada2:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 62 d4 9c 40 00 00 00 00 00 00
(ada2:ahcich2:0:0:0): CAM status: Command timeout
(ada2:ahcich2:0:0:0): Retrying command

It doesn’t matter if your FreeBSD guests run version 4.3.16 or version 4.3.18 of the emulators/virtualbox-ose-additions port.

Someone else reported similar kernel messages on physical servers, making me believe some recent changes in FreeBSD can be blamed. Or, maybe this is just a coincidence, despite the similarities.

Local slave port for emulators/virtualbox-ose-additions without OpenGL and X11

I have a bunch of FreeBSD VMs running in VirtualBox. They all share a number of virtual harddrives, and among them are a virtual harddrive with the common contents of /var/db/ports.

My ports configuration of emulators/virtualbox-ose-additions have the OPENGL and X11 options set. This is useless on some of my simpler VMs, as those VMs have no need for any X11 ports, but they could sure benefit from having the VirtualBox additions installed. These simpler VMs are usually used only to test ZFS in FreeBSD in various configurations.

I could juggle the settings for emulators/virtualbox-ose-additions for each time I’m updating the VirtualBox additions port on my VMs, but I decided to create a local slave port disabling the OPENGL and X11 options. Maybe this port, with the necessary tweaking, could sit among its siblings in the official emulators category.

OPTIONS_EXCLUDE=	OPENGL X11

MASTERDIR=	${.CURDIR}/../../emulators/virtualbox-ose-additions
.include "${MASTERDIR}/Makefile"

CATEGORIES=		local
VALID_CATEGORIES+=	local

COMMENT=	VirtualBox additions for FreeBSD guests without OPENGL and X11

PATCHDIR=	${MASTERDIR}/../${PORTNAME}/files

PKGNAMESUFFIX=	-additions-nox11

PKGORIGIN=	${CATEGORIES}/${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}

# EOF

For now you must copy the /var/db/ports/local_virtualbox-ose-additions-additions-nox11/options file to /var/db/ports/emulators_virtualbox-ose-additions-additions-nox11/options, or else dialog4ports(1) will keep nagging you until kingdom come.

I guess this problem stems from early processing of bsd.port.mk as done by the master Makefile at a time when the CATEGORIES variable was set to emulators.

Your own virtualized desktop FreeBSD lab

If you’re like me, eager to test new stuff in FreeBSD, you might as well run a virtualized FreeBSD laboratory on your desktop. I use Oracle VirtualBox, but you might as well use Microsoft Hyper-V, real hardware, or some other contraption. Couple this with ZFS and boot environments, and you’re even able to rapidly revert any mishaps, although enabled ZFS features can’t be reverted without some help in advance from the virtualization software. Continue reading Your own virtualized desktop FreeBSD lab

FreeBSD VT aka newcons in base/head

Update 2015-01-05:

I was more or less forced to adopt VT, UTF-8, KMS, and DRM2 when I upgraded my laptop from stable/9 to stable/10 in the time between Christmas of 2014 and New Year of 2015. My laptop, a Dell Latitude D531 of mid-2007 design, is equipped with the AMD/ATI Radeon X1270 GPU. What an awesome beast back in 2007/8! :P

Adding the two lines below to /boot/loader.conf, lets me watch the transition from a 80×25 text mode console, to a 80×30 graphics mode console, to a 210×65 graphics mode console, as the bootstrap firmware, the VGA driver, and subsequently, the KMS driver does their magic.

radeonkmsfw_RS690_cp_load="YES"
radeonkms_load="YES"

The VT console with the proper KMS driver truly rivals the old sc console in terms of geometry, UTF-8 capability, and speed.

Now, if only the former and latter were true for FreeBSD VMs running inside VirtualBox, which are still forced to run the VT console with the VGA driver or in the old text mode.


Update 2014-08-27:

I compiled and installed r270452 of base/head the other day, and the VT console is faster than ever before in VirtualBox 4.3.12. I imagine the speedups are similar on real hardware.

The VT console can’t compete with the old sc console in terms of speed, but, making room for a new line on a screen full of text, is considerably faster now than earlier this year.

Setting hw.vga.textmode="1" in /boot/loader.conf is even faster if you don’t need doublewidth characters. However, you may feel comfortably with the 30 lines of text provided by the graphical mode.

It’s nice to see the sc and the VT code being merged, making it possible to have both consoles compiled in the kernel for base/stable/10 and base/head. Only one of them may be active at a time, so set your /boot/loader.conf accordingly:

kern.vty="vt" for the VT console, or, kern.vty="sc" for the old sc console.


2014-02-15:
For last couple of days I’ve been playing with base/head and the VT kernel. It’s refreshing to finally be able to put Unicode with the UTF-8 encoding to use on the console. The console speed, at least when run in VirtualBox 4.3.6, reminds me of the console of the Sun SPARCstation IPCs I used to manage before they all died some years ago. I’ll see if I can find some idle equipment at work that’s not too old and see if the console speed is any different on real hardware. Anyway, this newcons business surely is a step in the right direction.

10 Gbit/s virtual wire speed in VirtualBox 4.2.16

I updated my FreeBSD 10.0-CURRENT virtual machine today. It reached r255120 and it’s running with vtnet as its virtual network interface under VirtualBox 4.2.16. I noticed the vtnet0 interface gained 10 Gbit/s virtual wire speed. Previously the interface ran with only 1 Gbit/s virtual wire speed. The actual wire speed depends largely on the physical limitations of the computer hardware and the computational speed of VirtualBox’ internals.

This is due to a range of revisions such as r255109, r255110, r255111, and more important r255112.

vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=6c03bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 08:00:27:0e:4a:ba
        inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet 10Gbase-T <full-duplex>
        status: active