• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

vCloud networking

TeeJayHoward

TeeJayHoward

Limpness Supreme
2FA
Joined
Feb 8, 2005
Messages
13,311
I can't figure out what's going on here.
vCloud director 1.5.1

1) Create a VM in a vApp. (RHEL6.3, in my example)
2) Create an isolated vApp network. (192.168.2.x)
3) Assign the VM an IP on that isolated network. (192.168.2.103)

Why can this VM not ping the gateway created by vCloud (192.168.2.1)? If I create multiple VMs, and assign them to the same network, they cannot ping each other. What am I doing wrong?
 
Is the VM's firewall turned off already? Connection might be good and its the firewall that wont let them ping each other, just guessing though. - n00b here :)
 
Were you not the one who installed vCloud Director? Maybe you could involve that person and see what they can find. The issue can vary depending on the type of network isolation used.
 
Oih. Ok, this is gonna be hard. You need to go out to the org network and see how it is configured, and possibly how the provider VDC network is configured.
 
0V3RC10CK3D said:
Were you not the one who installed vCloud Director? Maybe you could involve that person and see what they can find. The issue can vary depending on the type of network isolation used.
Click to expand...
I was handed an Org, and asked to make two VMs talk to each other by the guy who set it up. They can communicate just fine if I connect them to the physical network and use IPs associated with that VLAN, but if I create an isolated network, it doesn't work.

lopoetve said:
Oih. Ok, this is gonna be hard. You need to go out to the org network and see how it is configured, and possibly how the provider VDC network is configured.
Click to expand...
Another acronym for me to look up. VDC.
 
Provider VDC (Virtual Data Center) = The cluster or resource pool providing resources to vCloud
Org VDC (Virtual Data Center) = A segmentation of the resources for one Organization.

It could be that you do not have enough networks allocated to your Org VDC to create an isolated network. The guy who set it up will know most likely.
 
It looks like it was an OS issue. I created a new CentOS VM from scratch. It can't ping the gateway, but it can ping one of the RHEL VMs. The other RHEL VM can't talk to anything. It's got me scratching my head as to why, as it appears to be identically configured to the good one.

edit: Got some more info. Apparently, when I do a "Copy to", the copy of the VM will not function correctly. Any newly-created-from-scratch VMs have network access.

edit2: The same thing happens when I deploy from the catalog. Only one VM from the catalog works. Example:

I deploy VM1 from the catalog. It works great.
I then deploy VM2 from the same catalog entry as VM1. VM1 no longer works. VM2 does.
I then deploy VM3 from the same catalog entry as VM1. VM1 and VM2 no longer work. VM3 works fine.
I create a new VM (VM4) from scratch. It works great.
I copy VM4 to VM5. VM5 doesn't work.

What the heck is going on?

Edit3: Apparently, all the methods of adding a VM to the vApp are not created equal. The ONLY way that works 100% of the time is hitting the little green plus under the Virtual Machines tab, and deploying something from the catalog that way. (Nope! See below!)

Edit4: I had all of the VMs in the vApp talking to each other. Then I rebooted the vApp. Now two VMs can communicate with each other but nobody else. The other three can communicate amongst themselves, but not to the first two. What. The. Hell.

Edit5: I add a new VM. It can talk to the first two. I add another. It can't talk to anyone. Something's going on!
 
Last edited:
Different methods of customization. $5 the RHEL based stuff isn't getting a network card it understands due to udev hilarity.
 
lopoetve said:
Different methods of customization. $5 the RHEL based stuff isn't getting a network card it understands due to udev hilarity.
Click to expand...
More info... I think I may have tracked it down.

Code: 
VM	IP	HOST
====================
0	.100	6
1	.101	6
2	.102	5
3	.103	5
4	.104	5
5	.105	7
6	.199	7

VM0 can communicate with VM1, but not 2-6.
VM1 can communicate with VM0, but not 2-6.
VM2 can communicate with VM3+4, but not any other VM.
...etc.

It looks to me like the VMs can only talk to other VMs on the same host. What would cause this, and how can I fix it?
 
I need to see how the networks are configured, and you're on a version of vCD I'm not super familiar with.
 
Yeah..would like to see some screenshots if possible...kind of asking for internal info..that may not be a good thing though...
 
Yea we'll need some detailed networking info to figure out what. Sounds like vlans aren't trunked properly on a switch.

Can you call VMwares Global Support Services? Not sure if you want to post all that info here
 
0V3RC10CK3D said:
Yea we'll need some detailed networking info to figure out what. Sounds like vlans aren't trunked properly on a switch.

Can you call VMwares Global Support Services? Not sure if you want to post all that info here
Click to expand...
I can, and probably will sometime today or tomorrow. We're paying for a support contract. Might as well use it. I doubt any of our networking information's super-top-secret - it's just a class A network. That being said, the info's not really mine to give out.

I'll try to remember to post the results of the support call here.
 
TeeJayHoward said:
I can, and probably will sometime today or tomorrow. We're paying for a support contract. Might as well use it. I doubt any of our networking information's super-top-secret - it's just a class A network. That being said, the info's not really mine to give out.

I'll try to remember to post the results of the support call here.
Click to expand...

PM me the SR - I'll make sure it gets to good people.
 
lopoetve said:
PM me the SR - I'll make sure it gets to good people.
Click to expand...
I appreciate that. It may need to wait until next week, though. I'm working a priority 1 backup issue (tape drives failing), which I'll follow up with another priority 1 issue (essential servers have NEVER been backed up properly)... Then I'll get to it. While I'm working these, a coworker's actually upgrading our vCloud environment to 5.5.1, so who knows. The problem may even go away on it's own!
 
You must log in or register to reply here.
Back
Top