incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony Xu (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent
Date Wed, 05 Dec 2012 17:32:00 GMT


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/ root@ '/root/
06:55:22:00:00:11 anthony '
looks good to me

and I checked /etc/dhcpopts.txt in route VM, gateway and NDS is pragrammed correctly

I executed the bellow command in XenServer host, KVM might be different, cloud you do the
similar test in KVM and post the output?


bash -x -r -v -m  06:55:22:00:00:11 -n anthony 
-d  -N
+ cert=/root/.ssh/
+ domrIp=
+ vmMac=
+ vmIp=
+ vmName=
+ staticrt=
+ dfltrt=
+ dns=
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ domrIp=
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ vmIp=
+ 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=
+ getopts r:m:v:n:d:s:N: OPTION
+ case $OPTION in
+ dns=
+ getopts r:m:v:n:d:s:N: OPTION
+ add_dhcp_entry 06:55:22:00:00:11 anthony
+ local domr=
+ local mac=06:55:22:00:00:11
+ local ip=
+ local vm=anthony
+ local dfltrt=
+ local ns=
+ local staticrt=
+ ssh -p 3922 -o StrictHostKeyChecking=no -i /root/.ssh/ root@ '/root/
06:55:22:00:00:11 anthony '
+ return 0
+ exit 0
> DHCP entry provisioning is broken in the KVM agent
> --------------------------------------------------
>                 Key: CLOUDSTACK-585
>                 URL:
>             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:,
> When adding an instance to a routerVM DHCP configuration, it seems that the KVM agent
calls /usr/lib64/cloud/agent/scripts/network/domr/ 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/ -r -v -m 06:b5:88:00:02:30 -n vmname  -d  -N "
> 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/ 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/
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/ String buildCommandLine(String[]
command) { }
> ./utils/src/com/cloud/utils/script/ 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/
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 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:

View raw message