[ https://issues.apache.org/jira/browse/CLOUDSTACK-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13692773#comment-13692773 ]
Bharat Kumar commented on CLOUDSTACK-2644: ------------------------------------------ Earlier we used to use the eth0 ip of the router (http://eth0Ip/latest/userdata) to get the userdata. now with the multiple subnets the user data needs to be accessed by the name data-server (http://data-server/latest/userdata). We used to fetch the eth0 ip of the router from the dhcp files in the VM. For VMs in new subnet this will be one of the ipalises on the router eth0 interface. using this ip to access user-data will not work for new subnets as the user-data server is not running on the alias ips. so we now use a name to access the user-data. The name gets resolved by the dnsmasq to the primary ip of the eth0 interface . > [Multiple_IP_Ranges] user data service on VR does not work in case of > multiple subnets > -------------------------------------------------------------------------------------- > > Key: CLOUDSTACK-2644 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2644 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server > Affects Versions: 4.2.0 > Environment: Latest build on master: > CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz > Reporter: Sanjeev N > Assignee: Bharat Kumar > Priority: Critical > Fix For: 4.2.0 > > > user data service on VR does not work in case of multiple subnets > Steps to reproduce: > ================ > 1.Bring up CS in basic zone with xenserver6.1 > 2.Exhaust all the guest IP addresses in primary ip range > 3.Add new guest IP range in new subnet > 4.Deploy guest vm with user data using the IP address in new ip range. > http://10.147.59.126:8096/client/api?command=deployVirtualMachine&serviceofferingid=ab7ad806-65c2-4a12-8b6c-ddb3135b5d24&templateid=d3b13472-c2d2-11e2-ac35-06045a000066&zoneid=e4b7da5e-80d1-43d0-ac15-a987f725b80c&userdata=TXVsdGlwbGUgSVAgUmFuZ2VzIG11bHRpcGxlIFN1Ym5ldHMgVGVzdA== > 5.Fetch the user data > Expected behavior: > ================ > from the guest vm executing the following command should fetch the guest vm > userdata provided while deploying guest vm: > curl http://10.147.43.195/latest/user-data > Actual Result: > ============= > fetching userdata failed : > [root@e3e13452-7e1e-4939-95c0-c64c333d6937 ~]# curl > http://10.147.43.195/latest/user-data > curl: (7) couldn't connect to host > Observations: > ============ > On VR userdata service is running as a web server and listening on primary IP > address and port 80. > Following is the content of the /etc/apache2/port.conf : > # If you just change the port or add more ports here, you will likely also > # have to change the VirtualHost statement in > # /etc/apache2/sites-enabled/000-default > # This is also true if you have upgraded from before 2.2.9-3 (i.e. from > # Debian etch). See /usr/share/doc/apache2.2-common/NEWS.Debian.gz and > # README.Debian.gz > NameVirtualHost 10.147.43.6:80 > Listen 10.147.43.6:80 > <IfModule mod_ssl.c> > # If you add NameVirtualHost *:443 here, you will also have to change > # the VirtualHost statement in /etc/apache2/sites-available/default-ssl > # to <VirtualHost *:443> > # Server Name Indication for SSL named virtual hosts is currently not > # supported by MSIE on Windows XP. > Listen 10.147.43.6:443 > </IfModule> > <IfModule mod_gnutls.c> > Listen 10.147.43.6:443 > </IfModule> > But in case of multiple IP subnets, for every subnet one ip alis gets created > on router vm with IP address from each subnet. So the guest vm deployed in > new subnet can't fetch the userdata since there is no userdata service > listening on the ip alias address belongs to that subnet. > Either userdata service should listen on 0.0.0.0 ip address or for every ip > alis address one entry should be created in /etc/apache2/ports.conf file to > provide user data service to the guest vms in each subnet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira