What Hypervisors have you tried LTM VE in?

Hello:

 

 

I had luck with ESXi (v3.5) and Vmware Workstation 6.5 and 7.0. I am just building a new workstation and I wanted to give it a shot with VirtualBox (version 3.8 running on Win7 x64)

 

 

Unfortunately, I am getting the kernel panic as well and no tweaks helped so far. I even tried the XML that was provided earlier in this post but I guess VirtualBox configuration file is slightly different now.

 

 

Have anyone tried with latest version of VirtualBox?

 

 

Haluk

 

I have heard success stories on the VE trial on virtualbox, though I have not tried myself.

I have not seen 10.2 work on vmware server or vmware fusion.

 

The interfaces never go into an initialized state.

10.2 VE is only supported on ESX/ESXi with a valid license, there is no trial for this version. The VMXNET3 ethernetX.virtualDev is necessary.

I posted this in the vmware workstation thread as well....

 

 

Success:

 

Vmware Fusion 3.1.2

 

OSX 10.6.5

 

BIGIP-VE 10.2 build 1707

 

 

Be sure to edit the .vmx file as follows:

 

ethernet1.virtualDev = "vmxnet3"

 

ethernet2.virtualDev = "vmxnet3"

 

 

The interfaces leave the UNINITIALIZED state after putting them in a vlan, and I have tested that they do indeed pass traffic

 

Success:

 

 

VMWware ESX 4.0

 

 

BIGIP LTM VE 10.1.0

 

 

the interfaces are uninitialized, I added them to untagged VLAN, and they are working

I've managed to get LTM VE 10.1.0 (3341.1084) running under the Xen 4.0.1 hypervisor on Debian Squeeze as a HVM.

 

 

I am currently working on making LTM VE run as a PV domU on Xen 4.0.1.

 

 

 

For anyone wanting to try this the following domU config will get you started:

 

 

 

----------------------------------------------------------------------------------------------

 

import os, re

 

arch = os.uname()[4]

 

pae = 1

 

acpi = 1

 

apic = 1

 

sdl = 0

 

vnc = 1

 

vnclisten = "0.0.0.0"

 

vncconsole = 1

 

vncpasswd = ''

 

stdvga = 0

 

serial = 'pty'

 

kernel = '/usr/lib/xen-default/boot/hvmloader'

 

builder = 'hvm'

 

device_model = '/usr/lib/xen-default/bin/qemu-dm'

 

 

vcpus = '1'

 

memory = '1024'

 

shadow_memory = '8'

 

disk = [ 'phy:/dev/guest/dmzlb-disk,hda,w' ]

 

boot = 'c'

 

name = 'dmzlb'

 

vif = [

 

'type=ioemu, model=pcnet, bridge=mgmt',

 

'type=ioemu, model=e1000, bridge=internal',

 

'type=ioemu, model=e1000, bridge=external'

 

]

 

on_poweroff = 'destroy'

 

on_reboot = 'restart'

 

on_crash = 'restart'

 

 

----------------------------------------------------------------------------------------------

 

 

 

Adding interfaces is as simple as adding more 'type=ioemu, model=e1000, bridge=', elements to the vif config.

 

Same deal as for other hypervisors re UNITIALIZED interfaces - just add them to a VLAN and their status will change to UP.

 

I assume you are already familiar with Xen 4. If you want to try this and you aren't then I suggest reading through the Open Source Xen online documentation rather than asking for help here.

 

 

 

 

 

Dave

 

 

 

 

 

I also have the same release running in VMware Fusion on Snow Leopard 10.6.5.

 

 

Tagged VLANs on vmnet interfaces are problematic on OSX. I couldn't get them to work reliably. My work around in duplicating our production config where VLANs are used extensively was to add vmnet interfaces and map the VLANs untagged 1-to-1 with the tmm interfaces.

 

To do this on Fusion 3.1.x the UI is of no value. You will need to edit /Library/Application\ Support/VMware\ Fusion/locations. Don't bother editing /Library/Application\ Support/VMware\ Fusion/networking - it is generated from locations anyway.

 

 

Edit locations to look something like this (I have 5 vmnets - one for management and 4 mapped to VLANs on the BIG-IP. VNET_8 is the built-in default NAT vmnet):

 

 

----------------------------------------------------------------------------------------------

 

remove_answer VNET_0_HOSTONLY_HOSTADDR

 

remove_answer VNET_0_HOSTONLY_NETMASK

 

answer VNET_0_HOSTONLY_HOSTADDR 10.99.200.253

 

answer VNET_0_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_0_NAT

 

