VirtualBox 4.1 Released…

Hot on the heels of the VirtualBox 4.0.12 maintenance release, shipped a few days ago, comes VirtualBox 4.1. It contains loads of new features, explained here and in the changelog.

The upgrade went smoothly on my MacBook Pro, but on my Fedora 15 servers I had to uninstall the old version manually before installing the new version. None of my settings were lost so everything was easy enough.

It certainly seems applying VirtualBox upgrades is becoming a fulltime job. Of course, the quick release cycle is a lot better than getting no updates, like VMware Server. 🙂

Cheers

Tim…

Oracle VM [not] running inside VirtualBox… (update)

I mentioned a few days ago I was having trouble running Oracle VM inside VirtualBox. I had tried with multiple versions of VirtualBox (including the latest 4.0.8), so I finally decided that is must be an issue with the host OS (Fedora 14).

Today I worked up the enthusiasm and trashed my server by replacing the host OS with CentOS 5.6. Regarding Oracle VM and VirtualBox, the news is good. I now have a functioning OVM installation inside a VirtualBox VM, so I can get back to playing with OVM again.

I don’t know exactly what the problem was, but for the moment I’m going to bury my head in the sand and think happy thoughts. I’ve wasted far to much time with this already. 🙂

Cheers

Tim…

Oracle VM [not] running inside VirtualBox…

I know what you are thinking, sounds like a dumb idea right? Well yes, it is pretty stupid, but it’s nice to do it for testing Oracle VM when you don’t want to dedicate a whole server to it. I’ve done this before with no worries. The screen grabs for this article were taken from an installation of Oracle VM inside VirtualBox.

The reason for this post is it doesn’t seem to work for me anymore. Since I last did this successfully I’ve upgraded my host OS (to Fedora 14) and VirtualBox several times (now at 4.0.6). So before I start meddling with downgrading my OS, I would like to know if anyone else has any issues of this type of installation?

I’ve already tried installing old versions of VirtualBox (back to 3.2.8) and that doesn’t fix the issue, so it looks to me like it is the OS that is the issue (sigh). I get the same issue on two servers running Fedora14 as the host OS.

The problem: The installation of Oracle VM inside a VirtualBox VM works fine, but during the post install reboot the VM hangs and I get the following in my “/var/log/messages” file on the host.

