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 what the build process does 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-cvfBIGIP-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.
