In the first go-around, not sure what do you mean DNS didn't work. I assume you could ping www.google.com ? The cloudstack DHCP systemvm will forward DNS requests that it cannot resolve with its own /etc/hosts to the 'zone' DNS server.
In the second go-around it is probably expected behavior, but I cannot say for sure. CloudStack implements anti-spoofing at the hypervisor level, so if the packet coming out of the VM does not have a source ip/mac it doesn't know about, it instructs the hypervisor to drop it. In this case since the ip was assigned by a DHCP server not controlled by CloudStack this will most likely result in a dropped packet. You could try logging into the hypervisor and execute ebtables -F On 3/12/13 4:48 AM, "Wei Leong" <wle...@blackducksoftware.com> wrote: >Nope, basic networking the second time too. > >On Mar 12, 2013, at 1:25 AM, "Chiradeep Vittal" ><chiradeep.vit...@citrix.com> wrote: > >> Is the second go-around using advanced networking? >> >> On 3/10/13 1:54 PM, "Wei Leong" <wle...@blackducksoftware.com> wrote: >> >>> It seems I am having a lot of trouble setting up even the simplest of >>> cloudstack networking configurations. >>> >>> A quick background on my setup: >>> >>> The kvm host is part of a network of machines that gets their IPs from >>> the router. I intend to set up cloudstack to extend our development >>> infrastructure, VMs in the cloud will function just like physical >>> machines on the network and depend on the router for dhcp and dns. My >>> intention is to have cloudstack manage the provisioning of VMs and >>> provide analysis of the cloud resources (memory, storage etc). Pretty >>> straightforward stuff here. >>> >>> My initial setup actually worked out ok - I created a zone with basic >>> networking (DefaultSharedNetworkOfferingWithSGService) and guest VMs >>>were >>> assigned IPs according to the range I specified. The VMs had access to >>> the internet and were able to connect to other machines on the network, >>> but DNS did not work. My sys admin was also curious about whether the >>> virtual router was leasing out IPs to physical machines on the network, >>> could this happen? Is is better for hosts to have static IP addresses? >>> >>> I then scratched the initial setup and created a new network offering >>> without DHCP, and used that instead. For this configuration, no virtual >>> router came up, VMs seem to be getting IPs from the external router, >>>but >>> none of them can connect to physical machines on the network/the >>>internet. >>> >>> I feel like i'm close to getting the right configuration, and might >>>just >>> be missing a small detail. I'm not ready to give up yet, even though >>>I'm >>> out of ideas at this point. Any suggestions/help is much appreciated. >>> Thanks for reading! >>> >>> Wei >>> >>> >>> On Mar 7, 2013, at 6:22 PM, Bryan Whitehead >>> <dri...@megahappy.net<mailto:dri...@megahappy.net>> wrote: >>> >>> Create a new network offering without DHCP. After you do that create a >>>new >>> guest network using that network offering / vlan. >>> >>> >>> On Thu, Mar 7, 2013 at 8:58 AM, Wei Leong >>> >>><wle...@blackducksoftware.com<mailto:wle...@blackducksoftware.com>>wrote >>>: >>> >>> Is there an easy way from the UI to create a network without using the >>> virtual router? I'm running configured cloudstack with basic networking >>> and >>> the cloudstack server sits in our network that already has a >>>dhcp/server >>> setup. I would like my guest VMs to just that instead of the virtual >>> router. >>> >>> According to this blog it is possible but only through the API, is >>>there >>> an alternative? >>> >>> >>>http://blog.remibergsma.com/2012/03/10/howto-create-a-network-in-cloudst >>>ac >>> k-without-a-virtual-router/ >>
