8 Replies Latest reply: Nov 30, 2016 2:52 AM by flex RSS

    F5 BIG-IP VE in VIRL


      I finally found some time to test the script I developed to convert F5 BIG-IP VE images to be supported in VIRL. The script can be found at https://gogs.informatik.hs-fulda.de/srieger/virl-utils-hs-fulda/src/master/create-f5-bigip-image. Currently, you need a VE image >= 11.6 since these images are compatible wtih the VIRL environment (OpenStack with KVM on Ubuntu 14.04). Otherwise, the platform and virtual hardware is not detected correctly, leading to errors with chmand (e.g., also described at lost and found ( for me ? ): install F5 BIG IP 11.3 VE trial on unsupported KVM host Ubuntu 14.04). Sadly, this prohibits using the free trial, which is based on 11.3, but I've started to work on a function to patch platform files etc. So maybe this will be fixed in the near future, though it's unlikely as other network virtualization solutions also offer only >= 11.6 support for the BIG-IP images. Also, the official F5 OpenStack images only support BIG-IP version 11.6 and higher.


      To use the script, you need to get a KVM image of the VE from F5 (e.g. version 11.6 or 12.0). in qcow2 formar. Then, you can run the script, e.g. as:


      virl@virl1-hsfd:~/HSFD-VIRL/Big-IP-LTM$ sudo -s
      root@virl1-hsfd:~/HSFD-VIRL/Big-IP-LTM# ./create-f5-big-ip-image.sh BIGIP- F5-BIGIP


      The image is automatically imported into glance and a default flavor for OpenStack nova (4GB RAM, 2 VCPU) is created. I tested the VE with an additional flavor with 16GB RAM. You need to create a dynamic subtype (e.g., https://gogs.informatik.hs-fulda.de/srieger/virl-utils-hs-fulda/src/master/create-f5-bigip-image/dynamic-subtype-F5-BIGI…) and reimport the subtypes to VM Maestro. Afterwards, you can create a topology with a BIG-IP VE like this:


      The script activates serial console output as shown in the screenshot and reads the configuration defined in the node properties in VM Maestro. The configuration is treated as a shell script (see example at https://gogs.informatik.hs-fulda.de/srieger/virl-utils-hs-fulda/src/master/create-f5-bigip-image/minimal-config-F5-BIGIP…).


      After starting the simulation, you can login to the BIP-IP node using SSH, serial console or directly configure it through its web interface. This can be done using the flat network to connect to the node (as described in the VIRL documentation) or, e.g., using SSH tunneling from you management node to the HTTPS port of the BIG-IP node. For the topology shown above, I tested for example the following load balancing scenario:



      Keep in mind, that the license that you enter to active the BIG-IP VE will be limited to exaclty this VM! It seems like the license is bound to the UUID and MAC address so as soon as you stop the simulation and the VM is terminated, you cannot reuse the license as new simulations will build a new VM with different UUID and MAC address. I'm currently experimenting with exporting the VM configurations from the KVM definition and reinject it in future simulations to be able to reuse the same VM and hence its license for multiple simlations. Also, I'm looking at the scripts that F5 provides to import BIG-IP instances to OpenStack. Somehow, these also seem to require separate licensing for every new instance. Really strange... any suggestions for improvement on this is welcome!

        • 1. Re: F5 BIG-IP VE in VIRL

          Nice work Dude. Will try to add one in my VIRL ecology and would update you on the outcome or any issues I would face along the line.


          Thanks mate for the effort.




          • 2. Re: F5 BIG-IP VE in VIRL
            E. Rivera

            Have you tried taking a snapshot once the license has been activated? 

            • 3. Re: F5 BIG-IP VE in VIRL

              With all the honesty in my heart, I haven't tried it yet. I will be giving it a go over this weekend. Will keep you posted on the outcome because I may virtually pick your brains mate.




              • 4. Re: F5 BIG-IP VE in VIRL

                To take a snapshot was my first idea! I created a snapshot in VIRL UWM after installing the license and configuring the node. But the snapshot only stores the disk contents. It seems like some internals of the VM change after starting this snapshot (e.g., the system's UUID). Hence, you get some error messages on the console leading to the deactivation of the license:

                BIG-IP 11.6.1 Build 0.0.317

                Kernel 2.6.32-358.61.1.el6.f5.x86_64 on an x86_64

                host-10-255-0-80.openstacklocal login: Jul 18 00:10:39 host-10-255-0-60 emerg mcpd[5521]: 01070608:0: License is not operational (expired or digital signature does not match contents).


                BIG-IP 11.6.1 Build 0.0.317

                Kernel 2.6.32-358.61.1.el6.f5.x86_64 on an x86_64

                host-10-255-0-60.openstacklocal login: Jul 18 00:10:44 host-10-255-0-60 emerg load_config_files: "/usr/bin/tmsh -n -g load sys config partitions all" - failed. -- 01070356:3: Load balancing feature not licensed. Unexpected Error: Loading configuration process failed.

                I just tried again and started the snapshot two times. Then I took a look in the definition of the KVM instance /var/lib/nova/instances/<UUID of the node>/libvirt.xml. Sadly, my theory was correct. The UUID and all MAC addresses change when the snapshot is started. The same happens when you start a new simulation:


                --- C:\Users\Sebastian\Desktop\f5-bigip-instance-def1.txt

                +++ C:\Users\Sebastian\Desktop\f5-bigip-instance-def2.txt

                @@ -1,13 +1,13 @@

                <domain type="kvm">

                -  <uuid>535616d2-f850-4759-8be4-b21122e4ae0a</uuid>

                -  <name>instance-000000a5</name>

                +  <uuid>856e496e-9d10-4ced-aa4b-c86aaf8b5f15</uuid>

                +  <name>instance-000000a8</name>




                     <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0">

                       <nova:package version="2015.1.3"/>

                -      <nova:name>&lt;/advcompnet/endpoint&gt;-&lt;bigip-OQgISz&gt;-&lt;f5-bigip-1&gt;</nova:name>

                -      <nova:creationTime>2016-07-18 07:07:14</nova:creationTime>

                +      <nova:name>&lt;/advcompnet/endpoint&gt;-&lt;bigip-2a8GyW&gt;-&lt;f5-bigip-1&gt;</nova:name>

                +      <nova:creationTime>2016-07-18 07:18:55</nova:creationTime>

                       <nova:flavor name="F5-BIGIP.medium">



                @@ -28,7 +28,7 @@

                       <entry name="product">OpenStack Nova</entry>

                       <entry name="version">2015.1.3</entry>

                       <entry name="serial">4229e898-6100-680c-715b-19e43660c6f0</entry>

                -      <entry name="uuid">535616d2-f850-4759-8be4-b21122e4ae0a</entry>

                +      <entry name="uuid">856e496e-9d10-4ced-aa4b-c86aaf8b5f15</entry>




                @@ -54,46 +54,46 @@


                     <disk type="file" device="disk">

                       <driver name="qemu" type="qcow2" cache="none"/>

                -      <source file="/var/lib/nova/instances/535616d2-f850-4759-8be4-b21122e4ae0a/disk"/>

                +      <source file="/var/lib/nova/instances/856e496e-9d10-4ced-aa4b-c86aaf8b5f15/disk"/>

                       <target bus="virtio" dev="vda"/>


                     <disk type="file" device="disk">

                       <driver name="qemu" type="raw" cache="none"/>

                -      <source file="/var/lib/nova/instances/535616d2-f850-4759-8be4-b21122e4ae0a/disk.config"/>

                +      <source file="/var/lib/nova/instances/856e496e-9d10-4ced-aa4b-c86aaf8b5f15/disk.config"/>

                       <target bus="ide" dev="hdd"/>


                     <interface type="bridge">

                -      <mac address="fa:16:3e:0c:aa:84"/>

                +      <mac address="fa:16:3e:5e:be:99"/>

                       <model type="virtio"/>

                       <source bridge="brq3260baab-fd"/>

                -      <target dev="tape96fc453-f7"/>

                +      <target dev="tap04d7eca7-33"/>


                     <interface type="bridge">

                -      <mac address="fa:16:3e:49:12:a3"/>

                +      <mac address="fa:16:3e:58:95:60"/>

                       <model type="virtio"/>

                       <source bridge="brqb16710b7-6a"/>

                -      <target dev="tapea2cb5ec-3e"/>

                +      <target dev="tapd3f07b7a-26"/>


                     <interface type="bridge">

                -      <mac address="fa:16:3e:db:4d:24"/>

                +      <mac address="fa:16:3e:2c:20:71"/>

                       <model type="virtio"/>

                -      <source bridge="brq95acbaef-0a"/>

                -      <target dev="tap04f3fe6e-3c"/>

                +      <source bridge="brq0ac98f97-db"/>

                +      <target dev="tapb4d7bea1-4d"/>


                     <interface type="bridge">

                -      <mac address="fa:16:3e:4f:1d:11"/>

                +      <mac address="fa:16:3e:87:ae:6f"/>

                       <model type="virtio"/>

                -      <source bridge="brq3000a614-53"/>

                -      <target dev="tap90c48b8d-d7"/>

                +      <source bridge="brq504bf0cb-5f"/>

                +      <target dev="tap80d828ed-d8"/>


                     <interface type="bridge">

                -      <mac address="fa:16:3e:82:ae:df"/>

                +      <mac address="fa:16:3e:f6:4b:77"/>

                       <model type="virtio"/>

                -      <source bridge="brqf0dc7805-c3"/>

                -      <target dev="tap3f062cde-ea"/>

                +      <source bridge="brq34083fe9-7b"/>

                +      <target dev="tapaea75996-8c"/>


                     <serial type="tcp">

                -      <source host="" mode="bind" service="17000"/>

                +      <source host="" mode="bind" service="17001"/>

                       <protocol type="telnet"/>


                     <graphics type="vnc" autoport="yes" keymap="en-us" listen=""/>


                I was able to change the MAC address to the old base mac address from bigip_base.conf, but KVM refuses to inject the old UUID since this is also the base name for the entire domain. I'll try to find a solution  to give the VM the same UUID. But there must be a official solution by F5 for this. I cannot believe that they want us to enter a license each time a BIG-IP instance in an OpenStack environment is started... or - wait a second - maybe I can ...

                • 5. Re: F5 BIG-IP VE in VIRL

                  I tried to inject the MAC address and UUID (system uuid) to be able to reuse the license for multiple starts. Turns out that also for the official OpenStack images from F5 one needs to supply a unique and new licence/activation each time the instance is created. This license policy of F5 does not really fit current cloud paradigms from my point of view. Anyway... the MAC address can be fixed by predefining a neutron port. But VIRL STD does not allow to supply existing neutron ports for the instance creation. The UUID injection is also not really a good idea. The OpenStack nova source can be modifed to fix the uuid and/or reuse the old uuid, but there were some discussions about the uuid modification in the OpenStack forums and it is not advisable to change the uuids as it is used as a foreign key in other tables and expected to be unique. So F5's licensing policy effectively does not allow the usage of a licence after stopping the simulation.


                  Nonetheless, the script can be used to create a fully functional BIGIP image to be used in VIRL. The licence policy of F5 requires a new activation and/or licence each time a simulation is started. As long as you don't stop the simulation, the BIPIP instance works fine. As soon as you stop the simulation or destroy the BIGIP instance, you need to activate the license again. This limitation seems to be the same for other tools like GNS3 etc. as well as the official deployment scripts for BIPIP VE on OpenStack from F5. Next, I'll try to import the free trial 11.3 VE LTM (https://www.f5.com/trial/secure/big-ip-ltm-virtual-edition.php).

                  • 6. Re: F5 BIG-IP VE in VIRL

                    Our gitlab server was migrated to Gogs. The old gitlab server is available until the end of October. The new repository for the F5 BIG-IP VE image creation script for VIRL can be found at https://gogs.informatik.hs-fulda.de/srieger/virl-utils-hs-fulda/src/master/create-f5-bigip-image.



                    • 7. Re: F5 BIG-IP VE in VIRL

                      Thank you very much for your import script. It worked perfect for me. I just had to to one litte adoption:

                      In the glance import I had to change hw_disk_bus from virtio to ide. Otherwise the ressource provisioning page in the webinterface will not work. I hadn't investigated it very deep but it looks like with virtio not all partitions in the disk image are mounted correctly and some information were missing. With ide everything is working fine

                      • 8. Re: F5 BIG-IP VE in VIRL

                        Thanks for your feedback! I used a manual configuration during my tests. I fixed the hw_disk_bus both in the glance import as well as the subtype template to use ide!