date:20121205

Wolfram Schlich created CLOUDSTACK-585:
--

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


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 
END-OF-LINE

Notice the double spaces before -d and -N (and the extra space at the EOL).

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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Attachment: 2-dhcp_entry.sh.fix.patch

Patch for /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to work 
around wrongly constructed arguments (re-evaluates the positional parameters)

 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 END-OF-LINE
 Notice the double spaces before -d and -N (and the extra space at the EOL).
 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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Attachment: 1-dhcp_entry.sh.log.patch

Patch for /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to enable 
logging of wrongly constructed arguments and empty parameters passed to 
routerVM:/root/edithosts.sh

 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 END-OF-LINE
 Notice the double spaces before -d and -N (and the extra space at the EOL).
 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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

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

codepre2012-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 /pre/code

Notice the double spaces before -d and -N (and the extra space at the EOL).

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

  was:
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 
END-OF-LINE

Notice the double spaces before -d and -N (and the extra space at the EOL).

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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Description: 
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).

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

codepre2012-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 /pre/code

Notice the double spaces before -d and -N (and the extra space at the EOL).

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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

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

{noformat} 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 {noformat} 

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

  was:
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) { }

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Description: 
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).

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

{noformat} 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 {noformat} 

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) { }

[jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich edited comment on CLOUDSTACK-585 at 12/5/12 3:37 PM:
-

2-dhcp_entry.sh.fix.patch: Patch for 
/usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to work around 
wrongly constructed arguments (re-evaluates the positional parameters)

  was (Author: wschlich):
Patch for /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to work 
around wrongly constructed arguments (re-evaluates the positional parameters)
  
 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

[jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich edited comment on CLOUDSTACK-585 at 12/5/12 3:37 PM:
-

1-dhcp_entry.sh.log.patch: Patch for 
/usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to enable logging of 
wrongly constructed arguments and empty parameters passed to 
routerVM:/root/edithosts.sh

  was (Author: wschlich):
Patch for /usr/lib64/cloud/agent/scripts/network/domr/dhcp_entry.sh to 
enable logging of wrongly constructed arguments and empty parameters passed to 
routerVM:/root/edithosts.sh
  
 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

Reminder: IRC Meeting Today

2012-12-05 Thread Joe Brockmeier

Howdy all,

Reminder - IRC meeting today at 17:00 UTC, which is 12:00 Eastern, 09:00
Pacific.

We meet in #cloudstack-meeting on Freenode. 

If you're new to the meetings, remember that the purpose for real-time
meetings is for status reports and discussion only - topics that require
a decision are always discussed and decided on the mailing list. 

We use Meetbot to keep meeting minutes. If you aren't familiar with
Meetbot, the guide can be found here:

http://meetbot.debian.net/Manual.html

Best, 

jzb
-- 
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb

Re: [DISCUSS] changing the format of commit message subject lines

2012-12-05 Thread Joe Brockmeier

On Tue, Dec 04, 2012 at 03:35:48PM -0500, David Nalley wrote:
 Hi folks,
 
 I'd like to propose that we change the commit message subject line from:
 
 git commit: $short_commit_msg
 
 to:
 
 git commit: $branch - $short_commit_msg
 
 Any other opinions?

Works for me. Would be much easier to see what's going where just by
skimming the messages... 

+1 

Best, 

jzb
-- 
Joe Brockmeier
http://dissociatedpress.net/
Twitter: @jzb

[jira] [Commented] (CLOUDSTACK-460) Cloudstack 4.0 Cannot ssh into system vms

2012-12-05 Thread Joe Brockmeier (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510569#comment-13510569
 ] 

Joe Brockmeier commented on CLOUDSTACK-460:
---

There's time! I've added the commit from master. 

It's: 2f99c25a046b39f8377fb2cdacaedb7404a59481

 Cloudstack 4.0 Cannot ssh into system vms
 -

 Key: CLOUDSTACK-460
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-460
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, KVM
Affects Versions: 4.0.0
 Environment: Ubuntu 12.04
Reporter: jason
  Labels: newbie
 Fix For: 4.0.0, 4.0.1

   Original Estimate: 168h
  Remaining Estimate: 168h

 Cannot ssh into system vms, as far as i can see the the keys match up and im 
 also using the Link Local IP Adddress.
 I Have reinstalled 3 times to make sure its not user error
 please help
 thanks
 jason

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

[jira] [Created] (CLOUDSTACK-586) exportfs -a gives 'no_subtree_check warning' when following the Installation guide

2012-12-05 Thread Max Thoursie (JIRA)

Max Thoursie created CLOUDSTACK-586:
---

 Summary: exportfs -a gives 'no_subtree_check warning' when 
following the Installation guide
 Key: CLOUDSTACK-586
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-586
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Affects Versions: 4.0.0
 Environment: Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic x86_64)

Reporter: Max Thoursie
Priority: Minor


The installation guide says, under 4.5.5.1 and 4.5.5.2

2. To configure the new directories as NFS exports, edit /etc/exports. Export 
the NFS share(s) with rw,async,no_root_squash. For example:

# vi /etc/exports

Insert the following line.

/export  *(rw,async,no_root_squash)


Following these instructions, Ubuntu prints the following warning

  max@ubuntu:~$ sudo exportfs -a
  exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' 
specified for export *:/export.
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x



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

Re: SSVM Network Configuration Issue

2012-12-05 Thread John Burwell

All,

I was wondering if anyone else is experiencing this problem when using 
secondary storage on a devcloud-style VM with a host-only and NAT adapter.  One 
aspect of this issue that seems interesting is that following route table from 
the SSVM:

root@s-5-TEST:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.0.3.2192.168.56.1255.255.255.255 UGH   0  00 eth1
10.0.3.0*   255.255.255.0   U 0  00 eth2
192.168.56.0*   255.255.255.0   U 0  00 eth1
192.168.56.0*   255.255.255.0   U 0  00 eth3
link-local  *   255.255.0.0 U 0  00 eth0
default 10.0.3.20.0.0.0 UG0  00 eth2

In particular, the gateways for the management and guest networks do not match 
to the configuration provided to the management server (i.e. 10.0.3.2 is the 
gateway for the 10.0.3.0/24 network and 192.168.56.1 is the gateway for the 
192.168.56.0/24 network).  With this configuration, the SSVM has a socket 
connection to the management server, but is in alert state.  Finally, when I 
remove the host-only NIC and use only a NAT adapter the SSVM's networking works 
as expecting leading me to believe that the segregated network configuration is 
at the root of the problem.

Until I can get the networking on the SSVM configured, I am unable to complete 
the testing of the S3-backed Secondary Storage enhancement.

Thank you for your help,
-John

On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:

 All,
 
 I am setting up a multi-zone devcloud configuration on VirtualBox 4.2.4 using 
 the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base management server 
 VM (zone1) to serve as both the zone1, as well as, the management server 
 (running MySql) with eth0 as a host-only adapter and a static IP of 
 192.168.56.15 and eth1 as a NAT adapter (see the attached zone1-interfaces 
 file for the exact network configuration on the VM).  The management and 
 guest networks are configured as follows:
 
 Zone 1
 Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
 Zone 2
 Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
 The management server deploys and starts without error.  I then populate the 
 configuration it using the attached Marvin configuration file 
 (zone1.devcloud.cfg) and restart the management server in order to allow the 
 global configuration option changes to take effect.  Following the restart, 
 the CPVM and SSVM start without error.  Unfortunately, they drop into alert 
 status, and the SSVM is unable to connect outbound through the guest network 
 (very important for my tests because I am testing S3-backed secondary 
 storage).  
 
 From the diagnostic checks I have performed on the management server and the 
 SSVM, it appears that the daemon on the SSVM is connecting back to the 
 management server.  I have attached a set of diagnostic information from the 
 management server (mgmtsvr-zone1-diagnostics.log) and SSVM server 
 (ssvm-zone1-diagnostics.log) that includes the results of ifconfig, route, 
 netstat and ping checks, as well as, other information (e.g. the contents of 
 /var/cache/cloud/cmdline on the SSVM).  Finally, I have attached the vmops 
 log from the management server (vmops-zone1.log).
 
 What changes need to be made to management server configuration in order to 
 start up an SSVM that can communicate with the secondary storage NFS volumes, 
 management server, and connect to hosts on the Internet?
 
 Thanks for your help,
 -John
 
 ssvm-zone1-diagnostics.log
 vmops-zone1.tar.gz
 mgmtsvr-zone1-diagnostics.log
 zone1-interfaces
 zone1.devcloud.cfg

Re: SSVM Network Configuration Issue

I think it may have something to do with your DNS. I've noticed that it
drops routes in for my DNS servers, forcing them to use the management
network. So in this case perhaps you have your DNS configured as 10.0.3.2,
so it forces that to use eth1... just a guess. If thats the issue (or
something like that) then you'll want to set up a dnsmasq service on on the
192.168 network to use, or whatever to keep your DNS from routing.


On Wed, Dec 5, 2012 at 10:10 AM, John Burwell jburw...@basho.com wrote:

 All,

 I was wondering if anyone else is experiencing this problem when using
 secondary storage on a devcloud-style VM with a host-only and NAT adapter.
  One aspect of this issue that seems interesting is that following route
 table from the SSVM:

 root@s-5-TEST:~# route
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse
 Iface
 10.0.3.2192.168.56.1255.255.255.255 UGH   0  00
 eth1
 10.0.3.0*   255.255.255.0   U 0  00
 eth2
 192.168.56.0*   255.255.255.0   U 0  00
 eth1
 192.168.56.0*   255.255.255.0   U 0  00
 eth3
 link-local  *   255.255.0.0 U 0  00
 eth0
 default 10.0.3.20.0.0.0 UG0  00
 eth2

 In particular, the gateways for the management and guest networks do not
 match to the configuration provided to the management server (i.e. 10.0.3.2
 is the gateway for the 10.0.3.0/24 network and 192.168.56.1 is the
 gateway for the 192.168.56.0/24 network).  With this configuration, the
 SSVM has a socket connection to the management server, but is in alert
 state.  Finally, when I remove the host-only NIC and use only a NAT adapter
 the SSVM's networking works as expecting leading me to believe that the
 segregated network configuration is at the root of the problem.

 Until I can get the networking on the SSVM configured, I am unable to
 complete the testing of the S3-backed Secondary Storage enhancement.

 Thank you for your help,
 -John

 On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:

  All,
 
  I am setting up a multi-zone devcloud configuration on VirtualBox 4.2.4
 using the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base
 management server VM (zone1) to serve as both the zone1, as well as, the
 management server (running MySql) with eth0 as a host-only adapter and a
 static IP of 192.168.56.15 and eth1 as a NAT adapter (see the attached
 zone1-interfaces file for the exact network configuration on the VM).  The
 management and guest networks are configured as follows:
 
  Zone 1
  Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
  Zone 2
  Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
  The management server deploys and starts without error.  I then populate
 the configuration it using the attached Marvin configuration file
 (zone1.devcloud.cfg) and restart the management server in order to allow
 the global configuration option changes to take effect.  Following the
 restart, the CPVM and SSVM start without error.  Unfortunately, they drop
 into alert status, and the SSVM is unable to connect outbound through the
 guest network (very important for my tests because I am testing S3-backed
 secondary storage).
 
  From the diagnostic checks I have performed on the management server and
 the SSVM, it appears that the daemon on the SSVM is connecting back to the
 management server.  I have attached a set of diagnostic information from
 the management server (mgmtsvr-zone1-diagnostics.log) and SSVM server
 (ssvm-zone1-diagnostics.log) that includes the results of ifconfig, route,
 netstat and ping checks, as well as, other information (e.g. the contents
 of /var/cache/cloud/cmdline on the SSVM).  Finally, I have attached the
 vmops log from the management server (vmops-zone1.log).
 
  What changes need to be made to management server configuration in order
 to start up an SSVM that can communicate with the secondary storage NFS
 volumes, management server, and connect to hosts on the Internet?
 
  Thanks for your help,
  -John
 
  ssvm-zone1-diagnostics.log
  vmops-zone1.tar.gz
  mgmtsvr-zone1-diagnostics.log
  zone1-interfaces
  zone1.devcloud.cfg

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Description: 
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).

  was: 


 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

