Why the BIG-IP VE OVA does not work on Virtualbox

I've seen this question asked on this forum as well as on several other forums across the internet, so I wanted to put together this article to answer folks' questions and to settle the discussion. I'll also discuss options that you have for working around it.
 
The VE images I am working with will be from downloads.f5.com.

Perspective

Sometimes things like this get lost in the noise that PM should be channeling back to the maintainers of these products. Other times, PM does exactly what's needed to be done, but then it gets filed as "meh, not that important" and it gets checked on every 6 months or so to see if there has been any movement on it.
 
In this case, I just don't think enough people were making a fuss about it to attract any development effort. If something is listed as "not supported", that's usually why its not supported. There are many times though that a person in-house will need to scratch an itch. This is one of those cases.
 
I do not work on the team that builds the images that are available for download, but I have a great working relationship with them, so they gave me the access needed to squirrel around and find the answer.

Build process insight

The build process itself is encapsulated in a biiiiiig shell script. It throws off a number of different VE images. To understand why the OVA fails, you need to understand
 
  1. what the build process does
  2. a little something about virtualbox
The process to build the VE's starts with QEMU. For the, what I will call "standard" VE's (ALL-ide.ova, ALL-scsi.ova, ALL.qcow2, etc), the QEMU command attaches 2 disk drives during build; 1 for the system, and one for a data store.
 
For the VE's that are known as 1SLOT VE's, that second disk (the data store one) is never created. 1SLOTS are intended only to be used for LTM. As such, adequate disk space is not allocated for "everything else". You get ~7G of space and that's it.
 
To create those drives and attach them as needed by qemu, we simply append more and more "
-drive=blah blah blah
" parameters.
 
Ok, so that collection of QEMU commands eventually gets us a RAW image that we can transform into a  number of different formats.
 
One of those formats is OVA, which is created by use of the 
ovftool
command. The output of that command is an OVA file. For those unfamiliar with it, an OVA file is just a tarball that includes an OVF file, a number of disks, and some other "stuff" that you might want to include (certificates, eula files, yada yada yada).
 
An OVA file is picky though as to the order that files are added to it. The OVF file must come first.

Virtualbox

Virtualbox will happily support more than one disk on a single controller. It will not, however, support more than one controller.
 
 
On the surface, you would think this is not a problem. After all, when you "Import Appliance", it will happily list both of the controllers there.
 
 
In fact, the OVF file can even include multiple controllers in it, as we'll see below.

The Problem

So the problem stems from one of these tools, qemu or ovftool, attaching the second disk to the second controller.
 
If the disk were attached to the first controller, then everything would be fine. It's the lack of multiple controller support in Virtualbox that gums up the machine. VMWare allows multiple controllers, so this would explain why nobody in CM saw this problem when they created the OVA.
 
So can you workaround this problem in any way so that you get a working OVA on Virtualbox? Answer: Yes. It's not even a difficult workaround, but I wonder if it changes anything in the functionality of the OVA as imported into Virtualbox?
 
I suspect not, but if you're willing to hack on the VE, then I assume you're not all that concerned with the VE working 100% as designed either. I just needed it to give me a REST and SOAP API that I could throw scripts at to test stuff. I'm OK with hacking on the VE.

Workarounds

Since I'm not privy to the CM team's work pipeline, I can't even begin to guess at when (or if) this will be fixed. I suspect that "since it works in our supported platforms" it won't be fixed any time soon. Who knows.
 
In the meantime, here is a way to fix the problem if you are unable to resort to using the 1SLOT OVA. I am going to use the IDE version in this example, but similar steps will apply to the SCSI image.
 
Starting with the VE image, we'll use tar to extract its contents to view them.
 
SEA-ML-RUPP1:tim trupp$ tar xvf BIGIP-12.0.0.0.0.606.ALL-ide.ova
x BIGIP-12.0.0.0.0.606-ide.ovf
x BIGIP-12.0.0.0.0.606-ide.mf
x BIGIP-12.0.0.0.0.606-ide.cert
x BIGIP-12.0.0.0.0.606-disk1.vmdk
x BIGIP-12.0.0.0.0.606-disk2.vmdk
SEA-ML-RUPP1:tim trupp$
 
Now, let's take a moment to just copy those file names and put them in a temporary file. The reason we do this is because we will need to recreate the OVA later, but because it has a specific file list we need to specify that list when we recreate the file.
 
I just stick the file list in a file called "files.txt"
 
BIGIP-12.0.0.0.0.606-ide.ovf
BIGIP-12.0.0.0.0.606-ide.mf
BIGIP-12.0.0.0.0.606-ide.cert
BIGIP-12.0.0.0.0.606-disk1.vmdk
BIGIP-12.0.0.0.0.606-disk2.vmdk
 
From here on out, the remaining work will be done in the OVF file, so open that in your favorite editor. With it open, search around the bottom of the file for this block.
 
<Item>
<rasd:AddressOnParent>0</rasd:AddressOnParent>
<rasd:ElementName>disk2</rasd:ElementName>
<rasd:HostResource>ovf:/disk/vmdisk2</rasd:HostResource>
<rasd:InstanceID>6</rasd:InstanceID>
<rasd:Parent>3</rasd:Parent>
<rasd:ResourceType>17</rasd:ResourceType>
</Item>
 
