You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Matthew Midgett <cl...@trick-solutions.com.INVALID> on 2014/12/15 14:47:24 UTC
Virtual Router - Strange issue - Cloud-init
ACS 4.4.2 and Xenserver 6.2
When I try to deploy a template that is using cloud-ini and the VR is on the
other the VM can't connect to the meta data. When the VR and VM is on the
same host it works with no issue and now that I have migrated the VR back a
forth a few times it not an issue until the VM reboots and then it can't
connect to the VR unless it's on the same host. DHCP is working fine no
matter what host the VR is on. What could be causing this? Even when I can't
get the meta data I can ping the VR so I don't think it's a physical network
issue.
Tested getting meta data like this curl http://VR-IP/latest/meta-data/
Matthew Midgett
Re: Virtual Router - Strange issue - Cloud-init
Posted by Paul Omamogho <om...@icloud.com>.
Have you checked to ensure the entire VLAN Guest traffic ranges e.g. 500 - 550 specified in CS are subsequently tagged?
> On 15 Dec 2014, at 18:52, Matthew Midgett <cl...@trick-solutions.com.INVALID> wrote:
>
> Correct that is the way that I have it setup. CS creates a tagged network as
> shown in this example
> http://mirror.charlottecolo.com/cloudstack/xennetwork.jpg
>
> All the VM's can ping its gateway on the router. All the VM can ping any
> public address. The VM's can only ping the VM's on their hypervisor where
> the VR is.
>
>
>
> -----Original Message-----
> From: Paul Omamogho [mailto:omamogho@icloud.com]
> Sent: Monday, December 15, 2014 12:37 PM
> To: users@cloudstack.apache.org
> Subject: Re: Virtual Router - Strange issue - Cloud-init
>
> Hi Matthew,
>
> To my understanding your guest Nic in XenServer and CS should remain
> untagged while the associated VLAN ports in your Switch should be tagged.
>
> Cheers,
>
> Paul
>
>> On 15 Dec 2014, at 16:44, Matthew Midgett
> <cl...@trick-solutions.com.INVALID> wrote:
>>
>> I have advanced shared networking with a public address being assigned
>> to each VM. The VR doesn't show having a public IP this way but the
>> guest IP is a public one. Should I change the Vlans and trunks to
>> having a private address and let the VR setup the default networking
>> with a private range and let it do NAT the way that ACS was designed?
>>
>> Just tried to ping the VR again from a VM on another host and I can't.
>> I can ping the gateway which means the Vlans and trunking and cabling
>> are fine. Can ping the VR from the public IP all the time. Also can
>> ping the VR from both hypervisors using it's public.
>>
>> If 2 VM and VR are on the same host then pings work between them.
>>
>> Just logged into the VR and I can ping the address of the VM's that
>> are on the same host but not the one on the other host.
>>
>>
>> -----Original Message-----
>> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
>> Sent: Monday, December 15, 2014 8:47 AM
>> To: users@cloudstack.apache.org
>> Subject: Virtual Router - Strange issue - Cloud-init
>>
>> ACS 4.4.2 and Xenserver 6.2
>>
>>
>>
>> When I try to deploy a template that is using cloud-ini and the VR is
>> on the other the VM can't connect to the meta data. When the VR and VM
>> is on the same host it works with no issue and now that I have
>> migrated the VR back a forth a few times it not an issue until the VM
>> reboots and then it can't connect to the VR unless it's on the same
>> host. DHCP is working fine no matter what host the VR is on. What
>> could be causing this? Even when I can't get the meta data I can ping
>> the VR so I don't think it's a physical network issue.
>>
>>
>>
>> Tested getting meta data like this curl http://VR-IP/latest/meta-data/
>>
>>
>>
>> Matthew Midgett
>>
>>
>
>
RE: Virtual Router - Strange issue - Cloud-init
Posted by Matthew Midgett <cl...@trick-solutions.com.INVALID>.
Correct that is the way that I have it setup. CS creates a tagged network as
shown in this example
http://mirror.charlottecolo.com/cloudstack/xennetwork.jpg
All the VM's can ping its gateway on the router. All the VM can ping any
public address. The VM's can only ping the VM's on their hypervisor where
the VR is.
-----Original Message-----
From: Paul Omamogho [mailto:omamogho@icloud.com]
Sent: Monday, December 15, 2014 12:37 PM
To: users@cloudstack.apache.org
Subject: Re: Virtual Router - Strange issue - Cloud-init
Hi Matthew,
To my understanding your guest Nic in XenServer and CS should remain
untagged while the associated VLAN ports in your Switch should be tagged.
Cheers,
Paul
> On 15 Dec 2014, at 16:44, Matthew Midgett
<cl...@trick-solutions.com.INVALID> wrote:
>
> I have advanced shared networking with a public address being assigned
> to each VM. The VR doesn't show having a public IP this way but the
> guest IP is a public one. Should I change the Vlans and trunks to
> having a private address and let the VR setup the default networking
> with a private range and let it do NAT the way that ACS was designed?
>
> Just tried to ping the VR again from a VM on another host and I can't.
> I can ping the gateway which means the Vlans and trunking and cabling
> are fine. Can ping the VR from the public IP all the time. Also can
> ping the VR from both hypervisors using it's public.
>
> If 2 VM and VR are on the same host then pings work between them.
>
> Just logged into the VR and I can ping the address of the VM's that
> are on the same host but not the one on the other host.
>
>
> -----Original Message-----
> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
> Sent: Monday, December 15, 2014 8:47 AM
> To: users@cloudstack.apache.org
> Subject: Virtual Router - Strange issue - Cloud-init
>
> ACS 4.4.2 and Xenserver 6.2
>
>
>
> When I try to deploy a template that is using cloud-ini and the VR is
> on the other the VM can't connect to the meta data. When the VR and VM
> is on the same host it works with no issue and now that I have
> migrated the VR back a forth a few times it not an issue until the VM
> reboots and then it can't connect to the VR unless it's on the same
> host. DHCP is working fine no matter what host the VR is on. What
> could be causing this? Even when I can't get the meta data I can ping
> the VR so I don't think it's a physical network issue.
>
>
>
> Tested getting meta data like this curl http://VR-IP/latest/meta-data/
>
>
>
> Matthew Midgett
>
>
Re: Virtual Router - Strange issue - Cloud-init
Posted by Paul Omamogho <om...@icloud.com>.
Hi Matthew,
To my understanding your guest Nic in XenServer and CS should remain untagged while the associated VLAN ports in your Switch should be tagged.
Cheers,
Paul
> On 15 Dec 2014, at 16:44, Matthew Midgett <cl...@trick-solutions.com.INVALID> wrote:
>
> I have advanced shared networking with a public address being assigned to
> each VM. The VR doesn't show having a public IP this way but the guest IP is
> a public one. Should I change the Vlans and trunks to having a private
> address and let the VR setup the default networking with a private range and
> let it do NAT the way that ACS was designed?
>
> Just tried to ping the VR again from a VM on another host and I can't.
> I can ping the gateway which means the Vlans and trunking and cabling are
> fine. Can ping the VR from the public IP all the time. Also can ping the VR
> from both hypervisors using it's public.
>
> If 2 VM and VR are on the same host then pings work between them.
>
> Just logged into the VR and I can ping the address of the VM's that are on
> the same host but not the one on the other host.
>
>
> -----Original Message-----
> From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
> Sent: Monday, December 15, 2014 8:47 AM
> To: users@cloudstack.apache.org
> Subject: Virtual Router - Strange issue - Cloud-init
>
> ACS 4.4.2 and Xenserver 6.2
>
>
>
> When I try to deploy a template that is using cloud-ini and the VR is on the
> other the VM can't connect to the meta data. When the VR and VM is on the
> same host it works with no issue and now that I have migrated the VR back a
> forth a few times it not an issue until the VM reboots and then it can't
> connect to the VR unless it's on the same host. DHCP is working fine no
> matter what host the VR is on. What could be causing this? Even when I can't
> get the meta data I can ping the VR so I don't think it's a physical network
> issue.
>
>
>
> Tested getting meta data like this curl http://VR-IP/latest/meta-data/
>
>
>
> Matthew Midgett
>
>
RE: Virtual Router - Strange issue - Cloud-init
Posted by Matthew Midgett <cl...@trick-solutions.com.INVALID>.
I have advanced shared networking with a public address being assigned to
each VM. The VR doesn't show having a public IP this way but the guest IP is
a public one. Should I change the Vlans and trunks to having a private
address and let the VR setup the default networking with a private range and
let it do NAT the way that ACS was designed?
Just tried to ping the VR again from a VM on another host and I can't.
I can ping the gateway which means the Vlans and trunking and cabling are
fine. Can ping the VR from the public IP all the time. Also can ping the VR
from both hypervisors using it's public.
If 2 VM and VR are on the same host then pings work between them.
Just logged into the VR and I can ping the address of the VM's that are on
the same host but not the one on the other host.
-----Original Message-----
From: Matthew Midgett [mailto:cloudstck@trick-solutions.com.INVALID]
Sent: Monday, December 15, 2014 8:47 AM
To: users@cloudstack.apache.org
Subject: Virtual Router - Strange issue - Cloud-init
ACS 4.4.2 and Xenserver 6.2
When I try to deploy a template that is using cloud-ini and the VR is on the
other the VM can't connect to the meta data. When the VR and VM is on the
same host it works with no issue and now that I have migrated the VR back a
forth a few times it not an issue until the VM reboots and then it can't
connect to the VR unless it's on the same host. DHCP is working fine no
matter what host the VR is on. What could be causing this? Even when I can't
get the meta data I can ping the VR so I don't think it's a physical network
issue.
Tested getting meta data like this curl http://VR-IP/latest/meta-data/
Matthew Midgett