[jira] [Updated] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wolfram Schlich updated CLOUDSTACK-585:
---

Description:(was: 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).)

 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


  

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

RE: SSVM Network Configuration Issue

2012-12-05 Thread Anthony Xu

Hi join,

Try following,

Set global configuration management.network.cidr to your management server 
CIDR, if this configuration is not available in UI, you can change it in DB 
directly.

Restart management,
Stop/Start SSVM and CPVM.


And could you post cat /proc/cmdline in SSVM?



Anthony

 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Wednesday, December 05, 2012 9:11 AM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: SSVM Network Configuration Issue
 
 All,
 
 I was wondering if anyone else is experiencing this problem when using
 secondary storage on a devcloud-style VM with a host-only and NAT
 adapter.  One aspect of this issue that seems interesting is that
 following route table from the SSVM:
 
 root@s-5-TEST:~# route
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse
 Iface
 10.0.3.2192.168.56.1255.255.255.255 UGH   0  00
 eth1
 10.0.3.0*   255.255.255.0   U 0  00
 eth2
 192.168.56.0*   255.255.255.0   U 0  00
 eth1
 192.168.56.0*   255.255.255.0   U 0  00
 eth3
 link-local  *   255.255.0.0 U 0  00
 eth0
 default 10.0.3.20.0.0.0 UG0  00
 eth2
 
 In particular, the gateways for the management and guest networks do
 not match to the configuration provided to the management server (i.e.
 10.0.3.2 is the gateway for the 10.0.3.0/24 network and 192.168.56.1 is
 the gateway for the 192.168.56.0/24 network).  With this configuration,
 the SSVM has a socket connection to the management server, but is in
 alert state.  Finally, when I remove the host-only NIC and use only a
 NAT adapter the SSVM's networking works as expecting leading me to
 believe that the segregated network configuration is at the root of the
 problem.
 
 Until I can get the networking on the SSVM configured, I am unable to
 complete the testing of the S3-backed Secondary Storage enhancement.
 
 Thank you for your help,
 -John
 
 On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:
 
  All,
 
  I am setting up a multi-zone devcloud configuration on VirtualBox
 4.2.4 using the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base
 management server VM (zone1) to serve as both the zone1, as well as,
 the management server (running MySql) with eth0 as a host-only adapter
 and a static IP of 192.168.56.15 and eth1 as a NAT adapter (see the
 attached zone1-interfaces file for the exact network configuration on
 the VM).  The management and guest networks are configured as follows:
 
  Zone 1
  Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
  Zone 2
  Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
  The management server deploys and starts without error.  I then
 populate the configuration it using the attached Marvin configuration
 file (zone1.devcloud.cfg) and restart the management server in order to
 allow the global configuration option changes to take effect.
 Following the restart, the CPVM and SSVM start without error.
 Unfortunately, they drop into alert status, and the SSVM is unable to
 connect outbound through the guest network (very important for my tests
 because I am testing S3-backed secondary storage).
 
  From the diagnostic checks I have performed on the management server
 and the SSVM, it appears that the daemon on the SSVM is connecting back
 to the management server.  I have attached a set of diagnostic
 information from the management server (mgmtsvr-zone1-diagnostics.log)
 and SSVM server (ssvm-zone1-diagnostics.log) that includes the results
 of ifconfig, route, netstat and ping checks, as well as, other
 information (e.g. the contents of /var/cache/cloud/cmdline on the SSVM).
 Finally, I have attached the vmops log from the management server
 (vmops-zone1.log).
 
  What changes need to be made to management server configuration in
 order to start up an SSVM that can communicate with the secondary
 storage NFS volumes, management server, and connect to hosts on the
 Internet?
 
  Thanks for your help,
  -John
 
  ssvm-zone1-diagnostics.log
  vmops-zone1.tar.gz
  mgmtsvr-zone1-diagnostics.log
  zone1-interfaces
  zone1.devcloud.cfg

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich commented on CLOUDSTACK-585:


Crappy auto-update bs when you click into a field! Argh. Anyway.

Anthony, thanks for your response. Unfortunately, you didn't get the point at 
all :-)
Please re-read the description. I don't know how to make it even more clear 
than I already did. Thanks.

 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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich commented on CLOUDSTACK-585:


Ok I'll try:
You cannot reproduce it by running the command on the shell as you did!
You have to let the KVM agent do that task (call dhcp_entry.sh).
You can only simulate how the KVM agent does it by also quoting the arguments 
wrong on a shell:
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 
But that doesn't help you at all I believe.

 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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich commented on CLOUDSTACK-585:


The issue is NOT with dhcp_entry.sh, but with the command line construction 
that the KVM agent uses to execute it!

 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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Anthony Xu commented on CLOUDSTACK-585:
---

I can reproduce the issue with quote, and your fix works:-)
please check in your fix.

 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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich commented on CLOUDSTACK-585:


NO!!! The fix is only a *workaround*! It does not fix the cause of the 
problem! It's inside the KVM agent sourcecode! Please...

 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

[jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich edited comment on CLOUDSTACK-585 at 12/5/12 6:05 PM:
-

The command that is executed by the KVM agent seems to be constructed wrongly.

Let me explain that using pseudocode:

Here's what the Java KVM agent seems to be doing:

exec(/usr/lib64/cloud/agent/scripts/network/domr/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 );

Please look at the Java source code files and methods that I referenced, then 
it will get more clear.

  was (Author: wschlich):
The command that is execute by the KVM agent seems to be constructed 
wrongly.

Let me explain that using pseudocode:

Here's what the Java KVM agent seems to be doing:

exec(/usr/lib64/cloud/agent/scripts/network/domr/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 );

Please look at the Java source code files and methods that I referenced, then 
it will get more clear.
  
 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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich commented on CLOUDSTACK-585:


The command that is execute by the KVM agent seems to be constructed wrongly.

Let me explain that using pseudocode:

Here's what the Java KVM agent seems to be doing:

exec(/usr/lib64/cloud/agent/scripts/network/domr/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 );

Please look at the Java source code files and methods that I referenced, then 
it will get more clear.

 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

CentOS System VM?

2012-12-05 Thread Donal Lafferty

Has anyone looked into building a system VM that runs on a CentOS distro?

Re: MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:


On 04-Dec-2012, at 2:08 PM, Charles Moulliard ch0...@gmail.com wrote:

 Any idea on how to upgrade xen on Devcloud (= VB running Devian Wheezy +
 Xen 4.1) ?

apt-get update
apt-get upgrade

 
 
 On Tue, Dec 4, 2012 at 7:18 PM, Alex Huang alex.hu...@citrix.com wrote:
 
 Ah...Didn't realize you're using devCloud.  Anthony is right in another
 email.  This is most likely due to a mismatch between the xapi java stub
 library your deployment is using and the xapi your devcloud is on.
 
 --Alex
 
 -Original Message-
 From: Charles Moulliard [mailto:ch0...@gmail.com]
 Sent: Tuesday, December 04, 2012 9:11 AM
 To: cloudstack-dev
 Subject: Re: MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:
 
 Alex,
 
 There is no /var/log/xensource.log file on the XCP machine running in
 VirtualBox (= Devcloud2) but those one :
 ls -la /var/log
 -rw---  1 root root20206 Dec  4 16:58 xcp-networkd.log
 -rw---  1 root root   113299 Dec  4 17:04 xcp-squeezed.log
 -rw---  1 root root27422 Dec  4 16:58 xcp-v6d.log
 -rw---  1 root root 10351527 Dec  4 17:07 xcp-xapi.log
 drwxr-s---  2 root adm  4096 Dec  3 08:32 xen
 
 
 
 On Tue, Dec 4, 2012 at 6:01 PM, Alex Huang alex.hu...@citrix.com
 wrote:
 
 /var/log/xensource.log
 
 
 
 
 --
 Charles Moulliard
 Apache Committer / Sr. Enterprise Architect (RedHat)
 Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
 
 
 
 
 -- 
 Charles Moulliard
 Apache Committer / Sr. Enterprise Architect (RedHat)
 Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com

RE: CentOS System VM?

I guess you could, but why?

-Original Message-
From: Donal Lafferty [mailto:donal.laffe...@citrix.com] 
Sent: Wednesday, December 05, 2012 1:10 PM
To: cloudstack-dev@incubator.apache.org
Subject: CentOS System VM?

Has anyone looked into building a system VM that runs on a CentOS distro?

RE: CentOS System VM?

2012-12-05 Thread Donal Lafferty

CentOS has better support on Hyper-V


-Original Message-
From: Musayev, Ilya [mailto:imusa...@webmd.net] 
Sent: 05 December 2012 6:13 PM
To: cloudstack-dev@incubator.apache.org
Subject: RE: CentOS System VM?

I guess you could, but why?

-Original Message-
From: Donal Lafferty [mailto:donal.laffe...@citrix.com] 
Sent: Wednesday, December 05, 2012 1:10 PM
To: cloudstack-dev@incubator.apache.org
Subject: CentOS System VM?

Has anyone looked into building a system VM that runs on a CentOS distro?

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Anthony Xu commented on CLOUDSTACK-585:
---

Why not, I see it as a fix. It's very easy to add one space somehow in java 
file, instead of checking every possible places in Java. It is a good practice 
to remove extra space in shell script.

And I didn't find out how extra space is added.:-)

in VirtualRoutingResource.java,


protected synchronized Answer execute (final DhcpEntryCommand cmd) {
final Script command  = new Script(_dhcpEntryPath, _timeout, s_logger);
command.add(-r, cmd.getAccessDetail(NetworkElementCommand.ROUTER_IP));
command.add(-v, cmd.getVmIpAddress());
command.add(-m, cmd.getVmMac());
command.add(-n, cmd.getVmName());

if (cmd.getDefaultRouter() != null) {
command.add(-d, cmd.getDefaultRouter());
}
if (cmd.getStaticRoutes() != null) {
command.add(-s, cmd.getStaticRoutes());
}

if (cmd.getDefaultDns() != null) {
command.add(-N, cmd.getDefaultDns());
}

final String result = command.execute();
return new Answer(cmd, result==null, result);
}

 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

RE: CentOS System VM?

2012-12-05 Thread Anthony Xu

CS used to have Fedora 8 as system VM.
The reason CS moves to Debian is,
1.Debian 6 has iptable checksum module
2.Debian 6 is stable

If CentOS 6.* has iptable checksum module.
I think you can.


Anthony

 -Original Message-
 From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
 Sent: Wednesday, December 05, 2012 10:16 AM
 To: cloudstack-dev@incubator.apache.org
 Subject: RE: CentOS System VM?
 
 CentOS has better support on Hyper-V
 
 
 -Original Message-
 From: Musayev, Ilya [mailto:imusa...@webmd.net]
 Sent: 05 December 2012 6:13 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: RE: CentOS System VM?
 
 I guess you could, but why?
 
 -Original Message-
 From: Donal Lafferty [mailto:donal.laffe...@citrix.com]
 Sent: Wednesday, December 05, 2012 1:10 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: CentOS System VM?
 
 Has anyone looked into building a system VM that runs on a CentOS
 distro?

Re: CentOS System VM?

2012-12-05 Thread Kelceydamage@bbits

I'm very interested in this.

Sent from my iPhone

On Dec 5, 2012, at 10:10 AM, Donal Lafferty donal.laffe...@citrix.com wrote:

 Has anyone looked into building a system VM that runs on a CentOS distro?

[jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Wolfram Schlich edited comment on CLOUDSTACK-585 at 12/5/12 6:29 PM:
-

Sigh. That's the completely wrong approach IMHO. Fix crap where it emerges, not 
work around it afterwards.

Can you at least *confirm* that the KVM Java agent is doing it wrong (adding 
spaces)?
If you don't have a KVM node at hand, it might be hard, though ;

  was (Author: wschlich):
Sigh. That's the completely wrong approach IMHO. Fix crap where it breaks, 
not work around it afterwards.

Can you at least *confirm* that the KVM Java agent is doing it wrong (adding 
spaces)?
If you don't have a KVM node at hand, it might be hard, though ;
  
 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

Re: CentOS System VM?

2012-12-05 Thread Jason Davis

TBH Hyper-V synthetic drivers(modules) is supported in the mainline kernel.

So the argument that CentOS 6.x has better support is moot.

This assumes that the kernel version on the SSVM is at least 2.6.32. I ran
Ubuntu Server 11.x and Centos 6.x on Hyper-V natively and just needed to
load the kernel modules for the synthetic stuffs to work.

Ancient example of getting the Hyper-V modules built/working on Debian 6.0
http://virtualisationandmanagement.wordpress.com/2010/11/02/debian-on-hyper-v-with-4-vcpu-support-and-syntetic-network/





On Wed, Dec 5, 2012 at 12:25 PM, Kelceydamage@bbits kel...@bbits.ca wrote:

 I'm very interested in this.

 Sent from my iPhone

 On Dec 5, 2012, at 10:10 AM, Donal Lafferty donal.laffe...@citrix.com
 wrote:

  Has anyone looked into building a system VM that runs on a CentOS distro?

Re: SSVM Network Configuration Issue

2012-12-05 Thread John Burwell

Anthony,

The contents of that file are contained in the ssvm-zone1-diagnostics.log 
attached to my previous message (grep for cmdline.

Thanks,
-John

On Dec 5, 2012, at 12:46 PM, Anthony Xu xuefei...@citrix.com wrote:

 Hi join,
 
 Try following,
 
 Set global configuration management.network.cidr to your management server 
 CIDR, if this configuration is not available in UI, you can change it in DB 
 directly.
 
 Restart management,
 Stop/Start SSVM and CPVM.
 
 
 And could you post cat /proc/cmdline in SSVM?
 
 
 
 Anthony
 
 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Wednesday, December 05, 2012 9:11 AM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: SSVM Network Configuration Issue
 
 All,
 
 I was wondering if anyone else is experiencing this problem when using
 secondary storage on a devcloud-style VM with a host-only and NAT
 adapter.  One aspect of this issue that seems interesting is that
 following route table from the SSVM:
 
 root@s-5-TEST:~# route
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse
 Iface
 10.0.3.2192.168.56.1255.255.255.255 UGH   0  00
 eth1
 10.0.3.0*   255.255.255.0   U 0  00
 eth2
 192.168.56.0*   255.255.255.0   U 0  00
 eth1
 192.168.56.0*   255.255.255.0   U 0  00
 eth3
 link-local  *   255.255.0.0 U 0  00
 eth0
 default 10.0.3.20.0.0.0 UG0  00
 eth2
 
 In particular, the gateways for the management and guest networks do
 not match to the configuration provided to the management server (i.e.
 10.0.3.2 is the gateway for the 10.0.3.0/24 network and 192.168.56.1 is
 the gateway for the 192.168.56.0/24 network).  With this configuration,
 the SSVM has a socket connection to the management server, but is in
 alert state.  Finally, when I remove the host-only NIC and use only a
 NAT adapter the SSVM's networking works as expecting leading me to
 believe that the segregated network configuration is at the root of the
 problem.
 
 Until I can get the networking on the SSVM configured, I am unable to
 complete the testing of the S3-backed Secondary Storage enhancement.
 
 Thank you for your help,
 -John
 
 On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:
 
 All,
 
 I am setting up a multi-zone devcloud configuration on VirtualBox
 4.2.4 using the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base
 management server VM (zone1) to serve as both the zone1, as well as,
 the management server (running MySql) with eth0 as a host-only adapter
 and a static IP of 192.168.56.15 and eth1 as a NAT adapter (see the
 attached zone1-interfaces file for the exact network configuration on
 the VM).  The management and guest networks are configured as follows:
 
 Zone 1
 Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
 Zone 2
 Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
 The management server deploys and starts without error.  I then
 populate the configuration it using the attached Marvin configuration
 file (zone1.devcloud.cfg) and restart the management server in order to
 allow the global configuration option changes to take effect.
 Following the restart, the CPVM and SSVM start without error.
 Unfortunately, they drop into alert status, and the SSVM is unable to
 connect outbound through the guest network (very important for my tests
 because I am testing S3-backed secondary storage).
 
 From the diagnostic checks I have performed on the management server
 and the SSVM, it appears that the daemon on the SSVM is connecting back
 to the management server.  I have attached a set of diagnostic
 information from the management server (mgmtsvr-zone1-diagnostics.log)
 and SSVM server (ssvm-zone1-diagnostics.log) that includes the results
 of ifconfig, route, netstat and ping checks, as well as, other
 information (e.g. the contents of /var/cache/cloud/cmdline on the SSVM).
 Finally, I have attached the vmops log from the management server
 (vmops-zone1.log).
 
 What changes need to be made to management server configuration in
 order to start up an SSVM that can communicate with the secondary
 storage NFS volumes, management server, and connect to hosts on the
 Internet?
 
 Thanks for your help,
 -John
 
 ssvm-zone1-diagnostics.log
 vmops-zone1.tar.gz
 mgmtsvr-zone1-diagnostics.log
 zone1-interfaces
 zone1.devcloud.cfg

Re: CentOS System VM?

2012-12-05 Thread Kelceydamage@bbits

The sooner we decouple the systemVMs and allow preference in OS, and user 
building, we will be better off.

Sent from my iPhone

On Dec 5, 2012, at 10:38 AM, Jason Davis scr...@gmail.com wrote:

 TBH Hyper-V synthetic drivers(modules) is supported in the mainline kernel.
 
 So the argument that CentOS 6.x has better support is moot.
 
 This assumes that the kernel version on the SSVM is at least 2.6.32. I ran
 Ubuntu Server 11.x and Centos 6.x on Hyper-V natively and just needed to
 load the kernel modules for the synthetic stuffs to work.
 
 Ancient example of getting the Hyper-V modules built/working on Debian 6.0
 http://virtualisationandmanagement.wordpress.com/2010/11/02/debian-on-hyper-v-with-4-vcpu-support-and-syntetic-network/
 
 
 
 
 
 On Wed, Dec 5, 2012 at 12:25 PM, Kelceydamage@bbits kel...@bbits.ca wrote:
 
 I'm very interested in this.
 
 Sent from my iPhone
 
 On Dec 5, 2012, at 10:10 AM, Donal Lafferty donal.laffe...@citrix.com
 wrote:
 
 Has anyone looked into building a system VM that runs on a CentOS distro?

Re: Impact of tomcat CVE-2012-4534

2012-12-05 Thread Chiradeep Vittal

Versions higher than 6.0.33 have problems with classloading the MySQL
driver.

On 12/5/12 6:20 AM, Gavin Lee gavin@gmail.com wrote:

This vulnerability possibly causes denial of service.
See below link:
http://mail-archives.apache.org/mod_mbox/www-announce/201212.mbox/%3C50BE5
35a.9000...@apache.org%3E

It was fixed in tomcat 6.0.36, but we recommand to use 6.0.33.
Should we test a higher version and change the guide?

-- 
Gavin

Re: SSVM Network Configuration Issue

2012-12-05 Thread John Burwell

Anthony,

I apologize for forgetting to response to the part of your answer the first 
part of the question.  I had set the management.network.cidr and host global 
settings to 192.168.0.0/24 and 192.168.56.18 respectively.  Please see the 
zone1.devcloud.cfg Marvin configuration attached to my original email for the 
actual setting, as well as, the network configurations used when this problem 
occurs.

Thanks,
-John

On Dec 5, 2012, at 12:46 PM, Anthony Xu xuefei...@citrix.com wrote:

 Hi join,
 
 Try following,
 
 Set global configuration management.network.cidr to your management server 
 CIDR, if this configuration is not available in UI, you can change it in DB 
 directly.
 
 Restart management,
 Stop/Start SSVM and CPVM.
 
 
 And could you post cat /proc/cmdline in SSVM?
 
 
 
 Anthony
 
 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Wednesday, December 05, 2012 9:11 AM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: SSVM Network Configuration Issue
 
 All,
 
 I was wondering if anyone else is experiencing this problem when using
 secondary storage on a devcloud-style VM with a host-only and NAT
 adapter.  One aspect of this issue that seems interesting is that
 following route table from the SSVM:
 
 root@s-5-TEST:~# route
 Kernel IP routing table
 Destination Gateway Genmask Flags Metric RefUse
 Iface
 10.0.3.2192.168.56.1255.255.255.255 UGH   0  00
 eth1
 10.0.3.0*   255.255.255.0   U 0  00
 eth2
 192.168.56.0*   255.255.255.0   U 0  00
 eth1
 192.168.56.0*   255.255.255.0   U 0  00
 eth3
 link-local  *   255.255.0.0 U 0  00
 eth0
 default 10.0.3.20.0.0.0 UG0  00
 eth2
 
 In particular, the gateways for the management and guest networks do
 not match to the configuration provided to the management server (i.e.
 10.0.3.2 is the gateway for the 10.0.3.0/24 network and 192.168.56.1 is
 the gateway for the 192.168.56.0/24 network).  With this configuration,
 the SSVM has a socket connection to the management server, but is in
 alert state.  Finally, when I remove the host-only NIC and use only a
 NAT adapter the SSVM's networking works as expecting leading me to
 believe that the segregated network configuration is at the root of the
 problem.
 
 Until I can get the networking on the SSVM configured, I am unable to
 complete the testing of the S3-backed Secondary Storage enhancement.
 
 Thank you for your help,
 -John
 
 On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:
 
 All,
 
 I am setting up a multi-zone devcloud configuration on VirtualBox
 4.2.4 using the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base
 management server VM (zone1) to serve as both the zone1, as well as,
 the management server (running MySql) with eth0 as a host-only adapter
 and a static IP of 192.168.56.15 and eth1 as a NAT adapter (see the
 attached zone1-interfaces file for the exact network configuration on
 the VM).  The management and guest networks are configured as follows:
 
 Zone 1
 Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
 Zone 2
 Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
 Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
 The management server deploys and starts without error.  I then
 populate the configuration it using the attached Marvin configuration
 file (zone1.devcloud.cfg) and restart the management server in order to
 allow the global configuration option changes to take effect.
 Following the restart, the CPVM and SSVM start without error.
 Unfortunately, they drop into alert status, and the SSVM is unable to
 connect outbound through the guest network (very important for my tests
 because I am testing S3-backed secondary storage).
 
 From the diagnostic checks I have performed on the management server
 and the SSVM, it appears that the daemon on the SSVM is connecting back
 to the management server.  I have attached a set of diagnostic
 information from the management server (mgmtsvr-zone1-diagnostics.log)
 and SSVM server (ssvm-zone1-diagnostics.log) that includes the results
 of ifconfig, route, netstat and ping checks, as well as, other
 information (e.g. the contents of /var/cache/cloud/cmdline on the SSVM).
 Finally, I have attached the vmops log from the management server
 (vmops-zone1.log).
 
 What changes need to be made to management server configuration in
 order to start up an SSVM that can communicate with the secondary
 storage NFS volumes, management server, and connect to hosts on the
 Internet?
 
 Thanks for your help,
 -John
 
 ssvm-zone1-diagnostics.log
 vmops-zone1.tar.gz
 mgmtsvr-zone1-diagnostics.log
 zone1-interfaces
 zone1.devcloud.cfg

RE: MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:

2012-12-05 Thread Anthony Xu

Hi Charles,

This is a bug, have you filed a bug for this?

Anthony

 -Original Message-
 From: Charles Moulliard [mailto:ch0...@gmail.com]
 Sent: Tuesday, December 04, 2012 8:52 AM
 To: cloudstack-dev
 Subject: Fwd: MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:

 Hi,

 How can I figure out this exception when I try to create a new instance
 using by example Centos 6.3 ISO (compute offering = 500MHertz, 500MB,
 local
 storage) ?

 WARN  [xen.resource.CitrixResourceBase] (DirectAgent-36:) Catch
 Exception:
 class com.xensource.xenapi.Types$XenAPIException due to
 MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
 dynamic_min ? dynamic_max ? static_max
 MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
 dynamic_min ? dynamic_max ? static_max
 at com.xensource.xenapi.Types.checkResponse(Types.java:1732)
  at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
 at
 com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConn
 ection.dispatch(XenServerConnectionPool.java:909)
  at com.xensource.xenapi.VM.setMemoryStaticMin(VM.java:3450)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixRe
 sourceBase.java:3116)
  at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTempla
 te(CitrixResourceBase.java:985)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixReso
 urceBase.java:1278)
  at
 com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResource
 .java:142)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Cit
 rixResourceBase.java:497)
  at
 com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssR
 esource.java:136)
 at
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.
 java:191)
  at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ac
 cess$301(ScheduledThreadPoolExecutor.java:98)
  at
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ru
 n(ScheduledThreadPoolExecutor.java:206)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut
 or.java:886)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
 ava:908)
 at java.lang.Thread.run(Thread.java:680)

 Regards,

 --
 Charles Moulliard
 Apache Committer / Sr. Enterprise Architect (RedHat)
 Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com

 --
 Charles Moulliard
 Apache Committer / Sr. Enterprise Architect (RedHat)
 Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com

RouterVM bug fix patch - PLS DISCUSS

I've previously started few threads on router vm issue. After the reboot of
Router VM, the link local IP could not be reached until we initiate a ping
request from within the Router VM. This inturn creates an ARP entry and network
is functional from then on.

You can see the details of my setup under this tutorial.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step

Example setup - I have 2 network - Link Local is untagged and Guest Network
uses VLAN Tagging:

Guest Network: 10.18.24.0/23
Guest Network GW: 10.18.24.1
Guest Router IP: 10.18.24.20

Link Local Network: 10.12.34.0/24
Link Local GW: 10.12.34.1
Link Local Router IP: 10.12.34.30

CloudStack Net: 10.15.32.0/23
CloudStack Net GW: 10.15.32.1
CloudStack IP: 10.15.32.141

When router VM powers up, based on variables that are passed via
/var/cache/cloud/cmdline, the key variables for this patch are:
*Localgw=10.12.34.1
*Gateway=10.18.24.1
*Mgmtcidr=10.15.32.0/23

With one of somewhat recent patches you will notice that Router VM will ping
the Localgw and Geteway variables. This may fix some issue with local routing -
however my CS Host and gateway is 2 hops away and therefore - the ARP table is
not populated completely for inbound communication to function properly.
Outbound from the RouterVM communication is fine.

