cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Animesh Chaturvedi (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent
Date Wed, 05 Dec 2012 22:01:58 GMT

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

Animesh Chaturvedi edited comment on CLOUDSTACK-585 at 12/5/12 10:01 PM:
-------------------------------------------------------------------------

I think it is caused by trailing space from the previous arguments, which can be fixed defensively
by trimming the arguments in Java code and trimming the input at data entry. There is a discussion
on dev-list to improve data validation and cases like this can be avoided
                
      was (Author: animeshc):
    I think it is caused by trailing space from the previous arguments, which can be fixed
defensively by trimming the arguments in Java code and trimming the input at data entry
                  
> 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

Mime
View raw message