[jira] [Commented] (CLOUDSTACK-1469) kvm agent: agent service fails to start up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590565#comment-13590565 ] Wido den Hollander commented on CLOUDSTACK-1469: I'm not sure that one resolves it, see this link: https://github.com/twall/jna/issues/151 The platform.jar on that system seems to be too old. I just ran into it as well on Ubuntu 12.04 We might also want to distribute the platform.jar runtime. > kvm agent: agent service fails to start up > --- > > Key: CLOUDSTACK-1469 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1469 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.1.0 >Reporter: Prasanna Santhanam >Assignee: Hugo Trippaers >Priority: Blocker > > When management server tries to start the agent process the following errors > are seen in the agent logs > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177) > Caused by: java.lang.AbstractMethodError: > com.sun.jna.Structure.getFieldOrder()Ljava/util/List; > at com.sun.jna.Structure.fieldOrder(Structure.java:831) > at com.sun.jna.Structure.getFields(Structure.java:857) > at com.sun.jna.Structure.deriveLayout(Structure.java:983) > at com.sun.jna.Structure.calculateSize(Structure.java:908) > at com.sun.jna.Structure.calculateSize(Structure.java:896) > at com.sun.jna.Structure.allocateMemory(Structure.java:357) > at com.sun.jna.Structure.(Structure.java:191) > at com.sun.jna.Structure.(Structure.java:180) > at com.sun.jna.Structure.(Structure.java:167) > at com.sun.jna.Structure.(Structure.java:159) > at org.libvirt.jna.virError.(Unknown Source) > at org.libvirt.ErrorHandler.processError(Unknown Source) > at org.libvirt.Connect.(Unknown Source) > at > com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:31) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:666) > at com.cloud.agent.Agent.(Agent.java:163) > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:545) > at > com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:500) > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:416) > at com.cloud.agent.AgentShell.start(AgentShell.java:575) > ... 5 more > 01/03/2013 09:19:47 7080 jsvc.exec error: Cannot start daemon > 01/03/2013 09:19:47 7079 jsvc.exec error: Service exit with a return value of > 5 -- 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-1415) .deb packaging merge
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588136#comment-13588136 ] Wido den Hollander commented on CLOUDSTACK-1415: Patch looks good. I'd merge it into master. > .deb packaging merge > > > Key: CLOUDSTACK-1415 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1415 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Noa Resare >Assignee: Noa Resare > > This ticket tracks the merge of the packaging work that me and [~widodh] has > been working on in a separate branch. > The diff is kind of large, but most of the lines are the package > delimitations moving around resulting in a lot of file moves. The changes > should be orthogonal to non-packaging related developments and the target is > both the 4.1 and master branches. Since the current state of packaging is > very broken, at least it will be an improvement. > Concepts included in the diff: > * the replace.properties location used by maven is parameterized to allow for > a build that does not modify the currently git tracked files > * package naming is updated along the lines of what was discussed on the -dev > mailing list and between committers at the Build a Cloud Day in Belgium. > * package version pattern is updated (since we redo all package names, we > might as well drop the epoch) > This commit is not very well tested, and most likely broken in a few ways, > but since should be pretty safe regression-wise and it is a good starting > point to get to a broader user base for the last fixes to 4.1 packaging. -- 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-1421) 4.1 must be able to run with both 1.6 and 1.7 JRE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588109#comment-13588109 ] Wido den Hollander commented on CLOUDSTACK-1421: So my point is that we should be able to compile with 1.6 AND 1.7. I don't think there are any features in 1.7 we really need. > 4.1 must be able to run with both 1.6 and 1.7 JRE > - > > Key: CLOUDSTACK-1421 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1421 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Alex Huang >Assignee: Kelven Yang >Priority: Blocker > > Wido found the following error when compiling with 1.6 JDK. We have to make > sure that any changes didnot bring in the need to deploy on 1.7 JRE. > > /home/employee/wido/repos/cloudstack/framework/ipc/src/org/apache/cl > > >>> oudstack/framework/rpc/RpcServerCallImpl.java:[51,58] > > type parameters of T cannot be determined; no unique maximal > > instance exists for type variable T with upper bounds > > T,java.lang.Object [ERROR] > > >>> > > /home/employee/wido/repos/cloudstack/framework/ipc/src/org/apache/cl > > >>> oudstack/framework/rpc/RpcClientCallImpl.java:[191,60] > > type parameters of T cannot be determined; no unique maximal > > instance exists for type variable T with upper bounds > > T,java.lang.Object > > > > So I'm running Ubuntu 12.04.1 on all my systems (laptop, desktop, > > servers) and this is the maven information: -- 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-1410) Overcommit feature breaks compatibility between 4.0/4.1 management server and 4.2 agent
Wido den Hollander created CLOUDSTACK-1410: -- Summary: Overcommit feature breaks compatibility between 4.0/4.1 management server and 4.2 agent Key: CLOUDSTACK-1410 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1410 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Management Server Affects Versions: 4.1.0, 4.2.0 Environment: Ubuntu 12.04. 4.0 management server, 4.2 agent Reporter: Wido den Hollander Assignee: Bharat Kumar Fix For: 4.2.0 I just updated one of my agents to the 4.2 (master) code and it failed to start the new instance. I got a NullPointerException on this piece of code in LibvirtComputingResource: ctd.setShares(vmTO.getCpus() * vmTO.getMinSpeed()); getMinSpeed() is new, this used to be getSpeed() The VirtualMachineTO was however changed and getSpeed() was removed. A 4.0/4.1 management server however sends only the "speed" value instead of "minSpeed" and "maxSpeed". This leads to a 4.2 agent not working with 4.0 or 4.1 code. A couple of suggestions: - Add getSpeed() (and int speed) back to VirtualMachineTO - Check if getMinSpeed is empty and fall back to getSpeed if it's NULL Would that be a acceptable solution? -- 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-1301) VM I/O Throttling
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580720#comment-13580720 ] Wido den Hollander commented on CLOUDSTACK-1301: Forgot this one: http://libvirt.org/formatdomain.html#iotune So there is blkiotune and iotune, where we probably want iotune: "Currently, the only tuning available is Block I/O throttling for qemu." So that is handled in user-space which is better then kernel space where cgroups live. cgroups also only work with regular block devices and files, while iotune also works with RBD and such. > VM I/O Throttling > - > > Key: CLOUDSTACK-1301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1301 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Wei Zhou > > VM I/O Throttling, to set the maximum disk I/O rate of VMs. > Virtual machines are running on the same storage device (local storage or > share strage). Because of the rate limitation of device (such as iops), if > one VM has large disk operation, it may affect the disk performance of other > VMs running on the same storage device. > It is neccesary to set the maximum rate and limit the disk I/O of VMs. > More details: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+IO+Throttling -- 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-1301) VM I/O Throttling
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579791#comment-13579791 ] Wido den Hollander commented on CLOUDSTACK-1301: Yeah, but not all primary storage is able to do so. So I wouldn't be against handing this over to the primary storage, but if somebody wants to use the cgroups for this, they are more then welcome to do so arent they? But first I'd implement the actual polling of the IOps and store them in the usage database so admins can see how much IOps are being used by one Instance. > VM I/O Throttling > - > > Key: CLOUDSTACK-1301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1301 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Wei Zhou > > VM I/O Throttling, to set the maximum disk I/O rate of VMs. > Virtual machines are running on the same storage device (local storage or > share strage). Because of the rate limitation of device (such as iops), if > one VM has large disk operation, it may affect the disk performance of other > VMs running on the same storage device. > It is neccesary to set the maximum rate and limit the disk I/O of VMs. > More details: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+IO+Throttling -- 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-1302) Add per storage setting for cache="none/writeback/writethrough" options for VMs on KVM hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579792#comment-13579792 ] Wido den Hollander commented on CLOUDSTACK-1302: I wouldn't make this KVM specific. The disk offering would indeed be a great place. The hypervisor can do the translation of "none", "writeback" and "writethrough" to it's own settings. I'm also only aware of KVM having this, but that's my lack of knowledge of other hypervisors. > Add per storage setting for cache="none/writeback/writethrough" options for > VMs on KVM hypervisor > - > > Key: CLOUDSTACK-1302 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1302 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04.2 Host, KVM hypervisor >Reporter: Jason Villalta >Priority: Minor > > Version 4.0.0 of Cloudstack has a hard coded value of cache=none for virtual > machines deployed. This causes conflict with filesystems mounted with fuse > such as ZFS, GlusterFs and CEPH as fuse does not support directio with these > file systems. When starting VMs libvirt throws an error "could not open disk > image Invalid argument" > Changing the cache= setting to writethough or writeback solves this problem > but there currently is no way to set this. Ideally this would get set on a > per datastore basis. -- 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-1302) Add per storage setting for cache="none/writeback/writethrough" options for VMs on KVM hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579262#comment-13579262 ] Wido den Hollander commented on CLOUDSTACK-1302: Discussion which was already brought up by this: http://markmail.org/thread/qmrod55gfmhwzot4 > Add per storage setting for cache="none/writeback/writethrough" options for > VMs on KVM hypervisor > - > > Key: CLOUDSTACK-1302 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1302 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04.2 Host, KVM hypervisor >Reporter: Jason Villalta >Priority: Minor > > Version 4.0.0 of Cloudstack has a hard coded value of cache=none for virtual > machines deployed. This causes conflict with filesystems mounted with fuse > such as ZFS, GlusterFs and CEPH as fuse does not support directio with these > file systems. When starting VMs libvirt throws an error "could not open disk > image Invalid argument" > Changing the cache= setting to writethough or writeback solves this problem > but there currently is no way to set this. Ideally this would get set on a > per datastore basis. -- 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-449) Disk I/O polling for instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579257#comment-13579257 ] Wido den Hollander commented on CLOUDSTACK-449: --- No, I haven't gotten around to work on this yet. Patches are welcome! > Disk I/O polling for instances > -- > > Key: CLOUDSTACK-449 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-449 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server, Usage, VMware, Xen >Reporter: Wido den Hollander >Priority: Minor > > Disk I/O polling for instances would gather disk I/O statistics for root and > data volumes attached to instancesn, just like we do with network traffic. > This enables administrators to figure out how much I/O each instance is > doing. In public clouds users might want to start billing for this. > This is not a monitoring solution for the backing storage, it doesn't alarm > about high disk I/O, it simply accounts how much I/O each instance is doing. > The function specification for this is online at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Feature+Disk+IO+statistics+for+instances -- 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-1301) VM I/O Throttling
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579256#comment-13579256 ] Wido den Hollander commented on CLOUDSTACK-1301: I already made this spec: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Disk+IO+statistics+for+instances And the Jira ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-449 We should have polling work first before we start doing the throttling, right? I know that KVM (with libvirt) supports it all. > VM I/O Throttling > - > > Key: CLOUDSTACK-1301 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1301 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Wei Zhou > > VM I/O Throttling, to set the maximum disk I/O rate of VMs. > Virtual machines are running on the same storage device (local storage or > share strage). Because of the rate limitation of device (such as iops), if > one VM has large disk operation, it may affect the disk performance of other > VMs running on the same storage device. > It is neccesary to set the maximum rate and limit the disk I/O of VMs. > More details: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+IO+Throttling -- 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-1212) Sheepdog storage support for KVM
Wido den Hollander created CLOUDSTACK-1212: -- Summary: Sheepdog storage support for KVM Key: CLOUDSTACK-1212 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1212 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Storage Controller Affects Versions: Future Reporter: Wido den Hollander Assignee: Wido den Hollander Fix For: 4.2.0 Sheepdog is a distributed storage system for Qemu/KVM. It supports all cool stuff like snapshotting, cloning and thin provisioning. While this overlaps with RBD it would be nice to see additional storage since it might better suit other peoples needs. Sheepdog has already been integrated into libvirt, so the integration for sheepdog will be kind of similar to the one for RBD. Sheepdog's website: http://www.osrg.net/sheepdog/ -- 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-600) When rebooting KVM local storage VM host, libvirt definitions deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13574314#comment-13574314 ] Wido den Hollander commented on CLOUDSTACK-600: --- I pushed a commit for this yesterday evening, see commit 5dfcd309f10e5bd6a918f7fdff3f44a3dff2374a Verified that it works just fine on my hypervisors. Instances run just fine, but their XML doesn't show up in /etc/libvirt/qemu :) > When rebooting KVM local storage VM host, libvirt definitions deleted > - > > Key: CLOUDSTACK-600 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-600 > 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 >Reporter: Andrew Bayer > > This is definitely the case in 3.0.3, and I don't think the relevant code has > been touched since. > When you reboot a VM host running KVM local storage VMs, the VMs are deleted > from libvirt. I presume this is due to CloudStack thinking it's migrating > them away from the host, but obviously, given that we're on local storage, > it's unable to do that. The result is that the VMs are not able to be > restarted when the host comes back online. -- 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-1193) documentation typo error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-1193. Resolution: Fixed Clearly a stupid typo (of me, I wrote this). I just pushed a fix to the master branch! We want this to be merged into 4.1 as well. We just missed the 4.0.1 freeze though :( > documentation typo error > - > > Key: CLOUDSTACK-1193 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1193 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: akram berkawy >Assignee: Wido den Hollander > Labels: documentation, typo > > there is a typo error in the documentation in section 8.1.5.1 > "8.1.5. Install and Configure libvirt > > tcp_port = 16059 > ..." > the tcp_port should be 16509 as been said later in "8.1.8. Configuring the > firewall" -- 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] [Closed] (CLOUDSTACK-1193) documentation typo error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-1193. -- > documentation typo error > - > > Key: CLOUDSTACK-1193 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1193 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: akram berkawy >Assignee: Wido den Hollander > Labels: documentation, typo > > there is a typo error in the documentation in section 8.1.5.1 > "8.1.5. Install and Configure libvirt > > tcp_port = 16059 > ..." > the tcp_port should be 16509 as been said later in "8.1.8. Configuring the > firewall" -- 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-1193) documentation typo error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-1193: --- Assignee: Wido den Hollander > documentation typo error > - > > Key: CLOUDSTACK-1193 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1193 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: akram berkawy >Assignee: Wido den Hollander > Labels: documentation, typo > > there is a typo error in the documentation in section 8.1.5.1 > "8.1.5. Install and Configure libvirt > > tcp_port = 16059 > ..." > the tcp_port should be 16509 as been said latter in "8.1.8. Configuring the > firewall" -- 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-600) When rebooting KVM local storage VM host, libvirt definitions deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573609#comment-13573609 ] Wido den Hollander commented on CLOUDSTACK-600: --- Checking the upstart script of libvirt-bin under Ubuntu shows it will destroy all running VMs when going down, no mention of suspending them. We (the agent) should probably not use Connect.domainDefineXML for starting a instance, but use Connect.domainCreateXML. The latter wil launch a instance based on the XML, but won't make it persistent. Otherwise we can also use Domain.setAutostart() to make sure it's not starting on boot, although that would look redundant to me and won't fix the root cause. There should be a way to make XML definitions in libvirt not persistent so it gets lost as soon as you reboot the hypervisor. For Java API, see: http://libvirt.org/sources/java/javadoc/ > When rebooting KVM local storage VM host, libvirt definitions deleted > - > > Key: CLOUDSTACK-600 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-600 > 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 >Reporter: Andrew Bayer > > This is definitely the case in 3.0.3, and I don't think the relevant code has > been touched since. > When you reboot a VM host running KVM local storage VMs, the VMs are deleted > from libvirt. I presume this is due to CloudStack thinking it's migrating > them away from the host, but obviously, given that we're on local storage, > it's unable to do that. The result is that the VMs are not able to be > restarted when the host comes back online. -- 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-1192) Add disk I/O polling to statistics accounting of Instances
Wido den Hollander created CLOUDSTACK-1192: -- Summary: Add disk I/O polling to statistics accounting of Instances Key: CLOUDSTACK-1192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1192 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller, Usage Affects Versions: 4.2.0 Reporter: Wido den Hollander Priority: Minor Fix For: 4.2.0 In public clouds (and also private ones) it's important to know how much disk I/O each Instance is consuming. Today disk I/O is more expensive then RAM, CPU and Network bandwith, but CloudStack has no way of accounting this. CloudStack should collect the disk I/O statistics of all running instances so we can present these in the UI and in the Usage server The wiki page for this improvement: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Disk+IO+statistics+for+instances -- 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-1191) Implement RBD snapshotting, backups and cloning
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-1191: --- Assignee: Wido den Hollander > Implement RBD snapshotting, backups and cloning > --- > > Key: CLOUDSTACK-1191 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1191 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot, Storage Controller, Volumes >Affects Versions: 4.2.0 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: ceph, kvm, libvirt, rbd > Fix For: 4.2.0 > > > The current RBD implementation lacks these features. > The new storage subsystem will allow us to implement these features as > described on the wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/RBD+improvements+based+on+new+Storage+subsystem -- 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-1191) Implement RBD snapshotting, backups and cloning
Wido den Hollander created CLOUDSTACK-1191: -- Summary: Implement RBD snapshotting, backups and cloning Key: CLOUDSTACK-1191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1191 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Snapshot, Storage Controller, Volumes Affects Versions: 4.2.0 Reporter: Wido den Hollander Fix For: 4.2.0 The current RBD implementation lacks these features. The new storage subsystem will allow us to implement these features as described on the wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/RBD+improvements+based+on+new+Storage+subsystem -- 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-1179) API searches for names should not be fuzzy / wildcards
Wido den Hollander created CLOUDSTACK-1179:
--
Summary: API searches for names should not be fuzzy / wildcards
Key: CLOUDSTACK-1179
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1179
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.0.0, 4.0.1, 4.1.0
Reporter: Wido den Hollander
Fix For: 4.2.0
During some API work I found that when you query for a 'name' with
ListDomains, ListAccounts and/or ListVolumes this search is fuzzy (with
a wildcard).
For example when listing domains:
if (domainName != null) {
sc.setParameters("name", "%" + domainName + "%");
}
Or when listing volumes:
if (name != null) {
sc.setParameters("name", "%" + name + "%");
}
This search is always a wildcard.
So if you want to know if domain 'customerX' exists you query for that,
but your results can also contain 'customerXY' and 'customerXX'.
command=listDomains&name=customerX
I'm taking the listing of domains again and you can also use the
'keyword' parameter like:
command=listDomains&name=customerX&keyword=customerX
On the mailinglist it seems that we agree that these queries should not be
fuzzy but should be exact matches.
--
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-1150) Documentation for libvirt on Ubuntu 12.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-1150. Resolution: Fixed This has been fixed by commit a996e43bbd259867d2a7a69231978d9ba8d12e13 I didn't see your review in time, but it also documented it in a different way. This should match the Ubuntu 12.04 behaviour now. > Documentation for libvirt on Ubuntu 12.04 > - > > Key: CLOUDSTACK-1150 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1150 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: Logan McNaughton >Priority: Minor > Labels: docuentation > Fix For: 4.0.2 > > > In docs/en-US/hypervisor-host-install-libvirt.xml, we are told to modify: > "exec /usr/sbin/libvirtd -d" > However that line looks like this in 12.04: > "exec /usr/sbin/libvirtd $libvirtd_opts" > Therefore the documentation should be updated to direct the user to modify: > env libvirtd_opts="-d" -- 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-1158) Wrap qemu-img instead of using simpleBashScript
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13572461#comment-13572461
]
Wido den Hollander commented on CLOUDSTACK-1158:
I started working on this in the "qemu-img" branch.
> Wrap qemu-img instead of using simpleBashScript
> ---
>
> Key: CLOUDSTACK-1158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1158
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.0.0
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.2.0
>
>
> Currently when we are doing something with qemu-img in the KVM Agent we do
> things like this:
> ..
> String result = executeBashScript("qemu-img --help|grep convert");
> ..
> Script.runSimpleBashScript("qemu-img convert"
> ..
> This is not reliable and could be fixed by wrapping qemu-img like this:
> QemuImg.convert(String sourceFormat, String source, String destFormat, string
> dest);
> This could then handle all the stuff like checking the output and more
> importantly also checking the exit status of Qemu to see if everything works.
> It could throw exceptions where needed so it makes life easier when doing
> such operations in the KVM Agent.
> Hopefully we can then also get rid of all kinds of bash scripts being called
> by the KVM Agent.
--
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-1158) Wrap qemu-img instead of using simpleBashScript
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander updated CLOUDSTACK-1158:
---
Assignee: Wido den Hollander
> Wrap qemu-img instead of using simpleBashScript
> ---
>
> Key: CLOUDSTACK-1158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1158
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.0.0
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.2.0
>
>
> Currently when we are doing something with qemu-img in the KVM Agent we do
> things like this:
> ..
> String result = executeBashScript("qemu-img --help|grep convert");
> ..
> Script.runSimpleBashScript("qemu-img convert"
> ..
> This is not reliable and could be fixed by wrapping qemu-img like this:
> QemuImg.convert(String sourceFormat, String source, String destFormat, string
> dest);
> This could then handle all the stuff like checking the output and more
> importantly also checking the exit status of Qemu to see if everything works.
> It could throw exceptions where needed so it makes life easier when doing
> such operations in the KVM Agent.
> Hopefully we can then also get rid of all kinds of bash scripts being called
> by the KVM Agent.
--
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-1164) Use libvirt for security groups for KVM
Wido den Hollander created CLOUDSTACK-1164: -- Summary: Use libvirt for security groups for KVM Key: CLOUDSTACK-1164 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1164 Project: CloudStack Issue Type: Wish Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM Affects Versions: 4.0.0, 4.1.0 Reporter: Wido den Hollander Fix For: Future The current implementation for the security groups uses a custom Python script which applies iptable and ebtable rules to the hypervisor. Libvirt also supports this with network filters: http://libvirt.org/formatnwfilter.html It might be cleaner to do this via libvirt, but the downside is that a lot of functions are only supported by libvirt 0.9.8 and higher. This might not be possible at this moment, but it might be worth a shot at a later stadium. -- 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-1147) cloud-setup-* should be removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571679#comment-13571679 ] Wido den Hollander commented on CLOUDSTACK-1147: The current shape the scripts are in is horrible, they have all kinds of dead code in them and a bunch of Python dependencies. It could easily be rewritten in BASH to make it all easier. True, but that should be the goal. These scripts should not be mandatory, since a lot of admins will use Puppet or Chef to provision their systems (mainly hypervisors). Wido > cloud-setup-* should be removed > --- > > Key: CLOUDSTACK-1147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1147 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.0 >Reporter: Wido den Hollander > Fix For: 4.2.0 > > > The tools like cloud-setup-databases, cloud-setup-management and > cloud-setup-agent seem to come from the vmops/cloud.com time where CloudStack > used to be a black box appliance. > Now more and more people start using CloudStack I'm seeing all kinds of > criticism on these tools: > - They change files without telling the admin > - They punch wholes through firewalls > Those are two things which make sysadmins cry, especially if they want to > manage their systems with Puppet or Chef. > The steps for setting up an Agent are actually not that big and most of them > are actually already documented. > When a host is added through the GUI we shouldn't run cloud-setup-agent, but > we should just check if the host is ready to be added and bail out if not. > (And tell why) > The same goes for the management server and databases. > The databases is just a matter of importing the correct SQL files into the > databases and populating db.properties with the correct credentials. > Setting up the management server is also just a matter of creating the > correct configuration files, firewalling ports and setting sudo permissions. > We should tell system administrators what it is that he/she has to configure, > not just do things without telling. > Documentation is key here I think. -- 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-410) vnc_listen not configured in qemu.conf for Ubuntu KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-410: -- Fix Version/s: (was: 4.1.0) 4.2.0 > vnc_listen not configured in qemu.conf for Ubuntu KVM host > -- > > Key: CLOUDSTACK-410 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-410 > 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 >Reporter: Kirk Kosinski >Assignee: Wido den Hollander > Labels: ubuntu > Fix For: 4.2.0 > > Attachments: v-7-VM.xml > > > The vnc_listen configuration in /etc/libvirt/qemu.conf is left at the default > (commented out) for Ubuntu KVM hosts. The VNC console for VMs will listen on > the default of 127.0.0.1:59XX and will not be accessible to the Console Proxy > VM. I noticed this when using the CloudStack-non-OSS-4.0.0-24 build. > To reproduce: > 1. Install Ubuntu 12.04.1 Server, install updates. > 2. Install CloudStack agent on host (run install.sh with "A" option). > 3. Add the host to CloudStack. > 4. Launch a VM on the Ubuntu host and try to access the console. The error > will be: > Unable to start console session as connection is refused by the machine you > are accessing > 5. Check "netstat -plnt" on the KVM host to see the VNC session on > 127.0.0.1:59XX. -- 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-410) vnc_listen not configured in qemu.conf for Ubuntu KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571607#comment-13571607 ] Wido den Hollander commented on CLOUDSTACK-410: --- This is being worked on in the "kvm-vnc-listen" branch, but we have to wait for the new libvirt-java 0.5.0 bindings to come out before it can be merged in. > vnc_listen not configured in qemu.conf for Ubuntu KVM host > -- > > Key: CLOUDSTACK-410 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-410 > 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 >Reporter: Kirk Kosinski >Assignee: Wido den Hollander > Labels: ubuntu > Fix For: 4.1.0 > > Attachments: v-7-VM.xml > > > The vnc_listen configuration in /etc/libvirt/qemu.conf is left at the default > (commented out) for Ubuntu KVM hosts. The VNC console for VMs will listen on > the default of 127.0.0.1:59XX and will not be accessible to the Console Proxy > VM. I noticed this when using the CloudStack-non-OSS-4.0.0-24 build. > To reproduce: > 1. Install Ubuntu 12.04.1 Server, install updates. > 2. Install CloudStack agent on host (run install.sh with "A" option). > 3. Add the host to CloudStack. > 4. Launch a VM on the Ubuntu host and try to access the console. The error > will be: > Unable to start console session as connection is refused by the machine you > are accessing > 5. Check "netstat -plnt" on the KVM host to see the VNC session on > 127.0.0.1:59XX. -- 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] [Closed] (CLOUDSTACK-149) Configure Maven to build deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-149. - Resolution: Fixed Closing this one since we are working on packaging for 4.1 and that will not be done by maven. > Configure Maven to build deb packages > - > > Key: CLOUDSTACK-149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-149 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Reporter: Rohit Yadav >Assignee: Wido den Hollander >Priority: Blocker > Fix For: 4.1.0 > > > Configure a maven plugin to package debian packages. Deprecate waf as a > packaging tool. > Release Planning: > Dev list discussion: http://markmail.org/message/4yp5olwhept3wtd6 > Functional Spec: unknown > Feature Branch: unknown > Docs task is CLOUDSTACK-1 > QA will occur based on testing the whole release. -- 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-765) Ubuntu/Debian packaging is broken in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13571597#comment-13571597 ] Wido den Hollander commented on CLOUDSTACK-765: --- We are on our way with this. The current packaging branch on the Github mirror should produce DEB packages again. They haven't been tested though. > Ubuntu/Debian packaging is broken in master > --- > > Key: CLOUDSTACK-765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-765 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.1.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: debian, packaging, ubuntu > Fix For: 4.1.0 > > > Currently the DEB packaging for Debian and Ubuntu is broken. > I already started work on this in the "packaging" branch, but this has to be > completed for the release of 4.1 > The packaging structure will change a bit, so it's important that testing for > upgrades is done to see if it all still works. > Hugo Trippaers already started work on the RPM packaging and the DEB > packaging can use large pieces of that, like the management server packaging. > The goal is that the packages work on Ubuntu 12.04 at least, but newer Ubuntu > versions like 13.04 are preferrable just like Debian 7. -- 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-1158) Wrap qemu-img instead of using simpleBashScript
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander updated CLOUDSTACK-1158:
---
Summary: Wrap qemu-img instead of using simpleBashScript (was: Wrap
qemu-img in objects instead of using simpleBashScript)
> Wrap qemu-img instead of using simpleBashScript
> ---
>
> Key: CLOUDSTACK-1158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1158
> Project: CloudStack
> Issue Type: Improvement
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.0.0
>Reporter: Wido den Hollander
> Fix For: 4.2.0
>
>
> Currently when we are doing something with qemu-img in the KVM Agent we do
> things like this:
> ..
> String result = executeBashScript("qemu-img --help|grep convert");
> ..
> Script.runSimpleBashScript("qemu-img convert"
> ..
> This is not reliable and could be fixed by wrapping qemu-img like this:
> QemuImg.convert(String sourceFormat, String source, String destFormat, string
> dest);
> This could then handle all the stuff like checking the output and more
> importantly also checking the exit status of Qemu to see if everything works.
> It could throw exceptions where needed so it makes life easier when doing
> such operations in the KVM Agent.
> Hopefully we can then also get rid of all kinds of bash scripts being called
> by the KVM Agent.
--
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-1158) Wrap qemu-img in objects instead of using simpleBashScript
Wido den Hollander created CLOUDSTACK-1158:
--
Summary: Wrap qemu-img in objects instead of using simpleBashScript
Key: CLOUDSTACK-1158
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1158
Project: CloudStack
Issue Type: Improvement
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.0.0
Reporter: Wido den Hollander
Fix For: 4.2.0
Currently when we are doing something with qemu-img in the KVM Agent we do
things like this:
..
String result = executeBashScript("qemu-img --help|grep convert");
..
Script.runSimpleBashScript("qemu-img convert"
..
This is not reliable and could be fixed by wrapping qemu-img like this:
QemuImg.convert(String sourceFormat, String source, String destFormat, string
dest);
This could then handle all the stuff like checking the output and more
importantly also checking the exit status of Qemu to see if everything works.
It could throw exceptions where needed so it makes life easier when doing such
operations in the KVM Agent.
Hopefully we can then also get rid of all kinds of bash scripts being called by
the KVM Agent.
--
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-1147) cloud-setup-* should be removed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570391#comment-13570391 ] Wido den Hollander commented on CLOUDSTACK-1147: The current state of these tools is horrible. So if we intend to keep them, they have to be rewritten anyways. > cloud-setup-* should be removed > --- > > Key: CLOUDSTACK-1147 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1147 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.0.0 >Reporter: Wido den Hollander > Fix For: 4.2.0 > > > The tools like cloud-setup-databases, cloud-setup-management and > cloud-setup-agent seem to come from the vmops/cloud.com time where CloudStack > used to be a black box appliance. > Now more and more people start using CloudStack I'm seeing all kinds of > criticism on these tools: > - They change files without telling the admin > - They punch wholes through firewalls > Those are two things which make sysadmins cry, especially if they want to > manage their systems with Puppet or Chef. > The steps for setting up an Agent are actually not that big and most of them > are actually already documented. > When a host is added through the GUI we shouldn't run cloud-setup-agent, but > we should just check if the host is ready to be added and bail out if not. > (And tell why) > The same goes for the management server and databases. > The databases is just a matter of importing the correct SQL files into the > databases and populating db.properties with the correct credentials. > Setting up the management server is also just a matter of creating the > correct configuration files, firewalling ports and setting sudo permissions. > We should tell system administrators what it is that he/she has to configure, > not just do things without telling. > Documentation is key here I think. -- 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-1147) cloud-setup-* should be removed
Wido den Hollander created CLOUDSTACK-1147: -- Summary: cloud-setup-* should be removed Key: CLOUDSTACK-1147 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1147 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.0.0 Reporter: Wido den Hollander Fix For: 4.2.0 The tools like cloud-setup-databases, cloud-setup-management and cloud-setup-agent seem to come from the vmops/cloud.com time where CloudStack used to be a black box appliance. Now more and more people start using CloudStack I'm seeing all kinds of criticism on these tools: - They change files without telling the admin - They punch wholes through firewalls Those are two things which make sysadmins cry, especially if they want to manage their systems with Puppet or Chef. The steps for setting up an Agent are actually not that big and most of them are actually already documented. When a host is added through the GUI we shouldn't run cloud-setup-agent, but we should just check if the host is ready to be added and bail out if not. (And tell why) The same goes for the management server and databases. The databases is just a matter of importing the correct SQL files into the databases and populating db.properties with the correct credentials. Setting up the management server is also just a matter of creating the correct configuration files, firewalling ports and setting sudo permissions. We should tell system administrators what it is that he/she has to configure, not just do things without telling. Documentation is key here I think. -- 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-1146) auto update of KVM agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570167#comment-13570167 ] Wido den Hollander commented on CLOUDSTACK-1146: I totally disagree on this one. Let CloudStack do what it does best and don't try to re-invent the wheel here. With proper RPM and DEB packaging tools like Puppet and Chef are easily up to the task by just having Apt or Yum update the Agent. As soon as a new CloudStack version comes out, new packages are pushed to the RPM/DEB repo (or admins can maintain their own) and can let Apt and Yum do the rest. > auto update of KVM agent > > > Key: CLOUDSTACK-1146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1146 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 >Reporter: Kevin Kluge > > I'd like to see a feature to have the KVM agent automatically updated. > Managing hundreds or thousands of hosts becomes unwieldy in the current > design. Chef/Puppet can help but I think it'd be helpful to manage the > update through CloudStack. > From an earlier mail on this topic: > > > > - In connection to management server, the version of the software is > > exchanged. > > - Management server decides that it needs to be downloaded and terminates > > the connection with a response that contains the url to the new package. > > - The agent downloads the package using wget and quits. > > - The script that restarts the agent explodes the package and restarts the > > agent. > > - The agent connects again with the matched version. > I'd want this to have some way for the admin to control the update. The use > case is to slowly roll out the change across the hosts, or roll it out to > just a few clusters/pods first, verify functionality, then roll it out to all > hosts. Maybe unmanage hosts/clusters is sufficient for this. > We also need to think through host OS upgrade. Suppose a version of > CloudStack no longer supports RHEL 6.x for example. Now the admin needs to > update RHEL then CloudStack. So it would be nice if the MS could recognize > that the RHEL version has changed, then download the "new " version of the > agent (it's actually the same version of CloudStack agent, but built for RHEL > 7.x for example), then the admin upgrades CS Management Server, then the new > version of CS agent for RHEL 7.x is downloaded. -- 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-1054) ListDomains does not list all domains when the name is specified
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander resolved CLOUDSTACK-1054.
Resolution: Fixed
Resolved by commit 301c4413bc4532d885ee739f8890da11ce3bfebc
> ListDomains does not list all domains when the name is specified
>
>
> Key: CLOUDSTACK-1054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0, 4.0.1, 4.1.0
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>Priority: Minor
> Fix For: Future
>
>
> The documentation for listDomains says that you can list all domains by
> specifying the 'name'.
> id: List domain by domain ID.
> name: List domain by domain name.
> When doing this however you don't get the expected result.
> I turned on MySQL debugging and it showed me this query:
> SELECT domain.id, domain.parent, domain.name, domain.owner, domain.path,
> domain.level, domain.removed, domain.child_count, domain.next_child_seq,
> domain.state, domain.network_domain, domain.uuid FROM domain WHERE domain.id
> = 1 AND domain.name LIKE _binary'%pcextreme%' AND domain.state = 'Active'
> AND domain.removed IS NULL ORDER BY domain.id ASC LIMIT 0, 500
> What I noticed is 'domain.id = 1'.
> I haven't specified an ID and still it is set?
> Going into the code (DomainManagerImpl) I found:
> Long domainId = cmd.getId();
> boolean listAll = cmd.listAll();
> boolean isRecursive = false;
> if (domainId != null) {
> Domain domain = getDomain(domainId);
> if (domain == null) {
> throw new InvalidParameterValueException("Domain id=" +
> domainId + " doesn't exist");
> }
> _accountMgr.checkAccess(caller, domain);
> } else {
> domainId = caller.getDomainId();
> if (listAll) {
> isRecursive = true;
> }
> }
> So if domainId is not specified it is automatically set to the ID of the
> domain I'm in? Since I'm admin my ID is set to 1.
> This is odd behaviour since I want the domain specified by the name, not by
> my ID.
> I understand that this is a security flaw if every user can query for every
> domain, but it is kind of weird.
> The description for the 'name' argument isn't clear either.
> The code does: name LIKE '%%' so it is actually a wildcard search which
> the documentation does not say.
> I'm thinking about checking if the user is an admin and if that is the case
> not setting the domainId to the domain where the user is in.
--
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-1054) ListDomains does not list all domains when the name is specified
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander updated CLOUDSTACK-1054:
---
Assignee: Wido den Hollander
> ListDomains does not list all domains when the name is specified
>
>
> Key: CLOUDSTACK-1054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0, 4.0.1, 4.1.0
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>Priority: Minor
> Fix For: Future
>
>
> The documentation for listDomains says that you can list all domains by
> specifying the 'name'.
> id: List domain by domain ID.
> name: List domain by domain name.
> When doing this however you don't get the expected result.
> I turned on MySQL debugging and it showed me this query:
> SELECT domain.id, domain.parent, domain.name, domain.owner, domain.path,
> domain.level, domain.removed, domain.child_count, domain.next_child_seq,
> domain.state, domain.network_domain, domain.uuid FROM domain WHERE domain.id
> = 1 AND domain.name LIKE _binary'%pcextreme%' AND domain.state = 'Active'
> AND domain.removed IS NULL ORDER BY domain.id ASC LIMIT 0, 500
> What I noticed is 'domain.id = 1'.
> I haven't specified an ID and still it is set?
> Going into the code (DomainManagerImpl) I found:
> Long domainId = cmd.getId();
> boolean listAll = cmd.listAll();
> boolean isRecursive = false;
> if (domainId != null) {
> Domain domain = getDomain(domainId);
> if (domain == null) {
> throw new InvalidParameterValueException("Domain id=" +
> domainId + " doesn't exist");
> }
> _accountMgr.checkAccess(caller, domain);
> } else {
> domainId = caller.getDomainId();
> if (listAll) {
> isRecursive = true;
> }
> }
> So if domainId is not specified it is automatically set to the ID of the
> domain I'm in? Since I'm admin my ID is set to 1.
> This is odd behaviour since I want the domain specified by the name, not by
> my ID.
> I understand that this is a security flaw if every user can query for every
> domain, but it is kind of weird.
> The description for the 'name' argument isn't clear either.
> The code does: name LIKE '%%' so it is actually a wildcard search which
> the documentation does not say.
> I'm thinking about checking if the user is an admin and if that is the case
> not setting the domainId to the domain where the user is in.
--
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-1054) ListDomains does not list all domains when the name is specified
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13562703#comment-13562703
]
Wido den Hollander commented on CLOUDSTACK-1054:
Since I'm not 100% positive about this change I've posted it to reviewboard:
https://reviews.apache.org/r/9111/
If I was certain I would have committed it :)
> ListDomains does not list all domains when the name is specified
>
>
> Key: CLOUDSTACK-1054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0, 4.0.1, 4.1.0
>Reporter: Wido den Hollander
>Priority: Minor
> Fix For: Future
>
>
> The documentation for listDomains says that you can list all domains by
> specifying the 'name'.
> id: List domain by domain ID.
> name: List domain by domain name.
> When doing this however you don't get the expected result.
> I turned on MySQL debugging and it showed me this query:
> SELECT domain.id, domain.parent, domain.name, domain.owner, domain.path,
> domain.level, domain.removed, domain.child_count, domain.next_child_seq,
> domain.state, domain.network_domain, domain.uuid FROM domain WHERE domain.id
> = 1 AND domain.name LIKE _binary'%pcextreme%' AND domain.state = 'Active'
> AND domain.removed IS NULL ORDER BY domain.id ASC LIMIT 0, 500
> What I noticed is 'domain.id = 1'.
> I haven't specified an ID and still it is set?
> Going into the code (DomainManagerImpl) I found:
> Long domainId = cmd.getId();
> boolean listAll = cmd.listAll();
> boolean isRecursive = false;
> if (domainId != null) {
> Domain domain = getDomain(domainId);
> if (domain == null) {
> throw new InvalidParameterValueException("Domain id=" +
> domainId + " doesn't exist");
> }
> _accountMgr.checkAccess(caller, domain);
> } else {
> domainId = caller.getDomainId();
> if (listAll) {
> isRecursive = true;
> }
> }
> So if domainId is not specified it is automatically set to the ID of the
> domain I'm in? Since I'm admin my ID is set to 1.
> This is odd behaviour since I want the domain specified by the name, not by
> my ID.
> I understand that this is a security flaw if every user can query for every
> domain, but it is kind of weird.
> The description for the 'name' argument isn't clear either.
> The code does: name LIKE '%%' so it is actually a wildcard search which
> the documentation does not say.
> I'm thinking about checking if the user is an admin and if that is the case
> not setting the domainId to the domain where the user is in.
--
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-1054) ListDomains does not list all domains when the name is specified
Wido den Hollander created CLOUDSTACK-1054:
--
Summary: ListDomains does not list all domains when the name is
specified
Key: CLOUDSTACK-1054
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1054
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.0.0, 4.0.1, 4.1.0
Reporter: Wido den Hollander
Priority: Minor
Fix For: Future
The documentation for listDomains says that you can list all domains by
specifying the 'name'.
id: List domain by domain ID.
name: List domain by domain name.
When doing this however you don't get the expected result.
I turned on MySQL debugging and it showed me this query:
SELECT domain.id, domain.parent, domain.name, domain.owner, domain.path,
domain.level, domain.removed, domain.child_count, domain.next_child_seq,
domain.state, domain.network_domain, domain.uuid FROM domain WHERE domain.id =
1 AND domain.name LIKE _binary'%pcextreme%' AND domain.state = 'Active' AND
domain.removed IS NULL ORDER BY domain.id ASC LIMIT 0, 500
What I noticed is 'domain.id = 1'.
I haven't specified an ID and still it is set?
Going into the code (DomainManagerImpl) I found:
Long domainId = cmd.getId();
boolean listAll = cmd.listAll();
boolean isRecursive = false;
if (domainId != null) {
Domain domain = getDomain(domainId);
if (domain == null) {
throw new InvalidParameterValueException("Domain id=" +
domainId + " doesn't exist");
}
_accountMgr.checkAccess(caller, domain);
} else {
domainId = caller.getDomainId();
if (listAll) {
isRecursive = true;
}
}
So if domainId is not specified it is automatically set to the ID of the domain
I'm in? Since I'm admin my ID is set to 1.
This is odd behaviour since I want the domain specified by the name, not by my
ID.
I understand that this is a security flaw if every user can query for every
domain, but it is kind of weird.
The description for the 'name' argument isn't clear either.
The code does: name LIKE '%%' so it is actually a wildcard search which
the documentation does not say.
I'm thinking about checking if the user is an admin and if that is the case not
setting the domainId to the domain where the user is in.
--
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-1049) cloud-sccs does not return the commit id of the build being used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561530#comment-13561530 ] Wido den Hollander commented on CLOUDSTACK-1049: The generation of sccs-info was done by WAF but has been broken horribly for some time now. I don't know if we still want to use this? > cloud-sccs does not return the commit id of the build being used > > > Key: CLOUDSTACK-1049 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1049 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: CloudStack-non-OSS-49-rhel6.3.tar.gz >Reporter: Sanjeev N > > cloud-sccs does not return the commit id of the build being used. It says > error: SCCS info file '/usr/share/doc/cloud-4.1.0/sccs-info' cannot be found. > 1.Bring up CS with latest build. > 2.Execute the command cloud-sccs > It will give an error: SCCS info file '/usr/share/doc/cloud-4.1.0/sccs-info' > cannot be found. > Only version-info file is available at /usr/share/doc/cloud-4.1.0/ -- 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-684) Support VM Snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13561524#comment-13561524 ] Wido den Hollander commented on CLOUDSTACK-684: --- My patches for libvirt are accepted, so the next release of libvirt-java should contain the required functions for KVM. > Support VM Snapshot > --- > > Key: CLOUDSTACK-684 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-684 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Mice Xia >Assignee: Mice Xia > Fix For: 4.1.0 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots -- 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-974) listServiceOfferings doesn't sort by sortKey for non-root users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552795#comment-13552795 ] Wido den Hollander commented on CLOUDSTACK-974: --- It doesn't seem to be related to the startIndex and getPageSizeVal, but it seems to be something with being root user or a non-root user. > listServiceOfferings doesn't sort by sortKey for non-root users > --- > > Key: CLOUDSTACK-974 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-974 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.0, 4.0.1 >Reporter: Wido den Hollander >Priority: Minor > Fix For: 4.0.1 > > > I was just notified by a colleague that there is different behaviour between > the Admin UI and User UI. > When you list all Service Offerings in the Admin interface they get sorted by > sortKey descending. > If you go and create an Instance as a user through the wizard the Service > Offerings aren't sorted, they are in the order like they are in the database. > I logged the MySQL queries and they are: > ** ADMIN ** > SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, > disk_offering.name, disk_offering.display_text, disk_offering.disk_size, > disk_offering.tags, disk_offering.type, disk_offering.removed, > disk_offering.created, disk_offering.recreatable, > disk_offering.use_local_storage, disk_offering.system_use, > disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, > service_offering.cpu, service_offering.speed, service_offering.ram_size, > service_offering.nw_rate, service_offering.mc_rate, > service_offering.ha_enabled, service_offering.limit_cpu_use, > service_offering.host_tag, service_offering.default_use, > service_offering.vm_type, service_offering.sort_key > FROM service_offering INNER JOIN disk_offering ON > service_offering.id=disk_offering.id > WHERE disk_offering.type='Service' > AND disk_offering.system_use = 0 > AND disk_offering.system_use = 0 > AND disk_offering.removed IS NULL > ORDER BY service_offering.sort_key DESC > ** USER ** > SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, > disk_offering.name, disk_offering.display_text, disk_offering.disk_size, > disk_offering.tags, disk_offering.type, disk_offering.removed, > disk_offering.created, disk_offering.recreatable, > disk_offering.use_local_storage, disk_offering.system_use, > disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, > service_offering.cpu, service_offering.speed, service_offering.ram_size, > service_offering.nw_rate, service_offering.mc_rate, > service_offering.ha_enabled, service_offering.limit_cpu_use, > service_offering.host_tag, service_offering.default_use, > service_offering.vm_type, service_offering.sort_key > FROM service_offering INNER JOIN disk_offering ON > service_offering.id=disk_offering.id > WHERE disk_offering.type='Service' > AND disk_offering.domain_id IS NULL > AND disk_offering.system_use = 0 > AND disk_offering.removed IS NULL > To me it seems this goes wrong in > ManagementServerImpl.searchForServiceOfferings: > Filter searchFilter = new Filter(ServiceOfferingVO.class, "sortKey", > isAscending, cmd.getStartIndex(), cmd.getPageSizeVal()); > getStartIndex and getPageSizeVal are both NULL since the user UI doesn't add > page nor pagesize to the API request. -- 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-974) listServiceOfferings doesn't sort by sortKey for non-root users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-974: -- Summary: listServiceOfferings doesn't sort by sortKey for non-root users (was: listServiceOfferings doesn't sort by sortKey if page and/or pagesize isn't set) > listServiceOfferings doesn't sort by sortKey for non-root users > --- > > Key: CLOUDSTACK-974 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-974 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.0, 4.0.1 >Reporter: Wido den Hollander >Priority: Minor > Fix For: 4.0.1 > > > I was just notified by a colleague that there is different behaviour between > the Admin UI and User UI. > When you list all Service Offerings in the Admin interface they get sorted by > sortKey descending. > If you go and create an Instance as a user through the wizard the Service > Offerings aren't sorted, they are in the order like they are in the database. > I logged the MySQL queries and they are: > ** ADMIN ** > SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, > disk_offering.name, disk_offering.display_text, disk_offering.disk_size, > disk_offering.tags, disk_offering.type, disk_offering.removed, > disk_offering.created, disk_offering.recreatable, > disk_offering.use_local_storage, disk_offering.system_use, > disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, > service_offering.cpu, service_offering.speed, service_offering.ram_size, > service_offering.nw_rate, service_offering.mc_rate, > service_offering.ha_enabled, service_offering.limit_cpu_use, > service_offering.host_tag, service_offering.default_use, > service_offering.vm_type, service_offering.sort_key > FROM service_offering INNER JOIN disk_offering ON > service_offering.id=disk_offering.id > WHERE disk_offering.type='Service' > AND disk_offering.system_use = 0 > AND disk_offering.system_use = 0 > AND disk_offering.removed IS NULL > ORDER BY service_offering.sort_key DESC > ** USER ** > SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, > disk_offering.name, disk_offering.display_text, disk_offering.disk_size, > disk_offering.tags, disk_offering.type, disk_offering.removed, > disk_offering.created, disk_offering.recreatable, > disk_offering.use_local_storage, disk_offering.system_use, > disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, > service_offering.cpu, service_offering.speed, service_offering.ram_size, > service_offering.nw_rate, service_offering.mc_rate, > service_offering.ha_enabled, service_offering.limit_cpu_use, > service_offering.host_tag, service_offering.default_use, > service_offering.vm_type, service_offering.sort_key > FROM service_offering INNER JOIN disk_offering ON > service_offering.id=disk_offering.id > WHERE disk_offering.type='Service' > AND disk_offering.domain_id IS NULL > AND disk_offering.system_use = 0 > AND disk_offering.removed IS NULL > To me it seems this goes wrong in > ManagementServerImpl.searchForServiceOfferings: > Filter searchFilter = new Filter(ServiceOfferingVO.class, "sortKey", > isAscending, cmd.getStartIndex(), cmd.getPageSizeVal()); > getStartIndex and getPageSizeVal are both NULL since the user UI doesn't add > page nor pagesize to the API request. -- 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-974) listServiceOfferings doesn't sort by sortKey if page and/or pagesize isn't set
Wido den Hollander created CLOUDSTACK-974: - Summary: listServiceOfferings doesn't sort by sortKey if page and/or pagesize isn't set Key: CLOUDSTACK-974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-974 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.0.0, 4.0.1 Reporter: Wido den Hollander Priority: Minor Fix For: 4.0.1 I was just notified by a colleague that there is different behaviour between the Admin UI and User UI. When you list all Service Offerings in the Admin interface they get sorted by sortKey descending. If you go and create an Instance as a user through the wizard the Service Offerings aren't sorted, they are in the order like they are in the database. I logged the MySQL queries and they are: ** ADMIN ** SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, disk_offering.name, disk_offering.display_text, disk_offering.disk_size, disk_offering.tags, disk_offering.type, disk_offering.removed, disk_offering.created, disk_offering.recreatable, disk_offering.use_local_storage, disk_offering.system_use, disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, service_offering.cpu, service_offering.speed, service_offering.ram_size, service_offering.nw_rate, service_offering.mc_rate, service_offering.ha_enabled, service_offering.limit_cpu_use, service_offering.host_tag, service_offering.default_use, service_offering.vm_type, service_offering.sort_key FROM service_offering INNER JOIN disk_offering ON service_offering.id=disk_offering.id WHERE disk_offering.type='Service' AND disk_offering.system_use = 0 AND disk_offering.system_use = 0 AND disk_offering.removed IS NULL ORDER BY service_offering.sort_key DESC ** USER ** SELECT disk_offering.id, disk_offering.domain_id, disk_offering.unique_name, disk_offering.name, disk_offering.display_text, disk_offering.disk_size, disk_offering.tags, disk_offering.type, disk_offering.removed, disk_offering.created, disk_offering.recreatable, disk_offering.use_local_storage, disk_offering.system_use, disk_offering.customized, disk_offering.uuid, disk_offering.sort_key, service_offering.cpu, service_offering.speed, service_offering.ram_size, service_offering.nw_rate, service_offering.mc_rate, service_offering.ha_enabled, service_offering.limit_cpu_use, service_offering.host_tag, service_offering.default_use, service_offering.vm_type, service_offering.sort_key FROM service_offering INNER JOIN disk_offering ON service_offering.id=disk_offering.id WHERE disk_offering.type='Service' AND disk_offering.domain_id IS NULL AND disk_offering.system_use = 0 AND disk_offering.removed IS NULL To me it seems this goes wrong in ManagementServerImpl.searchForServiceOfferings: Filter searchFilter = new Filter(ServiceOfferingVO.class, "sortKey", isAscending, cmd.getStartIndex(), cmd.getPageSizeVal()); getStartIndex and getPageSizeVal are both NULL since the user UI doesn't add page nor pagesize to the API request. -- 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-620) Allow additional JVM opts and classpath injection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13548605#comment-13548605 ] Wido den Hollander commented on CLOUDSTACK-620: --- It seems like a reasonable fix! I'm working on packaging right now which moves the init scripts around a bit. I'll note this to look at it later, applying this patch right now to master could cause some merge issues later. > Allow additional JVM opts and classpath injection > -- > > Key: CLOUDSTACK-620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-620 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0 > Environment: ubuntu >Reporter: Pierre-Yves Ritschard >Priority: Minor > > The rationale is to allow configuration management to push > specific log4j configurations or JMX arguments directly through > `/etc/default/cloud-agent` instead of having to modify the startup script. -- 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-620) Allow additional JVM opts and classpath injection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-620: -- Priority: Minor (was: Major) > Allow additional JVM opts and classpath injection > -- > > Key: CLOUDSTACK-620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-620 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0 > Environment: ubuntu >Reporter: Pierre-Yves Ritschard >Priority: Minor > > The rationale is to allow configuration management to push > specific log4j configurations or JMX arguments directly through > `/etc/default/cloud-agent` instead of having to modify the startup script. -- 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-765) Ubuntu/Debian packaging is broken in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13547828#comment-13547828 ] Wido den Hollander commented on CLOUDSTACK-765: --- This is being worked on at a Github repo: https://github.com/noaresare/incubator-cloudstack/commits/packaging The reason for the Github repo is that Noa Resare does not have committer rights on the ASF infra and we are working on this together. > Ubuntu/Debian packaging is broken in master > --- > > Key: CLOUDSTACK-765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-765 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.1.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: debian, packaging, ubuntu > Fix For: 4.1.0 > > > Currently the DEB packaging for Debian and Ubuntu is broken. > I already started work on this in the "packaging" branch, but this has to be > completed for the release of 4.1 > The packaging structure will change a bit, so it's important that testing for > upgrades is done to see if it all still works. > Hugo Trippaers already started work on the RPM packaging and the DEB > packaging can use large pieces of that, like the management server packaging. > The goal is that the packages work on Ubuntu 12.04 at least, but newer Ubuntu > versions like 13.04 are preferrable just like Debian 7. -- 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-765) Ubuntu/Debian packaging is broken in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546963#comment-13546963 ] Wido den Hollander commented on CLOUDSTACK-765: --- Yes, you are right. I just updated the subject. For other reading this. Noa and I are going to work on the Debian and Ubuntu packaging for 4.1 We won't use WAF any longer and fully depend on Maven for everything. > Ubuntu/Debian packaging is broken in master > --- > > Key: CLOUDSTACK-765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-765 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.1.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: debian, packaging, ubuntu > Fix For: 4.1.0 > > > Currently the DEB packaging for Debian and Ubuntu is broken. > I already started work on this in the "packaging" branch, but this has to be > completed for the release of 4.1 > The packaging structure will change a bit, so it's important that testing for > upgrades is done to see if it all still works. > Hugo Trippaers already started work on the RPM packaging and the DEB > packaging can use large pieces of that, like the management server packaging. > The goal is that the packages work on Ubuntu 12.04 at least, but newer Ubuntu > versions like 13.04 are preferrable just like Debian 7. -- 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-765) Ubuntu/Debian packaging is broken in master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-765: -- Summary: Ubuntu/Debian packaging is broken in master (was: Ubuntu/Debian packaging should not use WAF anymore) > Ubuntu/Debian packaging is broken in master > --- > > Key: CLOUDSTACK-765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-765 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.1.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: debian, packaging, ubuntu > Fix For: 4.1.0 > > > Currently the DEB packaging for Debian and Ubuntu is broken. > I already started work on this in the "packaging" branch, but this has to be > completed for the release of 4.1 > The packaging structure will change a bit, so it's important that testing for > upgrades is done to see if it all still works. > Hugo Trippaers already started work on the RPM packaging and the DEB > packaging can use large pieces of that, like the management server packaging. > The goal is that the packages work on Ubuntu 12.04 at least, but newer Ubuntu > versions like 13.04 are preferrable just like Debian 7. -- 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-658) Scaling up CPU and RAM for running VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13545712#comment-13545712 ] Wido den Hollander commented on CLOUDSTACK-658: --- I'd like to add that KVM with the correct version of libvirt also supports this. "virsh help": setmem change memory allocation setvcpus change number of virtual CPUs It is also supported by libvirt-java: * http://libvirt.org/sources/java/javadoc/org/libvirt/Domain.html#setMemory%28long%29 * http://libvirt.org/sources/java/javadoc/org/libvirt/Domain.html#setVcpus%28int%29 If the correct Commands are added inside the CloudStack management server it won't be hard to add KVM support as well. > Scaling up CPU and RAM for running VMs > -- > > Key: CLOUDSTACK-658 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-658 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Koushik Das >Assignee: Nitin Mehta > Fix For: 4.1.0 > > > Currently CS supports changing CPU and RAM for stopped VM. This is achieved > by changing compute offering of the VM (with new CPU and RAM values) and then > starting it. I am planning to extend the same for running VM as well. > Initially planning to do it for Vmware where CPU and RAM can be dynamically > increased. Support of other HVs can also be added if they support increasing > CPU/RAM. > Assuming that in the updated compute offering only CPU and RAM has changed, > the deployment planner can either select the same host in which case the > values are dynamically scaled up OR a different one in which case the > operation fails. In future if there is support for live migration (provided > HV supports it) then another option in the latter case could be to migrate > the VM first and then scale it 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
[jira] [Created] (CLOUDSTACK-765) Ubuntu/Debian packaging should not use WAF anymore
Wido den Hollander created CLOUDSTACK-765: - Summary: Ubuntu/Debian packaging should not use WAF anymore Key: CLOUDSTACK-765 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-765 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.1.0 Environment: Ubuntu 12.04 Reporter: Wido den Hollander Assignee: Wido den Hollander Fix For: 4.1.0 Currently the DEB packaging for Debian and Ubuntu is broken. I already started work on this in the "packaging" branch, but this has to be completed for the release of 4.1 The packaging structure will change a bit, so it's important that testing for upgrades is done to see if it all still works. Hugo Trippaers already started work on the RPM packaging and the DEB packaging can use large pieces of that, like the management server packaging. The goal is that the packages work on Ubuntu 12.04 at least, but newer Ubuntu versions like 13.04 are preferrable just like Debian 7. -- 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-451) System VMs shouldn't be just Debian based
[ https://issues.apache.org/jira/browse/CLOUDSTACK-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-451: -- Assignee: ilya musayev > System VMs shouldn't be just Debian based > - > > Key: CLOUDSTACK-451 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-451 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wido den Hollander >Assignee: ilya musayev > > This one is tied into: CLOUDSTACK-450 > Currently our System VMs are a Debian based template which are pretty big. > If we abstract the way we talk to the System VM by adding an API it shouldn't > matter anymore which distro or OS will be running in there. > Some users might want to use a different distribution or build their own > homebrew System VM as long as they implement the API. > Most System VM tasks can be done in Read-Only mode as well, the filesystem of > the System VM doesn't need to be R/W, which would make them more robust. > In the end a System VM shouldn't have to be bigger then something like 50MB > when stripped down. > This issue is here to raise awareness that this has to be addressed at some > point. -- 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-448) SSVM bootstrap failure on XenServer hosts with E3 CPU
[ https://issues.apache.org/jira/browse/CLOUDSTACK-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-448. --- Resolution: Fixed Fix Version/s: 4.1.0 I just applied the fix to the master branch. > SSVM bootstrap failure on XenServer hosts with E3 CPU > - > > Key: CLOUDSTACK-448 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-448 > Project: CloudStack > Issue Type: Bug > Components: XenServer >Affects Versions: pre-4.0.0 > Environment: Cloudstack 3.0.2 + XenServer 6.0.2 on E3 CPU >Reporter: Randy McAnally >Priority: Blocker > Fix For: 4.1.0 > > Attachments: management-server.log.txt, screenshot-1.jpg, > ssvm_cloud.log.txt, ssvm_console.txt, ssvm_dmesg.txt, ssvm_vm-param-list.txt > > > Cannot add XenServer 6.0.2 based hosts with E3 CPU. SSVM of any type fail to > boostrap, ending up with incomplete network configuration and Cloudstack > unable to ping it. Adding a host with any other type of previous generation > CPU succeeds and SSVMs start properly (in this case X3450) . > Failing host: > [root@cl-ash-h1 ~]# xe host-cpu-info > cpu_count: 8 >vendor: GenuineIntel > speed: 3300.094 > modelname: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz >family: 6 > model: 58 > stepping: 9 > flags: fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov > pat clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc > aperfmperf pni pclmulqdq vmx est ssse3 sse4_1 sse4_2 x2apic popcnt aes > hypervisor ida arat tpr_shadow vnmi flexpriority ept vpid > features: --- > features_after_reboot: --- > physical_features: --- > maskable: no > Working host: > [root@localhost ~]# xe host-cpu-info > cpu_count: 8 >vendor: GenuineIntel > speed: 2666.760 > modelname: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz >family: 6 > model: 30 > stepping: 5 > flags: fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov > pat clflush acpi mmx fxsr sse sse2 ss ht nx constant_tsc nonstop_tsc > aperfmperf pni vmx est ssse3 sse4_1 sse4_2 popcnt hypervisor ida tpr_shadow > vnmi flexpriority ept vpid > features: 0098e3fd-bfebfbff-0001-28100800 > features_after_reboot: 0098e3fd-bfebfbff-0001-28100800 > physical_features: 0098e3fd-bfebfbff-0001-28100800 > maskable: full -- 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-460) Cloudstack 4.0 Cannot ssh into sysyem vms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493142#comment-13493142 ] Wido den Hollander commented on CLOUDSTACK-460: --- Is the cloud-system-iso package present on the Agent? > Cloudstack 4.0 Cannot ssh into sysyem vms > - > > Key: CLOUDSTACK-460 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-460 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup, KVM >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 >Reporter: jason > Labels: newbie > Fix For: 4.0.0 > > 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] [Commented] (CLOUDSTACK-454) cloud-utils package conflicts with cloud-utils from Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493124#comment-13493124 ] Wido den Hollander commented on CLOUDSTACK-454: --- That is a different discussion then this one. I'm working on some packaging stuff. This issue is just here to remind us that this is a problem. > cloud-utils package conflicts with cloud-utils from Ubuntu > -- > > Key: CLOUDSTACK-454 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-454 > Project: CloudStack > Issue Type: New Feature >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander > > On Ubuntu 12.04 there already is a package called "cloud-utils". > Our cloud-utils package conflicts with this package. -- 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-443) health monitoring for load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493046#comment-13493046 ] Wido den Hollander commented on CLOUDSTACK-443: --- Indeed, the loadbalancing itself is done by TCP, but the loadbalancer does protocol specific health checks. In the specification this should be taken into account, so we can support all the features loadbalancers might offer with health checks. > health monitoring for load balanced instances > - > > Key: CLOUDSTACK-443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-443 > Project: CloudStack > Issue Type: New Feature > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Rajesh Battala > Fix For: 4.1.0 > > > Enhance existing 'load balancer' network service provided by CloudStack, to > support health monitor the load balanced instances. ADC's supported > (NetScaler, Big IP, ADX) by CloudStack have native capabilities to monotor > health of in the instances. Leverage that to load balance the traffic only to > healthy instances. > This feature shall provide capabilities to > - to configure health check policy with load balancer rule > - delete configured 'health check policy' associated with a load balancer > rules > - list/describe instance healths. -- 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-450) Controlling System VMs should not happen through SSH
[ https://issues.apache.org/jira/browse/CLOUDSTACK-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493038#comment-13493038 ] Wido den Hollander commented on CLOUDSTACK-450: --- Yes, I think we should build the API first indeed and do it in steps. This issue is also a "brain dump" about what has to be done. It's clear I think that the System VMs need some work, since the current way we do stuff is not maintainable. The main point for the API is indeed to make it platform agnostic. We still need to figure out a way to inject a shared secret and set the network configuration for the System VM since DHCP is not available for them. > Controlling System VMs should not happen through SSH > > > Key: CLOUDSTACK-450 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-450 > Project: CloudStack > Issue Type: Improvement > Components: Management Server >Reporter: Wido den Hollander > > Currently we SSH into the System VMs to control them. > This is not doable on the longer run, it causes problems already, like > injecting the SSH keys into the System VM ISO which is not reliable. > Inside the System VM there should be an API running which the management > server(s) can talk to to inject DHCP entries, add loadbalancing settings to > HA proxy, have the SSVM download a template/ISO, etc, etc. > This would mean a complete rewrite of the System VMs, but it will make them > more robust over time. > The exact spec for this improvement still has to be written, this issue is > just here to identify the problem. -- 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-452) IPv6 support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493035#comment-13493035 ] Wido den Hollander commented on CLOUDSTACK-452: --- I completely agree with you Marcus, Instances should get IPv6 asap. It will be however also very easy to have the Management server support IPv6 for the API, since that is also needed. In public clouds you also want you API to be available over IPv6 without a proxy. Still, the need is there for having IPv6 in the Instances. > IPv6 support > > > Key: CLOUDSTACK-452 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-452 > Project: CloudStack > Issue Type: New Feature >Reporter: Wido den Hollander > > This is quite a large feature, but we are lacking complete IPv6 support at > this moment. > We should support IPv6 for: > - The Management server itself > - Communication with the Hypervisors > - Communication with the System VMs > Those three are probably the easiest work, we also need to support IPv6 for > instances. > In both the Advanced and Basic zone Instances should be able to get a non-NAT > true and native IPv6 address. > We should also not limit them to having one IP, they should be able to get > multiple IPv6 addresses. > In the basic zone it can be done pretty easily by having the Virtual Router > also hand out IPv6 over DHCPv6 and have your router in the network handle the > gateway work. > In the advanced zone it becomes more difficult. > One way could be that the network admin creates a static route for a /48 > towards a Virtual Router and then the VR can hand out /64s to Instances. > But static routing can become a problem, so you might want to use OSPF, LISP > or even iBGP for getting those prefixes to the VR. > This is a big feature, but I think the Basic zone is the easiest for now. > In the Advanced Zone you COULD keep everything behind the VR IPv4 and have > the VR do IPv6 loadbalancing, but that would still not be true IPv6 > connectivity. > NAT in the VR seems like a firewall, but a true statefull firewall in the VR > could do the same while the Instances still have publicly routeable IPv6 > addresses. > There is no functional spec on this yet, but we have to keep this in mind > that we need IPv6 support. People are running out of IPv4 space. -- 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] [Closed] (CLOUDSTACK-453) KVM plugin used in the management server - is also needed by the KVM agent - we should split those accordingly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander closed CLOUDSTACK-453. - Resolution: Invalid We got this wrong, the KVM plugin is only used by the Agent. It contains LibvirtComputingResource which the AgentShell loads. > KVM plugin used in the management server - is also needed by the KVM agent - > we should split those accordingly > -- > > Key: CLOUDSTACK-453 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-453 > Project: CloudStack > Issue Type: Improvement > Components: KVM >Affects Versions: 4.1.0 >Reporter: David Nalley > Fix For: 4.1.0 > > > KVM plugin used in the management server - is also needed by the KVM agent - > we should split those accordingly -- 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-443) health monitoring for load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493032#comment-13493032 ] Wido den Hollander commented on CLOUDSTACK-443: --- So we will only limit ourselfs to HTTP or TCP checks? Modern loadbalancers can also do IMAP or SMTP health checks, so imho we should support that as well. Just because AWS only supports HTTP or TCP doesn't mean we should do the same. A F5 can do SMTP health checks by doing HELO requests. > health monitoring for load balanced instances > - > > Key: CLOUDSTACK-443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-443 > Project: CloudStack > Issue Type: New Feature > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Rajesh Battala > Fix For: 4.1.0 > > > Enhance existing 'load balancer' network service provided by CloudStack, to > support health monitor the load balanced instances. ADC's supported > (NetScaler, Big IP, ADX) by CloudStack have native capabilities to monotor > health of in the instances. Leverage that to load balance the traffic only to > healthy instances. > This feature shall provide capabilities to > - to configure health check policy with load balancer rule > - delete configured 'health check policy' associated with a load balancer > rules > - list/describe instance healths. -- 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-454) cloud-utils package conflicts with cloud-utils from Ubuntu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493031#comment-13493031 ] Wido den Hollander commented on CLOUDSTACK-454: --- That is what Hugo, David and I discussed at ApacheCon. We feel it's best to indeed rename the packages to cloudstack-* This bug is just here to let everybody know it is a problem right now. > cloud-utils package conflicts with cloud-utils from Ubuntu > -- > > Key: CLOUDSTACK-454 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-454 > Project: CloudStack > Issue Type: New Feature >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 >Reporter: Wido den Hollander > > On Ubuntu 12.04 there already is a package called "cloud-utils". > Our cloud-utils package conflicts with this package. -- 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-454) cloud-utils package conflicts with cloud-utils from Ubuntu
Wido den Hollander created CLOUDSTACK-454: - Summary: cloud-utils package conflicts with cloud-utils from Ubuntu Key: CLOUDSTACK-454 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-454 Project: CloudStack Issue Type: New Feature Affects Versions: 4.0.0 Environment: Ubuntu 12.04 Reporter: Wido den Hollander On Ubuntu 12.04 there already is a package called "cloud-utils". Our cloud-utils package conflicts with this package. -- 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-452) IPv6 support
Wido den Hollander created CLOUDSTACK-452: - Summary: IPv6 support Key: CLOUDSTACK-452 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-452 Project: CloudStack Issue Type: New Feature Reporter: Wido den Hollander This is quite a large feature, but we are lacking complete IPv6 support at this moment. We should support IPv6 for: - The Management server itself - Communication with the Hypervisors - Communication with the System VMs Those three are probably the easiest work, we also need to support IPv6 for instances. In both the Advanced and Basic zone Instances should be able to get a non-NAT true and native IPv6 address. We should also not limit them to having one IP, they should be able to get multiple IPv6 addresses. In the basic zone it can be done pretty easily by having the Virtual Router also hand out IPv6 over DHCPv6 and have your router in the network handle the gateway work. In the advanced zone it becomes more difficult. One way could be that the network admin creates a static route for a /48 towards a Virtual Router and then the VR can hand out /64s to Instances. But static routing can become a problem, so you might want to use OSPF, LISP or even iBGP for getting those prefixes to the VR. This is a big feature, but I think the Basic zone is the easiest for now. In the Advanced Zone you COULD keep everything behind the VR IPv4 and have the VR do IPv6 loadbalancing, but that would still not be true IPv6 connectivity. NAT in the VR seems like a firewall, but a true statefull firewall in the VR could do the same while the Instances still have publicly routeable IPv6 addresses. There is no functional spec on this yet, but we have to keep this in mind that we need IPv6 support. People are running out of IPv4 space. -- 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-451) System VMs shouldn't be just Debian based
Wido den Hollander created CLOUDSTACK-451: - Summary: System VMs shouldn't be just Debian based Key: CLOUDSTACK-451 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-451 Project: CloudStack Issue Type: Improvement Reporter: Wido den Hollander This one is tied into: CLOUDSTACK-450 Currently our System VMs are a Debian based template which are pretty big. If we abstract the way we talk to the System VM by adding an API it shouldn't matter anymore which distro or OS will be running in there. Some users might want to use a different distribution or build their own homebrew System VM as long as they implement the API. Most System VM tasks can be done in Read-Only mode as well, the filesystem of the System VM doesn't need to be R/W, which would make them more robust. In the end a System VM shouldn't have to be bigger then something like 50MB when stripped down. This issue is here to raise awareness that this has to be addressed at some point. -- 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-450) Controlling System VMs should not happen through SSH
Wido den Hollander created CLOUDSTACK-450: - Summary: Controlling System VMs should not happen through SSH Key: CLOUDSTACK-450 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-450 Project: CloudStack Issue Type: Improvement Components: Management Server Reporter: Wido den Hollander Currently we SSH into the System VMs to control them. This is not doable on the longer run, it causes problems already, like injecting the SSH keys into the System VM ISO which is not reliable. Inside the System VM there should be an API running which the management server(s) can talk to to inject DHCP entries, add loadbalancing settings to HA proxy, have the SSVM download a template/ISO, etc, etc. This would mean a complete rewrite of the System VMs, but it will make them more robust over time. The exact spec for this improvement still has to be written, this issue is just here to identify the problem. -- 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-449) Disk I/O polling for instances
Wido den Hollander created CLOUDSTACK-449: - Summary: Disk I/O polling for instances Key: CLOUDSTACK-449 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-449 Project: CloudStack Issue Type: New Feature Components: KVM, Management Server, Usage, VMware, Xen Reporter: Wido den Hollander Priority: Minor Disk I/O polling for instances would gather disk I/O statistics for root and data volumes attached to instancesn, just like we do with network traffic. This enables administrators to figure out how much I/O each instance is doing. In public clouds users might want to start billing for this. This is not a monitoring solution for the backing storage, it doesn't alarm about high disk I/O, it simply accounts how much I/O each instance is doing. The function specification for this is online at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Feature+Disk+IO+statistics+for+instances -- 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-443) health monitoring for load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492266#comment-13492266 ] Wido den Hollander commented on CLOUDSTACK-443: --- Yes, that seems sane indeed. It would be a challange though, since we also might want to support profiles for SMTP loadbalancing, IMAP, etc, etc. The configuration abstraction should be well though of. Other then that, it seems like a valuable feature to be added so that loadbalancing works even better and more dynamic. > health monitoring for load balanced instances > - > > Key: CLOUDSTACK-443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-443 > Project: CloudStack > Issue Type: New Feature > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Rajesh Battala > Fix For: 4.1.0 > > > Enhance existing 'load balancer' network service provided by CloudStack, to > support health monitor the load balanced instances. ADC's supported > (NetScaler, Big IP, ADX) by CloudStack have native capabilities to monotor > health of in the instances. Leverage that to load balance the traffic only to > healthy instances. > This feature shall provide capabilities to > - to configure health check policy with load balancer rule > - delete configured 'health check policy' associated with a load balancer > rules > - list/describe instance healths. -- 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-443) health monitoring for load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492183#comment-13492183 ] Wido den Hollander commented on CLOUDSTACK-443: --- That would indeed work, but how does this going to work with other loadbalancers then a NetScaler? They will all probably have their own ways of doing these things. Since HAProxy in the Virtual Router also supports health monitoring we also should include it there. This is assuming that CloudStack will only push a configuration profile, nothing more (or less). > health monitoring for load balanced instances > - > > Key: CLOUDSTACK-443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-443 > Project: CloudStack > Issue Type: New Feature > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.1.0 > > > Enhance existing 'load balancer' network service provided by CloudStack, to > support health monitor the load balanced instances. ADC's supported > (NetScaler, Big IP, ADX) by CloudStack have native capabilities to monotor > health of in the instances. Leverage that to load balance the traffic only to > healthy instances. > This feature shall provide capabilities to > - to configure health check policy with load balancer rule > - delete configured 'health check policy' associated with a load balancer > rules > - list/describe instance healths. -- 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-445) Non-Committer documentation is not clear
[ https://issues.apache.org/jira/browse/CLOUDSTACK-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-445. --- Resolution: Fixed Assignee: Wido den Hollander Applied to the subversion repo. Thanks! > Non-Committer documentation is not clear > > > Key: CLOUDSTACK-445 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-445 > Project: CloudStack > Issue Type: Improvement > Components: Website >Reporter: Ahmed Fathalla >Assignee: Wido den Hollander >Priority: Trivial > Attachments: CLOUDSTACK-445-patch.txt > > > The documentation on the Contributing to "Apache CloudStack as a > Non-Committer" is a bit ambiguous and uses the word contributor instead of > committer. -- 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-443) health monitoring for load balanced instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490520#comment-13490520 ] Wido den Hollander commented on CLOUDSTACK-443: --- Won't this go out of the scope of CloudStack? Isn't health monitoring something that the loadbalancer itself should do? For HTTP those loadbalancers should just do a health check every X seconds to all the backends and see if they are alive. Why should CloudStack do this? If you add this to CloudStack then it will become some monitoring tool that is collecting data from the instances to see if they are 'alive'. I don't think this is up to CloudStack, the loadbalancers should handle this themselves. > health monitoring for load balanced instances > - > > Key: CLOUDSTACK-443 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-443 > Project: CloudStack > Issue Type: New Feature > Components: Network Controller >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.1.0 > > > Enhance existing 'load balancer' network service provided by CloudStack, to > support health monitor the load balanced instances. ADC's supported > (NetScaler, Big IP, ADX) by CloudStack have native capabilities to monotor > health of in the instances. Leverage that to load balance the traffic only to > healthy instances. > This feature shall provide capabilities to > - to configure health check policy with load balancer rule > - delete configured 'health check policy' associated with a load balancer > rules > - list/describe instance healths. -- 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-411) Add another step during kvm agent installation on Ubuntu machine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483530#comment-13483530 ] Wido den Hollander commented on CLOUDSTACK-411: --- See this commit: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commit;h=bc94948e0604e0e5931759be3c3d3155e84686f6 > Add another step during kvm agent installation on Ubuntu machine > > > Key: CLOUDSTACK-411 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-411 > Project: CloudStack > Issue Type: Bug > Components: Doc >Reporter: edison su >Assignee: Jessica Tomechak > > Ref: https://issues.apache.org/jira/browse/CLOUDSTACK-410. For 4.0 release, > we can document it in the installation guide for kvm agent installation on > ubuntu machine, with the following command: > uncomment out "# vnc_listen = "0.0.0.0"" in /etc/libvirt/qemu.conf -- 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-411) Add another step during kvm agent installation on Ubuntu machine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483528#comment-13483528 ] Wido den Hollander commented on CLOUDSTACK-411: --- This should not be necesarry anymore, see CS-410. I pushed a bit of code which binds the Instance to the hypervisor host private IP-address. There seems to be a bug in this code, but that is a different discussion ;) > Add another step during kvm agent installation on Ubuntu machine > > > Key: CLOUDSTACK-411 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-411 > Project: CloudStack > Issue Type: Bug > Components: Doc >Reporter: edison su >Assignee: Jessica Tomechak > > Ref: https://issues.apache.org/jira/browse/CLOUDSTACK-410. For 4.0 release, > we can document it in the installation guide for kvm agent installation on > ubuntu machine, with the following command: > uncomment out "# vnc_listen = "0.0.0.0"" in /etc/libvirt/qemu.conf -- 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-410) vnc_listen not configured in qemu.conf for Ubuntu KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483431#comment-13483431 ] Wido den Hollander commented on CLOUDSTACK-410: --- This should not be required anymore, but I think I bumped into this one as well. I did a commit some time ago which would use the Hypervisor IP for setting the VNC address in the domain XML: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=bc94948e0604e0e5931759be3c3d3155e84686f6 I'll look into this, since my commit should make changing vnc_listen in qemu.conf obsolete. > vnc_listen not configured in qemu.conf for Ubuntu KVM host > -- > > Key: CLOUDSTACK-410 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-410 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup, KVM >Affects Versions: 4.0.0 >Reporter: Kirk Kosinski >Assignee: Wido den Hollander > Labels: ubuntu > Fix For: 4.0.0 > > > The vnc_listen configuration in /etc/libvirt/qemu.conf is left at the default > (commented out) for Ubuntu KVM hosts. The VNC console for VMs will listen on > the default of 127.0.0.1:59XX and will not be accessible to the Console Proxy > VM. I noticed this when using the CloudStack-non-OSS-4.0.0-24 build. > To reproduce: > 1. Install Ubuntu 12.04.1 Server, install updates. > 2. Install CloudStack agent on host (run install.sh with "A" option). > 3. Add the host to CloudStack. > 4. Launch a VM on the Ubuntu host and try to access the console. The error > will be: > Unable to start console session as connection is refused by the machine you > are accessing > 5. Check "netstat -plnt" on the KVM host to see the VNC session on > 127.0.0.1:59XX. -- 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-324) Cannot edit default security group rules, default security group blocks all inbound traffic.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474566#comment-13474566 ] Wido den Hollander commented on CLOUDSTACK-324: --- I can't seem to find on which platform this is. Is this a KVM Hypervisor? I assume so following the forum link? This is with CloudStack 3.0.2 I guess? > Cannot edit default security group rules, default security group blocks all > inbound traffic. > > > Key: CLOUDSTACK-324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-324 > Project: CloudStack > Issue Type: Bug >Affects Versions: pre-4.0.0 >Reporter: Max Clark > Labels: iptables, network, security > > When configuring basic networking, by default the network is created with the > "DefaultSharedNetworkOffering". This offering does not have a security group. > No inbound traffic is allowed to the created VMs. Reading the AdminGuide > documentation: > "Each CloudStack account comes with a default security group that denies all > inbound traffic and allows all outbound traffic. The default security group > can be modified so that all new VMs inherit some other desired set of rules." > If a network is created without a security group, it shouldn't have a > security group and all inbound/outbound traffic should be allowed - or at the > very least the default security group should be able to be configured. > http://www.cloudstack.com/forum/8-storage-and-networking/7054-vm-instance-cant-be-accessd-using-basic-networking.html?limit=6&start=6#7084 -- 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-316) KVM Agent setup fails due to cloudbr0 set as public network interface
[
https://issues.apache.org/jira/browse/CLOUDSTACK-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474142#comment-13474142
]
Wido den Hollander commented on CLOUDSTACK-316:
---
Checking my api-server.log I see this:
2012-10-11 14:54:55,513 INFO [cloud.api.ApiServer] (catalina-exec-5:null)
(userId=2 accountId=2 sessionId=FF59B183869EB5D6931A3B4386E8F8BE)
0:0:0:0:0:0:0:1 -- GET
command=addTrafficType&trafficType=Guest&physicalnetworkid=ac1e061f-08b5-4e42-8637-51aa6342b5c5&kvmnetworklabel=vlanbr672&response=json&sessionkey=PKgIfLQ%2F5Is1rJEmuyAG6HQ2BjY%3D&_=1349960095344
200 { "addtraffictyperesponse" :
{"id":"c0c57ed9-70f7-412a-aebd-69cafe4e80a4","jobid":"81d2128a-c508-4221-97ad-6204164a4899"}
}
2012-10-11 14:54:55,530 INFO [cloud.api.ApiServer] (catalina-exec-3:null)
(userId=2 accountId=2 sessionId=FF59B183869EB5D6931A3B4386E8F8BE)
0:0:0:0:0:0:0:1 -- GET
command=addTrafficType&trafficType=Management&physicalnetworkid=ac1e061f-08b5-4e42-8637-51aa6342b5c5&kvmnetworklabel=vlanbr670&response=json&sessionkey=PKgIfLQ%2F5Is1rJEmuyAG6HQ2BjY%3D&_=1349960095348
200 { "addtraffictyperesponse" :
{"id":"74630522-3e20-4d6f-b112-23a3e8c695f6","jobid":"56385149-fe98-43f3-9f95-ba26076c72ed"}
}
Is this a GUI issue? Should the GUI set the "kvmnetworklabel" for the public
network during the wizard or should this be handled by the management server?
However, in my GUI right now I don't see a way to modify the public network
label.
> KVM Agent setup fails due to cloudbr0 set as public network interface
> -
>
> Key: CLOUDSTACK-316
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-316
> Project: CloudStack
> Issue Type: Bug
> Components: KVM, Management Server
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04
> CloudStack 4.0.0-incubator
>Reporter: Wido den Hollander
>
> I just set up a fresh CloudStack 4.0 platform and tried to add a host via the
> wizard.
> My Basic network settings:
> - guest: vlanbr672
> - private: vlanbr670
> During the wizard there is never a prompt for the public network, you can
> only set the storage label, but I didn't do that.
> I kept waiting for the hypervisor to come online, but the agent wouldn't
> start. The log showed:
> 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) Retrieving network interface: cloudbr0
> 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) Unable to get network interface for cloudbr0
> 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) Retrieving network interface: null
> 2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
> (main:null) Retrieving network interface: null
> ...
>
> .
> ..
> 2012-10-11 14:55:50,617 DEBUG [utils.script.Script] (main:null)
> Executing: /bin/bash -c brctl show | grep cloudbr0 | awk '{print $4}'
> 2012-10-11 14:55:50,624 DEBUG [utils.script.Script] (main:null) Execution
> is successful.
> 2012-10-11 14:55:50,624 DEBUG [utils.script.Script] (main:null)
> Executing: /bin/bash -c ls /proc/net/vlan/null
> 2012-10-11 14:55:50,630 DEBUG [utils.script.Script] (main:null) Exit
> value is 2
> 2012-10-11 14:55:50,630 DEBUG [utils.script.Script] (main:null) ls:
> cannot access /proc/net/vlan/null: No such file or directory
> ...
>
> .
> 2012-10-11 14:55:50,649 DEBUG [kvm.resource.LibvirtComputingResource]
> (main:null) Failed to get public nic name
> 2012-10-11 14:55:50,649 ERROR [cloud.agent.AgentShell] (main:null) Unable
> to start agent: Failed to get public nic name
> This was due to this setting in agent.properties:
> public.network.device=cloudbr0
> My setup doesn't have cloudbr0, so why was this set?
> The management server log shows me:
> 2012-10-11 14:55:14,545 DEBUG [utils.ssh.SSHCmdHelper]
> (catalina-exec-21:null) Executing cmd: cloud-setup-agent -m 31.25.100.163 -z
> 1 -p 1 -c 1 -g 614b7f96-b6e9-38f2-984b-956af817f771 -a --pubNic=cloudbr0
> --prvNic=vlanbr670 --guestNic=vlanbr672
> 2012-10-11 14:55:47,555 DEBUG [utils.ssh.SSHCmdHelper]
> (catalina-exec-21:null) cloud-setup-agent -m 31.25.100.163 -z 1 -p 1 -c 1 -g
> 614b7f96-b6e9-38f2-984b-956af817f771 -a --pubNic=cloudbr0 --prvNic=vlanbr670
> --guestNic=vlanbr672 output:CloudStack Agent setup is done!
> As you can see, the management server came up with "cloudbr0" for the public
> network, while I never configured that.
> Should public network be set to guest network in a Basic KVM zone?
--
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-316) KVM Agent setup fails due to cloudbr0 set as public network interface
Wido den Hollander created CLOUDSTACK-316:
-
Summary: KVM Agent setup fails due to cloudbr0 set as public
network interface
Key: CLOUDSTACK-316
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-316
Project: CloudStack
Issue Type: Bug
Components: KVM, Management Server
Affects Versions: 4.0.0
Environment: Ubuntu 12.04
CloudStack 4.0.0-incubator
Reporter: Wido den Hollander
I just set up a fresh CloudStack 4.0 platform and tried to add a host via the
wizard.
My Basic network settings:
- guest: vlanbr672
- private: vlanbr670
During the wizard there is never a prompt for the public network, you can only
set the storage label, but I didn't do that.
I kept waiting for the hypervisor to come online, but the agent wouldn't start.
The log showed:
2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
(main:null) Retrieving network interface: cloudbr0
2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
(main:null) Unable to get network interface for cloudbr0
2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
(main:null) Retrieving network interface: null
2012-10-11 14:55:46,835 DEBUG [cloud.resource.ServerResourceBase]
(main:null) Retrieving network interface: null
...
.
..
2012-10-11 14:55:50,617 DEBUG [utils.script.Script] (main:null) Executing:
/bin/bash -c brctl show | grep cloudbr0 | awk '{print $4}'
2012-10-11 14:55:50,624 DEBUG [utils.script.Script] (main:null) Execution
is successful.
2012-10-11 14:55:50,624 DEBUG [utils.script.Script] (main:null) Executing:
/bin/bash -c ls /proc/net/vlan/null
2012-10-11 14:55:50,630 DEBUG [utils.script.Script] (main:null) Exit value
is 2
2012-10-11 14:55:50,630 DEBUG [utils.script.Script] (main:null) ls: cannot
access /proc/net/vlan/null: No such file or directory
...
.
2012-10-11 14:55:50,649 DEBUG [kvm.resource.LibvirtComputingResource]
(main:null) Failed to get public nic name
2012-10-11 14:55:50,649 ERROR [cloud.agent.AgentShell] (main:null) Unable
to start agent: Failed to get public nic name
This was due to this setting in agent.properties:
public.network.device=cloudbr0
My setup doesn't have cloudbr0, so why was this set?
The management server log shows me:
2012-10-11 14:55:14,545 DEBUG [utils.ssh.SSHCmdHelper] (catalina-exec-21:null)
Executing cmd: cloud-setup-agent -m 31.25.100.163 -z 1 -p 1 -c 1 -g
614b7f96-b6e9-38f2-984b-956af817f771 -a --pubNic=cloudbr0 --prvNic=vlanbr670
--guestNic=vlanbr672
2012-10-11 14:55:47,555 DEBUG [utils.ssh.SSHCmdHelper] (catalina-exec-21:null)
cloud-setup-agent -m 31.25.100.163 -z 1 -p 1 -c 1 -g
614b7f96-b6e9-38f2-984b-956af817f771 -a --pubNic=cloudbr0 --prvNic=vlanbr670
--guestNic=vlanbr672 output:CloudStack Agent setup is done!
As you can see, the management server came up with "cloudbr0" for the public
network, while I never configured that.
Should public network be set to guest network in a Basic KVM zone?
--
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-294) Package AWSAPI in debian files
[ https://issues.apache.org/jira/browse/CLOUDSTACK-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13472257#comment-13472257 ] Wido den Hollander commented on CLOUDSTACK-294: --- I'm waiting for the consensus on the mailinglist about this. There seems to be a discussion if this should be a part of the CloudStack project or that we need a separate repository for just CloudBridge. It doesn't seem to be tied into the core at all. > Package AWSAPI in debian files > -- > > Key: CLOUDSTACK-294 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-294 > Project: CloudStack > Issue Type: Bug > Components: AWSAPI, Install and Setup >Affects Versions: pre-4.0.0 >Reporter: David Nalley >Assignee: Wido den Hollander >Priority: Blocker > Fix For: 4.0.0 > > > AWSAPI isn't packaged for debian currently. > Plz 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] [Resolved] (CLOUDSTACK-218) Permission problem while running /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS Instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-218. --- Resolution: Fixed Fixed by commit 82e57f8f40e73783f600e1925ca335c41eb54595 We now use /tmp to use as a temporary mount location. > Permission problem while running > /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS > Instance > - > > Key: CLOUDSTACK-218 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-218 > Project: CloudStack > Issue Type: Bug > Components: Management Server >Affects Versions: 4.0.0 > Environment: Fresh Ubuntu 12.04 AWS instance of type m1.medium > root@ip-10-145-150-14:/var/log/cloud/management# lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 12.04.1 LTS > Release:12.04 > Codename: precise > root@ip-10-145-150-14:/var/log/cloud/management# > root@ip-10-145-150-14:/var/log/cloud/management# dpkg -l | grep cloud > ii cloud-client 1:4.0.0-1beta1 > CloudStack client > ii cloud-client-ui 1:4.0.0-1beta1 > CloudStack management server UI > ii cloud-core 1:4.0.0-1beta1 > CloudStack core library > ii cloud-deps 1:4.0.0-1beta1 > CloudStack library dependencies > ii cloud-init 0.6.3-0ubuntu1 > Init scripts for cloud instances > ii cloud-initramfs-growroot 0.4ubuntu1 > automatically resize the root partition on first boot > ii cloud-initramfs-rescuevol0.4ubuntu1 > boot off a rescue volume rather than root filesystem > ii cloud-python 1:4.0.0-1beta1 > CloudStack Python library > ii cloud-scripts1:4.0.0-1beta1 > CloudStack scripts > ii cloud-server 1:4.0.0-1beta1 > CloudStack server library > ii cloud-setup 1:4.0.0-1beta1 > CloudStack client > ii cloud-system-iso 1:4.0.0-1beta1 > CloudStack system iso > ii cloud-utils 1:4.0.0-1beta1 > CloudStack utility library >Reporter: Shanker Balan >Assignee: Wido den Hollander >Priority: Trivial > Fix For: 4.0.0 > > > To reproduce: > Create new AWS instance running Ubuntu precise > deb http://cloudstack.apt-get.eu/ubuntu precise 4.0 > wget -O - http://cloudstack.apt-get.eu/release.asc|sudo apt-key add - > sudo apt-get update > sudo apt-get install cloud-client > sudo apt-get install mysql-server > sudo cloud-setup-databases cloud:password@localhost --deploy-as=root:password > sudo cloud-setup-management > sudo /etc/init.d/cloud-management restart > tail -f management-server.log > ubuntu@ip-10-145-150-14:~$ ls -al > total 40 > drwxr-xr-x 6 ubuntu ubuntu 4096 Sep 27 07:10 . > drwxr-xr-x 3 root root 4096 Aug 22 05:48 .. > -rw-r--r-- 1 ubuntu ubuntu 220 Apr 3 15:58 .bash_logout > -rw-r--r-- 1 ubuntu ubuntu 3486 Apr 3 15:58 .bashrc > drwxrwxr-x 2 ubuntu ubuntu 4096 Sep 27 07:08 .byobu > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:44 .cache > -rw-r--r-- 1 ubuntu ubuntu 675 Apr 3 15:58 .profile > -rw-rw-r-- 1 ubuntu ubuntu0 Sep 27 06:47 .screenrc > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:42 .ssh > -rw-r--r-- 1 ubuntu ubuntu0 Sep 27 06:47 .sudo_as_admin_successful > drwxr-xr-x 2 root root 4096 Sep 27 07:10 systemvm_mnt > -rw--- 1 root root672 Sep 27 06:47 .viminfo > ubuntu@ip-10-145-150-14:~$ pwd > /home/ubuntu > ubuntu@ip-10-145-150-14:~$ id > uid=1000(ubuntu) gid=1000(ubuntu) > groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),110(netdev),111(admin) > ubuntu@ip-10-145-150-14:~$ sudo tail -2 /etc/sudoers > #includedir /etc/sudoers.d > cloud ALL =NOPASSWD : ALL > snip > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/common > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/common/vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [cloud.server.ConfigurationServerImpl] > (main:null) Executing: > /u
[jira] [Commented] (CLOUDSTACK-218) Permission problem while running /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS Instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464576#comment-13464576 ] Wido den Hollander commented on CLOUDSTACK-218: --- The management server seems to think it's homedirectory is /home/ubuntu because you used "sudo". That seems like a bug, I'll check that. > Permission problem while running > /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS > Instance > - > > Key: CLOUDSTACK-218 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-218 > Project: CloudStack > Issue Type: Bug > Components: Management Server >Affects Versions: 4.0.0 > Environment: Fresh Ubuntu 12.04 AWS instance of type m1.medium > root@ip-10-145-150-14:/var/log/cloud/management# lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 12.04.1 LTS > Release:12.04 > Codename: precise > root@ip-10-145-150-14:/var/log/cloud/management# > root@ip-10-145-150-14:/var/log/cloud/management# dpkg -l | grep cloud > ii cloud-client 1:4.0.0-1beta1 > CloudStack client > ii cloud-client-ui 1:4.0.0-1beta1 > CloudStack management server UI > ii cloud-core 1:4.0.0-1beta1 > CloudStack core library > ii cloud-deps 1:4.0.0-1beta1 > CloudStack library dependencies > ii cloud-init 0.6.3-0ubuntu1 > Init scripts for cloud instances > ii cloud-initramfs-growroot 0.4ubuntu1 > automatically resize the root partition on first boot > ii cloud-initramfs-rescuevol0.4ubuntu1 > boot off a rescue volume rather than root filesystem > ii cloud-python 1:4.0.0-1beta1 > CloudStack Python library > ii cloud-scripts1:4.0.0-1beta1 > CloudStack scripts > ii cloud-server 1:4.0.0-1beta1 > CloudStack server library > ii cloud-setup 1:4.0.0-1beta1 > CloudStack client > ii cloud-system-iso 1:4.0.0-1beta1 > CloudStack system iso > ii cloud-utils 1:4.0.0-1beta1 > CloudStack utility library >Reporter: Shanker Balan >Assignee: Wido den Hollander >Priority: Trivial > Fix For: 4.0.0 > > > To reproduce: > Create new AWS instance running Ubuntu precise > deb http://cloudstack.apt-get.eu/ubuntu precise 4.0 > wget -O - http://cloudstack.apt-get.eu/release.asc|sudo apt-key add - > sudo apt-get update > sudo apt-get install cloud-client > sudo apt-get install mysql-server > sudo cloud-setup-databases cloud:password@localhost --deploy-as=root:password > sudo cloud-setup-management > sudo /etc/init.d/cloud-management restart > tail -f management-server.log > ubuntu@ip-10-145-150-14:~$ ls -al > total 40 > drwxr-xr-x 6 ubuntu ubuntu 4096 Sep 27 07:10 . > drwxr-xr-x 3 root root 4096 Aug 22 05:48 .. > -rw-r--r-- 1 ubuntu ubuntu 220 Apr 3 15:58 .bash_logout > -rw-r--r-- 1 ubuntu ubuntu 3486 Apr 3 15:58 .bashrc > drwxrwxr-x 2 ubuntu ubuntu 4096 Sep 27 07:08 .byobu > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:44 .cache > -rw-r--r-- 1 ubuntu ubuntu 675 Apr 3 15:58 .profile > -rw-rw-r-- 1 ubuntu ubuntu0 Sep 27 06:47 .screenrc > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:42 .ssh > -rw-r--r-- 1 ubuntu ubuntu0 Sep 27 06:47 .sudo_as_admin_successful > drwxr-xr-x 2 root root 4096 Sep 27 07:10 systemvm_mnt > -rw--- 1 root root672 Sep 27 06:47 .viminfo > ubuntu@ip-10-145-150-14:~$ pwd > /home/ubuntu > ubuntu@ip-10-145-150-14:~$ id > uid=1000(ubuntu) gid=1000(ubuntu) > groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),110(netdev),111(admin) > ubuntu@ip-10-145-150-14:~$ sudo tail -2 /etc/sudoers > #includedir /etc/sudoers.d > cloud ALL =NOPASSWD : ALL > snip > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/common > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/common/vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [cloud.serv
[jira] [Updated] (CLOUDSTACK-218) Permission problem while running /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS Instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-218: -- Assignee: Wido den Hollander > Permission problem while running > /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh on Ubuntu 12.04 AWS > Instance > - > > Key: CLOUDSTACK-218 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-218 > Project: CloudStack > Issue Type: Bug > Components: Management Server >Affects Versions: 4.0.0 > Environment: Fresh Ubuntu 12.04 AWS instance of type m1.medium > root@ip-10-145-150-14:/var/log/cloud/management# lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description:Ubuntu 12.04.1 LTS > Release:12.04 > Codename: precise > root@ip-10-145-150-14:/var/log/cloud/management# > root@ip-10-145-150-14:/var/log/cloud/management# dpkg -l | grep cloud > ii cloud-client 1:4.0.0-1beta1 > CloudStack client > ii cloud-client-ui 1:4.0.0-1beta1 > CloudStack management server UI > ii cloud-core 1:4.0.0-1beta1 > CloudStack core library > ii cloud-deps 1:4.0.0-1beta1 > CloudStack library dependencies > ii cloud-init 0.6.3-0ubuntu1 > Init scripts for cloud instances > ii cloud-initramfs-growroot 0.4ubuntu1 > automatically resize the root partition on first boot > ii cloud-initramfs-rescuevol0.4ubuntu1 > boot off a rescue volume rather than root filesystem > ii cloud-python 1:4.0.0-1beta1 > CloudStack Python library > ii cloud-scripts1:4.0.0-1beta1 > CloudStack scripts > ii cloud-server 1:4.0.0-1beta1 > CloudStack server library > ii cloud-setup 1:4.0.0-1beta1 > CloudStack client > ii cloud-system-iso 1:4.0.0-1beta1 > CloudStack system iso > ii cloud-utils 1:4.0.0-1beta1 > CloudStack utility library >Reporter: Shanker Balan >Assignee: Wido den Hollander >Priority: Trivial > Fix For: 4.0.0 > > > To reproduce: > Create new AWS instance running Ubuntu precise > deb http://cloudstack.apt-get.eu/ubuntu precise 4.0 > wget -O - http://cloudstack.apt-get.eu/release.asc|sudo apt-key add - > sudo apt-get update > sudo apt-get install cloud-client > sudo apt-get install mysql-server > sudo cloud-setup-databases cloud:password@localhost --deploy-as=root:password > sudo cloud-setup-management > sudo /etc/init.d/cloud-management restart > tail -f management-server.log > ubuntu@ip-10-145-150-14:~$ ls -al > total 40 > drwxr-xr-x 6 ubuntu ubuntu 4096 Sep 27 07:10 . > drwxr-xr-x 3 root root 4096 Aug 22 05:48 .. > -rw-r--r-- 1 ubuntu ubuntu 220 Apr 3 15:58 .bash_logout > -rw-r--r-- 1 ubuntu ubuntu 3486 Apr 3 15:58 .bashrc > drwxrwxr-x 2 ubuntu ubuntu 4096 Sep 27 07:08 .byobu > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:44 .cache > -rw-r--r-- 1 ubuntu ubuntu 675 Apr 3 15:58 .profile > -rw-rw-r-- 1 ubuntu ubuntu0 Sep 27 06:47 .screenrc > drwx-- 2 ubuntu ubuntu 4096 Sep 27 06:42 .ssh > -rw-r--r-- 1 ubuntu ubuntu0 Sep 27 06:47 .sudo_as_admin_successful > drwxr-xr-x 2 root root 4096 Sep 27 07:10 systemvm_mnt > -rw--- 1 root root672 Sep 27 06:47 .viminfo > ubuntu@ip-10-145-150-14:~$ pwd > /home/ubuntu > ubuntu@ip-10-145-150-14:~$ id > uid=1000(ubuntu) gid=1000(ubuntu) > groups=1000(ubuntu),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),110(netdev),111(admin) > ubuntu@ip-10-145-150-14:~$ sudo tail -2 /etc/sudoers > #includedir /etc/sudoers.d > cloud ALL =NOPASSWD : ALL > snip > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/common > 2012-09-27 07:10:46,743 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/common/vms/systemvm.iso > 2012-09-27 07:10:46,743 DEBUG [cloud.server.ConfigurationServerImpl] > (main:null) Executing: > /usr/lib/cloud/common/scripts/vm/systemvm/injectkeys.sh > /var/lib/cloud/management/.ssh/id_rsa.pub > /var/lib/cloud
[jira] [Resolved] (CLOUDSTACK-209) Upgrade from CS-3.0.2 to ASF 4.0 fails with com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject script scripts/vm/systemvm/injectkeys.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-209. --- Resolution: Fixed This should be resolved by commit 6839f7020c4458457589927198afc0866ae7eecc > Upgrade from CS-3.0.2 to ASF 4.0 fails with > com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject > script scripts/vm/systemvm/injectkeys.sh > --- > > Key: CLOUDSTACK-209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-209 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup, Management Server >Affects Versions: pre-4.0.0 > Environment: MS : Rhel 6.2 > HOST : KVM ( Rhel 6.2) > BUILDS : > CS-3.0.2 - CloudStack-3.0.2-1-rhel6.2.tar.gz > ASF 4.0 - CloudStack-oss-4.0.0-187.tar.bz2 >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > Attachments: agent.log, api-server.log, management-server.log, > SQL_09_26.dmp > > > Steps : > == > 1. Deploy an advanced zone setup with CS-3.0.2 and KVM host (Rhel 6.2) > 2. Create a VM instance. > 3. Stop Management server. > 4. Upgrade to ASF 4.0 > 5. Stop agent services on the host. > 6. Upgrade to ASF 4.0 > 7. Start agent on the host. > 8. Start management server services. > Expected Behaviour : > == > The upgrade should happen smoothly without any error. > Observed Behaviour : > == > 1. After executing above steps, following exception is seen in the logs > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking > for scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking for > scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 WARN [utils.script.Script] (main:null) Unable to > find script scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in the classpath > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) System > resource: null > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib64/cloud/common > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Searching in > the current directory > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/management/./vms/systemvm.iso > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/management/./vms/systemvm.iso > 2012-09-26 17:44:41,579 WARN [utils.script.Script] (main:null) Unable to > find script vms/systemvm.iso
[jira] [Updated] (CLOUDSTACK-209) Upgrade from CS-3.0.2 to ASF 4.0 fails with com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject script scripts/vm/systemvm/injectkeys.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-209: -- Assignee: Wido den Hollander > Upgrade from CS-3.0.2 to ASF 4.0 fails with > com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject > script scripts/vm/systemvm/injectkeys.sh > --- > > Key: CLOUDSTACK-209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-209 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup, Management Server >Affects Versions: pre-4.0.0 > Environment: MS : Rhel 6.2 > HOST : KVM ( Rhel 6.2) > BUILDS : > CS-3.0.2 - CloudStack-3.0.2-1-rhel6.2.tar.gz > ASF 4.0 - CloudStack-oss-4.0.0-187.tar.bz2 >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > Attachments: agent.log, api-server.log, management-server.log, > SQL_09_26.dmp > > > Steps : > == > 1. Deploy an advanced zone setup with CS-3.0.2 and KVM host (Rhel 6.2) > 2. Create a VM instance. > 3. Stop Management server. > 4. Upgrade to ASF 4.0 > 5. Stop agent services on the host. > 6. Upgrade to ASF 4.0 > 7. Start agent on the host. > 8. Start management server services. > Expected Behaviour : > == > The upgrade should happen smoothly without any error. > Observed Behaviour : > == > 1. After executing above steps, following exception is seen in the logs > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking > for scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking for > scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 WARN [utils.script.Script] (main:null) Unable to > find script scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in the classpath > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) System > resource: null > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib64/cloud/common > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Searching in > the current directory > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/management/./vms/systemvm.iso > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/management/./vms/systemvm.iso > 2012-09-26 17:44:41,579 WARN [utils.script.Script] (main:null) Unable to > find script vms/systemvm.iso > 2012-09-26 17:44:41,582 ERROR [cloud.servlet.CloudStartupServlet] (main:null
[jira] [Commented] (CLOUDSTACK-209) Upgrade from CS-3.0.2 to ASF 4.0 fails with com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject script scripts/vm/systemvm/injectkeys.sh
[ https://issues.apache.org/jira/browse/CLOUDSTACK-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464132#comment-13464132 ] Wido den Hollander commented on CLOUDSTACK-209: --- The problem is that cloud-server doesn't depend on cloud-scripts where injectkeys.sh is a part of. I have a commit pending here locally, that should fix that dependency. > Upgrade from CS-3.0.2 to ASF 4.0 fails with > com.cloud.utils.exception.CloudRuntimeException: Unable to find key inject > script scripts/vm/systemvm/injectkeys.sh > --- > > Key: CLOUDSTACK-209 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-209 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup, Management Server >Affects Versions: pre-4.0.0 > Environment: MS : Rhel 6.2 > HOST : KVM ( Rhel 6.2) > BUILDS : > CS-3.0.2 - CloudStack-3.0.2-1-rhel6.2.tar.gz > ASF 4.0 - CloudStack-oss-4.0.0-187.tar.bz2 >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > Attachments: agent.log, api-server.log, management-server.log, > SQL_09_26.dmp > > > Steps : > == > 1. Deploy an advanced zone setup with CS-3.0.2 and KVM host (Rhel 6.2) > 2. Create a VM instance. > 3. Stop Management server. > 4. Upgrade to ASF 4.0 > 5. Stop agent services on the host. > 6. Upgrade to ASF 4.0 > 7. Start agent on the host. > 8. Start management server services. > Expected Behaviour : > == > The upgrade should happen smoothly without any error. > Observed Behaviour : > == > 1. After executing above steps, following exception is seen in the logs > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking > for scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 DEBUG [utils.script.Script] (main:null) Looking for > scripts/vm/systemvm/injectkeys.sh in > /var/lib/cloud/management/./scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,571 WARN [utils.script.Script] (main:null) Unable to > find script scripts/vm/systemvm/injectkeys.sh > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in the classpath > 2012-09-26 17:44:41,574 DEBUG [utils.script.Script] (main:null) System > resource: null > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-26 17:44:41,575 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-26 17:44:41,576 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib64/cloud/common > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/common/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/cloud/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib64/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-26 17:44:41,578 DEBUG [utils.script.Script] (main:null) Searching in > the current directory > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/management/./vms/systemvm.iso > 2012-09-26 17:44:41,579 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /var/lib/cloud/manageme
[jira] [Resolved] (CLOUDSTACK-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-81. -- Resolution: Fixed This has been resolved. JSVC has replaced the daemonize binary and the init script on RHEL based platforms has been fixed since it's lacking a good LSB package. > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] -- This message is automatically generated by JIRA. If you think it wa
[jira] [Resolved] (CLOUDSTACK-190) DEB build have changed prefix install paths, for systemvm.zip/iso and agent/scripts
[
https://issues.apache.org/jira/browse/CLOUDSTACK-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wido den Hollander resolved CLOUDSTACK-190.
---
Resolution: Fixed
Fixed for both Ubuntu and RedHat.
For the agent directory a symlink is created to the common directory.
> DEB build have changed prefix install paths, for systemvm.zip/iso and
> agent/scripts
> ---
>
> Key: CLOUDSTACK-190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-190
> Project: CloudStack
> Issue Type: Bug
>Reporter: Rohit Yadav
>Assignee: Wido den Hollander
>Priority: Blocker
> Fix For: pre-4.0.0
>
>
> The install prefix for scripts and vms/systemvm.iso/zip has changed from
> /usr/lib(32/64)/cloud/agent/ to /usr/lib(32/64)/cloud/common/
> Note: There are paths harcoded in source code. Changing them will break
> backward compatibility and possible migration (upgrade) issues.
> Proposed solution (from IRC): Fix by symlinking paths for backward
> compatibility
> ln -f -s %{_libdir}/%{name}/common/scripts %{_libdir}/%{name}/agent/
> ln -f -s %{_libdir}/%{name}/common/vms %{_libdir}/%{name}/agent/
--
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-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461714#comment-13461714 ] Wido den Hollander commented on CLOUDSTACK-81: -- Discussed this with Rohit on IRC. The problem is that LSB-base is not available on RedHat/CentOS. There is a redhat-lsb package, but this depends on libraries like QT and we don't want that. I'll rewrite the init scripts for CentOS/RedHat to use other functions. The goal was to have one init script for all distros by using LSB. > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bi
[jira] [Commented] (CLOUDSTACK-4) Complete installation guide in XML
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458496#comment-13458496 ] Wido den Hollander commented on CLOUDSTACK-4: - I'm still working on the Agent and Hypervisor docs. This got delayed, but I should be able to make progress on it again next week. > Complete installation guide in XML > -- > > Key: CLOUDSTACK-4 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4 > Project: CloudStack > Issue Type: Bug > Components: Doc >Affects Versions: 4.0.0 >Reporter: Jessica Tomechak >Assignee: Jessica Tomechak > Fix For: pre-4.0.0 > > > Some sections of the 3.x installation guide are not present in the 4.x > installation guide. Need to add complete docbook XML files in the /docs > directory. -- 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-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-81. -- Resolution: Fixed I'm resolving this one, I've tested it and works. Re-open if the issue comes back. > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more informatio
[jira] [Commented] (CLOUDSTACK-92) Copying the system-vm template on UBUNTU 12.04 fails with " bash: /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13455314#comment-13455314 ] Wido den Hollander commented on CLOUDSTACK-92: -- Both issues have been resolved. The injectkeys issues has been resolved by renaming the package cloud-agent-scripts to cloud-scripts and having cloud-client package depend on it. The correct path is: /usr/lib/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt > Copying the system-vm template on UBUNTU 12.04 fails with " bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory" > -- > > Key: CLOUDSTACK-92 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-92 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: OS : Ubuntu 12.04 > ASF Build : CloudStack-oss-4.0.0.22-ubuntu12.04.tar.gz. > [ Git Revision: ea7fee8b2bf67630e52662ef38b8ae138bcd5ca9 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git ] >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > == > 1. Install CloudStack on Ubuntu 12.04 > 2. copy the system-vm templates to the secondary using the following command : > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > Expected Behaviour : > == > Both step 1 and step 2 should go fine, without any errors. > Observed Behaviour : > == > step 1 goes fine and the install is successful. > But we get the following errors after executing step2 > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory > This was the corresponding exception in the management server logs : > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/agent > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/agent/vms/systemvm.iso > 2012-09-13 12:06:10,121 ERROR [cloud.servlet.CloudStartupServlet] (main:null) > Exception starting management > servercom.cloud.utils.exception.CloudRuntimeException: Unable to find key > inject script scripts/vm/systemvm/injectkeys.sh at > com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:675) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:265) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:47) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1206) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026) at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734) > at > org.apache.catalina.core.Container
[jira] [Resolved] (CLOUDSTACK-92) Copying the system-vm template on UBUNTU 12.04 fails with " bash: /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No such file or directory"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander resolved CLOUDSTACK-92. -- Resolution: Fixed Fixed in commit 7eaf537d9573839f84494ed31f52ff70b2d03a7e cloud-client now depends on cloud-scripts > Copying the system-vm template on UBUNTU 12.04 fails with " bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory" > -- > > Key: CLOUDSTACK-92 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-92 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: OS : Ubuntu 12.04 > ASF Build : CloudStack-oss-4.0.0.22-ubuntu12.04.tar.gz. > [ Git Revision: ea7fee8b2bf67630e52662ef38b8ae138bcd5ca9 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git ] >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > == > 1. Install CloudStack on Ubuntu 12.04 > 2. copy the system-vm templates to the secondary using the following command : > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > Expected Behaviour : > == > Both step 1 and step 2 should go fine, without any errors. > Observed Behaviour : > == > step 1 goes fine and the install is successful. > But we get the following errors after executing step2 > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory > This was the corresponding exception in the management server logs : > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/agent > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/agent/vms/systemvm.iso > 2012-09-13 12:06:10,121 ERROR [cloud.servlet.CloudStartupServlet] (main:null) > Exception starting management > servercom.cloud.utils.exception.CloudRuntimeException: Unable to find key > inject script scripts/vm/systemvm/injectkeys.sh at > com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:675) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:265) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:47) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1206) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026) at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.j
[jira] [Commented] (CLOUDSTACK-92) Copying the system-vm template on UBUNTU 12.04 fails with " bash: /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454994#comment-13454994 ] Wido den Hollander commented on CLOUDSTACK-92: -- I fixed this in commit 7eaf537d9573839f84494ed31f52ff70b2d03a7e The cloud-agent-scripts package got renamed to cloud-scripts and all scripts are in /usr/lib/cloud/common/* For backwords compatibilty I'll add a symlink from agent -> common. The documentation needs to be adjusted though > Copying the system-vm template on UBUNTU 12.04 fails with " bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory" > -- > > Key: CLOUDSTACK-92 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-92 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: OS : Ubuntu 12.04 > ASF Build : CloudStack-oss-4.0.0.22-ubuntu12.04.tar.gz. > [ Git Revision: ea7fee8b2bf67630e52662ef38b8ae138bcd5ca9 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git ] >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > == > 1. Install CloudStack on Ubuntu 12.04 > 2. copy the system-vm templates to the secondary using the following command : > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > Expected Behaviour : > == > Both step 1 and step 2 should go fine, without any errors. > Observed Behaviour : > == > step 1 goes fine and the install is successful. > But we get the following errors after executing step2 > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory > This was the corresponding exception in the management server logs : > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/agent > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/agent/vms/systemvm.iso > 2012-09-13 12:06:10,121 ERROR [cloud.servlet.CloudStartupServlet] (main:null) > Exception starting management > servercom.cloud.utils.exception.CloudRuntimeException: Unable to find key > inject script scripts/vm/systemvm/injectkeys.sh at > com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:675) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:265) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:47) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1206) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026) at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734) > at > org.apache.catalina.cor
[jira] [Updated] (CLOUDSTACK-92) Copying the system-vm template on UBUNTU 12.04 fails with " bash: /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No such file or directory"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-92: - Assignee: Wido den Hollander (was: edison su) > Copying the system-vm template on UBUNTU 12.04 fails with " bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory" > -- > > Key: CLOUDSTACK-92 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-92 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: OS : Ubuntu 12.04 > ASF Build : CloudStack-oss-4.0.0.22-ubuntu12.04.tar.gz. > [ Git Revision: ea7fee8b2bf67630e52662ef38b8ae138bcd5ca9 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git ] >Reporter: Abhinav Roy >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > == > 1. Install CloudStack on Ubuntu 12.04 > 2. copy the system-vm templates to the secondary using the following command : > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > Expected Behaviour : > == > Both step 1 and step 2 should go fine, without any errors. > Observed Behaviour : > == > step 1 goes fine and the install is successful. > But we get the following errors after executing step2 > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory > This was the corresponding exception in the management server logs : > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/agent > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/agent/vms/systemvm.iso > 2012-09-13 12:06:10,121 ERROR [cloud.servlet.CloudStartupServlet] (main:null) > Exception starting management > servercom.cloud.utils.exception.CloudRuntimeException: Unable to find key > inject script scripts/vm/systemvm/injectkeys.sh at > com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:675) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:265) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:47) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1206) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026) at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostCo
[jira] [Commented] (CLOUDSTACK-92) Copying the system-vm template on UBUNTU 12.04 fails with " bash: /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454874#comment-13454874 ] Wido den Hollander commented on CLOUDSTACK-92: -- The docs are wrong about this, on Ubuntu the path is: /usr/lib/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt Right now the cloud-client package does not depend on cloud-agent-scripts, that package will probably be renamed to cloud-scripts to make the name more generic for that it's containing. > Copying the system-vm template on UBUNTU 12.04 fails with " bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory" > -- > > Key: CLOUDSTACK-92 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-92 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: OS : Ubuntu 12.04 > ASF Build : CloudStack-oss-4.0.0.22-ubuntu12.04.tar.gz. > [ Git Revision: ea7fee8b2bf67630e52662ef38b8ae138bcd5ca9 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git ] >Reporter: Abhinav Roy >Assignee: edison su >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > == > 1. Install CloudStack on Ubuntu 12.04 > 2. copy the system-vm templates to the secondary using the following command : > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > Expected Behaviour : > == > Both step 1 and step 2 should go fine, without any errors. > Observed Behaviour : > == > step 1 goes fine and the install is successful. > But we get the following errors after executing step2 > root@MS-ubuntu12:/home/abhinavr# > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m > /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012..vhd.bz2 -h > xenserver > bash: > /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt: No > such file or directory > This was the corresponding exception in the management server logs : > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Current > binaries reside at /usr/share/java > 2012-09-13 12:06:10,118 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/java/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/share/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /vms/systemvm.iso > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Searching in > environment.properties > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) > environment.properties says scripts should be in /usr/lib/cloud/agent > 2012-09-13 12:06:10,119 DEBUG [utils.script.Script] (main:null) Looking for > vms/systemvm.iso in /usr/lib/cloud/agent/vms/systemvm.iso > 2012-09-13 12:06:10,121 ERROR [cloud.servlet.CloudStartupServlet] (main:null) > Exception starting management > servercom.cloud.utils.exception.CloudRuntimeException: Unable to find key > inject script scripts/vm/systemvm/injectkeys.sh at > com.cloud.server.ConfigurationServerImpl.updateKeyPairs(ConfigurationServerImpl.java:675) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:265) > at > com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:47) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1206) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1026) at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4421) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4734) > at > org.apa
[jira] [Commented] (CLOUDSTACK-90) Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !!
[ https://issues.apache.org/jira/browse/CLOUDSTACK-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454871#comment-13454871 ] Wido den Hollander commented on CLOUDSTACK-90: -- There is indeed no upgrade path defined in the code, it's due to the build number the build got. You can disable (comment) the upgrade checker in the components.xml for now and manually apply schema-302to40.sql > Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !! > -- > > Key: CLOUDSTACK-90 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-90 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: Management Sever : Rhel 6.2 > CloudStack 3.0.2 Build : CloudStack-3.0.2-1-rhel6.2.tar.gz > [Git Revision: 26c4eade7f9970efd8eee76bdeb9f678c2d544e4 > Git URL: ssh://hud...@git.cloud.com/var/lib/git/cloudstack-oss] > ASF 4.0 Build : CloudStack-oss-4.0.59-rhel6.3.tar.gz > [Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git] >Reporter: Abhinav Roy >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > === > 1. Install CloudStack 3.0.2 on Rhel 6.2 and deploy Advanced zone config. > 2. Create a VM instance. > 3. Stop the management server. > 4. Take DB backup. > 5. Upgrade to ASF 4.0 > 6. Start the management server . > Expected Behaviour > > The upgrade should be successful. > Observed Behaviour > > The upgrade failed with the following errors : > 2012-09-13 16:06:48,238 DEBUG [cloud.upgrade.DatabaseIntegrityChecker] > (main:null) No duplicate hosts with the same local storage found in database > 2012-09-13 16:06:48,243 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,399 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Grabbing lock to check for database upgrade. > 2012-09-13 16:06:48,401 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,406 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) DB version = 3.0.2.20120506222956 Code Version = > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Database upgrade must be performed from 3.0.2.20120506222956 to > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 ERROR [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) The end upgrade version is actually at 4.0.0 but our management > server code version is at 4.0.59.20120908055459 > 2012-09-13 16:06:48,411 ERROR [utils.component.ComponentLocator] (main:null) > Problems with running checker:DatabaseUpgradeChecker > com.cloud.utils.exception.CloudRuntimeException: The end upgrade version is > actually at 4.0.0 but our management server code version is at > 4.0.59.20120908055459 > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:193) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:351) > at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) > at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) > at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) > at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) >
[jira] [Comment Edited] (CLOUDSTACK-90) Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !!
[ https://issues.apache.org/jira/browse/CLOUDSTACK-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454871#comment-13454871 ] Wido den Hollander edited comment on CLOUDSTACK-90 at 9/14/12 12:00 AM: There is indeed no upgrade path defined in the code, it's due to the build number the build got. You can disable (comment) the upgrade checker in the components.xml for now and manually apply schema-302to40.sql I'm assigning this one to Edison for now, since this is a Jenkins thing. was (Author: widodh): There is indeed no upgrade path defined in the code, it's due to the build number the build got. You can disable (comment) the upgrade checker in the components.xml for now and manually apply schema-302to40.sql > Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !! > -- > > Key: CLOUDSTACK-90 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-90 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: Management Sever : Rhel 6.2 > CloudStack 3.0.2 Build : CloudStack-3.0.2-1-rhel6.2.tar.gz > [Git Revision: 26c4eade7f9970efd8eee76bdeb9f678c2d544e4 > Git URL: ssh://hud...@git.cloud.com/var/lib/git/cloudstack-oss] > ASF 4.0 Build : CloudStack-oss-4.0.59-rhel6.3.tar.gz > [Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git] >Reporter: Abhinav Roy >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > === > 1. Install CloudStack 3.0.2 on Rhel 6.2 and deploy Advanced zone config. > 2. Create a VM instance. > 3. Stop the management server. > 4. Take DB backup. > 5. Upgrade to ASF 4.0 > 6. Start the management server . > Expected Behaviour > > The upgrade should be successful. > Observed Behaviour > > The upgrade failed with the following errors : > 2012-09-13 16:06:48,238 DEBUG [cloud.upgrade.DatabaseIntegrityChecker] > (main:null) No duplicate hosts with the same local storage found in database > 2012-09-13 16:06:48,243 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,399 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Grabbing lock to check for database upgrade. > 2012-09-13 16:06:48,401 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,406 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) DB version = 3.0.2.20120506222956 Code Version = > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Database upgrade must be performed from 3.0.2.20120506222956 to > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 ERROR [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) The end upgrade version is actually at 4.0.0 but our management > server code version is at 4.0.59.20120908055459 > 2012-09-13 16:06:48,411 ERROR [utils.component.ComponentLocator] (main:null) > Problems with running checker:DatabaseUpgradeChecker > com.cloud.utils.exception.CloudRuntimeException: The end upgrade version is > actually at 4.0.0 but our management server code version is at > 4.0.59.20120908055459 > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:193) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:351) > at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) > at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) > at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) > at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) > at > org.apache.catalina.core.StandardContext.start(Stand
[jira] [Updated] (CLOUDSTACK-90) Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !!
[ https://issues.apache.org/jira/browse/CLOUDSTACK-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-90: - Assignee: edison su > Upgrade from CloudStack 3.0.2 to ASF 4.0 Failed !! > -- > > Key: CLOUDSTACK-90 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-90 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 > Environment: Management Sever : Rhel 6.2 > CloudStack 3.0.2 Build : CloudStack-3.0.2-1-rhel6.2.tar.gz > [Git Revision: 26c4eade7f9970efd8eee76bdeb9f678c2d544e4 > Git URL: ssh://hud...@git.cloud.com/var/lib/git/cloudstack-oss] > ASF 4.0 Build : CloudStack-oss-4.0.59-rhel6.3.tar.gz > [Git Revision: 03df2fa9dd45c938f72cd1866044b09d1b0cc978 > Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git] >Reporter: Abhinav Roy >Assignee: edison su >Priority: Blocker > Fix For: pre-4.0.0 > > > Steps : > === > 1. Install CloudStack 3.0.2 on Rhel 6.2 and deploy Advanced zone config. > 2. Create a VM instance. > 3. Stop the management server. > 4. Take DB backup. > 5. Upgrade to ASF 4.0 > 6. Start the management server . > Expected Behaviour > > The upgrade should be successful. > Observed Behaviour > > The upgrade failed with the following errors : > 2012-09-13 16:06:48,238 DEBUG [cloud.upgrade.DatabaseIntegrityChecker] > (main:null) No duplicate hosts with the same local storage found in database > 2012-09-13 16:06:48,243 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,399 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Grabbing lock to check for database upgrade. > 2012-09-13 16:06:48,401 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) > Checking to see if the database is at a version before it was the version > table is created > 2012-09-13 16:06:48,406 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) DB version = 3.0.2.20120506222956 Code Version = > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 INFO [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) Database upgrade must be performed from 3.0.2.20120506222956 to > 4.0.59.20120908055459 > 2012-09-13 16:06:48,407 ERROR [cloud.upgrade.DatabaseUpgradeChecker] > (main:null) The end upgrade version is actually at 4.0.0 but our management > server code version is at 4.0.59.20120908055459 > 2012-09-13 16:06:48,411 ERROR [utils.component.ComponentLocator] (main:null) > Problems with running checker:DatabaseUpgradeChecker > com.cloud.utils.exception.CloudRuntimeException: The end upgrade version is > actually at 4.0.0 but our management server code version is at > 4.0.59.20120908055459 > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:193) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:351) > at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) > at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) > at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) > at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) > at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) > at org.apache.catalina.startup.HostConfi
[jira] [Updated] (CLOUDSTACK-93) Management server failed start with java.sql.SQLException:No suitable driver found for jdbc:mysql:
[ https://issues.apache.org/jira/browse/CLOUDSTACK-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-93: - Assignee: Wido den Hollander > Management server failed start with java.sql.SQLException:No suitable driver > found for jdbc:mysql: > -- > > Key: CLOUDSTACK-93 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-93 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 >Reporter: Sailaja Mada >Assignee: Wido den Hollander >Priority: Critical > Fix For: pre-4.0.0 > > Attachments: management-server.log > > > Setup : RHEL 6.3 Management Server Platform , > Build : Tried with below builds : > 1. > http://jenkins.cloudstack.org/job/build-cloudstack-4.0-rhel6.3/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.12-rhel6.3.tar.gz > > 2. > http://jenkins.cloudstack.org/job/build-cloudstack-4.0/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.69-rhel6.3.tar.gz > Steps: > 1. Install Management server > 2. Install DB > 3. Set password to DB root user > 4. Setup DB with cloud-setup-databases > 5. Setup Cloud Management > Verify the log for the management server status: Management server failed > start > 2012-09-13 16:37:31,980 INFO [utils.component.ComponentLocator] (main:null) > Adding system integrity checker: DatabaseUpgradeChecker > 2012-09-13 16:37:32,059 DEBUG [utils.crypt.EncryptionSecretKeyChecker] > (main:null) Encryption Type: file > 2012-09-13 16:37:32,208 INFO [cloud.upgrade.DatabaseIntegrityChecker] > (main:null) Grabbing lock to check for database integrity. > 2012-09-13 16:37:32,342 ERROR [db.Transaction.Transaction] (main:null) > Unexpected exception: > java.sql.SQLException: No suitable driver found for > jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true > at java.sql.DriverManager.getConnection(DriverManager.java:640) > at java.sql.DriverManager.getConnection(DriverManager.java:200) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:840) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) > at > com.cloud.utils.db.Transaction.getStandaloneConnectionWithException(Transaction.java:199) > at > com.cloud.utils.db.Transaction.getStandaloneConnection(Transaction.java:208) > at > com.cloud.utils.db.DbUtil.getConnectionForGlobalLocks(DbUtil.java:58) > at com.cloud.utils.db.DbUtil.getGlobalLock(DbUtil.java:203) > at com.cloud.utils.db.GlobalLock.lock(GlobalLock.java:151) > at > com.cloud.upgrade.DatabaseIntegrityChecker.check(DatabaseIntegrityChecker.java:228) > at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) > at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) > at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) > at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) > at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) >
[jira] [Commented] (CLOUDSTACK-93) Management server failed start with java.sql.SQLException:No suitable driver found for jdbc:mysql:
[ https://issues.apache.org/jira/browse/CLOUDSTACK-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454845#comment-13454845 ] Wido den Hollander commented on CLOUDSTACK-93: -- I just downloaded the same build as Ahmad Saif did and checked. The problem lies in /etc/cloud/management/classpath.conf It looks for /usr/share/java/mysql-connector-java-5.1.21.jar, but that one isn't present. I think we should add "mysql-connector-java.jar" to the "common" JARs in wscript_configure since both the Ubuntu and CentOS packages symlink /usr/share/java/mysql-connector-java.jar to the installed connector. The version doesn't really bother that much I think. > Management server failed start with java.sql.SQLException:No suitable driver > found for jdbc:mysql: > -- > > Key: CLOUDSTACK-93 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-93 > Project: CloudStack > Issue Type: Bug > Components: Install and Setup >Affects Versions: pre-4.0.0 >Reporter: Sailaja Mada >Priority: Critical > Attachments: management-server.log > > > Setup : RHEL 6.3 Management Server Platform , > Build : Tried with below builds : > 1. > http://jenkins.cloudstack.org/job/build-cloudstack-4.0-rhel6.3/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.12-rhel6.3.tar.gz > > 2. > http://jenkins.cloudstack.org/job/build-cloudstack-4.0/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.69-rhel6.3.tar.gz > Steps: > 1. Install Management server > 2. Install DB > 3. Set password to DB root user > 4. Setup DB with cloud-setup-databases > 5. Setup Cloud Management > Verify the log for the management server status: Management server failed > start > 2012-09-13 16:37:31,980 INFO [utils.component.ComponentLocator] (main:null) > Adding system integrity checker: DatabaseUpgradeChecker > 2012-09-13 16:37:32,059 DEBUG [utils.crypt.EncryptionSecretKeyChecker] > (main:null) Encryption Type: file > 2012-09-13 16:37:32,208 INFO [cloud.upgrade.DatabaseIntegrityChecker] > (main:null) Grabbing lock to check for database integrity. > 2012-09-13 16:37:32,342 ERROR [db.Transaction.Transaction] (main:null) > Unexpected exception: > java.sql.SQLException: No suitable driver found for > jdbc:mysql://localhost:3306/cloud?autoReconnect=true&prepStmtCacheSize=517&cachePrepStmts=true > at java.sql.DriverManager.getConnection(DriverManager.java:640) > at java.sql.DriverManager.getConnection(DriverManager.java:200) > at > org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:48) > at > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290) > at > org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:840) > at > org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) > at > com.cloud.utils.db.Transaction.getStandaloneConnectionWithException(Transaction.java:199) > at > com.cloud.utils.db.Transaction.getStandaloneConnection(Transaction.java:208) > at > com.cloud.utils.db.DbUtil.getConnectionForGlobalLocks(DbUtil.java:58) > at com.cloud.utils.db.DbUtil.getGlobalLock(DbUtil.java:203) > at com.cloud.utils.db.GlobalLock.lock(GlobalLock.java:151) > at > com.cloud.upgrade.DatabaseIntegrityChecker.check(DatabaseIntegrityChecker.java:228) > at > com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) > at > com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) > at > com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) > at > com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) > at > com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) > at > com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) > at javax.servlet.GenericServlet.init(GenericServlet.java:212) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) >
[jira] [Commented] (CLOUDSTACK-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13454143#comment-13454143 ] Wido den Hollander commented on CLOUDSTACK-81: -- The init scripts have been fixed in commit:359d5acda4a49c558afee89500919707105bb507 I verified it works under Ubuntu 12.04 and it should work on RHEL/CentOS 6.3 as well, but I'd like conformation before marking this one resolved. > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > Fix For: pre-4.0.0 > > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >
[jira] [Commented] (CLOUDSTACK-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453881#comment-13453881 ] Wido den Hollander commented on CLOUDSTACK-81: -- The usage server doesn't use JSVC yet. I'll update the init script and fix the usage server. cloud-daemonize is NO longer in use and required. It should be removed for the 4.0 release. > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] -- This message is automatically generated by JI
[jira] [Updated] (CLOUDSTACK-81) fail to start cloud-usage service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wido den Hollander updated CLOUDSTACK-81: - Assignee: Wido den Hollander > fail to start cloud-usage service > - > > Key: CLOUDSTACK-81 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-81 > Project: CloudStack > Issue Type: Bug > Components: Usage >Affects Versions: pre-4.0.0 > Environment: build :CloudStack-oss-4.0.59-rhel6.3.tar.gz >Reporter: sadhu suresh >Assignee: Wido den Hollander >Priority: Blocker > > steps: > 1.Install new build on rhel6.3 > 2.install the usage server > 3.start the cloud-usage service > actual result: > Installation of cloud-usage server was successful but fail to start > :cloud-usage service fail to start and it shows the following error when we > try to start > root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] > cloud-usage server installation requires additional rpm and installed > additional rpm nd installed > fter installing the jsvc package installation usage server was successful: > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-tmp.pGKPCJ: Header V3 RSA/SHA256 Signature, key ID > c105b9de: NOKEY > Preparing... ### [100%] >1:jakarta-commons-daemon-### [100%] > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# ./install.sh > Setting up the temporary repository... > Cleaning Yum cache... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > Cleaning repos: cloud-temp rhel > 2 metadata files removed > Welcome to the Cloud.com CloudStack Installer. What would you like to do? > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > D) Install the database server > U) Upgrade the CloudStack packages installed on this computer > R) Stop any running CloudStack services and remove the CloudStack > packages from this computer > Q) Quit > > s > Installing the Usage Server... > Loaded plugins: product-id, subscription-manager > Updating certificate-based repositories. > Unable to read consumer identity > cloud-temp | 2.6 kB 00:00 ... > rhel | 4.0 kB 00:00 ... > Setting up Install Process > No package cloud-premium available. > Resolving Dependencies > --> Running transaction check > ---> Package cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > > Package Arch Version Repository Size > > Installing: > cloud-usage x86_64 4.0.59-0.59.el6.4.0 cloud-temp 81 k > Transaction Summary > > Install 1 Package(s) > Total download size: 81 k > Installed size: 87 k > Is this ok [y/N]: y > Downloading Packages: > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Warning: RPMDB altered outside of yum. > Installing : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed products updated. > Verifying : cloud-usage-4.0.59-0.59.el6.4.0.x86_64 1/1 > Installed: > cloud-usage.x86_64 0:4.0.59-0.59.el6.4.0 > Complete! > CloudStack Management Server setup is Done! > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-management status > cloud-management (pid 2984) is running... > [root@rhel63 CloudStack-oss-4.0.59-rhel6.3]# service cloud-usage start > Starting CloudStack Usage Monitor: /bin/bash: /usr/bin/cloud-daemonize: No > such file or directory >[FAILED] -- 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