My proposed fix is to do a 2 second ping count to a new variable MGMTGW,
derived via:
MGMTGW=$(echo $Mgtmcidr | awk -F . '{print $1.$2.$3.1}'

This will generate the gateway of CloudStack Net GW - however there is an
assumption that your gateway always ends with .1 - which is probably typical
97%.

Even is the ping to gateway fails because its not set to .1, in theory - the
ARP table should be populated with proper MAC addresses and INBOUND
communication should be functional after a 2 hop ping.

The worst case user will get is a 2 second delay even if ping fails - no harm -
so it's a very low risk solution.

Please let me know if the proposed solution is acceptable, if so - I will push
a patch into JIRA.

Thanks
ilya

RE: RouterVM bug fix patch - PLS DISCUSS

The ideal solution would be to push the IP of CloudStack core(s) in 
/var/cache/cloud/cmdline and ping would be initiated just to that host.

This will avoid the gateway guessing all together. 

However, at this moment - no CS GW IP is passed and hence we take another non 
harmful route.

-Original Message-
From: Musayev, Ilya [mailto:imusa...@webmd.net] 
Sent: Wednesday, December 05, 2012 2:38 PM
To: cloudstack-dev@incubator.apache.org
Subject: RouterVM bug fix patch - PLS DISCUSS

I've previously started few threads on router vm issue. After the reboot of 
Router VM, the link local IP could not be reached until we initiate a ping 
request from within the Router VM. This inturn creates an ARP entry and network 
is functional from then on.


You can see the details of my setup under this tutorial.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Advanced+Network+Tutorial+-+Step+by+Step


Example setup - I have 2 network - Link Local is untagged and Guest Network 
uses VLAN Tagging:

Guest Network: 10.18.24.0/23
Guest Network GW: 10.18.24.1
Guest Router IP: 10.18.24.20

Link Local Network: 10.12.34.0/24
Link Local GW: 10.12.34.1
Link Local Router IP: 10.12.34.30


CloudStack Net: 10.15.32.0/23
CloudStack Net GW: 10.15.32.1
CloudStack IP: 10.15.32.141


When router VM powers up, based on variables that are passed via 
/var/cache/cloud/cmdline, the key variables for this patch are:
*Localgw=10.12.34.1
*Gateway=10.18.24.1
*Mgmtcidr=10.15.32.0/23

With one of somewhat recent patches you will notice that Router VM will ping 
the Localgw and Geteway variables. This may fix some issue with local routing - 
however my CS Host and gateway is 2 hops away and therefore - the ARP table is 
not populated completely for inbound communication to function properly. 
Outbound from the RouterVM communication is fine.

My proposed fix is to do a 2 second ping count to a new variable MGMTGW, 
derived via:
MGMTGW=$(echo $Mgtmcidr | awk -F . '{print $1.$2.$3.1}'

This will generate the gateway of CloudStack Net GW - however there is an 
assumption that your gateway always ends with .1 - which is probably typical 
97%.

Even is the ping to gateway fails because its not set to .1, in theory - the 
ARP table should be populated with proper MAC addresses and INBOUND 
communication should be functional after a 2 hop ping.

The worst case user will get is a 2 second delay even if ping fails - no harm - 
so it's a very low risk solution.

Please let me know if the proposed solution is acceptable, if so - I will push 
a patch into JIRA.

Thanks
ilya

Re: SSVM Network Configuration Issue

Yes, see your cmdline. internaldns1=10.0.3.2, so it is forcing the use of
management network to route to 10.0.3.2 for DNS. that's where the route is
coming from. you will want to use something on your management net for
internal DNS, or something other than that router.


On Wed, Dec 5, 2012 at 11:59 AM, John Burwell jburw...@basho.com wrote:

 Anthony,

 I apologize for forgetting to response to the part of your answer the
 first part of the question.  I had set the management.network.cidr and host
 global settings to 192.168.0.0/24 and 192.168.56.18 respectively.  Please
 see the zone1.devcloud.cfg Marvin configuration attached to my original
 email for the actual setting, as well as, the network configurations used
 when this problem occurs.

 Thanks,
 -John

 On Dec 5, 2012, at 12:46 PM, Anthony Xu xuefei...@citrix.com wrote:

  Hi join,
 
  Try following,
 
  Set global configuration management.network.cidr to your management
 server CIDR, if this configuration is not available in UI, you can change
 it in DB directly.
 
  Restart management,
  Stop/Start SSVM and CPVM.
 
 
  And could you post cat /proc/cmdline in SSVM?
 
 
 
  Anthony
 
  -Original Message-
  From: John Burwell [mailto:jburw...@basho.com]
  Sent: Wednesday, December 05, 2012 9:11 AM
  To: cloudstack-dev@incubator.apache.org
  Subject: Re: SSVM Network Configuration Issue
 
  All,
 
  I was wondering if anyone else is experiencing this problem when using
  secondary storage on a devcloud-style VM with a host-only and NAT
  adapter.  One aspect of this issue that seems interesting is that
  following route table from the SSVM:
 
  root@s-5-TEST:~# route
  Kernel IP routing table
  Destination Gateway Genmask Flags Metric RefUse
  Iface
  10.0.3.2192.168.56.1255.255.255.255 UGH   0  00
  eth1
  10.0.3.0*   255.255.255.0   U 0  00
  eth2
  192.168.56.0*   255.255.255.0   U 0  00
  eth1
  192.168.56.0*   255.255.255.0   U 0  00
  eth3
  link-local  *   255.255.0.0 U 0  00
  eth0
  default 10.0.3.20.0.0.0 UG0  00
  eth2
 
  In particular, the gateways for the management and guest networks do
  not match to the configuration provided to the management server (i.e.
  10.0.3.2 is the gateway for the 10.0.3.0/24 network and 192.168.56.1 is
  the gateway for the 192.168.56.0/24 network).  With this configuration,
  the SSVM has a socket connection to the management server, but is in
  alert state.  Finally, when I remove the host-only NIC and use only a
  NAT adapter the SSVM's networking works as expecting leading me to
  believe that the segregated network configuration is at the root of the
  problem.
 
  Until I can get the networking on the SSVM configured, I am unable to
  complete the testing of the S3-backed Secondary Storage enhancement.
 
  Thank you for your help,
  -John
 
  On Dec 3, 2012, at 4:46 PM, John Burwell jburw...@basho.com wrote:
 
  All,
 
  I am setting up a multi-zone devcloud configuration on VirtualBox
  4.2.4 using the Ubuntu 12.04.1 and Xen 4.1.  I have configured the base
  management server VM (zone1) to serve as both the zone1, as well as,
  the management server (running MySql) with eth0 as a host-only adapter
  and a static IP of 192.168.56.15 and eth1 as a NAT adapter (see the
  attached zone1-interfaces file for the exact network configuration on
  the VM).  The management and guest networks are configured as follows:
 
  Zone 1
  Management: 192.168.56.100-149 gw 192.168.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.200-10.0.3.220 gw 10.0.3.2 dns 8.8.8.8
  Zone 2
  Management: 192.168.56.150-200 gw 192.68.56.1 dns 10.0.3.2 (?)
  Guest: 10.0.3.221-240 gw 10.0.3.2 dns 8.8.8.8
 
  The management server deploys and starts without error.  I then
  populate the configuration it using the attached Marvin configuration
  file (zone1.devcloud.cfg) and restart the management server in order to
  allow the global configuration option changes to take effect.
  Following the restart, the CPVM and SSVM start without error.
  Unfortunately, they drop into alert status, and the SSVM is unable to
  connect outbound through the guest network (very important for my tests
  because I am testing S3-backed secondary storage).
 
  From the diagnostic checks I have performed on the management server
  and the SSVM, it appears that the daemon on the SSVM is connecting back
  to the management server.  I have attached a set of diagnostic
  information from the management server (mgmtsvr-zone1-diagnostics.log)
  and SSVM server (ssvm-zone1-diagnostics.log) that includes the results
  of ifconfig, route, netstat and ping checks, as well as, other
  information (e.g. the contents of /var/cache/cloud/cmdline on the SSVM).
  Finally, I have attached the vmops log from the management server
  (vmops-zone1.log).

[jira] [Created] (CLOUDSTACK-587) MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:

Anthony Xu created CLOUDSTACK-587:
-

 Summary: MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:
 Key: CLOUDSTACK-587
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-587
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Anthony Xu
Assignee: Anthony Xu


 How can I figure out this exception when I try to create a new 
 instance using by example Centos 6.3 ISO (compute offering = 
 500MHertz, 500MB, local
 storage) ?
 
 WARN  [xen.resource.CitrixResourceBase] (DirectAgent-36:) Catch
 Exception:
 class com.xensource.xenapi.Types$XenAPIException due to 
 MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
 dynamic_min ? dynamic_max ? static_max 
 MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
 dynamic_min ? dynamic_max ? static_max at 
 com.xensource.xenapi.Types.checkResponse(Types.java:1732)
  at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
 at
 com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerCon
 n
 ection.dispatch(XenServerConnectionPool.java:909)
  at com.xensource.xenapi.VM.setMemoryStaticMin(VM.java:3450)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixR
 e
 sourceBase.java:3116)
  at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTempl
 a
 te(CitrixResourceBase.java:985)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixRes
 o
 urceBase.java:1278)
  at
 com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResourc
 e
 .java:142)
 at
 com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Ci
 t
 rixResourceBase.java:497)
  at
 com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOss
 R
 esource.java:136)
 at
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.
 java:191)
  at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439
 ) at 
 java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  at java.util.concurrent.FutureTask.run(FutureTask.java:138)
 at
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
 c
 cess$301(ScheduledThreadPoolExecutor.java:98)
  at
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
 u
 n(ScheduledThreadPoolExecutor.java:206)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu
 t
 or.java:886)
  at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
 j
 ava:908)
 at java.lang.Thread.run(Thread.java:680)
 
 Regards,
 
 --


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

Re: Review Request: Changed the @Parameter for some VM group commands.


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8133/#review14057
---

Ship it!


Ship It!

- Rohit Yadav


On Nov. 20, 2012, 2:05 a.m., Fang Wang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8133/
 ---
 
 (Updated Nov. 20, 2012, 2:05 a.m.)
 
 
 Review request for cloudstack, Prachi Damle and Alex Huang.
 
 
 Description
 ---
 
 Part of the API refactoring work. This is the initial modification to the 
 @Parameter annotation for
 some commands in the VM group. 
 
 
 This addresses bug cloudstack-518.
 
 
 Diffs
 -
 
   api/src/com/cloud/api/Parameter.java 2da3c40 
   api/src/org/apache/cloudstack/user/api/vm/commands/AssignVMCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/CreateVMGroupCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DeleteVMGroupCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DeployVMCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DestroySystemVmCmd.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/8133/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Fang Wang

Re: Review Request: Changed the @Parameter for some VM group commands.



 On Dec. 5, 2012, 7:53 p.m., Rohit Yadav wrote:
  Ship It!

Committed on api_refactoring branch:

commit ee0a4a41d0f8db2f895a1699150c60cac6facab8
Author: Fang Wang fang.w...@citrix.com
Date:   Wed Dec 5 11:50:23 2012 -0800

api_refactor: entity annotation and fix parameter

- Add Entity annotation
- Annotate few responses
- Fix Parameter annotation to have entityType

Signed-off-by: Rohit Yadav bhais...@apache.org


- Rohit


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8133/#review14057
---


On Nov. 20, 2012, 2:05 a.m., Fang Wang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8133/
 ---
 
 (Updated Nov. 20, 2012, 2:05 a.m.)
 
 
 Review request for cloudstack, Prachi Damle and Alex Huang.
 
 
 Description
 ---
 
 Part of the API refactoring work. This is the initial modification to the 
 @Parameter annotation for
 some commands in the VM group. 
 
 
 This addresses bug cloudstack-518.
 
 
 Diffs
 -
 
   api/src/com/cloud/api/Parameter.java 2da3c40 
   api/src/org/apache/cloudstack/user/api/vm/commands/AssignVMCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/CreateVMGroupCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DeleteVMGroupCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DeployVMCmd.java 
 PRE-CREATION 
   api/src/org/apache/cloudstack/user/api/vm/commands/DestroySystemVmCmd.java 
 PRE-CREATION 
 
 Diff: https://reviews.apache.org/r/8133/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Fang Wang

[jira] [Created] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI

Pranav Saxena created CLOUDSTACK-588:


 Summary: restoreVirtualMachine api functionality on the UI
 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Pranav Saxena


RestoreVirtualMachine api action not shown in UI. 

We have 2 apis in Cloudstack - restoreVirtualMachine and recoverVirtualMachine. 
But we show actions for only one of them in the UI actions. We should have one 
for restoreVirtualMachine api and call it Reset vm on the UI.

Restore action can happen while VMs are in the Running and Stopped state and 
can be done by root admin /domain-admin and users.

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

[jira] [Assigned] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pranav Saxena reassigned CLOUDSTACK-588:


Assignee: Pranav Saxena

 restoreVirtualMachine api functionality on the UI
 -

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Pranav Saxena
Assignee: Pranav Saxena

 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

qemu-img convert a qcow2 to a qcow2

Anyone know why we do a convert from qcow2 to qcow2 when we crete a volume
or template? It seems slower than file copy, and it strips valuable
compression which could speed up deployments significantly. Our qcow2
templates are compressed to about 1/3 size of uncompressed, and since the
compression is read-only it doesn't really affect future write performance,
and gives a slight performance gain to reads since less is read.

createvolume.sh
qemu_img convert -f qcow2 -O qcow2

managesnapshot.sh
qemu_img convert -f qcow2 -O qcow2

createtmplt.sh
qemu_img convert -f qcow2 -O qcow2

I'd suggest if we already know it's qcow2, and we want to create a qcow2 to
copy the file. Objections?

[jira] [Commented] (CLOUDSTACK-536) remove citrix cloudpatform from 4.0 build - CloudStack is ASF project

2012-12-05 Thread Joe Brockmeier (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510733#comment-13510733
 ] 

Joe Brockmeier commented on CLOUDSTACK-536:
---

As far as I can tell, these aren't displaying in ACS 4.0 - just present. Looks 
like it's been set up to have a workaround to call no-logo in the stylesheet. 
We should clean it up to get rid of these entirely, but I don't think it's 
crucial that they be removed in 4.0.1 if we don't have a patch by freeze. 

 remove citrix cloudpatform from 4.0 build - CloudStack is ASF project
 -

 Key: CLOUDSTACK-536
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-536
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
 Environment: CS 4.0 from http://cloudstack.apt-get.eu/rhel/4.0/
 The rpms are:
 cloud-utils-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-4.0.0-0.140.el6.4.0.x86_64
 cloud-setup-4.0.0-0.140.el6.4.0.x86_64
 cloud-scripts-4.0.0-0.140.el6.4.0.x86_64
 cloud-deps-4.0.0-0.140.el6.4.0.x86_64
 cloud-server-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-ui-4.0.0-0.140.el6.4.0.x86_64
 cloud-python-4.0.0-0.140.el6.4.0.x86_64
 cloud-core-4.0.0-0.140.el6.4.0.x86_64
 cloud-usage-4.0.0-0.140.el6.4.0.x86_64
 cloud-aws-api-4.0.0-0.140.el6.4.0.x86_64