There are two values we will want to change here. They are
 
  • <rasd:AddressOnParent>0</rasd:AddressOnParent>
  • <rasd:Parent>3</rasd:Parent>
You want to change those values to be the following
 
  • <rasd:AddressOnParent>1</rasd:AddressOnParent>
  • <rasd:Parent>4</rasd:Parent>
Then, save the file.
 
What we have accomplished with this change is that we have removed the disk from the second controller, and attached it as a second disk on the first controller.
 
With all disks being on one controller, the OVA will now boot fine in Virtualbox. Let's repack up the OVA.
 
tar -cvf BIGIP-12.0.0.0.0.606.ALL-ide-FIXED.ova -T files.txt
 
This should deliver output that resembles the following
 
SEA-ML-RUPP1:tim trupp$ tar -cvf BIGIP-12.0.0.0.0.606.ALL-ide-FIXED.ova -T files.txt
a BIGIP-12.0.0.0.0.606-ide.ovf
a BIGIP-12.0.0.0.0.606-ide.mf
a BIGIP-12.0.0.0.0.606-ide.cert
a BIGIP-12.0.0.0.0.606-disk1.vmdk
a BIGIP-12.0.0.0.0.606-disk2.vmdk
SEA-ML-RUPP1:tim trupp$
 
And that should be all you need to do. With the fixed OVA made, open it up in Virtualbox and have at it.
 
One last thing. Remember I mentioned that multiple controllers could be specified as long as no disks were attached to the second controller? Take a look at the OVF file again and you will see this block
 
<Item>
  <rasd:Address>1</rasd:Address>
  <rasd:Description>IDE Controller</rasd:Description>
  <rasd:ElementName>ideController1</rasd:ElementName>
  <rasd:InstanceID>3</rasd:InstanceID>
  <rasd:ResourceType>5</rasd:ResourceType>
</Item>
<Item>
  <rasd:Address>0</rasd:Address>
  <rasd:Description>IDE Controller</rasd:Description>
  <rasd:ElementName>ideController0</rasd:ElementName>
  <rasd:InstanceID>4</rasd:InstanceID>
  <rasd:ResourceType>5</rasd:ResourceType>
</Item>
 
Proof that more than one controller can exist, but when you boot the fixed OVA, it still works right?
 
Weird.
 
Anyways, I hope this was useful and answers any outstanding questions you may have had about why the OVA doesn't work on Virtualbox.
Updated Jun 06, 2023
Version 2.0
BIG-IP
devops
virtual box
virtualization
  • CP_Scott's avatar
    CP_Scott
    Icon for Altostratus rankAltostratus
    Oct 03, 2017

    Hey Tim -

     

    This is still broken (probably dev pri 99), but there's now a signature for the manifest included in the .cert file. If that isn't updated, then importing the OVA fails. Can that be regenerated as well, or is the best answer (as recommended elsewhere) to just delete the .cert file before rebuilding the OVA?

     

  • Ghislain_Cote_3's avatar
    Ghislain_Cote_3
    Icon for Nimbostratus rankNimbostratus
    Apr 09, 2018

    Thanks. I needed that for PoC purposes.

    It worked for me BUT I had to remove the extra (unused) SCSI controller.

    So it worked when I did all you did, AND removed all these lines before re-creating the .ova

      
    1
    SCSI Controller
    scsiController1
    3
    lsilogic
    6
  
`

    IMPORTANT : I also had to delete de .cert and .mf files, because the signature of the OVA did not match since the .ovf file is changed.

  • ChansonNZ_36811's avatar
    ChansonNZ_36811
    Icon for Nimbostratus rankNimbostratus
    Jul 27, 2018

    what tool could i use to extract its contents? Am i able to make it through Windows environment, looks like you ran it through Linux?

     

  • Pavel_SK's avatar
    Pavel_SK
    Icon for Nimbostratus rankNimbostratus
    Sep 18, 2018

    One thousand thanks Tim Rupp for this workaround!

     

    I am now able to run BIGIP-13.1.1-0.0.4.ALL-ide.ova on Virtual Box Version 5.1.10 r112026 (Qt5.6.2) (all done on Win7)

     

    ChansonNZ - I used 7zip to open OVA file, removed .cert and .mf files as suggested by Ghislain Cote and then edited OVF file as per Tim's guideline. Advantage to use 7zip is that you can just open OVA file and remove included files as well as edit some and then 7zip automatically "compress" it back so no need to uncompress everything prior. I also recommend to use notepad++ as editor - you can edit OVF via 7zip directly but you need to configure notepad++ as editor in settings of 7zip else it uses default windows notepad. Notepad was not parsing the output of OVF properly.

     

  • T-Heron_379117's avatar
    T-Heron_379117
    Icon for Nimbostratus rankNimbostratus
    Dec 12, 2018

    Sure wish F5 would just start supporting VirtualBox going forward. Other team members at my company feel the same way.