cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-2620) [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case of multiple subnets
Date Mon, 03 Jun 2013 13:45:20 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673109#comment-13673109
] 

ASF subversion and git services commented on CLOUDSTACK-2620:
-------------------------------------------------------------

Commit 0a69b828993088487876ce859e6c00e96e4b545c in branch refs/heads/master from [~bharat.kumar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0a69b82 ]

CLOUDSTACK-2620 [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address
in case of multiple subnets

Signed-off-by: Abhinandan Prateek <aprateek@apache.org>

                
> [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case
of multiple subnets
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-2620
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2620
>             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: Build from master branch: CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz
>            Reporter: Sanjeev N
>            Assignee: Bharat Kumar
>            Priority: Critical
>             Fix For: 4.2.0
>
>
> [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case
of multiple subnets
> Steps to Reproduce:
> ================
> 1.Bring up CS in basic zone with Xen61 server
> 2.Consume all the guest IP ranges in the existing subnet
> 3.Add guest ip range in new CIDR
> 4.Deploy guest vm
> 5.Verify the nameserver in /etc/resolve.conf in guest vm
> Expected Behaviour:
> =================
> nameserver on guest vm should be set to ip alias address on VR
> Actual Behaviour:
> ==============
> nameserver on guest vm was set to zone level internal DNS ip address instead of VR's
ip alias address.
> Observations:
> ===========
> Primary ip range: 10.147.43.3-10.147.43.7 GW:10.147.43.1 Netmask: 255.255.255.128
> New IP Range : 10.147.43.130-10.147.43.133 GW: 10.147.43.129 Netmask: 255.255.255.192
> When the vm is deployed with IP address from the new CIDR , ip alis on VR got created
with ip address from new CIDR.
> ip alias on the VR was set to  10.147.43.132
> root@r-4-VM:/etc# ifconfig
> eth0      Link encap:Ethernet  HWaddr 06:ba:90:00:00:0e
>           inet addr:10.147.43.6  Bcast:10.147.43.127  Mask:255.255.255.128
>           inet6 addr: fe80::4ba:90ff:fe00:e/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:36018 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:1007 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:1919944 (1.8 MiB)  TX bytes:46214 (45.1 KiB)
>           Interrupt:24
> eth0:18   Link encap:Ethernet  HWaddr 06:ba:90:00:00:0e
>           inet addr:10.147.43.132  Bcast:10.147.43.191  Mask:255.255.255.192
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           Interrupt:24
> During ip alias creation process dnsmasq.conf was re-generated with new ip range and
dhcp-option was set as following:
> dhcp-option=6,10.103.128.16,10.103.128.16
> dnsmasq.conf regeneration process is taking DNS values set at zone level and replacing
with the exiting values in the file. Hence guest vms are getting internal DNS ip address as
nemeserver.
> Impact:
> ======
> Since guest vms nameserver is set to an IP address other than VR's , vm to vm communication
using domain names will fail.

--
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

Mime
View raw message