Reporter: ilya musayev
Assignee: Brian Federle
Priority: Minor
 Fix For: 4.0.0, 4.0.1, 4.1.0


 Please remove Citrix Logo and CloudPlaform from the UI page, files are (could 
 be more):
 rpm/deb release:
 in /client/images/
 logo-login.png
 citrix-logo-darkbg.png
 logo-cloudplatform.png
 and possibly others that may contain Citrix CloudPlatform mention.
 Also, please include the wording for CloudStack as Apache CloudStack in 
 corresponding documentation and UI pages for CS ASF project.
 Thank you
 -ilya

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

RE: [jira] [Commented] (CLOUDSTACK-536) remove citrix cloudpatform from 4.0 build - CloudStack is ASF project

Agreed, as these are not functionality impacting.

-Original Message-
From: Joe Brockmeier (JIRA) [mailto:j...@apache.org] 
Sent: Wednesday, December 05, 2012 3:30 PM
To: cloudstack-dev@incubator.apache.org
Subject: [jira] [Commented] (CLOUDSTACK-536) remove citrix cloudpatform from 
4.0 build - CloudStack is ASF project


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510733#comment-13510733
 ] 

Joe Brockmeier commented on CLOUDSTACK-536:
---

As far as I can tell, these aren't displaying in ACS 4.0 - just present. Looks 
like it's been set up to have a workaround to call no-logo in the stylesheet. 
We should clean it up to get rid of these entirely, but I don't think it's 
crucial that they be removed in 4.0.1 if we don't have a patch by freeze. 

 remove citrix cloudpatform from 4.0 build - CloudStack is ASF project
 -

 Key: CLOUDSTACK-536
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-536
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
 Environment: CS 4.0 from 
 http://cloudstack.apt-get.eu/rhel/4.0/
 The rpms are:
 cloud-utils-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-4.0.0-0.140.el6.4.0.x86_64
 cloud-setup-4.0.0-0.140.el6.4.0.x86_64
 cloud-scripts-4.0.0-0.140.el6.4.0.x86_64
 cloud-deps-4.0.0-0.140.el6.4.0.x86_64
 cloud-server-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-ui-4.0.0-0.140.el6.4.0.x86_64
 cloud-python-4.0.0-0.140.el6.4.0.x86_64
 cloud-core-4.0.0-0.140.el6.4.0.x86_64
 cloud-usage-4.0.0-0.140.el6.4.0.x86_64
 cloud-aws-api-4.0.0-0.140.el6.4.0.x86_64
Reporter: ilya musayev
Assignee: Brian Federle
Priority: Minor
 Fix For: 4.0.0, 4.0.1, 4.1.0


 Please remove Citrix Logo and CloudPlaform from the UI page, files are (could 
 be more):
 rpm/deb release:
 in /client/images/
 logo-login.png
 citrix-logo-darkbg.png
 logo-cloudplatform.png
 and possibly others that may contain Citrix CloudPlatform mention.
 Also, please include the wording for CloudStack as Apache CloudStack in 
 corresponding documentation and UI pages for CS ASF project.
 Thank you
 -ilya

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

[jira] [Commented] (CLOUDSTACK-536) remove citrix cloudpatform from 4.0 build - CloudStack is ASF project

2012-12-05 Thread Musayev, Ilya (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510744#comment-13510744
 ] 

Musayev, Ilya commented on CLOUDSTACK-536:
--

Agreed, as these are not functionality impacting.



 remove citrix cloudpatform from 4.0 build - CloudStack is ASF project
 -

 Key: CLOUDSTACK-536
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-536
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
 Environment: CS 4.0 from http://cloudstack.apt-get.eu/rhel/4.0/
 The rpms are:
 cloud-utils-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-4.0.0-0.140.el6.4.0.x86_64
 cloud-setup-4.0.0-0.140.el6.4.0.x86_64
 cloud-scripts-4.0.0-0.140.el6.4.0.x86_64
 cloud-deps-4.0.0-0.140.el6.4.0.x86_64
 cloud-server-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-ui-4.0.0-0.140.el6.4.0.x86_64
 cloud-python-4.0.0-0.140.el6.4.0.x86_64
 cloud-core-4.0.0-0.140.el6.4.0.x86_64
 cloud-usage-4.0.0-0.140.el6.4.0.x86_64
 cloud-aws-api-4.0.0-0.140.el6.4.0.x86_64
Reporter: ilya musayev
Assignee: Brian Federle
Priority: Minor
 Fix For: 4.0.0, 4.0.1, 4.1.0


 Please remove Citrix Logo and CloudPlaform from the UI page, files are (could 
 be more):
 rpm/deb release:
 in /client/images/
 logo-login.png
 citrix-logo-darkbg.png
 logo-cloudplatform.png
 and possibly others that may contain Citrix CloudPlatform mention.
 Also, please include the wording for CloudStack as Apache CloudStack in 
 corresponding documentation and UI pages for CS ASF project.
 Thank you
 -ilya

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

Re: qemu-img convert a qcow2 to a qcow2


On 05-Dec-2012, at 12:17 PM, Marcus Sorensen shadow...@gmail.com wrote:

 Anyone know why we do a convert from qcow2 to qcow2 when we crete a volume
 or template? It seems slower than file copy, and it strips valuable
 compression which could speed up deployments significantly. Our qcow2
 templates are compressed to about 1/3 size of uncompressed, and since the
 compression is read-only it doesn't really affect future write performance,
 and gives a slight performance gain to reads since less is read.
 
 createvolume.sh
 qemu_img convert -f qcow2 -O qcow2
 
 managesnapshot.sh
 qemu_img convert -f qcow2 -O qcow2
 
 createtmplt.sh
 qemu_img convert -f qcow2 -O qcow2
 
 I'd suggest if we already know it's qcow2, and we want to create a qcow2 to
 copy the file. Objections?


I don't know why we do that, but what the command is saying is that we want to 
convert an input image from qcow2 to keeping the same output format, -O qcow2
But yes, if the input format is already qcow2 and output is qcow2 we can just 
copy the file. Edison?

Regards.

[jira] [Resolved] (CLOUDSTACK-587) MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:

2012-12-05 Thread Rohit Yadav (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav resolved CLOUDSTACK-587.


Resolution: Fixed

Fixed by Anthony on master:
commit 40682fc43dc202b1dbffb4fd32388ad1a46f6e6a
Author: anthony anth...@cloud.com
Date:   Wed Dec 5 05:24:46 2012 -0800

CLOUDSTACK-587:
 use setMemoryLimits instead

 MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy:
 --

 Key: CLOUDSTACK-587
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-587
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anthony Xu
Assignee: Anthony Xu

  How can I figure out this exception when I try to create a new 
  instance using by example Centos 6.3 ISO (compute offering = 
  500MHertz, 500MB, local
  storage) ?
  
  WARN  [xen.resource.CitrixResourceBase] (DirectAgent-36:) Catch
  Exception:
  class com.xensource.xenapi.Types$XenAPIException due to 
  MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
  dynamic_min ? dynamic_max ? static_max 
  MEMORY_CONSTRAINT_VIOLATIONMemory limits must satisfy: static_min ?
  dynamic_min ? dynamic_max ? static_max at 
  com.xensource.xenapi.Types.checkResponse(Types.java:1732)
   at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
  at
  com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerCon
  n
  ection.dispatch(XenServerConnectionPool.java:909)
   at com.xensource.xenapi.VM.setMemoryStaticMin(VM.java:3450)
  at
  com.cloud.hypervisor.xen.resource.CitrixResourceBase.setMemory(CitrixR
  e
  sourceBase.java:3116)
   at
  com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTempl
  a
  te(CitrixResourceBase.java:985)
  at
  com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixRes
  o
  urceBase.java:1278)
   at
  com.cloud.hypervisor.xen.resource.XcpOssResource.execute(XcpOssResourc
  e
  .java:142)
  at
  com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(Ci
  t
  rixResourceBase.java:497)
   at
  com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOss
  R
  esource.java:136)
  at
  com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.
  java:191)
   at
  java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439
  ) at 
  java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
  at
  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
  c
  cess$301(ScheduledThreadPoolExecutor.java:98)
   at
  java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
  u
  n(ScheduledThreadPoolExecutor.java:206)
  at
  java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecu
  t
  or.java:886)
   at
  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
  j
  ava:908)
  at java.lang.Thread.run(Thread.java:680)
  
  Regards,
  
  --

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

[jira] [Updated] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pranav Saxena updated CLOUDSTACK-588:
-

Affects Version/s: 4.0.1
   4.0.0
Fix Version/s: 4.0.1
  Summary: restoreVirtualMachine api functionality on the UI   
(was: restoreVirtualMachine api functionality on the UI)

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.0.1


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

Re: qemu-img convert a qcow2 to a qcow2

Eventually we'll probably want to support multiple versions, replacing one
or both of the formats with variables, but even then we'll probably just
want to copy if source format == destination format.


On Wed, Dec 5, 2012 at 1:51 PM, Rohit Yadav rohit.ya...@citrix.com wrote:


 On 05-Dec-2012, at 12:17 PM, Marcus Sorensen shadow...@gmail.com wrote:

  Anyone know why we do a convert from qcow2 to qcow2 when we crete a
 volume
  or template? It seems slower than file copy, and it strips valuable
  compression which could speed up deployments significantly. Our qcow2
  templates are compressed to about 1/3 size of uncompressed, and since the
  compression is read-only it doesn't really affect future write
 performance,
  and gives a slight performance gain to reads since less is read.
 
  createvolume.sh
  qemu_img convert -f qcow2 -O qcow2
 
  managesnapshot.sh
  qemu_img convert -f qcow2 -O qcow2
 
  createtmplt.sh
  qemu_img convert -f qcow2 -O qcow2
 
  I'd suggest if we already know it's qcow2, and we want to create a qcow2
 to
  copy the file. Objections?


 I don't know why we do that, but what the command is saying is that we
 want to convert an input image from qcow2 to keeping the same output
 format, -O qcow2
 But yes, if the input format is already qcow2 and output is qcow2 we can
 just copy the file. Edison?

 Regards.

[jira] [Commented] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI

2012-12-05 Thread David Nalley (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510761#comment-13510761
 ] 

David Nalley commented on CLOUDSTACK-588:
-

4.0.1 is a bugfix version, please introduce new functionality into the next 
feature release (4.1.0) 



 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.0.1


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

[jira] [Updated] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pranav Saxena updated CLOUDSTACK-588:
-

