Ok, well thanks for confirmation of my findings. So i tested creating VMs with API and it is indeed working like it should. VR gets an alias for the additional subnet and dhcp is working as expected.
I assume the alias is determined from the gateway on the nic. So the flaw is in updateVmNicIp which doesn't update the gateway for the nic when the IP is from a different subnet. This isn't that critical, but i'll look into it later. Regards On Wed, 2016-05-18 at 17:24 +0200, Ronald van Zantvoort wrote: > On 18/05/16 17:10, Linas Žilinskas wrote: > > This is in relation to https://github.com/apache/cloudstack/pull/1547 > > But since it seems that my observations are beyond the scope of it, I'm > > posting it here. > > > > I'm having hard time understanding what's going on, but something seems > > off. > > Like i mentioned in the PR comments, I'm using advanced networking with > > security groups, so my setup is different to the PR which is meant for > > Simple zones. > > > > My setup consists of initial zone deployment, with defaultGuestNetwork. > > Then i created a new guest (through infrastructure) network with > > 172.40.0.0/24, xx.1 gateway. > > Then added additional subnet 172.50.0.0/24, xx.1 gateway. > > Created a VM through web ui, which automatically got ip from > > 172.40.0.0/24 > > Everything seems fine up to this point. > > > > Now I changed the ip to 172.50.0.xx through web ui. (interesting point - > > the gateway doesn't change when IP is assigned from different subnet for > > VM) > > > > Restarted VM / deleted VR. > > And here's where i don't understand things anymore. > > VR got assined an IP alias (original 172.40.0.10, additional > > 172.40.0.11). > > > > I would guess it would need 172.50.0.xx to serve the additional subnet > > (dhcp / metadata) > > That is correct and it's one of the major things my PR fixes. You should > find in /var/log/cloud.log references to unparsed/unparseable ipalias.json. > > That JSON contains all alias info: > cat /var/cache/cloud/processed/ip_aliases.json.1462968045 > {"aliases":[{ > "revoke":false,"ip_address":"172.50.0.11","netmask":"255.255.255.0","count":141 > },{ > "revoke":false,"ip_address":"172.40.0.11","netmask":"255.255.255.0","count":152 > }],"type":"ipaliases"} > > The proposed PR parses through this file and sets up IP, DHCP, metadata > etc for each alias. > > > > > Some confirmation would be nice if this is the intended behavior and if > > a situation like this is not supported / tested. Or is there some bug > > somewhere. > > > > PS. I started looking into why the VR (4.8 release) dhcp doesn't serve > > additional subnets. Found the above PR and was hoping it solves the > > issue. But it seems there might be some problems above the VR as well. > > > The part where stuff seems weird in your case is that you got an > additional alias in the wrong range, which would seem to have to > originate from the CS mgr & db or an error in configuration. >
