I have new DellEMC server having 4 physical ports and installed ESXI 6.0 successfully
2 ports - management network
2 ports - data network
when i connect 2 ports from physical switch by making port-channel / lacp to vmware machine
there is shown following error:
Port-channel14 is down, line protocol is down (notconnect)
Hardware is EtherChannel, address is 0000.0000.0000 (bia 0000.0000.0000)
Description: CONN_MBL_UAT_VM_NEW MTU 1500 bytes, BW 100000 Kbit/sec,
DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Auto-duplex,
Auto-speed, link type is auto, media type is input flow-control is
on, output flow-control is unsupported ARP type: ARPA, ARP Timeout
04:00:00 Last input never, output never, output hang never Last
clearing of "show interface" counters never
...
please help me to solve the issue and also i have query "may i able to achieve lacp without vsphere only from vmware"
if you want to configure LACP you need a switch that support this feature with protocol 802.3ad with route ip hash enable. Then the first step is configure lacp on vmware and finally enable Lacp on switch. I attach some docs with examples.
https://kb.vmware.com/s/article/1001938
Any question let me know.
Related
I'm trying to host a Spigot Minecraft 1.12.2 Server using Ubuntu, The server has been properly set up and is working properly, The ping however isn't really great, I am playing from India and the server VM instance region has been set to Germany-Frankfurt, I should be getting anywhere between 130-200ms latency but It's always above 300 or even 1000 at times, I did tracert using windows CMD terminal and the packets seem to go to U.S.A first and then to Germany, I asked several of my friends to ping the server and they all get the same result. How can I fix this? Is there any way to route packets straight to Germany Instead of going to the U.S first?
Made a new Instance in Mumbai Region, India, which is where I live, I'm getting 3 Ping while on the server select menu, but upon joining it jumps to 200.
I expect around 130-160 ping, which is what I get on other servers on that region, Other players who live near Germany are getting high pings, I can't make this server public with a major issue like this.
Have a look at the network map on this page: https://cloud.google.com/about/locations/#network-tab
As you can see, Google's network is not connected between Europe and India - therefore traffic has to take a detour around the other side of the world through Asia and the US.
Within a region, so from Germany to Germany and from India to India, you should however achieve low latency.
Probably you're experiencing this issue due to instance's machine type and CPU's count.
As stated in the documentation:
"Outbound or egress traffic from a virtual machine is subject to maximum network egress throughput caps. These caps are dependent on the number of vCPUs that a virtual machine instance has. Each core is subject to a 2 Gbits/second (Gbps) cap for peak performance. Each additional core increases the network cap, up to a theoretical maximum of 16 Gbps for each virtual machine".
Having so little information about your setup i cannot help you further unfortunately.
Please provide more information about your setup and your customer's needs.
For example, who will your customers be? From which country? Is this the reason why you're using an European region for your services while you live in India?
From some reason download traffic from virtual machine on GCP (Google Cloud Platform) with Debian 9 is limited to 50K/s? Upload seems to be fine, inline with my local upload link.
It is the same with scp or https download. Any suggestions what might be wrong, where to search?
Machine type
n1-standard-1 (1 vCPU, 3.75 GB memory)
CPU platform
Intel Skylake
Zone
europe-west4-a
Network interfaces
Premium tier
Thanks,
Mihaelus
Simple test:
wget https://hrcki.primasystems.si/Nova/assets/download.test.html
Output:
--2018-10-18 15:21:00-- https://hrcki.primasystems.si/Nova/assets/download.test.html Resolving
hrcki.primasystems.si (hrcki.primasystems.si)... 35.204.252.248
Connecting to hrcki.primasystems.si
(hrcki.primasystems.si)|35.204.252.248|:443... connected. HTTP request
sent, awaiting response... 200 OK Length: 541422592 (516M) [text/html]
Saving to: `download.test.html.1' 0% [] 1,073,152 48.7K/s eta
2h 59m
Always good to minimize variables when trying to diagnose. So while it is unlikely the use of HTTP is why things are that very slow, you might consider using netperf or iperf3 to measure TCP bulk transfer performance between your VM in GCP and your local system. You can do that either "by hand" or via PerfKit Benchmarker https://cloud.google.com/blog/products/networking/perfkit-benchmarker-for-evaluating-cloud-network-performance
It can be helpful to have packet traces - from both ends when possible - to look at. You want the packet traces to be started before the test - it is important to see the packets used to establish the TCP connection(s). They do not need to be "full packet" traces, and often you don't want them to be. Capturing just the first 96 bytes of each packet would be sufficient for this sort of investigating.
You might also consider taking snapshots of the network statistics offered by the OSes running in your GCP VM and local system. For example, if running *nix taking a snapshot of "netstat -s" before and after the test. And perhaps a traceroute from each end towards the other.
Network statistics and packet traces, along with as many details about the two endpoints as possible are among the sorts of things support organizations are likely to request when looking to help resolve an issue of this sort.
We are working on VMware and HA and DRS are enabled on a cluster. We want to set CPU threshold for every host i.e. if cpu utilization goes above 80% vm's move automatically.
Thanks in advance
Details
You receive an event message when the number of phisycal cpu on the host exceeds their limit.
This occurs when clients register more cpu on an ESXi host than the host can support.
Impact
If the limit is exceeded, the management agent is at risk of running out of system resources. Consequently, VMware vCenter Server might stop managing the corresponding ESXi host.
Solution
To ensure management functionality, restrict the number of Pcpu to the limit indicated by the VMkernel.Boot.maxPCPUS property of the ESXi host.
To lower the value of maximum number of allowed registered pcpu:
Edit the VMkernel.Boot.maxPCPUS variable by selecting the host in vCenter Server.
Open the Configuration tab and select Advanced Options in the Software box.
Expand the VMkernel option and click Boot.
Alter the value in the text box to the right of the VMkernel.Boot.maxPCPUS variable.
Hope to be useful ;)
during the last week I spent all my time trying to access the MCF in offline mode. I'm working behind a company network (proxy) and the MCF try to do things that conflict with the local network.
I've followed several different tutorials such as 1. Working offline with MCF and 2. Working offline with MCF. But the result keeps the same, even if I change all sort of configuration on my ubuntu.
Trying to set up the target.
vm target http: //api.mycloud.me
HTTP exception: Errno::ECONNREFUSED:Connection refused - connect(2)
The MCF console show the following information:
Identity: mycloud.me (ok)
Admin: admin#mycloud.me
IP address 10.0.x.x (network up / offline)
When I ping to the IP address, I got positive return.
PING 10.0.x.x (10.0.x.x) 56(84) bytes of data.
64 bytes from 10.0.x.x: icmp_req=1 ttl=62 time=1.06 ms
64 bytes from 10.0.x.x: icmp_req=2 ttl=62 time=0.896 ms
64 bytes from 10.0.x.x: icmp_req=3 ttl=62 time=0.880 ms
--- 10.0.2.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.880/0.948/1.069/0.089 ms
But if I try to do a telnet to the port 80 or a ssh I got connection refused error.
ssh: connect to host mycloud.me port 22: Connection refused
I don't know what I need to do to fix this, if anyone have a tip that help me to figure out a solution, I'll be very thankful.
Cheers!
OK dudes! That I fixed it!
So, after some problems to understand what was happening, I could finally connect to the Micro Cloud. I'm still validating the information from the two tutorials above, because could have some conflicted data.
I didn't test if it is necessary to set a nameserver to the dhclient, but the second tutorial seems to be more reliable. Just one tip, run the ssh -L tunnel on a separate terminal, and leave it open. This wasn't so clear for people like me, that was not used to working with network administration.
Thanks for the help.
given the assigned IP address, it looks like you are using bridged networking, have you tried changing the VM configuration to use NAT instead?
This will use an interface exclusive to your local machine and the VM and shouldn't be affected by your corporate network.
I have a rather interesting problem. We have 2 networks at work that are physical duplicates of each other (network A and network B). They just run on different subnets.
I am working on some fault tolerance improvements for our devices that cluster with each other on the network. One of the test cases that I am exercising is the behaviour of these devices when a misconfiguration is introduced. For example, lets say I have two devices with the following interface configurations:
Device X
IP: 10.200.234.127
Subnet Mask: 255.255.254.0
Default Gateway: 10.200.234.1
Device Y
IP: 10.200.234.127
Subnet Mask: 255.255.254.0
Default Gateway: 10.200.234.1
These 2 devices discover each other via the broadcast of cluster heartbeats. The heartbeats contain the devices ip address, etc which allows them to then establish communication with each other. Pretty standard stuff. Now, lets say I introduce a network misconfiguration such that one of these devices is configured for a different sunbet:
Device X
IP: 192.168.1.115
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1
What happens here is that both devices still learn about each other from the cluster broadcasts (they are physically connected together on the same switch). However, as you would expect, they cannot communicate with each other as expected. However, I am seeing some strange behaviour with respect to connect timeouts when these devices attempt to communicate with each other. For example, if the devices are connected on network A, the connection attempts timeout within a few seconds which is great. Now, if I place both devices on network B I see a completely different behaviour. On network B, the connect() calls to establish socket connections between the devices do not fail quickly. Rather, they fall into this backoff and retransmit cycle that takes 189 seconds to finally give up ( retransmits at 3, 6, 12, 24, 48, and 96 seconds as verified with wireshark).
So what I am wondering is, why does the connect() call fail so rapidly in network A and not in network B. I have tried using blocking sockets and a call to connect() as well as non-blocking sockets and a call to connect() followed by a call to select(). In both cases I cannot get the connect to give up any sooner than 189 seconds. I know that I can impose a shorter timeout in the call to select and give up much sooner but that is not the point here. I am trying to understand what could possibly be different on these 2 networks that is causing this issue.
Maybe you should give more addresses? It's not clear exactly what the IPs are.
My guess is that:
In the slow case you're getting ARP failures (no response because target has incorrect netmask)
In the fast case you're getting a routing failure. If the host has an incorrect smaller netmask it won't even attempt ARPs.
Please try to strace blocking sockets, error code should be different.