Fix Version/s: (was: 4.0.1)
   4.1.0

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.1.0


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

[jira] [Commented] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510765#comment-13510765
 ] 

Pranav Saxena commented on CLOUDSTACK-588:
--

Sure David , done that . This functionality is supported by the API but wasn't 
supported by the UI .Hence I have added the functionality to support it from 
the UI as well . 

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.1.0


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

[jira] [Commented] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510766#comment-13510766
 ] 

Pranav Saxena commented on CLOUDSTACK-588:
--

Commit: 
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/commit/30dd34d2

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.1.0


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

[jira] [Resolved] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pranav Saxena resolved CLOUDSTACK-588.
--

Resolution: Fixed

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.1.0


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

[jira] [Updated] (CLOUDSTACK-588) restoreVirtualMachine api functionality on the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pranav Saxena updated CLOUDSTACK-588:
-

Issue Type: Task  (was: Bug)

 restoreVirtualMachine api functionality on the UI 
 --

 Key: CLOUDSTACK-588
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-588
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
Reporter: Pranav Saxena
Assignee: Pranav Saxena
 Fix For: 4.1.0


 RestoreVirtualMachine api action not shown in UI. 
 We have 2 apis in Cloudstack - restoreVirtualMachine and 
 recoverVirtualMachine. But we show actions for only one of them in the UI 
 actions. We should have one for restoreVirtualMachine api and call it Reset 
 vm on the UI.
 Restore action can happen while VMs are in the Running and Stopped state and 
 can be done by root admin /domain-admin and users.

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

RE: qemu-img convert a qcow2 to a qcow2

2012-12-05 Thread Edison Su

If the source image has dependence on other images, then we should use 
qemu-img convert , otherwise, cp is enough. 

 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Wednesday, December 05, 2012 1:01 PM
 To: cloudstack-dev@incubator.apache.org
 Subject: Re: qemu-img convert a qcow2 to a qcow2

 Eventually we'll probably want to support multiple versions, replacing one or
 both of the formats with variables, but even then we'll probably just want to
 copy if source format == destination format.

 On Wed, Dec 5, 2012 at 1:51 PM, Rohit Yadav rohit.ya...@citrix.com
 wrote:

  On 05-Dec-2012, at 12:17 PM, Marcus Sorensen shadow...@gmail.com
 wrote:

   Anyone know why we do a convert from qcow2 to qcow2 when we crete
 a
  volume
   or template? It seems slower than file copy, and it strips valuable
   compression which could speed up deployments significantly. Our
   qcow2 templates are compressed to about 1/3 size of uncompressed,
   and since the compression is read-only it doesn't really affect
   future write
  performance,
   and gives a slight performance gain to reads since less is read.

   createvolume.sh
   qemu_img convert -f qcow2 -O qcow2

   managesnapshot.sh
   qemu_img convert -f qcow2 -O qcow2

   createtmplt.sh
   qemu_img convert -f qcow2 -O qcow2

   I'd suggest if we already know it's qcow2, and we want to create a
   qcow2
  to
   copy the file. Objections?

  I don't know why we do that, but what the command is saying is that we
  want to convert an input image from qcow2 to keeping the same output
  format, -O qcow2 But yes, if the input format is already qcow2 and
  output is qcow2 we can just copy the file. Edison?

  Regards.

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent

2012-12-05 Thread Animesh Chaturvedi (JIRA)


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

Animesh Chaturvedi commented on CLOUDSTACK-585:
---

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

[jira] [Resolved] (CLOUDSTACK-536) remove citrix cloudpatform from 4.0 build - CloudStack is ASF project

