Welcome to the BIG-IP LTM VE forums

After a bit of a frustrating day trying to find server hardware, could I request support for ESX 3.5

 

 

Basically my company is happy for us to have our own test labs if we can do it for free (Odd that..). The ESX 4 64bit processor requirement blows running on retired tin right out of the water.

@gabe128: Upgrades and downgrades are not something this specific virtual edition was designed for. This is because the ability to install and upgrade is a more production-level concept. This version here is more of a subset of what will eventually be offered in a virtualized package. This is a whole new *platform* as well, so there isn't a direct upgrade path to it or downgrade path from it with a standard UCS.

 

 

About the concept of a virtualized package: The reason upgrades and downgrades (as we know them) have changed in this context is simply because the same task can now be accomplished in the hypervisor. By rolling out a new instance of the BIG-IP LTM VE and applying a modified config from the original, you can achieve the desired result without really compromising the original. Just think about it - a world where a failed upgrade doesn't grind the world to a standstill. =)

 

 

So you can see there are limitations here on what was previously implemented. But there are also many new workflows in the hypervisor to explore when deploying setups including HA pairs, for example.

@Colin I was thinking about something that could do the equivalent of a tcpdump on a vip to capture the traffic info( of requests, frequency of requests). You could take that info and play it back though the VM. This does bring up the question of backend nodes. You really need something on the backend to pick up those requests. Maybe a generic configured http server in another VM that would be a catch the requests return some sort of response and could log traffic?

 

You could standup a whole lab with a couple VMs on one machine.

 

re: ESX 3.5 support.

 

 

ESX 3.5 is nearing it's own retirement. It's official "end of general support" date is May 21st of this year - less than four months from now.

 

 

Here's VMware's chart on those dates:

 

http://www.vmware.com/support/policies/lifecycle/vi/eos.html

 

 

There are many other reasons for not supporting 3.5 beyond support availability - the primary technical difference being a lack of Virtual Hardware 7 support.

 

 

Food for thought: a capable quad core box with ~8GB of ram that supports ESXi 4 can be found for less than $1000 from most of the major vendors.

 

 

Treepose. If i could pick it up for a tenner I'd have the same headache getting it in.

 

 

It has to be either something we can cobble together with spare parts, or have months of business cases, planning, purchase order raising, power ordering, change management, etc, etc.

Steve,

 

 

The difficulty is that ESX4 added support for IDE disks which is how the VE runs. In theory, if the core *nix kernel supports SCSI, then there is a chance you could create a version that runs on ESX 3.5.

 

 

Your best bet for testing is to download VMware Player (free) or VMware Workstation (not free) and use it that way. Either will easily run on a regular workstation without the 64-bit CPU requirement.

 

 

-Robert

Steve,

 

I heard a user got it working in VirtualBox as well.

Colin,

 

 

Thanks for the quick feedback and answers - looks great so far.

 

 

As for 3 - just a reference to TACACS & RADIUS - does it play well with them?

 

 

 

Offset,

 

 

Thanks for the explanation. If I understand your explanation as well as the documentation correctly, it would indeed be as useful as you indicate in the hypervisor examples you listed if we could have the option of HA in the VE configurations (currently not supported). Product and config testing is limited to a single version of VE software, so any beneficial workflow for post-installation work is subsequently constrained with only a single flavor as well.

 

 

For example - if you're working in version 9 software and you want to test an upgrade to another version of 9, or even the latest version of v10 - you cannot predict how an actual product upgrade will occur, and thus any established or new workflows are for all practical purposes useless. (I.E. the tool will work well for new deployments, but perhaps not as well in already existing production environments.)

 

 

I do understand this is not meant as a production tool, so we are grateful for it's existence in that way and from a feature perspective. But even feature testing is truly only relevant on a version software that you are running. Example: What good is a VE tool to me with v10 software when I'm running 9? Or if I am running a newer version of 10 with new features or fixes that the tool doesn't cover?

 

 

The VE product will provide for function and feature testing, but will not enable validation of key critical areas for the code on platforms themselves, so it will consequently have some level of limited application in our lab.

 

 

If there is a VE released for different versions of LTM code, well that is a different thing and would definitely be welcome. As it stands though our hands are somewhat tied with a single flavor as we are running different software (v9, v10), on different pairs of platforms for very different reasons.

 

 

Thanks again guys,

 

 

- Gabe

 

If I understand your explanation as well as the documentation correctly, it would indeed be as useful as you indicate in the hypervisor examples you listed if we could have the option of HA in the VE configurations (currently not supported).

 

 

I can tell you that HA, while it's not perfect quite yet in this VE, it will begin to form in subsequent releases to behave much like a physcial box would. I've been tinkering with an active/standby pair implementing network failover and connection mirroring on an HTTP virtual. We can work on getting examples of HA configurations in the docs for upcoming releases.

 

 

For example - if you're working in version 9 software and you want to test an upgrade to another version of 9, or even the latest version of v10 - you cannot predict how an actual product upgrade will occur

 

 

True, and that would be really nice if we could watch the mock upgrade go down, but this is a completely different platform from the perspective of the operating system. The line in the sand starts here, at version 10.1.0, where you can start tinkering with parts of your config. For example, I've been using the 'bigpipe merge' functionality to cut virtual servers, nodes, pools, and iRules out of my 9.x configs and apply them to 10.1.0 VE. It's useful for testing migration of my most customized config objects in 10.x. While it doesn't test the exact workflow you'd follow in a real physical migration, it tests whether your existing 9.x config elements will load.

 

 

What good is a VE tool to me with v10 software when I'm running 9?

 

 

It's just for checking out the functionality of v10.

 

 

The VE product will provide for function and feature testing, but will not enable validation of key critical areas for the code on platforms themselves, so it will consequently have some level of limited application in our lab.

 

 

You are correct. This is a limitation we cannot sidestep since this is a completely different platform. Unless you plan on deploying production virtual systems. The one thing you should be able to count on though, is the core configuration elements (in bigip.conf, for example) like big, scary iRules. Those are supposed to load *and work* in VE and should when applied from VE to subsequent releases down the code line.

 

 

You have a lot of very good points, keem 'em coming.

I downloaded the Big-ip LTM VE and when I tried to open it in Vmware workstation 7 i get an error failed to query source for information . The file is in a ova format