[
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510614#comment-13510614
]
Anthony Xu commented on CLOUDSTACK-585:
---------------------------------------
Hi wolfram,
I can't reproduce the issue, see following example, I put double spaces before
"-d" and "-N", at the end of the output,
+ ssh -p 3922 -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud
root@169.254.2.144 '/root/edithosts.sh 06:55:22:00:00:11 10.223.170.23 anthony
10.223.170.1 10.223.110.254 '
looks good to me
and I checked /etc/dhcpopts.txt in route VM, gateway and NDS is pragrammed
correctly
10_223_170_23,3,10.223.170.1
10_223_170_23,6,10.223.110.254
I executed the bellow command in XenServer host, KVM might be different, cloud
you do the similar test in KVM and post the output?
Anthony
bash -x dhcp_entry.sh -r 169.254.2.144 -v 10.223.170.23 -m 06:55:22:00:00:11
-n anthony -d 10.223.170.1 -N 10.223.110.254
+ cert=/root/.ssh/id_rsa.cloud
+ domrIp=
+ vmMac=
+ vmIp=
+ vmName=
+ staticrt=
+ dfltrt=
+ dns=
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ domrIp=169.254.2.144
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ vmIp=10.223.170.23
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ vmMac=06:55:22:00:00:11
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ vmName=anthony
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ dfltrt=10.223.170.1
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ dns=10.223.110.254
+ getopts r:m:v:n:d:s:N: OPTION
+ add_dhcp_entry 169.254.2.144 06:55:22:00:00:11 10.223.170.23 anthony
10.223.170.1 10.223.110.254
+ local domr=169.254.2.144
+ local mac=06:55:22:00:00:11
+ local ip=10.223.170.23
+ local vm=anthony
+ local dfltrt=10.223.170.1
+ local ns=10.223.110.254
+ local staticrt=
+ ssh -p 3922 -o StrictHostKeyChecking=no -i /root/.ssh/id_rsa.cloud
root@169.254.2.144 '/root/edithosts.sh 06:55:22:00:00:11 10.223.170.23 anthony
10.223.170.1 10.223.110.254 '
+ return 0
+ exit 0
> DHCP entry provisioning is broken in the KVM agent
> --------------------------------------------------
>
> Key: CLOUDSTACK-585
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-585
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, KVM
> Environment: CloudStack 3.0.2 KVM agent running on Fedora 14
> Reporter: Wolfram Schlich
> Labels: agent, kvm
> Attachments: 1-dhcp_entry.sh.log.patch, 2-dhcp_entry.sh.fix.patch
>
>
> When adding an instance to a routerVM DHCP configuration, it seems that the
> KVM agent calls /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh
> with wrongly constructed command line arguments, making the script fail to
> add correct entries (specifically default router, DNS servers and static
> routes) for that instance to the routerVM's /etc/dhcphosts.txt +
> /etc/dhcpopts.txt.
> Especially adding a specific default gateway fails, so the routerVM will
> always announce itself as the default router, because the correct entry in
> /etc/dhcpopts specifying the gateway of the instance's default network as the
> gateway is missing. This is especially nasty for non-default/additional
> networks of an instance, messing up the default routing.
> Examples:
> Management server log entry:
> "2012-11-29 14:36:37,764 DEBUG
> [resource.virtualnetwork.VirtualRoutingResource]
> (agentRequest-Handler-3:null) Executing:
> /usr/lib64/cloud/agent/./scripts/network/domr/dhcp_entry.sh -r 169.254.0.122
> -v 172.31.2.233 -m 06:b5:88:00:02:30 -n vmname -d 172.31.2.1 -N
> 172.31.2.201 "
> Notice the double spaces before -d and -N (and the extra space at the EOL) --
> WARNING: you have to view the source of this description to actually _see_
> the double spaces!)
> After patching /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to
> do meaningful logging, it's clear that the script does not get called with
> "-d", but " -d" instead (same for -N), so with an extra space before the
> dash. Thus, getopts fails to parse/recognize these two arguments correctly
> and passed empty values for $dfltrt and $dns to the /root/edithosts.sh being
> called on the routerVM.
> It's also clear that the CloudStack KVM Java agent calls it with the wrongly
> constructed command line, because if a shell would interpret this command
> line, it would just ignore the extra spaces itself.
> I've not been able to dig it down, but I somehow suspect that one of
> ./utils/src/com/cloud/utils/script/Script.java:protected String
> buildCommandLine(String[] command) { }
> ./utils/src/com/cloud/utils/script/Script.java:public String
> execute(OutputInterpreter interpreter) { }
> might mess up building the command line of the command that had been built by
> ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java:protected
> synchronized Answer execute (final DhcpEntryCommand cmd) { }
> before.
> I've not tried 4.0.0 so far, thus I cannot say whether it might be affected
> or not.
> As a workaround, I've patched dhcp_entry.sh to re-evaluate the positional
> parameters using 'set -- ${@}' (will attach a patch, also one for logging).
--
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
