Im running 2 IBM rack servers with ESX 4 on both.
Ive got a strange issue with network performance when my virtual ASG V7 box and virtual servers are located on the same esx host. Look at the image for 3 different scenarios:
If these weren't virtual machines, I would suspect an incompatibility between the configurations of the Ethernet adapters. Is there an MTU definition that might be causing problems between the two VMs?
a) from where do you measure access speed? b) is access always done through the ASG? c) Does it affect performance if you change the ASG settings (e.g. turn off the IPS if enabled)? d) How is access speed generally inbetween two VMWare machines on a single ESX server? e) AFAIK Astaro does not officially support ESX 4 yet, but just ESX 3.
Some questions: 1. Is the server slow at anytime? 2. Is a general slowdown or only in the case connections are coming from a specific interface? 3. have you configured any bandwidth pool on the vmware? 4. have you tried to reserve some CPU and RAM usage on the hypervisor for this virtual machine? 5. have you tcpdumped the network flow to figure out where the slowdown is coming from? 6. which kind of switch is between the VMWARE esx servers?
Has anyone figured anything out about this? I am seeing a similar issue. In my setup I have 3 ESXi hosts in a cluster mode. Any VM's running on the same physical host as the Astaro VM run really slow, seems like network access speed is the cause. All stats for that specific VM host are low, usage is low, network is low etc. If I vmotion a vm to another physical server its like night and day speed wise, the only difference being is said VM on the same physical server or not as an Astaro VM.
I am having the same problem. I am running vSphere 4 in a 2 host cluster. If I have VM's on the same ESX host as the astaro appliance I get slow performance. If I vMotion the astaro appliance to another host then the VM's on the ESX host that had the problem return to normal conditions, however then the VM on the NEW host start experience slowness.
I did not use vconverter to convert, however I did download it from the VMware Virtual Appliance store. Has anyone else confirmed that a clean reinstall of the astaro appliance will fix this or is it something else?
Running a single ESXi 4.0u2 host with Astaro 8.0 and a couple of other VM's on it. Astaro WAN is two ADSLs with uplink balancing.
- Access from internet to VMs on the ESXi host is painfully slow. - Access from internet to physical computers on LAN behind ESXi/Astaro is fine. - Access from physical computers on LAN to VMs on ESXi is fine. - Access between VMs on ESXi is fine - Tried deploying Astaro from .ovf and fresh install from iso - same performance - Tried with two different VMs on ESXi - same performance - Tried access through both ADSLs - same performance. - Tried using vmxnet3 adapters instead of flexible in the Astaro VM
Only thing I can come up with is that I'm running VM hardware version 7 (vSphere). I changed the .ovf deployment from v4 to v7 as well - in order to use more interfaces.
Before upgrading I had an Astaro v7.5 running fine with VM hardware version 7. - However, I did use E1000 adapters in that VM
Will try fresh .ovf deployment with v4 hardware tonight. - might try v7 hardware with E1000 adapters as well.
I switched to E1000 adapters instead of the "flexible" and "vmxnet3" adapters previously used - and everything now seems to run smoothly again.
Still running the guest as VMware hardware version 7, by the way.
I will be doing some more tests tomorrow. But the problem seems to be solved for me. [:)]
Edit 16/7-2010: Yup, performance is back to v7.5 standards when E1000 adapters are used. Must be an issue with the VMWare driveres in the ISO/Appliance.
Yes changing the network adapters from Flexable to E1000 fixes the issue. This worked for me with the latest Astaro ESX v4 Appliance ASG 8.300. I had the same issue with all VMs on the save server having extremely slow internet connection. Physical hosts on the network worked fine going through the ASG VMs for internet access.