2012-12-05 Thread Brian Federle (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Federle resolved CLOUDSTACK-536.
--

Resolution: Fixed

Committed to master:

commit 9e90ff58e955c0908e14fa527995838f2a00b425
Author: Brian Federle brian.fede...@citrix.com
Date:   Wed Dec 5 13:18:25 2012 -0800

CLOUDSTACK-536: Remove legacy CloudPlatform files

 remove citrix cloudpatform from 4.0 build - CloudStack is ASF project
 -

 Key: CLOUDSTACK-536
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-536
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.0.0, 4.0.1
 Environment: CS 4.0 from http://cloudstack.apt-get.eu/rhel/4.0/
 The rpms are:
 cloud-utils-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-4.0.0-0.140.el6.4.0.x86_64
 cloud-setup-4.0.0-0.140.el6.4.0.x86_64
 cloud-scripts-4.0.0-0.140.el6.4.0.x86_64
 cloud-deps-4.0.0-0.140.el6.4.0.x86_64
 cloud-server-4.0.0-0.140.el6.4.0.x86_64
 cloud-client-ui-4.0.0-0.140.el6.4.0.x86_64
 cloud-python-4.0.0-0.140.el6.4.0.x86_64
 cloud-core-4.0.0-0.140.el6.4.0.x86_64
 cloud-usage-4.0.0-0.140.el6.4.0.x86_64
 cloud-aws-api-4.0.0-0.140.el6.4.0.x86_64
Reporter: ilya musayev
Assignee: Brian Federle
Priority: Minor
 Fix For: 4.0.0, 4.0.1, 4.1.0


 Please remove Citrix Logo and CloudPlaform from the UI page, files are (could 
 be more):
 rpm/deb release:
 in /client/images/
 logo-login.png
 citrix-logo-darkbg.png
 logo-cloudplatform.png
 and possibly others that may contain Citrix CloudPlatform mention.
 Also, please include the wording for CloudStack as Apache CloudStack in 
 corresponding documentation and UI pages for CS ASF project.
 Thank you
 -ilya

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

[jira] [Comment Edited] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent

2012-12-05 Thread Animesh Chaturvedi (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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

[jira] [Commented] (CLOUDSTACK-585) DHCP entry provisioning is broken in the KVM agent


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

Anthony Xu commented on CLOUDSTACK-585:
---

Wolfram,

Could you please check if there is trailing space in name, instance_name column 
of DB entry in vm_instance table for this VM? I suspect there is a trailing 
space.


Anthony


 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

Connecting Netscaler VPX and CS4

What user permissions would I need?

My Network Team would not give me admin priveleges - since I would not have 
admin in the production, so I need to know which perms are needed  or commands 
used to create a custom perm set.

Thanks
ilya

[jira] [Commented] (CLOUDSTACK-335) KVM VPC load balancer not working

2012-12-05 Thread Joe Brockmeier (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510892#comment-13510892
 ] 

Joe Brockmeier commented on CLOUDSTACK-335:
---

This has been pulled into 4.0.1 with commit 
1217f5cd326c9a36d21b0136f76d77caceb09d84. 

 KVM VPC load balancer not working
 -

 Key: CLOUDSTACK-335
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-335
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: pre-4.0.0, 4.0.0
Reporter: Marcus Sorensen
Assignee: edison su
 Fix For: 4.0.0, 4.0.1, 4.1.0

   Original Estimate: 4h
  Remaining Estimate: 4h

 The load balancer doesn't work in VPC for KVM. I've looked at the code and 
 will fix this in the next day or two. We're just missing 
 VPCLoadBalancerConfig, should be an easy fix.

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

[jira] [Commented] (CLOUDSTACK-576) PaaS Enablement: Composite Application Blueprints

2012-12-05 Thread Jie Feng (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510913#comment-13510913
]

Jie Feng commented on CLOUDSTACK-576:
-

Here is my take on Alex's questions:

(1) I recommend something lightweight based on CloudStack concepts. We can use
AWS CloudFormation's JS format as a reference starting point and make changes
where needed.
(2) For v1.0, at minimum, the ability to launch a set of VMs. The blueprint
should capture VM deployment properties like template ID/network, startup
order.
(3) Scripts, Chef and Puppet can be used to install software and configure VMs
after they are launched. You can already do this today within a running VM. In
my opinion, deeper integration should be optional.

This feature should be able to use CloudStack's credential and integrate into
the CloudStack UI (through UI plugin or other means).

Jie

PaaS Enablement: Composite Application Blueprints
-

Key: CLOUDSTACK-576
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-576
Project: CloudStack
Issue Type: New Feature
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, AWSAPI
Reporter: Duncan Johnston-Watt

Given the level of interest in CloudStack as a platform for private, hybrid
and public cloud one of the gaps is support for composite/multi-tier
application blueprints comparable to VMware vApp and CloudFormation templates
without necessarily slavishly following either of them. This is almost
certainly a new component. One that will leverage/enhance the API/AWSAPI
components amongst others.

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

[jira] [Commented] (CLOUDSTACK-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2012-12-05 Thread Jason Bausewein (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510950#comment-13510950
 ] 

Jason Bausewein commented on CLOUDSTACK-105:


I am able to reproduce this issue consistently.  I have a single xen host in a 
basic zone.  I tracked it down to the following process creating the 
stream-unix.. files about every 10 seconds.

root  8237  8223  0 09:59 ?00:00:00 ovs-vsctl add-br xapi0

Dec  5 09:59:15 xenserver1 ovs-vsctl: 1|vsctl|INFO|Called as ovs-vsctl 
add-br xapi0
Dec  5 09:59:15 xenserver1 ovs-vsctl: 
2|stream_unix|ERR|/tmp/stream-unix.8237.0: connection to 
/var/run/openvswitch/db.sock failed: No such file or directory
Dec  5 09:59:15 xenserver1 ovs-vsctl: 
3|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt 
failed (No such file or directory)
Dec  5 09:59:16 xenserver1 ovs-vsctl: 
4|stream_unix|ERR|/tmp/stream-unix.8237.1: connection to 
/var/run/openvswitch/db.sock failed: No such file or directory
Dec  5 09:59:16 xenserver1 ovs-vsctl: 
5|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt 
failed (No such file or directory)
Dec  5 09:59:18 xenserver1 ovs-vsctl: 
6|stream_unix|ERR|/tmp/stream-unix.8237.2: connection to 
/var/run/openvswitch/db.sock failed: No such file or directory
Dec  5 09:59:18 xenserver1 ovs-vsctl: 
7|reconnect|WARN|unix:/var/run/openvswitch/db.sock: connection attempt 
failed (No such file or directory)

I am not using openvswitch.  Is there something I need to turn off?


 /tmp/stream-unix..## stale sockets causing inodes to run out on 
 Xenserver
 -

 Key: CLOUDSTACK-105
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-105
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: pre-4.0.0
 Environment: Xenserver 6.0.2
 Cloudstack 3.0.2
Reporter: Caleb Call
Assignee: Devdeep Singh
 Fix For: 4.1.0


 We came across an interesting issue in one of our clusters.  We ran out of 
 inodes on all of our cluster members (since when does this happen in 2012?).  
 When this happened, it in turn made the / filesystem a read-only filesystem 
 which in turn made all the hosts go in to emergency maintenance mode and as a 
 result get marked down by Cloudstack.  We found that it was caused by 
 hundreds of thousands of stale socket files in /tmp named 
 stream-unix..##.  To resolve the issue, we had to delete those 
 stale socket files (find /tmp -name *stream* -mtime +7 -exec rm -v {} \;), 
 then kill and restart xapi, then correct the emergency maintenance mode.  
 These hosts had only been up for 45 days before this issue occurred.  
 In our scouring of the interwebs, the only other instance we've been able to 
 find of this (or similar) happening is in the same setup we are currently 
 running. Xenserver 6.0.2 with CS 3.0.2.  Do these stream-unix sockets have 
 anything to do with Cloudstack?  I would think if this was a Xenserver issue 
 (bug), there would be a lot more on the internet about this happening.  For a 
 temporary workaround, we've added a cronjob to cleanup these files but we'd 
 really like to address the actual issue that's causing these sockets to 
 become stale and not get cleaned-up.

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

Re: CentOS System VM?

2012-12-05 Thread Chiradeep Vittal

The current system vm is getting long in the tooth. I (or Rohit Yadav)
will looking into building a wheezy-based systemvm that includes hyper-v
drivers.
Hopefully network throughput should be better as well when used with
multiple cores.

On 12/5/12 10:38 AM, Jason Davis scr...@gmail.com wrote:

TBH Hyper-V synthetic drivers(modules) is supported in the mainline
kernel.

So the argument that CentOS 6.x has better support is moot.

This assumes that the kernel version on the SSVM is at least 2.6.32. I ran
Ubuntu Server 11.x and Centos 6.x on Hyper-V natively and just needed to
load the kernel modules for the synthetic stuffs to work.

Ancient example of getting the Hyper-V modules built/working on Debian 6.0
http://virtualisationandmanagement.wordpress.com/2010/11/02/debian-on-hype
r-v-with-4-vcpu-support-and-syntetic-network/





On Wed, Dec 5, 2012 at 12:25 PM, Kelceydamage@bbits kel...@bbits.ca
wrote:

 I'm very interested in this.

 Sent from my iPhone

 On Dec 5, 2012, at 10:10 AM, Donal Lafferty donal.laffe...@citrix.com
 wrote:

  Has anyone looked into building a system VM that runs on a CentOS
distro?

Re: API refactoring work for 4.1.0

2012-12-05 Thread Prasanna Santhanam

On Wed, Dec 05, 2012 at 03:15:11AM +0530, Andrew Bayer wrote:
 Seems to me that coming up with a general API validation test suite (using
 jclouds, Marvin, whatever) that verifies consistency of behavior across API
 versions would be a very handy thing to have.
 
 A.

My idea is to use marvin to build a basic test suite to validate that
none of the API contracts are broken. I might be able to get to this
work going next week. There's a lot of APIs to go through though so
I'll be calling out for help on the lists.  I'll publish the first set
of tests so others can pick up after me.

 
 On Tue, Dec 4, 2012 at 11:52 AM, David Nalley da...@gnsa.us wrote:
 
  
   Please go through the api fs proposal. Suggestions, proposals, feedback,
  flames?
  
 
  Sorry for not going through this earlier.
  The unit tests and testing in general concern me.
  So let me ask - what is the plan to test that the refactored API
  behaves the same as the current API?
 
  --David
 

-- 
Prasanna.,

Re: Review Request: List API performance optimization part I.


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8172/#review14081
---

Ship it!


Please git pull latest api refactoring, the patch was big about 5-6k lines and 
huge merge conflicts, took me some time to merge them.
Please check the code, in case I missed something.

The build system is broken now, we need to fix it.

Committed in api_refactoring;

commit b0ce8fd4ff512c7a7da0a71671c4477492e854e7
Author: Min Chen min.c...@citrix.com
Date:   Wed Dec 5 16:18:38 2012 -0800

api: Optimize and improve api, db call perfomance

This is part 1 of list API refactoring. Commands covered:
listVmsCmd, listRoutersCmd Response covered:
UserVmResponse, DomainRouterResponse. DB views created:
user_vm_view, domain_router_view.

Signed-off-by: Rohit Yadav bhais...@apache.org

- Rohit Yadav


On Nov. 29, 2012, 6:57 p.m., Min Chen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8172/
 ---
 
 (Updated Nov. 29, 2012, 6:57 p.m.)
 
 
 Review request for cloudstack and Prachi Damle.
 
 
 Description
 ---
 
 This is part 1 of list API refactoring.
 Commands covered: listVmsCmd, listRoutersCmd
 Response covered: UserVmResponse, DomainRouterResponse.
 DB views created: user_vm_view, domain_router_view.
 
 
 This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-527.
 
 
 Diffs
 -
 
   api/src/com/cloud/api/ResponseGenerator.java 4e8fbd8 
   api/src/com/cloud/api/ResponseObject.java 2d08fb9 
   api/src/com/cloud/api/commands/ListRoutersCmd.java 8bf9ba8 
   api/src/com/cloud/api/commands/ListVMsCmd.java 2f6f988 
   api/src/com/cloud/api/response/BaseResponse.java e343a10 
   api/src/com/cloud/api/response/ControlledViewEntityResponse.java 
 PRE-CREATION 
   api/src/com/cloud/api/response/DomainRouterResponse.java d710aad 
   api/src/com/cloud/api/response/NicResponse.java 69d5c31 
   api/src/com/cloud/api/response/UserVmResponse.java f74c072 
   api/src/com/cloud/api/view/vo/ControlledViewEntity.java PRE-CREATION 
   api/src/com/cloud/api/view/vo/DomainRouterJoinVO.java PRE-CREATION 
   api/src/com/cloud/api/view/vo/UserVmJoinVO.java PRE-CREATION 
   api/src/com/cloud/server/ManagementService.java 7532cae 
   api/src/com/cloud/vm/UserVmService.java 98d02db 
   api/test/src/com/cloud/api/commands/test/ListRoutersCmdTest.java 
 PRE-CREATION 
   api/test/src/com/cloud/api/commands/test/ListVmsCmdTest.java PRE-CREATION 
   server/src/com/cloud/api/ApiDBUtils.java 3b5f634 
   server/src/com/cloud/api/ApiResponseHelper.java ebe8415 
   server/src/com/cloud/api/ApiServer.java a5c9ea5 
   server/src/com/cloud/api/response/ApiResponseSerializer.java 4be5dfa 
   server/src/com/cloud/configuration/DefaultComponentLibrary.java ef61044 
   server/src/com/cloud/server/ManagementServerImpl.java 117be57 
   server/src/com/cloud/user/AccountManager.java 90a34ad 
   server/src/com/cloud/user/AccountManagerImpl.java f595478 
   server/src/com/cloud/vm/UserVmManager.java 4ce9bfe 
   server/src/com/cloud/vm/UserVmManagerImpl.java 687f521 
   server/src/com/cloud/vm/dao/DomainRouterJoinDao.java PRE-CREATION 
   server/src/com/cloud/vm/dao/DomainRouterJoinDaoImpl.java PRE-CREATION 
   server/src/com/cloud/vm/dao/UserVmJoinDao.java PRE-CREATION 
   server/src/com/cloud/vm/dao/UserVmJoinDaoImpl.java PRE-CREATION 
   server/test/com/cloud/keystore/KeystoreTest.java e0e2126 
   server/test/com/cloud/user/MockAccountManagerImpl.java 08234fd 
   server/test/com/cloud/vm/MockUserVmManagerImpl.java 35ee139 
   setup/db/create-schema.sql fff084e 
   utils/src/com/cloud/utils/db/GenericDaoBase.java 8d5cb96 
 
 Diff: https://reviews.apache.org/r/8172/diff/
 
 
 Testing
 ---
 
 Create a performance unit test class to test the performance time.
 
 
 Thanks,
 
 Min Chen

[jira] [Created] (CLOUDSTACK-589) Juniper SRX does not depends on f5 iControl jar

2012-12-05 Thread Hiroaki Kawai (JIRA)

Hiroaki Kawai created CLOUDSTACK-589:


 Summary: Juniper SRX does not depends on f5 iControl jar
 Key: CLOUDSTACK-589
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-589
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.0.0, 4.0.1, 4.1.0
Reporter: Hiroaki Kawai


In plugins / network-elements / juniper-srx / pom.xml, there's a dependency 
element which says srx requires icontrol. But the code does not use icontrol at 
all, and it is safe to remove this dependency from here.

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

[jira] [Updated] (CLOUDSTACK-589) Juniper SRX does not depends on f5 iControl jar

2012-12-05 Thread Hiroaki Kawai (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hiroaki Kawai updated CLOUDSTACK-589:
-

Attachment: srx_pom.patch

 Juniper SRX does not depends on f5 iControl jar
 ---

 Key: CLOUDSTACK-589
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-589
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.0.0, 4.0.1, 4.1.0
Reporter: Hiroaki Kawai
  Labels: maven, patch
 Attachments: srx_pom.patch


 In plugins / network-elements / juniper-srx / pom.xml, there's a dependency 
 element which says srx requires icontrol. But the code does not use icontrol 
 at all, and it is safe to remove this dependency from here.

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

RE: [Discuss] Style Guide for Apache CloudStack Documentation ?

2012-12-05 Thread Radhika Puthiyetath

Thank you Animesh. This should help us.

-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] 
Sent: Wednesday, December 05, 2012 12:08 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [Discuss] Style Guide for Apache CloudStack Documentation ?

Radhika

The Struts style guide has more details 
http://struts.apache.org/2.2.3/docs/documentation-style-guide.html and we can 
borrow some tips from there. 

One other thing I think will help users is quick link to Single Page Html.  
This is useful because people often want to search for a specific word or 
phrase across the entire documentation. Generally, they already know what 
they're looking for; they just can't remember what section it's in. 

The separate-page style is useful for those who already know what section they 
need, or who want to read the entire documentation from front to back in 
sequence. But this is not the most common way documentation is accessed.

Thanks
Animesh

-Original Message-
From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com] 
Sent: Tuesday, December 04, 2012 6:11 AM
To: cloudstack-dev@incubator.apache.org
Subject: [Discuss] Style Guide for Apache CloudStack Documentation ?

Hello Community,

Any thoughts on the need of a style guide for the CloudStack Documentation ?

First of all, do we need one-If yes, do we need to create afresh , or follow 
the existing style guides within Apache projects, such as Maven. Here is the 
link: http://maven.apache.org/guides/development/guide-documentation-style.html.

Please educate me on the Apache way for Documentation style.

Alternatively, we can always follow what XenServer documentation is following.

Thanks
-Radhika

PS: I do understand that enhancing the documentation/ fixing the doc defect is 
the first priority of the doc contributors.

Re: CentOS System VM?