May 10 10:42:26 maggie kernel: [  308.782339] BUG: unable to handle kernel paging request at 0000000000002dc4
May 10 10:42:26 maggie kernel: [  308.782345] IP: [] g_abExecMemory+0x1cee8/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782359] PGD 21600b067 PUD 216319067 PMD 0
May 10 10:42:26 maggie kernel: [  308.782363] Oops: 0000 [#1] SMP
May 10 10:42:26 maggie kernel: [  308.782366] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
May 10 10:42:26 maggie kernel: [  308.782370] CPU 3
May 10 10:42:26 maggie kernel: [  308.782371] Modules linked in: vboxnetadp vboxnetflt vboxdrv fuse cifs nfsd lockd nfs_acl auth_rpcgss exportfs sunrpc ipv6 nls_utf8 udf uinput snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep iTCO_wdt ppdev parport_pc parport r8169 iTCO_vendor_support sky2 mii asus_atk0110 i2c_i801 snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc microcode ata_generic pata_acpi firewire_ohci firewire_core crc_itu_t pata_jmicron nouveau usb_storage ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: scsi_wait_scan]
May 10 10:42:26 maggie kernel: [  308.782377]
May 10 10:42:26 maggie kernel: [  308.782377] Pid: 5584, comm: VirtualBox Not tainted 2.6.35.13-91.fc14.x86_64 #1 P5K-VM/P5K-VM
May 10 10:42:26 maggie kernel: [  308.782377] RIP: 0010:[]  [] g_abExecMemory+0x1cee8/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377] RSP: 0018:ffff8801d63ffa68  EFLAGS: 00010286
May 10 10:42:26 maggie kernel: [  308.782377] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000003
May 10 10:42:26 maggie kernel: [  308.782377] RDX: 0000000000000001 RSI: ffff8801d63ffa38 RDI: 00007f579403be30
May 10 10:42:26 maggie kernel: [  308.782377] RBP: ffff8801d63ffae8 R08: 0000000000000008 R09: 0000000000000000
May 10 10:42:26 maggie kernel: [  308.782377] R10: 0000000000000fa0 R11: ffffffffa041f430 R12: 00007f57950ef260
May 10 10:42:26 maggie kernel: [  308.782377] R13: ffffc900118d3000 R14: ffffc900118eeb00 R15: 0000000000000008
May 10 10:42:26 maggie kernel: [  308.782377] FS:  00007f5795bae700(0000) GS:ffff880002180000(0000) knlGS:0000000000000000
May 10 10:42:26 maggie kernel: [  308.782377] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
May 10 10:42:26 maggie kernel: [  308.782377] CR2: 0000000000002dc4 CR3: 00000001e6c77000 CR4: 00000000000026e0
May 10 10:42:26 maggie kernel: [  308.782377] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
May 10 10:42:26 maggie kernel: [  308.782377] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
May 10 10:42:26 maggie kernel: [  308.782377] Process VirtualBox (pid: 5584, threadinfo ffff8801d63fe000, task ffff8801fdce1740)
May 10 10:42:26 maggie kernel: [  308.782377] Stack:
May 10 10:42:26 maggie kernel: [  308.782377]  ffffffffa03c9830 00000000000001f4 ffff8801d63ffae8 ffffffffa03d8c17
May 10 10:42:26 maggie kernel: [  308.782377] <0> 00000000000b8000 ffff880100000002 000000000000064e ffff8801d63ffc27
May 10 10:42:26 maggie kernel: [  308.782377] <0> ffffc900118eeb00 0000000300000000 ffffc900118ee000 0000000000000002
May 10 10:42:26 maggie kernel: [  308.782377] Call Trace:
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? g_abExecMemory+0x1e070/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? g_abExecMemory+0x2d457/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0x3508b/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? g_abExecMemory+0x5907e/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0x2cece/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0x11e1e/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? g_abExecMemory+0xf840/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? g_abExecMemory+0xf25e/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0xa18d/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0x49f97/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] g_abExecMemory+0x1599b/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? unlock_page+0x27/0x2c
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? __do_fault+0x342/0x379
May 10 10:42:26 maggie kernel: [  308.782377]  [] supdrvIOCtlFast+0x50/0x54 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] VBoxDrvLinuxIOCtl+0x44/0x1b0 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  [] ? pmd_offset+0x19/0x40
May 10 10:42:26 maggie kernel: [  308.782377]  [] vfs_ioctl+0x36/0xa7
May 10 10:42:26 maggie kernel: [  308.782377]  [] do_vfs_ioctl+0x468/0x49b
May 10 10:42:26 maggie kernel: [  308.782377]  [] sys_ioctl+0x56/0x79
May 10 10:42:26 maggie kernel: [  308.782377]  [] system_call_fastpath+0x16/0x1b
May 10 10:42:26 maggie kernel: [  308.782377] Code: 24 60 45 89 f8 48 8b 55 a0 41 ff d3 85 c0 89 c1 44 8b 55 88 0f 85 91 fe ff ff 45 89 ff 42 8b 0c bd c0 70 40 a0 41 d3 e2 4d 01 16  83 c4 2d 00 00 10 0f 84 6a fe ff ff 41 c7 46 30 00 00 00 00
May 10 10:42:26 maggie kernel: [  308.782377] RIP  [] g_abExecMemory+0x1cee8/0x180000 [vboxdrv]
May 10 10:42:26 maggie kernel: [  308.782377]  RSP
May 10 10:42:26 maggie kernel: [  308.782377] CR2: 0000000000002dc4
May 10 10:42:26 maggie kernel: [  308.782663] ---[ end trace b439b59bc93da8ee ]---

I’ve done the standard Googling, but nothing jumped out at me as a possible solution.

Cheers

Tim…

 

VirtualBox 4.0.0. Changes to VBoxManage Syntax…

I just got home to find a question about my RAC on VirtualBox article. The poster was having problems creating the virtual disks using the commands in the article. A quick scan through the docs reveals a number of changes to the way VirtualBox 4.0.0 handles disks and also changes to the VBoxManage syntax. I’ve amended the article to include a version of the commands for version 4.0.0 which seem to create and attach the shared disks in the same state, but it will be a few days before I get to test this properly.

So what’s happened that affects shared disk setup?

First, you can’t create a shareable disk. You have to create the disk (createhd), then modify it to shareable (modifyhd). That sounds fine, but there is an issue. The manual says,

“Before VirtualBox 4.0, it was necessary to call VBoxManage openmedium before a medium could be attached to a virtual machine; that call “registered” the medium with the global VirtualBox media registry. With VirtualBox 4.0 this is no longer necessary; media are added to media registries automatically. The “closemedium” call has been retained, however, to allow for explicitly removing a medium from a registry”

Well that is not entirely true. When you create a new disk it is not visible in the media manager until it is attached to a VM. That means you have to create the disk, attach it to a VM and then convert it to shareable. If you try to modify it before attaching it to a VM you get told the disk doesn’t exist. This just feels wrong.

As a minor annoyance, the VM detail pane doesn’t notice the “–type” change so the disks still display as normal unless you restart VirtualBox, or click the “Storage” link for the VM and come straight out, which seems to get the screen to update.

This is not a big deal, it’s just a little annoying as the old syntax was more straight forward. I’m sure it was done for a good reason… 🙂

Cheers

Tim…