answer VNET_0_NAT yes

 

remove_answer VNET_0_DHCP

 

answer VNET_0_DHCP no

 

remove_answer VNET_1_HOSTONLY_HOSTADDR

 

remove_answer VNET_1_HOSTONLY_NETMASK

 

answer VNET_1_HOSTONLY_HOSTADDR 10.99.99.254

 

answer VNET_1_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_1_NAT

 

answer VNET_1_NAT no

 

remove_answer VNET_1_DHCP

 

answer VNET_1_DHCP no

 

remove_answer VNET_2_HOSTONLY_HOSTADDR

 

remove_answer VNET_2_HOSTONLY_NETMASK

 

answer VNET_2_HOSTONLY_HOSTADDR 10.99.0.254

 

answer VNET_2_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_2_NAT

 

answer VNET_2_NAT no

 

remove_answer VNET_2_DHCP

 

answer VNET_2_DHCP no

 

remove_answer VNET_3_HOSTONLY_HOSTADDR

 

remove_answer VNET_3_HOSTONLY_NETMASK

 

answer VNET_3_HOSTONLY_HOSTADDR 10.99.1.254

 

answer VNET_3_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_3_NAT

 

answer VNET_3_NAT no

 

remove_answer VNET_3_DHCP

 

answer VNET_3_DHCP no

 

remove_answer VNET_4_HOSTONLY_HOSTADDR

 

remove_answer VNET_4_HOSTONLY_NETMASK

 

answer VNET_4_HOSTONLY_HOSTADDR 10.99.2.254

 

answer VNET_4_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_4_NAT

 

answer VNET_4_NAT no

 

remove_answer VNET_4_DHCP

 

answer VNET_4_DHCP no

 

remove_answer VNET_5_HOSTONLY_HOSTADDR

 

remove_answer VNET_5_HOSTONLY_NETMASK

 

answer VNET_5_HOSTONLY_HOSTADDR 10.99.3.254

 

answer VNET_5_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_5_NAT

 

answer VNET_5_NAT no

 

remove_answer VNET_5_DHCP

 

answer VNET_5_DHCP no

 

remove_answer VNET_8_HOSTONLY_HOSTADDR

 

remove_answer VNET_8_HOSTONLY_NETMASK

 

answer VNET_8_HOSTONLY_HOSTADDR 192.168.200.1

 

answer VNET_8_HOSTONLY_NETMASK 255.255.255.0

 

remove_answer VNET_8_NAT

 

answer VNET_8_NAT yes

 

remove_answer VNET_8_DHCP

 

answer VNET_8_DHCP yes

 

----------------------------------------------------------------------------------------------

 

Then run:

 

 

sudo /Library/Application\ Support/VMware\ Fusion/vmnet-cli -c; sudo /Library/Application\ Support/VMware\ Fusion/vmnet-cli --start

 

 

You're config will now be persistent across restarts.

 

Now edit your VMX that shipped with LTM VE. Mine, corresponding to the VMNET config above looks like this (as you can see I renamed the VM and its disk etc):

 

----------------------------------------------------------------------------------------------

 

.encoding = "UTF-8"

 

 

cleanShutdown = "FALSE"

 

config.version = "8"

 

displayName = "dmzlb (10.1.0.3341.1084)"

 

ethernet0.addressType = "generated"

 

ethernet0.connectionType = "custom"

 

ethernet0.generatedAddress = "00:0c:29:9e:3e:a8"

 

ethernet0.generatedAddressOffset = "0"

 

ethernet0.pciSlotNumber = "16"

 

ethernet0.present = "true"

 

ethernet0.startConnected = "true"

 

ethernet0.virtualDev = "vlance"

 

ethernet0.vnet = "vmnet0"

 

ethernet1.addressType = "generated"

 

ethernet1.connectionType = "custom"

 

ethernet1.generatedAddress = "00:0c:29:9e:3e:b2"

 

ethernet1.generatedAddressOffset = "10"

 

ethernet1.pciSlotNumber = "17"

 

ethernet1.present = "true"

 

ethernet1.startConnected = "true"

 

ethernet1.virtualDev = "e1000"

 

ethernet1.vnet = "vmnet1"

 

ethernet2.addressType = "generated"

 

ethernet2.connectionType = "custom"

 

ethernet2.generatedAddress = "00:0c:29:9e:3e:bc"

 

ethernet2.generatedAddressOffset = "20"

 

ethernet2.pciSlotNumber = "18"

 

ethernet2.present = "true"

 

ethernet2.startConnected = "true"

 

ethernet2.virtualDev = "e1000"

 

ethernet2.vnet = "vmnet2"

 

ethernet3.addressType = "generated"

 

ethernet3.connectionType = "custom"

 

ethernet3.generatedAddress = "00:0c:29:9e:3e:c6"

 

ethernet3.generatedAddressOffset = "30"

 

ethernet3.pciSlotNumber = "19"

 

ethernet3.present = "true"

 

ethernet3.startConnected = "true"

 

ethernet3.virtualDev = "e1000"

 

ethernet3.vnet = "vmnet5"

 

ethernet4.present = "FALSE"

 

extendedConfigFile = "dmzlb-10.1.0.3341.1084.vmxf"

 

floppy0.present = "FALSE"

 

guestOS = "other"

 

guestOSAltName = "BIGIP-10.1.0.3341.1084"

 

ide0:0.fileName = "dmzlb-10.1.0.3341.1084.vmdk"

 

ide0:0.mode = "persistent"

 

ide0:0.present = "true"

 

ide0:0.redo = ""

 

ide0:0.startConnected = "true"

 

ide0:0.writeThrough = "true"

 

memsize = "1024"

 

numvcpus = "1"

 

nvram = "luxor.nvram"

 

replay.filename = ""

 

replay.supported = "FALSE"

 

tools.remindInstall = "false"

 

tools.syncTime = "false"

 

tools.upgrade.policy = "manual"

 

uuid.bios = "56 4d 2a 5c fe 1c d4 81-ec 0b 8c 9e f1 9e 3e a8"

 

uuid.location = "56 4d 5d e8 c3 c6 fc 40-bf 2f 44 47 d5 82 7c 8d"

 

virtualHW.productCompatibility = "hosted"

 

virtualHW.version = "7"

 

vmotion.checkpointFBSize = "65536000"

 

----------------------------------------------------------------------------------------------

 

 

Adding interfaces to the BIG-IP is as simple as adding vmnets in the locations file above and adding interfaces to your VMX. It should be clear from the examples what you need to do. Pay attention to the generatedAddressOffset and use it to calculate your MACs correctly.

 

 

Dave

 

I just noticed this in /config/tmm_base.tcl:

 

----------------------------------------------------------------------------------------------

 

 

if { [string compare $platform "C36"] == 0 } {

 

scheduler::rtc_frequency 2048

 

scheduler::sleep_range 122070 1000000

 

} elseif { [string compare $platform "Z99"] == 0 } {

 

scheduler::sleep_range 1000000 1000000

 

VirtualBox has a disagreeable LAPIC. Workaround by using the RTC

 

if { [ file exists "/var/run/VirtualBox" ] } {

 

scheduler::rtc_frequency 256

 

scheduler::use_rtc true

 

} else {

 

scheduler::rtc_frequency 1024

 

scheduler::use_rtc false

 

}

 

}

 

----------------------------------------------------------------------------------------------

 

and this in dmesg:

 

----------------------------------------------------------------------------------------------

 

ENABLING IO-APIC IRQs

 

..TIMER: vector=0x31 apic1=0 pin1=2 apic2=0 pin2=0

 

Using local APIC timer interrupts.

 

WARNING calibrate_APIC_clock: the APIC timer calibration may be wrong.

 

 

 

 

ACPI: Using IOAPIC for interrupt routing

 

ACPI: PCI Root Bridge [PCI0] (0000:00)

 

* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,

 

* this clock source is slow. Consider trying other clock sources

 

 

 

 

Assertion failed! tmict >= tmcct,/home/f5cm/cm/bigip10.1.0-luxor/90741/f5_build/BUILD/lapict-10.1.0/main.c,countdown,line=852

 

Assertion failed! tmict >= tmcct,/home/f5cm/cm/bigip10.1.0-luxor/90741/f5_build/BUILD/lapict-10.1.0/main.c,countdown,line=852

 

Assertion failed! tmict >= tmcct,/home/f5cm/cm/bigip10.1.0-luxor/90741/f5_build/BUILD/lapict-10.1.0/main.c,countdown,line=852

 

Assertion failed! tmict >= tmcct,/home/f5cm/cm/bigip10.1.0-luxor/90741/f5_build/BUILD/lapict-10.1.0/main.c,countdown,line=852

 

Assertion failed! tmict >= tmcct,/home/f5cm/cm/bigip10.1.0-luxor/90741/f5_build/BUILD/lapict-10.1.0/main.c,countdown,line=852

 

 

----------------------------------------------------------------------------------------------

 

 

So on Xen you might want to touch /var/run/VirtualBox

 

Anyone had success with KVM? If so.. tips are welcome =D