[jira] [Closed] (CLOUDSTACK-9978) Kernel security update for CVE-2017-1000364 breaks cloudstack startup scripts with jsvc on Ubuntu 14.04 or 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9978. Resolution: Not A Problem Fixed into last kernel > Kernel security update for CVE-2017-1000364 breaks cloudstack startup scripts > with jsvc on Ubuntu 14.04 or 16.04 > > > Key: CLOUDSTACK-9978 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9978 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: cloudstack-agent, Management Server >Affects Versions: 4.10.0.0, 4.9.2.0 > Environment: Ubuntu 14.04 or Ubuntu 16.04 >Reporter: Milamber >Priority: Blocker > Fix For: Future > > > cloudstack-management or cloudstack-agent services won't start > The error message is : "jsvc.exec error: Service killed by signal 11" > This is a 'bug' from the last kernel update (~2017/06/20). > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865311 > Workarounds (for 4.9 or 4.10): > Revert the last kernel update or add -Xss1280k option into the startup > scripts (after the -Xmx option for example) > Diff for fix this issue on 4.9 cloudstack-agent script=== > # diff cloudstack-agent_orig cloudstack-agent > 103c103 > < if start_daemon -p $PIDFILE $DAEMON -Djava.io.tmpdir="$TMP" -Xms256m > -Xmx2048m -cp "$CLASSPATH" -Djna.nosys=true -pidfile "$PIDFILE" -errfile > SYSLOG $CLASS > --- > > if start_daemon -p $PIDFILE $DAEMON -Djava.io.tmpdir="$TMP" -Xms256m > > -Xmx2048m -Xss1280k -cp "$CLASSPATH" -Djna.nosys=true -pidfile "$PIDFILE" > > -errfile SYSLOG $CLASS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-9978) Kernel security update for CVE-2017-1000364 breaks cloudstack startup scripts with jsvc on Ubuntu 14.04 or 16.04
Milamber created CLOUDSTACK-9978: Summary: Kernel security update for CVE-2017-1000364 breaks cloudstack startup scripts with jsvc on Ubuntu 14.04 or 16.04 Key: CLOUDSTACK-9978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9978 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: cloudstack-agent, Management Server Affects Versions: 4.10.0.0, 4.9.2.0 Environment: Ubuntu 14.04 or Ubuntu 16.04 Reporter: Milamber Priority: Blocker Fix For: Future cloudstack-management or cloudstack-agent services won't start The error message is : "jsvc.exec error: Service killed by signal 11" This is a 'bug' from the last kernel update (~2017/06/20). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865311 Workarounds (for 4.9 or 4.10): Revert the last kernel update or add -Xss1280k option into the startup scripts (after the -Xmx option for example) Diff for fix this issue on 4.9 cloudstack-agent script=== # diff cloudstack-agent_orig cloudstack-agent 103c103 < if start_daemon -p $PIDFILE $DAEMON -Djava.io.tmpdir="$TMP" -Xms256m -Xmx2048m -cp "$CLASSPATH" -Djna.nosys=true -pidfile "$PIDFILE" -errfile SYSLOG $CLASS --- > if start_daemon -p $PIDFILE $DAEMON -Djava.io.tmpdir="$TMP" -Xms256m > -Xmx2048m -Xss1280k -cp "$CLASSPATH" -Djna.nosys=true -pidfile "$PIDFILE" > -errfile SYSLOG $CLASS -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (CLOUDSTACK-9770) Virtual router / Network regression since 4.9.1.0 with public interface eth2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9770. Resolution: Fixed Fix Version/s: 4.10.0.0 > Virtual router / Network regression since 4.9.1.0 with public interface eth2 > > > Key: CLOUDSTACK-9770 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9770 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0, 4.9.2.0, 4.9.1.0 > Environment: CloudStack with advanced network installation >Reporter: Milamber >Priority: Critical > Labels: regresion > Fix For: Future, 4.10.0.0 > > > I found a (possible) bug introduce by CLOUDSTACK-9339 [1] (Pull Request > PR1659 [2]) on CloudStack Advanced network installation. > Since this changes (9339), the public network's route on eth2 (public > interface) in VR is missing. > Before on VR, we have sometimes like: > ip route show table Table_eth2 > 212.217.2.0/24 dev eth2 table Table_eth2 scope link > default via 212.217.2.1 dev eth2 > ... > where 212.217.2.0/24 is the public network and 212.217.2.1 the default > gateway. > After with 4.9.1.0+ the ip route command shows only: > default via 212.217.2.1 dev eth2 proto static > throw 10.230.1.0/24 proto static > throw 169.254.0.0/16 proto static > (missing route for public network) > The changes 9339 introduce the iptables connmark to add 0x2 mark on ip > packets from internal VMs IP and an ip rule to use the Table_eth2 network > table for these ip packets. > So if another machine into the public network try to reach a virtual machine > inside CloudStack using their public IP, the packets's travel is: > source_machine--> VR (de-NAT) --> VM_inside_CS --> VR (NAT+using Table_eth2) > --> default_public_gateway --> source machine > The issue is if the default_public_gateway refuse to forward IP packets with > the source IP and destination IP in the same network (often when the gateway > is a firewall), then the connection between a machine into public network is > not possible with all VM behind the CS virtual router. > The correct network path for the packet must be: > source_machine--> VR (de-nat) --> VM_inside_CS --> VR (NAT+using Table_eth2) > --> source machine (directly because on public network) > To fix the issue (workaround), just execute this command on the virtual > router: > ip route add dev eth2 table Table_eth2212.217.2.0/24 > Please note: this issue isn't visible on CloudStack upgrade installation from > anterior version of 4.9.1.0+ until you decide to restart with clean up the > network in CS. > What is the best way to fix this bug? > Thanks > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > [2] https://github.com/apache/cloudstack/pull/1659 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9770) Virtual router / Network regression since 4.9.1.0 with public interface eth2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15851679#comment-15851679 ] Milamber commented on CLOUDSTACK-9770: -- Thanks Wei, I try this patch with success, now route for the table Table_eth2 include the public network's route: root@r-101-VM:~# ip route show table Table_eth2 default via 212.217.8.1 dev eth2 proto static throw 10.46.46.0/24 proto static throw 169.254.0.0/16 proto static 212.217.8.0/21 dev eth2 scope link Wei can you open the PR in Github? Or if you prefer I can do the PR. With the PR, Jenkins/Marvin/Travis tests will runs to check this changes. > Virtual router / Network regression since 4.9.1.0 with public interface eth2 > > > Key: CLOUDSTACK-9770 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9770 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.10.0.0, 4.9.2.0, 4.9.1.0 > Environment: CloudStack with advanced network installation >Reporter: Milamber >Priority: Critical > Labels: regresion > Fix For: Future > > > I found a (possible) bug introduce by CLOUDSTACK-9339 [1] (Pull Request > PR1659 [2]) on CloudStack Advanced network installation. > Since this changes (9339), the public network's route on eth2 (public > interface) in VR is missing. > Before on VR, we have sometimes like: > ip route show table Table_eth2 > 212.217.2.0/24 dev eth2 table Table_eth2 scope link > default via 212.217.2.1 dev eth2 > ... > where 212.217.2.0/24 is the public network and 212.217.2.1 the default > gateway. > After with 4.9.1.0+ the ip route command shows only: > default via 212.217.2.1 dev eth2 proto static > throw 10.230.1.0/24 proto static > throw 169.254.0.0/16 proto static > (missing route for public network) > The changes 9339 introduce the iptables connmark to add 0x2 mark on ip > packets from internal VMs IP and an ip rule to use the Table_eth2 network > table for these ip packets. > So if another machine into the public network try to reach a virtual machine > inside CloudStack using their public IP, the packets's travel is: > source_machine--> VR (de-NAT) --> VM_inside_CS --> VR (NAT+using Table_eth2) > --> default_public_gateway --> source machine > The issue is if the default_public_gateway refuse to forward IP packets with > the source IP and destination IP in the same network (often when the gateway > is a firewall), then the connection between a machine into public network is > not possible with all VM behind the CS virtual router. > The correct network path for the packet must be: > source_machine--> VR (de-nat) --> VM_inside_CS --> VR (NAT+using Table_eth2) > --> source machine (directly because on public network) > To fix the issue (workaround), just execute this command on the virtual > router: > ip route add dev eth2 table Table_eth2212.217.2.0/24 > Please note: this issue isn't visible on CloudStack upgrade installation from > anterior version of 4.9.1.0+ until you decide to restart with clean up the > network in CS. > What is the best way to fix this bug? > Thanks > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > [2] https://github.com/apache/cloudstack/pull/1659 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850330#comment-15850330 ] Milamber edited comment on CLOUDSTACK-9339 at 2/2/17 7:01 PM: -- Possible regression found with this change. See: https://issues.apache.org/jira/browse/CLOUDSTACK-9770 was (Author: milamber): Possible regression found with this change. > Virtual Routers don't handle Multiple Public Interfaces > --- > > Key: CLOUDSTACK-9339 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 >Reporter: dsclose >Assignee: Murali Reddy > Labels: firewall, nat, router > Fix For: 4.10.0.0, 4.9.1.0 > > > There are a series of issues with the way Virtual Routers manage multiple > public interfaces. These are more pronounced on redundant virtual router > setups. I have not attempted to examine these issues in a VPC context. > Outside of a VPC context, however, the following is expected behaviour: > * eth0 connects the router to the guest network. > * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on > eth0. > * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue > commands to the router. > * eth2 is the routers public interface. By default, a single public IP will > be setup on eth2 along with the necessary iptables and ip rules to source-NAT > guest traffic to that public IP. > * When a public IP address is assigned to the router that is on a separate > subnet to the source-NAT IP, a new interface is configured, such as eth3, and > the IP is assigned to that interface. > * This can result in eth3, eth4, eth5, etc. being created depending upon how > many public subnets the router has to work with. > The above all works. The following, however, is currently not working: > * Public interfaces should be set to DOWN on backup redundant routers. The > master.py script is responsible for setting public interfaces to UP during a > keepalived transition. Currently the check_is_up method of the CsIP class > brings all interfaces UP on both RvR. A proposed fix for this has been > discussed on the mailing list. That fix will leave public interfaces DOWN on > RvR allowing the keepalived transition to control the state of public > interfaces. Issue #1413 includes a commit that contradicts the proposed fix > so it is unclear what the current state of the code should be. > * Newly created interfaces should be set to UP on master redundant routers. > Assuming public interfaces should be default be DOWN on an RvR we need to > accommodate the fact that, as interfaces are created, no keepalived > transition occurs. This means that assigning an IP from a new public subnet > will have no effect (as the interface will be down) until the network is > restarted with a "clean up." > * Public interfaces other than eth2 do not forward traffic. There are two > iptables rules in the FORWARD chain of the filter table created for eth2 that > allow forwarding between eth2 and eth0. Equivalent rules are not created for > other public interfaces so forwarded traffic is dropped. > * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, > outbound traffic is source-NAT'd to the networks default source-NAT IP. New > connections from guests that are destined for public networks are processed > like so: > 1. Traffic is matched against the following rule in the mangle table that > marks the connection with a 0x0: > *mangle > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > 2. There are no "ip rule" statements that match a connection marked 0x0, so > the kernel routes the connection via the default gateway. That gateway is on > source-NAT subnet, so the connection is routed out of eth2. > 3. The following iptables rules are then matched in the filter table: > *filter > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A FW_OUTBOUND -j FW_EGRESS_RULES > -A FW_EGRESS_RULES -j ACCEPT > 4. Finally, the following rule is matched from the nat table, where the IP > address is the source-NAT IP: > *nat > -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67 > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15850330#comment-15850330 ] Milamber commented on CLOUDSTACK-9339: -- Possible regression found with this change. > Virtual Routers don't handle Multiple Public Interfaces > --- > > Key: CLOUDSTACK-9339 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 >Reporter: dsclose >Assignee: Murali Reddy > Labels: firewall, nat, router > Fix For: 4.10.0.0, 4.9.1.0 > > > There are a series of issues with the way Virtual Routers manage multiple > public interfaces. These are more pronounced on redundant virtual router > setups. I have not attempted to examine these issues in a VPC context. > Outside of a VPC context, however, the following is expected behaviour: > * eth0 connects the router to the guest network. > * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on > eth0. > * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue > commands to the router. > * eth2 is the routers public interface. By default, a single public IP will > be setup on eth2 along with the necessary iptables and ip rules to source-NAT > guest traffic to that public IP. > * When a public IP address is assigned to the router that is on a separate > subnet to the source-NAT IP, a new interface is configured, such as eth3, and > the IP is assigned to that interface. > * This can result in eth3, eth4, eth5, etc. being created depending upon how > many public subnets the router has to work with. > The above all works. The following, however, is currently not working: > * Public interfaces should be set to DOWN on backup redundant routers. The > master.py script is responsible for setting public interfaces to UP during a > keepalived transition. Currently the check_is_up method of the CsIP class > brings all interfaces UP on both RvR. A proposed fix for this has been > discussed on the mailing list. That fix will leave public interfaces DOWN on > RvR allowing the keepalived transition to control the state of public > interfaces. Issue #1413 includes a commit that contradicts the proposed fix > so it is unclear what the current state of the code should be. > * Newly created interfaces should be set to UP on master redundant routers. > Assuming public interfaces should be default be DOWN on an RvR we need to > accommodate the fact that, as interfaces are created, no keepalived > transition occurs. This means that assigning an IP from a new public subnet > will have no effect (as the interface will be down) until the network is > restarted with a "clean up." > * Public interfaces other than eth2 do not forward traffic. There are two > iptables rules in the FORWARD chain of the filter table created for eth2 that > allow forwarding between eth2 and eth0. Equivalent rules are not created for > other public interfaces so forwarded traffic is dropped. > * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, > outbound traffic is source-NAT'd to the networks default source-NAT IP. New > connections from guests that are destined for public networks are processed > like so: > 1. Traffic is matched against the following rule in the mangle table that > marks the connection with a 0x0: > *mangle > -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark > 0x0/0x > 2. There are no "ip rule" statements that match a connection marked 0x0, so > the kernel routes the connection via the default gateway. That gateway is on > source-NAT subnet, so the connection is routed out of eth2. > 3. The following iptables rules are then matched in the filter table: > *filter > -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND > -A FW_OUTBOUND -j FW_EGRESS_RULES > -A FW_EGRESS_RULES -j ACCEPT > 4. Finally, the following rule is matched from the nat table, where the IP > address is the source-NAT IP: > *nat > -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67 > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9770) Virtual router / Network regression since 4.9.1.0 with public interface eth2
Milamber created CLOUDSTACK-9770: Summary: Virtual router / Network regression since 4.9.1.0 with public interface eth2 Key: CLOUDSTACK-9770 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9770 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.10.0.0, 4.9.2.0, 4.9.1.0 Environment: CloudStack with advanced network installation Reporter: Milamber Priority: Critical Fix For: Future I found a (possible) bug introduce by CLOUDSTACK-9339 [1] (Pull Request PR1659 [2]) on CloudStack Advanced network installation. Since this changes (9339), the public network's route on eth2 (public interface) in VR is missing. Before on VR, we have sometimes like: ip route show table Table_eth2 212.217.2.0/24 dev eth2 table Table_eth2 scope link default via 212.217.2.1 dev eth2 ... where 212.217.2.0/24 is the public network and 212.217.2.1 the default gateway. After with 4.9.1.0+ the ip route command shows only: default via 212.217.2.1 dev eth2 proto static throw 10.230.1.0/24 proto static throw 169.254.0.0/16 proto static (missing route for public network) The changes 9339 introduce the iptables connmark to add 0x2 mark on ip packets from internal VMs IP and an ip rule to use the Table_eth2 network table for these ip packets. So if another machine into the public network try to reach a virtual machine inside CloudStack using their public IP, the packets's travel is: source_machine--> VR (de-NAT) --> VM_inside_CS --> VR (NAT+using Table_eth2) --> default_public_gateway --> source machine The issue is if the default_public_gateway refuse to forward IP packets with the source IP and destination IP in the same network (often when the gateway is a firewall), then the connection between a machine into public network is not possible with all VM behind the CS virtual router. The correct network path for the packet must be: source_machine--> VR (de-nat) --> VM_inside_CS --> VR (NAT+using Table_eth2) --> source machine (directly because on public network) To fix the issue (workaround), just execute this command on the virtual router: ip route add dev eth2 table Table_eth2212.217.2.0/24 Please note: this issue isn't visible on CloudStack upgrade installation from anterior version of 4.9.1.0+ until you decide to restart with clean up the network in CS. What is the best way to fix this bug? Thanks [1] https://issues.apache.org/jira/browse/CLOUDSTACK-9339 [2] https://github.com/apache/cloudstack/pull/1659 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9753) Update L10N resource files with 4.10 strings from Transifex (20170121)
Milamber created CLOUDSTACK-9753: Summary: Update L10N resource files with 4.10 strings from Transifex (20170121) Key: CLOUDSTACK-9753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9753 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.10.0.0 Reporter: Milamber Assignee: Milamber Priority: Minor Fix For: 4.10.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9736) Incoherent validation and error message when you change the vm.password.length configuration parameter
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822754#comment-15822754
]
Milamber commented on CLOUDSTACK-9736:
--
Sorry I forgot to mention that the error message occurred with cloudmonkey when
I run this command:
update configuration name="vm.password.length" value="8"
> Incoherent validation and error message when you change the
> vm.password.length configuration parameter
> --
>
> Key: CLOUDSTACK-9736
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9736
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.7.0, 4.8.0, 4.9.0, 4.10.0.0
>Reporter: Milamber
>Assignee: Milamber
>Priority: Minor
> Fix For: 4.10.0.0
>
>
> When you try to change the value of vm.password.length parameters, if the
> value is < 10 the error message says:
> "Please enter a value greater than 6 for the configuration parameter"
> In the code server/src/com/cloud/configuration/ConfigurationManagerImpl.java
> the validation use 10 as length and the message says 6 for length:
> if ("vm.password.length".equalsIgnoreCase(name) && val < 10) {
> throw new InvalidParameterValueException("Please enter a
> value greater than 6 for the configuration parameter:" + name);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9736) Incoherent validation and error message when you change the vm.password.length configuration parameter
Milamber created CLOUDSTACK-9736:
Summary: Incoherent validation and error message when you change
the vm.password.length configuration parameter
Key: CLOUDSTACK-9736
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9736
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.9.0, 4.8.0, 4.7.0, 4.10.0.0
Reporter: Milamber
Assignee: Milamber
Priority: Minor
Fix For: 4.10.0.0
When you try to change the value of vm.password.length parameters, if the value
is < 10 the error message says:
"Please enter a value greater than 6 for the configuration parameter"
In the code server/src/com/cloud/configuration/ConfigurationManagerImpl.java
the validation use 10 as length and the message says 6 for length:
if ("vm.password.length".equalsIgnoreCase(name) && val < 10) {
throw new InvalidParameterValueException("Please enter a
value greater than 6 for the configuration parameter:" + name);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9513) Migrate transifex workflow and format to json
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9513. Resolution: Fixed Fix Version/s: (was: Future) The work is done. > Migrate transifex workflow and format to json > - > > Key: CLOUDSTACK-9513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9513 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0 > > > With the changes introduced by the PR > https://github.com/apache/cloudstack/pull/1669 we no longer need > messages.properties format. Therefore, we can migrate Transifex workflow to > the json format. /cc [~milamber] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9732) Update L10N resource files with 4.9 strings from Transifex (20170106)
Milamber created CLOUDSTACK-9732: Summary: Update L10N resource files with 4.9 strings from Transifex (20170106) Key: CLOUDSTACK-9732 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9732 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.9.0, 4.9.2.0, 4.9.1.0 Reporter: Milamber Priority: Minor Fix For: Future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9671) Unknown column 'image_store_details.display' in 'field list' when upgrade from 4.9.1.0 to 4.10.0.0 SNAPSHOT
Milamber created CLOUDSTACK-9671: Summary: Unknown column 'image_store_details.display' in 'field list' when upgrade from 4.9.1.0 to 4.10.0.0 SNAPSHOT Key: CLOUDSTACK-9671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9671 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.1.0 Reporter: Milamber When I try to upgrade CloudStack from 4.9.1.0 to 4.10.0.0-SNAPSHOT, I've this error: 2016-12-13 11:43:28,367 ERROR [c.c.a.m.AgentManagerImpl] (AgentConnectTaskPool-5:ctx-bce6aee5) (logid:7c5e9164) Monitor SecondaryStorageListener says there is an error in the connect process for 4 due to DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@3f5ef58a: SELECT image_store_details.id, image_store_details.store_id, image_store_details.name, image_store_details.value, image_store_details.display FROM image_store_details WHERE image_store_details.store_id = 1 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@3f5ef58a: SELECT image_store_details.id, image_store_details.store_id, image_store_details.name, image_store_details.value, image_store_details.display FROM image_store_details WHERE image_store_details.store_id = 1 at com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427) at com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:363) at com.cloud.utils.db.GenericDaoBase.listIncludingRemovedBy(GenericDaoBase.java:933) at com.cloud.utils.db.GenericDaoBase.listBy(GenericDaoBase.java:910) at com.cloud.utils.db.GenericDaoBase.listBy(GenericDaoBase.java:923) at org.apache.cloudstack.storage.datastore.db.ImageStoreDetailsDaoImpl.getDetails(ImageStoreDetailsDaoImpl.java:70) 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:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy182.getDetails(Unknown Source) at org.apache.cloudstack.storage.image.NfsImageStoreDriverImpl.getNfsVersion(NfsImageStoreDriverImpl.java:40) at org.apache.cloudstack.storage.datastore.driver.CloudStackImageStoreDriverImpl.getStoreTO(CloudStackImageStoreDriverImpl.java:63) at org.apache.cloudstack.storage.image.store.ImageStoreImpl.getTO(ImageStoreImpl.java:185) at org.apache.cloudstack.secondarystorage.SecondaryStorageManagerImpl.generateSetupCommand(SecondaryStorageManagerImpl.java:305) at com.cloud.storage.secondary.SecondaryStorageListener.processConnect(SecondaryStorageListener.java:85) at com.cloud.agent.manager.AgentManagerImpl.notifyMonitorsOfConnection(AgentManagerImpl.java:564) at com.cloud.agent.manager.AgentManagerImpl.handleConnectedAgent(AgentManagerImpl.java:1087) at com.cloud.agent.manager.AgentManagerImpl.access$000(AgentManagerImpl.java:120) at com.cloud.agent.manager.AgentManagerImpl$HandleAgentConnectTask.runInContext(AgentManagerImpl.java:1171) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at
[jira] [Closed] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9621. Resolution: Fixed Thanks Rohit. > Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0 > -- > > Key: CLOUDSTACK-9621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.10.0.0 >Reporter: Milamber >Priority: Minor > Labels: easytest > Fix For: 4.10.0.0 > > > Update the localization files (new format JSON) with the latest translation > files from Transifex CloudStack project. > See PR #1789 > https://github.com/apache/cloudstack/pull/1789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9622. Resolution: Fixed Thanks Rohit. > Localisation for 'Project' label on the top of Web UI > - > > Key: CLOUDSTACK-9622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Milamber >Assignee: Milamber >Priority: Trivial > Labels: easytest > Fix For: 4.10.0.0, 4.9.1.0 > > > The label "Project" isn't translate on the top of UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-9622: - Fix Version/s: (was: 4.9.2.0) 4.9.1.0 > Localisation for 'Project' label on the top of Web UI > - > > Key: CLOUDSTACK-9622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Milamber >Assignee: Milamber >Priority: Trivial > Labels: easytest > Fix For: 4.10.0.0, 4.9.1.0 > > > The label "Project" isn't translate on the top of UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-9622: - Fix Version/s: 4.9.2.0 > Localisation for 'Project' label on the top of Web UI > - > > Key: CLOUDSTACK-9622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Milamber >Assignee: Milamber >Priority: Trivial > Labels: easytest > Fix For: 4.10.0.0, 4.9.1.0 > > > The label "Project" isn't translate on the top of UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reassigned CLOUDSTACK-9622: Assignee: Milamber > Localisation for 'Project' label on the top of Web UI > - > > Key: CLOUDSTACK-9622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Milamber >Assignee: Milamber >Priority: Trivial > Labels: easytest > Fix For: 4.10.0.0 > > > The label "Project" isn't translate on the top of UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-9621: - Assignee: (was: Milamber) > Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0 > -- > > Key: CLOUDSTACK-9621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.10.0.0 >Reporter: Milamber >Priority: Minor > Labels: easytest > Fix For: 4.10.0.0 > > > Update the localization files (new format JSON) with the latest translation > files from Transifex CloudStack project. > See PR #1789 > https://github.com/apache/cloudstack/pull/1789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9622) Localisation for 'Project' label on the top of Web UI
Milamber created CLOUDSTACK-9622: Summary: Localisation for 'Project' label on the top of Web UI Key: CLOUDSTACK-9622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9622 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Milamber Priority: Trivial Fix For: 4.10.0.0 The label "Project" isn't translate on the top of UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reassigned CLOUDSTACK-9621: Assignee: Milamber > Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0 > -- > > Key: CLOUDSTACK-9621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.10.0.0 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: easytest > Fix For: 4.10.0.0 > > > Update the localization files (new format JSON) with the latest translation > files from Transifex CloudStack project. > See PR #1789 > https://github.com/apache/cloudstack/pull/1789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9621) Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0
Milamber created CLOUDSTACK-9621: Summary: Update L10N files from Transifex (2016-11-27) for the new release 4.10.0.0 Key: CLOUDSTACK-9621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9621 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.10.0.0 Reporter: Milamber Priority: Minor Fix For: 4.10.0.0 Update the localization files (new format JSON) with the latest translation files from Transifex CloudStack project. See PR #1789 https://github.com/apache/cloudstack/pull/1789 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15404411#comment-15404411 ] Milamber commented on CLOUDSTACK-6671: -- Copy/paste error sorry. > Failed to start instance VM java.lang.NullPointerException at > com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) > - > > Key: CLOUDSTACK-6671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 > 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.4.0 > Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 / > 20140516 >Reporter: Milamber >Assignee: Amogh Vasekar >Priority: Critical > Labels: KVM > Attachments: extract-management.log > > > Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). > SSVM, Console proxy and first virtual routeur are correctly created and UP. > 10 day ago, this issue isn't present. > In attachment, full log. > 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance > VM[User|i-2-5-VM] > java.lang.NullPointerException > at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) > at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15404410#comment-15404410 ] Milamber commented on CLOUDSTACK-9444: -- Patch from PR1621 https://github.com/apache/cloudstack/pull/1621 > ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during > migration from 4.7.1 to 4.9) > > > Key: CLOUDSTACK-9444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.7.1, 4.8.0, 4.8.1, 4.9.0 > Environment: Ubuntu 14.04 + KVM + CS 4.7.1 >Reporter: Milamber >Assignee: Milamber >Priority: Minor > Labels: patch > Fix For: 4.9.1 > > > The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the > last line of the db.properties file hasn't a EOL character, the first line of > your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the > last line: > example: > db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql > db.usage.driver=jdbc:mysql > db.simulator.driver=jdbc:mysql > And after the migration, the management service don't start correctly. > The error messages: > 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not > supported! > 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db > configuration, using defaults with 5 connections. Falling back on assumed > datasource on localhost:3306 using username:password=cloud:cloud. Please > check your configuration > com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not > supported! > [...] > 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db > connection > java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using > password: YES) > [...] > === > The workaround is to edit the /etc/cloudstack/management/db.properties file > and insert a line return before "db.cloud.driver=jdbc:mysql" > and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9444) ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9)
Milamber created CLOUDSTACK-9444: Summary: ERROR c.c.u.d.DriverLoader DB driver type null is not supported (during migration from 4.7.1 to 4.9) Key: CLOUDSTACK-9444 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9444 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.9.0, 4.8.0, 4.7.1, 4.8.1 Environment: Ubuntu 14.04 + KVM + CS 4.7.1 Reporter: Milamber Assignee: Milamber Priority: Minor Fix For: 4.9.1 The PR #1610 has been include with the latest CS 4.9.0, unfortunately if the last line of the db.properties file hasn't a EOL character, the first line of your patch from #1610 (db.cloud.driver=jdbc:mysql) will be concatenate to the last line: example: db.cloud.secondsBeforeRetryMaster=3600db.cloud.driver=jdbc:mysql db.usage.driver=jdbc:mysql db.simulator.driver=jdbc:mysql And after the migration, the management service don't start correctly. The error messages: 2016-07-31 15:05:10,684 ERROR c.c.u.d.DriverLoader DB driver type null is not supported! 2016-07-31 15:05:10,709 WARN c.c.u.d.T.Transaction Unable to load db configuration, using defaults with 5 connections. Falling back on assumed datasource on localhost:3306 using username:password=cloud:cloud. Please check your configuration com.cloud.utils.exception.CloudRuntimeException: DB driver type null is not supported! [...] 2016-07-31 15:05:10,979 ERROR c.c.u.d.Merovingian2 Unable to get a new db connection java.sql.SQLException: Access denied for user 'cloud'@'localhost' (using password: YES) [...] === The workaround is to edit the /etc/cloudstack/management/db.properties file and insert a line return before "db.cloud.driver=jdbc:mysql" and restart the cloudstack-management service -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15208995#comment-15208995 ] Milamber commented on CLOUDSTACK-9319: -- Related with CLOUDSTACK-9255 I think https://issues.apache.org/jira/browse/CLOUDSTACK-9255 > Timeout is not passed to virtual router operations consistently > --- > > Key: CLOUDSTACK-9319 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.8.0 > Environment: KVM + Ceph cloud, Ubuntu hosts. >Reporter: Aaron Brady >Priority: Trivial > > The timeout parameter is not passed down to `applyConfigToVR` inside > `VirtualRoutingResource` in all cases. > This timeout is worked out as 3 seconds per command or 120 seconds (whichever > is larger), but because it's not passed to the first invocation, the default > (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used. > In a recent upgrade of our Virtual Routers, the timeout was being hit and > increasing `router.aggregation.command.each.timeout` had no effect. I built a > custom 4.8 agent with the timeout increased to allow the upgrade to continue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-9255) Unable to start VM DomainRouter due to error in finalizeStart, not retrying
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milamber closed CLOUDSTACK-9255.
Resolution: Fixed
Assignee: Wilder Rodrigues
Fix Version/s: 4.9.0
4.7.2
> Unable to start VM DomainRouter due to error in finalizeStart, not retrying
> ---
>
> Key: CLOUDSTACK-9255
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9255
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.6.2, 4.8.0, 4.7.1
> Environment: Ubuntu 14.04.3
> KVM
> NFS (primary/secondary)
>Reporter: Milamber
>Assignee: Wilder Rodrigues
> Fix For: 4.7.2, 4.9.0
>
> Attachments: anon-rvr-2nd-after-20.log
>
>
> I've spent 3 days with the same issue : unable to restart with clean up a
> network (virtual router or redondant virtual router) if the network have at
> least 20 virtual machines.
> I've tested with CS 4.6.2, 4.7.0, 4.7.1RC1, 4.8.0RC1, same problem. I've used
> the system vm from apt-get.eu and last builds from jenkins.
> My tests are made with hosts/mgr on Ubuntu 14.04.3 / KVM / NFS
> primary/secondary.
> My test case (with ansible modules) :
> 1/ create a new network (normal or RVR)
> 2/ create 20 vms (same params, just the name is changes)
> wait the end of creation
> 3/ restart the network with clean up option
> 4/ wait the restart, after some minutes, an error message arrived : "Failed
> to restart network"
> The trace in management.log are:
> 2016-01-23 23:02:51,503 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-51:ctx-9ed51622 job-268/job-271) (logid:b9a521fa) Unable
> to complete AsyncJobVO {id:271, userId: 2, accountId: 2, instanceType: null,
> instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIAMnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AA5SZXN0YXJ0TmV0d29ya3QAP3JPMEFCWE55QUJGcVlYWmhMbXhoYm1jdVFtOXZiR1ZoYnMwZ2NvRFZuUHJ1QWdBQldnQUZkbUZzZFdWNGNBRXhw,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 146456419427, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Jan 23 22:56:00 CET 2016}, job origin:268
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Unable to start instance due to Unable to start
> VM[DomainRouter|r-50-VM] due to error in finalizeStart, not retrying
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1119)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4578)
> at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4734)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at
[jira] [Commented] (CLOUDSTACK-9255) Unable to start VM DomainRouter due to error in finalizeStart, not retrying
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15203319#comment-15203319
]
Milamber commented on CLOUDSTACK-9255:
--
This bug is fixed by the PR 1356 (has been merge in master, in 4.8 branch for
4.8.1, and 4.7 branch for 4.7.2)
https://github.com/apache/cloudstack/pull/1356
> Unable to start VM DomainRouter due to error in finalizeStart, not retrying
> ---
>
> Key: CLOUDSTACK-9255
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9255
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.6.2, 4.8.0, 4.7.1
> Environment: Ubuntu 14.04.3
> KVM
> NFS (primary/secondary)
>Reporter: Milamber
> Attachments: anon-rvr-2nd-after-20.log
>
>
> I've spent 3 days with the same issue : unable to restart with clean up a
> network (virtual router or redondant virtual router) if the network have at
> least 20 virtual machines.
> I've tested with CS 4.6.2, 4.7.0, 4.7.1RC1, 4.8.0RC1, same problem. I've used
> the system vm from apt-get.eu and last builds from jenkins.
> My tests are made with hosts/mgr on Ubuntu 14.04.3 / KVM / NFS
> primary/secondary.
> My test case (with ansible modules) :
> 1/ create a new network (normal or RVR)
> 2/ create 20 vms (same params, just the name is changes)
> wait the end of creation
> 3/ restart the network with clean up option
> 4/ wait the restart, after some minutes, an error message arrived : "Failed
> to restart network"
> The trace in management.log are:
> 2016-01-23 23:02:51,503 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-51:ctx-9ed51622 job-268/job-271) (logid:b9a521fa) Unable
> to complete AsyncJobVO {id:271, userId: 2, accountId: 2, instanceType: null,
> instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIAMnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AA5SZXN0YXJ0TmV0d29ya3QAP3JPMEFCWE55QUJGcVlYWmhMbXhoYm1jdVFtOXZiR1ZoYnMwZ2NvRFZuUHJ1QWdBQldnQUZkbUZzZFdWNGNBRXhw,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 146456419427, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Jan 23 22:56:00 CET 2016}, job origin:268
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Unable to start instance due to Unable to start
> VM[DomainRouter|r-50-VM] due to error in finalizeStart, not retrying
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1119)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4578)
> at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4734)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>
[jira] [Created] (CLOUDSTACK-9255) Unable to start VM DomainRouter due to error in finalizeStart, not retrying
Milamber created CLOUDSTACK-9255:
Summary: Unable to start VM DomainRouter due to error in
finalizeStart, not retrying
Key: CLOUDSTACK-9255
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9255
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Virtual Router
Affects Versions: 4.7.0, 4.6.2, 4.8.0, 4.7.1
Environment: Ubuntu 14.04.3
KVM
NFS (primary/secondary)
Reporter: Milamber
I've spent 3 days with the same issue : unable to restart with clean up a
network (virtual router or redondant virtual router) if the network have at
least 20 virtual machines.
I've tested with CS 4.6.2, 4.7.0, 4.7.1RC1, 4.8.0RC1, same problem. I've used
the system vm from apt-get.eu and last builds from jenkins.
My tests are made with hosts/mgr on Ubuntu 14.04.3 / KVM / NFS
primary/secondary.
My test case (with ansible modules) :
1/ create a new network (normal or RVR)
2/ create 20 vms (same params, just the name is changes)
wait the end of creation
3/ restart the network with clean up option
4/ wait the restart, after some minutes, an error message arrived : "Failed to
restart network"
The trace in management.log are:
2016-01-23 23:02:51,503 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-51:ctx-9ed51622 job-268/job-271) (logid:b9a521fa) Unable to
complete AsyncJobVO {id:271, userId: 2, accountId: 2, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIAMnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AA5SZXN0YXJ0TmV0d29ya3QAP3JPMEFCWE55QUJGcVlYWmhMbXhoYm1jdVFtOXZiR1ZoYnMwZ2NvRFZuUHJ1QWdBQldnQUZkbUZzZFdWNGNBRXhw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 146456419427, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Sat Jan 23 22:56:00 CET 2016}, job origin:268
com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
unreachable: Host 1: Unable to start instance due to Unable to start
VM[DomainRouter|r-50-VM] due to error in finalizeStart, not retrying
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1119)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4578)
at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4734)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: com.cloud.utils.exception.ExecutionException: Unable to start
VM[DomainRouter|r-50-VM] due to error in finalizeStart, not retrying
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1083)
at
[jira] [Updated] (CLOUDSTACK-9255) Unable to start VM DomainRouter due to error in finalizeStart, not retrying
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milamber updated CLOUDSTACK-9255:
-
Attachment: anon-rvr-2nd-after-20.log
The cloud.log of the RVR (master) before the kill
> Unable to start VM DomainRouter due to error in finalizeStart, not retrying
> ---
>
> Key: CLOUDSTACK-9255
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9255
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.6.2, 4.8.0, 4.7.1
> Environment: Ubuntu 14.04.3
> KVM
> NFS (primary/secondary)
>Reporter: Milamber
> Attachments: anon-rvr-2nd-after-20.log
>
>
> I've spent 3 days with the same issue : unable to restart with clean up a
> network (virtual router or redondant virtual router) if the network have at
> least 20 virtual machines.
> I've tested with CS 4.6.2, 4.7.0, 4.7.1RC1, 4.8.0RC1, same problem. I've used
> the system vm from apt-get.eu and last builds from jenkins.
> My tests are made with hosts/mgr on Ubuntu 14.04.3 / KVM / NFS
> primary/secondary.
> My test case (with ansible modules) :
> 1/ create a new network (normal or RVR)
> 2/ create 20 vms (same params, just the name is changes)
> wait the end of creation
> 3/ restart the network with clean up option
> 4/ wait the restart, after some minutes, an error message arrived : "Failed
> to restart network"
> The trace in management.log are:
> 2016-01-23 23:02:51,503 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-51:ctx-9ed51622 job-268/job-271) (logid:b9a521fa) Unable
> to complete AsyncJobVO {id:271, userId: 2, accountId: 2, instanceType: null,
> instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAACAAIAMnQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AA5SZXN0YXJ0TmV0d29ya3QAP3JPMEFCWE55QUJGcVlYWmhMbXhoYm1jdVFtOXZiR1ZoYnMwZ2NvRFZuUHJ1QWdBQldnQUZkbUZzZFdWNGNBRXhw,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 146456419427, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Sat Jan 23 22:56:00 CET 2016}, job origin:268
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Unable to start instance due to Unable to start
> VM[DomainRouter|r-50-VM] due to error in finalizeStart, not retrying
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1119)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4578)
> at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4734)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>
[jira] [Created] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
Milamber created CLOUDSTACK-9183: Summary: CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory Key: CLOUDSTACK-9183 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.7.0 Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS Reporter: Milamber On my 4.7.0 RC1 test environment, I've this warning message: 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory I don't find this bash script anywhere (on management node, host node and inside the VR) I find theses references to this script inside: public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java ExecutionResult result = _vrDeployer.executeInVR(routerIp, VRScripts.ROUTER_ALERTS, args); ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9183) CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15060011#comment-15060011 ] Milamber commented on CLOUDSTACK-9183: -- >From [~remibergsma] I see getRouterAlerts.sh in 4.6 but not in 4.7/master. Since I upgraded it still works for me somehow. Will need to investigate why that is. It looks like regression from 6477bd8ff7f982e10d0d20a97857262897dc05ed, PR 1084. > CS 4.7.0 bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or directory > --- > > Key: CLOUDSTACK-9183 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9183 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.7.0 > Environment: CloudStack 4.7.0 RC1, Ubuntu 14.04.3, KVM, NFS >Reporter: Milamber > Labels: kvm, systemvm > > On my 4.7.0 RC1 test environment, I've this warning message: > 2015-12-15 23:57:35,165 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-f1556e81) (logid:db80c3d4) Unable to get alerts > from router r-11-VM bash: /opt/cloud/bin/getRouterAlerts.sh: No such file or > directory > I don't find this bash script anywhere (on management node, host node and > inside the VR) > I find theses references to this script inside: > public static final String ROUTER_ALERTS = "getRouterAlerts.sh"; > ./core/src/com/cloud/agent/resource/virtualnetwork/VRScripts.java > ExecutionResult result = _vrDeployer.executeInVR(routerIp, > VRScripts.ROUTER_ALERTS, args); > ./core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058579#comment-15058579 ] Milamber commented on CLOUDSTACK-9170: -- Works fine in my installation (4.5.2 to 4.7.0RC1 / KVM) > Register template in UI does not show zones in dropdown listbox > --- > > Key: CLOUDSTACK-9170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.7.0 >Reporter: Remi Bergsma > Attachments: Screen Shot 2015-12-15 at 15.16.51.png > > > The only option listed is "All zones". No API call is done to query the zones. > Check screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9173) new Quota plugins: CPU Used column is CPU Free column
Milamber created CLOUDSTACK-9173: Summary: new Quota plugins: CPU Used column is CPU Free column Key: CLOUDSTACK-9173 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9173 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.7.0 Environment: CS 4.7.0 RC1 / Ubuntu 14/ KVM (CS inside CS) Reporter: Milamber Assignee: Rohit Yadav Attachments: Selection_242.png I thinks that the CPU stats column "Used" is in reality a "Free" column? In the screen shots, the cs-host2 node have 0 vm (normal or system) running inside, and the Used cell is red. Normal? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9173) new Quota plugins: CPU Used column is CPU Free column
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-9173: - Attachment: Selection_242.png > new Quota plugins: CPU Used column is CPU Free column > - > > Key: CLOUDSTACK-9173 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9173 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.7.0 > Environment: CS 4.7.0 RC1 / Ubuntu 14/ KVM (CS inside CS) >Reporter: Milamber >Assignee: Rohit Yadav > Attachments: Selection_242.png > > > I thinks that the CPU stats column "Used" is in reality a "Free" column? > In the screen shots, the cs-host2 node have 0 vm (normal or system) running > inside, and the Used cell is red. > Normal? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-9170: - Attachment: On my CS 4.7.0 (upgraded from 4.6.2 RC1) (works fine too with a CS 4.7.0 from 4.5.2).png > Register template in UI does not show zones in dropdown listbox > --- > > Key: CLOUDSTACK-9170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.7.0 >Reporter: Remi Bergsma > Attachments: On my CS 4.7.0 (upgraded from 4.6.2 RC1) (works fine too > with a CS 4.7.0 from 4.5.2).png, Screen Shot 2015-12-15 at 15.16.51.png > > > The only option listed is "All zones". No API call is done to query the zones. > Check screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9170) Register template in UI does not show zones in dropdown listbox
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059619#comment-15059619 ] Milamber commented on CLOUDSTACK-9170: -- Please note, I clean up my browser cache before use my CS 4.7.0 Web UI > Register template in UI does not show zones in dropdown listbox > --- > > Key: CLOUDSTACK-9170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.7.0 >Reporter: Remi Bergsma > Attachments: On my CS 4.7.0 (upgraded from 4.6.2 RC1) (works fine too > with a CS 4.7.0 from 4.5.2).png, Screen Shot 2015-12-15 at 15.16.51.png > > > The only option listed is "All zones". No API call is done to query the zones. > Check screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021131#comment-15021131
]
Milamber commented on CLOUDSTACK-8845:
--
I have this bug on my test platform after the upgrade from 4.5.2 to 4.6.0.
After some analysis on your database, I
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
>
[jira] [Issue Comment Deleted] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milamber updated CLOUDSTACK-8845:
-
Comment: was deleted
(was:
I have this bug on my test platform after the upgrade from 4.5.2 to 4.6.0.
After some analysis on your database, I
)
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
>
[jira] [Commented] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15021143#comment-15021143
]
Milamber commented on CLOUDSTACK-8845:
--
I have this bug on my test platform after an upgrade from 4.5.2 to 4.6.0.
After some analysis on your database, I think the issue come form the volume id
3 and/or the snapshot id 1.
(same diagnotic on my database with another volume id/snapshot id)
When the list snapshot command run, the manager make 3 sql requests. Request
[1] select the snapshots list, and for each snapshot, search all volume id for
this snapshot with request [2], if 0 volume id found, else the request [3] is
run to find the snapshot id from snapshot_store_ref table.
In your case, the requests [2] and [3] retrieve 0 result, so in the
StorageSystemSnapshotStrategy.java:455 class with enter in a
CloudRuntimeException and the list command failed.
I don't known (currently) how this bug is possible. In my test platform, I
change the fields 'status' to 'Destroyed' and 'removed' to some date on
snapshots table as a workaround.
[1]Â SELECT snapshots.id, snapshots.data_center_id, snapshots.account_id,
snapshots.domain_id, snapshots.volume_id,
snapshots.disk_offering_id, snapshots.name, snapshots.status,
snapshots.snapshot_type, snapshots.type_description,
snapshots.size, snapshots.created, snapshots.removed,
snapshots.hypervisor_type, snapshots.version, snapshots.uuid,
snapshots.min_iops, snapshots.max_iops
FROM snapshots
INNER JOIN account ON snapshots.account_id=account.id
WHERE snapshots.account_id=2 AND snapshots.status != 'Destroyed'
AND snapshots.snapshot_type != 2 AND snapshots.removed IS NULL
AND (account.type != 5 )
ORDER BY snapshots.created DESC LIMIT 0, 500
GO
[2] SELECT volumes.id, volumes.name, volumes.pool_id, volumes.last_pool_id,
volumes.account_id,
volumes.domain_id, volumes.instance_id, volumes.device_id, volumes.size,
volumes.min_iops, volumes.max_iops,
volumes.folder, volumes.path, volumes.pod_id, volumes.created,
volumes.attached, volumes.data_center_id,
volumes.host_ip, volumes.disk_offering_id, volumes.template_id,
volumes.first_snapshot_backup_uuid,
volumes.volume_type, volumes.pool_type, volumes.removed, volumes.updated,
volumes.update_count,
volumes.recreatable, volumes.state, volumes.chain_info, volumes.uuid,
volumes.format,
volumes.provisioning_type, volumes.display_volume, volumes.iscsi_name,
volumes.vm_snapshot_chain_size,
volumes.iso_id, volumes.hv_ss_reserve
FROM volumes
WHERE volumes.id = 3
AND volumes.removed IS NULL
GO
[3] SELECT snapshot_store_ref.id, snapshot_store_ref.store_id,
snapshot_store_ref.store_role, snapshot_store_ref.snapshot_id,
snapshot_store_ref.created, snapshot_store_ref.last_updated,
snapshot_store_ref.size,
snapshot_store_ref.physical_size, snapshot_store_ref.parent_snapshot_id,
snapshot_store_ref.job_id,
snapshot_store_ref.install_path, snapshot_store_ref.update_count,
snapshot_store_ref.updated, snapshot_store_ref.state,
snapshot_store_ref.ref_cnt, snapshot_store_ref.volume_id
FROM snapshot_store_ref
WHERE snapshot_store_ref.snapshot_id = 1
AND snapshot_store_ref.store_role = 'Primary'
ORDER BY RAND() LIMIT 1
GO
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
>
[jira] [Updated] (CLOUDSTACK-8845) list snapshot without id is failing with Unable to determine the storage pool of the snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milamber updated CLOUDSTACK-8845:
-
Labels: snapshot (was: )
> list snapshot without id is failing with Unable to determine the storage pool
> of the snapshot
> -
>
> Key: CLOUDSTACK-8845
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8845
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.6.0
>Reporter: prashant kumar mishra
> Labels: snapshot
> Attachments: cloud.dmp, management-server.log
>
>
> steps
>
> Try to list snapshot using api/UI without passing id
> http://10.*.*.*:8080/client/api?command=listSnapshots=json&_=1442227513154
> {"listsnapshotsresponse":{"uuidList":[],"errorcode":530,"cserrorcode":4250,"errortext":"Unable
> to determine the storage pool of the snapshot"}}
> logs
> -
> 2015-09-14 10:23:10,579 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-4:ctx-600cffa2) ===START=== 10.252.193.23 -- GET
> command=listSnapshots=json&_=1442227513154
> 2015-09-14 10:23:10,635 ERROR [c.c.a.ApiServer] (catalina-exec-4:ctx-600cffa2
> ctx-92e1cd5e) unhandled exception executing api command:
> [Ljava.lang.String;@10e4744f
> com.cloud.utils.exception.CloudRuntimeException: Unable to determine the
> storage pool of the snapshot
> at
> org.apache.cloudstack.storage.snapshot.StorageSystemSnapshotStrategy.canHandle(StorageSystemSnapshotStrategy.java:455)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:72)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl$3.canHandle(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.bestMatch(StorageStrategyFactoryImpl.java:95)
> at
> org.apache.cloudstack.storage.helper.StorageStrategyFactoryImpl.getSnapshotStrategy(StorageStrategyFactoryImpl.java:69)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.isRevertable(SnapshotObject.java:133)
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:499)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529)
> at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:296)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> at
> org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
> at
> org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at
[jira] [Closed] (CLOUDSTACK-9043) Localization de_DE and zh_CN don't works: Uncaught SyntaxError: Unexpected token ILLEGAL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-9043. Resolution: Fixed Merged on master (next 4.6RC2) > Localization de_DE and zh_CN don't works: Uncaught SyntaxError: Unexpected > token ILLEGAL > > > Key: CLOUDSTACK-9043 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9043 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Milamber >Assignee: Milamber > Labels: ui > Fix For: 4.6.0 > > > Found 2 bugs in German and Chinese localization (characters illegals in > javascript) > Some strings don't localized, only thes keys displays (all strings after the > illegal char) > (Error message in Chrome: Uncaught SyntaxError: Unexpected token ILLEGAL) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9043) Localization de_DE and zh_CN don't works: Uncaught SyntaxError: Unexpected token ILLEGAL
Milamber created CLOUDSTACK-9043: Summary: Localization de_DE and zh_CN don't works: Uncaught SyntaxError: Unexpected token ILLEGAL Key: CLOUDSTACK-9043 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9043 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.6.0 Reporter: Milamber Assignee: Milamber Fix For: 4.6.0 Found 2 bugs in German and Chinese localization (characters illegals in javascript) Some strings don't localized, only thes keys displays (all strings after the illegal char) (Error message in Chrome: Uncaught SyntaxError: Unexpected token ILLEGAL) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8427) Some messages are hard-coded in javascript after Volume upload branch merge(0b835592)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-8427. Resolution: Fixed > Some messages are hard-coded in javascript after Volume upload branch > merge(0b835592) > - > > Key: CLOUDSTACK-8427 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8427 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Ramamurti Subramanian >Assignee: Milamber > Fix For: 4.6.0 > > > Some messages are hard-coded in javascript after Volume upload branch > merge(0b835592) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8427) Some messages are hard-coded in javascript after Volume upload branch merge(0b835592)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-8427: - Fix Version/s: (was: Future) 4.6.0 > Some messages are hard-coded in javascript after Volume upload branch > merge(0b835592) > - > > Key: CLOUDSTACK-8427 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8427 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Ramamurti Subramanian >Assignee: Milamber > Fix For: 4.6.0 > > > Some messages are hard-coded in javascript after Volume upload branch > merge(0b835592) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8744) Add missing localization (l10n) for several parts in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-8744. Resolution: Fixed PR merged > Add missing localization (l10n) for several parts in the UI > --- > > Key: CLOUDSTACK-8744 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8744 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.6.0 >Reporter: Milamber >Assignee: Milamber > Fix For: 4.6.0 > > > Add missing localization (l10n) for several parts in the UI > - l10n for the SSH Key Pairs behavior > - l10n for Autoscaling / LB sections > - l10n for Reset password > - l10n on some strings for the installation Wizard > - l10n on some strings in VPN/VPC section > - l10n on Service offerings sections -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8744) Add missing localization (l10n) for several parts in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14701042#comment-14701042 ] Milamber commented on CLOUDSTACK-8744: -- For the SSH Key Pairs section, related to: CLOUDSTACK-7882 CLOUDSTACK-8649 https://github.com/apache/cloudstack/pull/615 https://github.com/apache/cloudstack/pull/709 Add missing localization (l10n) for several parts in the UI --- Key: CLOUDSTACK-8744 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8744 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.6.0 Reporter: Milamber Assignee: Milamber Fix For: 4.6.0 Add missing localization (l10n) for several parts in the UI - l10n for the SSH Key Pairs behavior - l10n for Autoscaling / LB sections - l10n for Reset password - l10n on some strings for the installation Wizard - l10n on some strings in VPN/VPC section - l10n on Service offerings sections -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8744) Add missing localization (l10n) for several parts in the UI
Milamber created CLOUDSTACK-8744: Summary: Add missing localization (l10n) for several parts in the UI Key: CLOUDSTACK-8744 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8744 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.6.0 Reporter: Milamber Assignee: Milamber Fix For: 4.6.0 Add missing localization (l10n) for several parts in the UI - l10n for the SSH Key Pairs behavior - l10n for Autoscaling / LB sections - l10n for Reset password - l10n on some strings for the installation Wizard - l10n on some strings in VPN/VPC section - l10n on Service offerings sections -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-8427) Some messages are hard-coded in javascript after Volume upload branch merge(0b835592)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693794#comment-14693794 ] Milamber edited comment on CLOUDSTACK-8427 at 8/12/15 5:05 PM: --- Several messages stills hard-coded. was (Author: milamber): Several message still hardcoded. Some messages are hard-coded in javascript after Volume upload branch merge(0b835592) - Key: CLOUDSTACK-8427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Ramamurti Subramanian Assignee: Milamber Fix For: Future Some messages are hard-coded in javascript after Volume upload branch merge(0b835592) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-8427) Some messages are hard-coded in javascript after Volume upload branch merge(0b835592)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reopened CLOUDSTACK-8427: -- Assignee: Milamber Several message still hardcoded. Some messages are hard-coded in javascript after Volume upload branch merge(0b835592) - Key: CLOUDSTACK-8427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Ramamurti Subramanian Assignee: Milamber Fix For: Future Some messages are hard-coded in javascript after Volume upload branch merge(0b835592) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6673) cloudstack-setup-management make a chmod 777 on /root
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010838#comment-14010838 ] Milamber commented on CLOUDSTACK-6673: -- Yes seems related only on Ubuntu platform. The name of python class is: class ubuntuFirewallConfigServer(firewallConfigServer): [...] #FIXME: urgly make /root writable bash(sudo chmod 0777 /root) Deployment of CloudStack on Ubuntu 14.04 with this last line commented works well... cloudstack-setup-management make a chmod 777 on /root - Key: CLOUDSTACK-6673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: Ubuntu 14.04 / KVM CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Blocker Labels: security Before run cloudstack-setup-management, /root directory permissions are: drwx-- 4 root root 4096 mai 14 15:05 root After the runs of cloudstack-setup-management, /root directory permissions are: drwxrwxrwx 4 root root 4096 mai 14 15:05 root -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6673) cloudstack-setup-management make a chmod 777 on /root
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002362#comment-14002362 ] Milamber commented on CLOUDSTACK-6673: -- Comment this line seems have no impact on CS 4.4 deployment (KVM installation on Ubuntu 14.04 and Debian7+backports) cloudstack-setup-management make a chmod 777 on /root - Key: CLOUDSTACK-6673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: Ubuntu 14.04 / KVM CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Blocker Labels: security Before run cloudstack-setup-management, /root directory permissions are: drwx-- 4 root root 4096 mai 14 15:05 root After the runs of cloudstack-setup-management, /root directory permissions are: drwxrwxrwx 4 root root 4096 mai 14 15:05 root -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999736#comment-13999736 ] Milamber commented on CLOUDSTACK-6671: -- Rebase without this commit, fixes the issue. CLOUDSTACK-6358: As a part of supporting dynamic guest OS defined by user, removing the hard-coded dependencies. This patch is for KVM 1. Local testing on KVM 2. Successfully got up system VMs 3. Successfully created a CentOS VM 4. Snapshots are not supported for KVM Signed off by :- Nitin Mehtanitin.me...@citrix.com Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/02bd3d06 Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/02bd3d06 Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/02bd3d06 Branch: refs/heads/4.4 Commit: 02bd3d0671b0cde46f8aa7892f20aa0bb0d48d1c Parents: 1fb358d Author: Amogh Vasekar amogh.vase...@citrix.com Authored: Wed May 7 15:16:55 2014 -0700 Committer: Daan Hoogland d...@onecht.net Committed: Tue May 13 10:33:15 2014 +0200 Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) - Key: CLOUDSTACK-6671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 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.4.0 Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Critical Labels: KVM Attachments: extract-management.log Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). SSVM, Console proxy and first virtual routeur are correctly created and UP. 10 day ago, this issue isn't present. In attachment, full log. 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance VM[User|i-2-5-VM] java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) 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:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999711#comment-13999711 ] Milamber commented on CLOUDSTACK-6671: -- This issue occur only when I create a new instance from an ISO. With Centos 5.5 template, the VM is created with success. Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) - Key: CLOUDSTACK-6671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 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.4.0 Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Critical Labels: KVM Attachments: extract-management.log Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). SSVM, Console proxy and first virtual routeur are correctly created and UP. 10 day ago, this issue isn't present. In attachment, full log. 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance VM[User|i-2-5-VM] java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) 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:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-6671: - Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 / 20140516 (was: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) - Key: CLOUDSTACK-6671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 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.4.0 Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 / 20140516 Reporter: Milamber Priority: Critical Labels: KVM Attachments: extract-management.log Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). SSVM, Console proxy and first virtual routeur are correctly created and UP. 10 day ago, this issue isn't present. In attachment, full log. 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance VM[User|i-2-5-VM] java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) 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:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
Milamber created CLOUDSTACK-6671: Summary: Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) Key: CLOUDSTACK-6671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 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.4.0 Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Critical Attachments: extract-management.log Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). SSVM, Console proxy and first virtual routeur are correctly created and UP. 10 day ago, this issue isn't present. In attachment, full log. 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance VM[User|i-2-5-VM] java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) 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:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-4770: - Environment: CentOS 6.4, Ubuntu 14.04 (was: CentOS 6.4) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address - Key: CLOUDSTACK-4770 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.2.0, 4.4.0 Environment: CentOS 6.4, Ubuntu 14.04 Reporter: Richard Chatterton Priority: Minor Installing CloudStack 4.1.1 today, the management server failed to start with the following errors: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I attempted to reinstall with CloudStack 4.2.0. This produced the following error messages: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: Unable to get the management server node id at com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) I found a mailing list post which mentioned that this might be due to missing MAC address, and recommended testing by running the class directly. This produced the following output for me: $ java -classpath /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar com.cloud.utils.net.MacAddress addr in integer is 0 addr in bytes is 0 0 0 0 0 0 addr in char is 00:00:00:00:00:00 This was odd to me, as the output of ifconfig didn't have any MAC addresses that were 00:00:00:00:00:00. Looking into the code for that module, I found that what it appears to be doing is parsing ifconfig -a and returning the first string that looks like a MAC address. Reviewing the ifconfig -a output on the server, there was a downed bond interface with a MAC address of 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC address from one of its slave physical interfaces. After assigning a dummy IP address to that interface and upping it, it received a MAC address and I was able to start the management server normally. I expect that there may be a better way to determine what the node id for the management server should be, or logic could be implemented to look for another MAC address if the first once it receives is invalid. Alternatively, if this behavior is expected, logging/debugging resources should be provided to help the user correct the problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997452#comment-13997452 ] Milamber commented on CLOUDSTACK-4770: -- With CS 4.4.0 snapshot (20140513) on Ubuntu 14.04 same issue (after a restart of management service (all host are in maintenance mode and primary storage too)) java -classpath /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.4.0-SNAPSHOT.jar com.cloud.utils.net.MacAddress addr in integer is 0 addr in bytes is 0 0 0 0 0 0 addr in char is 00:00:00:00:00:00 Reboot the manager host fix the issue. Management server fails to start with Unable to get the management server node due to downed interface with no MAC address - Key: CLOUDSTACK-4770 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.2.0, 4.4.0 Environment: CentOS 6.4, Ubuntu 14.04 Reporter: Richard Chatterton Priority: Minor Installing CloudStack 4.1.1 today, the management server failed to start with the following errors: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I attempted to reinstall with CloudStack 4.2.0. This produced the following error messages: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: Unable to get the management server node id at com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) I found a mailing list post which mentioned that this might be due to missing MAC address, and recommended testing by running the class directly. This produced the following output for me: $ java -classpath /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar com.cloud.utils.net.MacAddress addr in integer is 0 addr in bytes is 0 0 0 0 0 0 addr in char is 00:00:00:00:00:00 This was odd to me, as the output of ifconfig didn't have any MAC addresses that were 00:00:00:00:00:00. Looking into the code for that module, I found that what it appears to be doing is parsing ifconfig -a and returning the first string that looks like a MAC address. Reviewing the ifconfig -a output on the server, there was a downed bond interface with a MAC address of 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC address from one of its slave physical interfaces. After assigning a dummy IP address to that interface and upping it, it received a MAC address and I was able to start the management server normally. I expect that there may be a better way to determine what the node id for the management server should be, or logic could be implemented to look for another MAC address if the first once it receives is invalid. Alternatively, if this behavior is expected, logging/debugging resources should be provided to help the user correct the problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6673) cloudstack-setup-management make a chmod 777 on /root
Milamber created CLOUDSTACK-6673: Summary: cloudstack-setup-management make a chmod 777 on /root Key: CLOUDSTACK-6673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6673 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: Ubuntu 14.04 / KVM CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Blocker Before run cloudstack-setup-management, /root directory permissions are: drwx-- 4 root root 4096 mai 14 15:05 root After the runs of cloudstack-setup-management, /root directory permissions are: drwxrwxrwx 4 root root 4096 mai 14 15:05 root -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6670) A lot of IAMServiceImpl] (main:null) Invalidate IAM cache message in log until web-ui isn't loaded
Milamber created CLOUDSTACK-6670: Summary: A lot of IAMServiceImpl] (main:null) Invalidate IAM cache message in log until web-ui isn't loaded Key: CLOUDSTACK-6670 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6670 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Environment: Ubuntu 14.04 CloudStack 4.4.0 snapshot 20140513 Reporter: Milamber A lot of these message below appear in management log until the web ui isn't loaded. 2014-05-14 15:22:38,733 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:38,800 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:38,900 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,000 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,554 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,654 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,731 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,809 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,865 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,920 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:39,964 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:40,009 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:40,098 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:40,353 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:40,519 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:22:40,619 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache [.] 2014-05-14 15:25:07,990 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:25:08,065 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:25:08,133 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:25:08,199 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:25:08,266 DEBUG [o.a.c.i.s.IAMServiceImpl] (main:null) Invalidate IAM cache 2014-05-14 15:25:08,266 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Starting CloudStack Components 2014-05-14 15:25:08,267 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Starting module [ldap] 2014-05-14 15:25:08,267 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Starting CloudStack Components 2014-05-14 15:25:08,267 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Starting CloudStack Components 2014-05-14 15:25:08,267 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Starting module [md5] 2014-05-14 15:25:08,267 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Starting module [plaintext] 2014-05-14 15:25:08,268 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Starting module [rate-limit] 2014-05-14 15:25:08,268 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Done Starting CloudStack Components 2014-05-14 15:25:08,268 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Starting module [server-api] [..] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6671) Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-6671: - Attachment: extract-management.log Full log when I try to create a VM. Failed to start instance VM java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) - Key: CLOUDSTACK-6671 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6671 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.4.0 Environment: Ubuntu 14.04 / KVM / CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Critical Labels: KVM Attachments: extract-management.log Unable to create VM on a fresh CS 4.4.0 installation (branch 4.4). SSVM, Console proxy and first virtual routeur are correctly created and UP. 10 day ago, this issue isn't present. In attachment, full log. 2014-05-14 15:46:33,085 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-6:job-25/job-27 ctx-57c7f749) Failed to start instance VM[User|i-2-5-VM] java.lang.NullPointerException at com.cloud.hypervisor.KVMGuru.implement(KVMGuru.java:64) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:995) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:5180) 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:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5325) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6594) [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-6594: - Attachment: management-server.log Full management log [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists Key: CLOUDSTACK-6594 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: RHEL 6.3, Build - 4.4-forward, Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Fix For: 4.4.0 Attachments: CLOUDSTACK-6594.rar, management-server.log Below exception observed while staring MS INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module context [system] from URL [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml] INFO [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability enabled? Ans : false INFO [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352 INFO [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for database upgrade. INFO [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code Version = 4.4.0-SNAPSHOT INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be performed from 4.0.0 to 4.4.0-SNAPSHOT WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key last_sent on table alert com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'last_sent'; check that column/key exists at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37) at com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28) at com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543) at com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) at org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51) at
[jira] [Commented] (CLOUDSTACK-6673) cloudstack-setup-management make a chmod 777 on /root
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998247#comment-13998247 ] Milamber commented on CLOUDSTACK-6673: -- Probably origin from: ./python/lib/cloudutils/serviceConfig.py #FIXME: urgly make /root writable bash(sudo chmod 0777 /root) cloudstack-setup-management make a chmod 777 on /root - Key: CLOUDSTACK-6673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: Ubuntu 14.04 / KVM CS 4.4.0 snapshot 20140513 Reporter: Milamber Priority: Blocker Labels: security Before run cloudstack-setup-management, /root directory permissions are: drwx-- 4 root root 4096 mai 14 15:05 root After the runs of cloudstack-setup-management, /root directory permissions are: drwxrwxrwx 4 root root 4096 mai 14 15:05 root -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-4770: - Affects Version/s: 4.4.0 Management server fails to start with Unable to get the management server node due to downed interface with no MAC address - Key: CLOUDSTACK-4770 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.2.0, 4.4.0 Environment: CentOS 6.4 Reporter: Richard Chatterton Priority: Minor Installing CloudStack 4.1.1 today, the management server failed to start with the following errors: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I attempted to reinstall with CloudStack 4.2.0. This produced the following error messages: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: Unable to get the management server node id at com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) I found a mailing list post which mentioned that this might be due to missing MAC address, and recommended testing by running the class directly. This produced the following output for me: $ java -classpath /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar com.cloud.utils.net.MacAddress addr in integer is 0 addr in bytes is 0 0 0 0 0 0 addr in char is 00:00:00:00:00:00 This was odd to me, as the output of ifconfig didn't have any MAC addresses that were 00:00:00:00:00:00. Looking into the code for that module, I found that what it appears to be doing is parsing ifconfig -a and returning the first string that looks like a MAC address. Reviewing the ifconfig -a output on the server, there was a downed bond interface with a MAC address of 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC address from one of its slave physical interfaces. After assigning a dummy IP address to that interface and upping it, it received a MAC address and I was able to start the management server normally. I expect that there may be a better way to determine what the node id for the management server should be, or logic could be implemented to look for another MAC address if the first once it receives is invalid. Alternatively, if this behavior is expected, logging/debugging resources should be provided to help the user correct the problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4770) Management server fails to start with Unable to get the management server node due to downed interface with no MAC address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997456#comment-13997456 ] Milamber commented on CLOUDSTACK-4770: -- Please note: before the restard of CS management service, a lot of these messages appear in logs: 2014-05-14 11:01:31,177 INFO [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-8284b79e) Management node 1 is detected inactive by timestamp but is pingable 2014-05-14 11:01:32,681 INFO [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-c7f636db) Trying to connect to 10.7.1.21 After the restart, these messages disappeared. Management server fails to start with Unable to get the management server node due to downed interface with no MAC address - Key: CLOUDSTACK-4770 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4770 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.2.0, 4.4.0 Environment: CentOS 6.4, Ubuntu 14.04 Reporter: Richard Chatterton Priority: Minor Installing CloudStack 4.1.1 today, the management server failed to start with the following errors: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup Due to CLOUDSTACK-4170, there wasn't any useful information provided, so I attempted to reinstall with CloudStack 4.2.0. This produced the following error messages: 2013-09-30 14:43:43,436 INFO [utils.component.ComponentContext] (Timer-2:null) Running SystemIntegrityChecker managementServerNode 2013-09-30 14:43:43,438 ERROR [utils.component.ComponentContext] (Timer-2:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: Unable to get the management server node id at com.cloud.cluster.ManagementServerNode.check(ManagementServerNode.java:46) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) I found a mailing list post which mentioned that this might be due to missing MAC address, and recommended testing by running the class directly. This produced the following output for me: $ java -classpath /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-utils-4.2.0.jar com.cloud.utils.net.MacAddress addr in integer is 0 addr in bytes is 0 0 0 0 0 0 addr in char is 00:00:00:00:00:00 This was odd to me, as the output of ifconfig didn't have any MAC addresses that were 00:00:00:00:00:00. Looking into the code for that module, I found that what it appears to be doing is parsing ifconfig -a and returning the first string that looks like a MAC address. Reviewing the ifconfig -a output on the server, there was a downed bond interface with a MAC address of 00:00:00:00:00:00. When this interface is up, it automatically gets a MAC address from one of its slave physical interfaces. After assigning a dummy IP address to that interface and upping it, it received a MAC address and I was able to start the management server normally. I expect that there may be a better way to determine what the node id for the management server should be, or logic could be implemented to look for another MAC address if the first once it receives is invalid. Alternatively, if this behavior is expected, logging/debugging resources should be provided to help the user correct the problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6594) [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13997574#comment-13997574 ] Milamber commented on CLOUDSTACK-6594: -- Also with CS 4.4.0 snapshot 20140513 (fresh install) Full log in attachment. 2014-05-14 15:09:13,266 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key last_sent on table alert 2014-05-14 15:09:13,271 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key i_alert__last_sent on table alert 2014-05-14 15:09:13,542 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_nsp_id on table baremetal_dhcp_devices 2014-05-14 15:09:13,665 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_host_id on table baremetal_dhcp_devices 2014-05-14 15:09:13,765 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_pod_id on table baremetal_dhcp_devices 2014-05-14 15:09:13,854 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_physical_network_id on table baremetal_dhcp_devices 2014-05-14 15:09:13,977 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_nsp_id on table baremetal_pxe_devices 2014-05-14 15:09:14,066 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_host_id on table baremetal_pxe_devices 2014-05-14 15:09:14,167 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_pod_id on table baremetal_pxe_devices 2014-05-14 15:09:14,268 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_dhcp_devices_physical_network_id on table baremetal_pxe_devices 2014-05-14 15:09:14,369 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_pxe_devices_nsp_id on table baremetal_pxe_devices 2014-05-14 15:09:14,469 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_pxe_devices_host_id on table baremetal_pxe_devices 2014-05-14 15:09:14,569 WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop foreign key fk_external_pxe_devices_physical_network_id on table baremetal_pxe_devices [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists Key: CLOUDSTACK-6594 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: RHEL 6.3, Build - 4.4-forward, Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Fix For: 4.4.0 Attachments: CLOUDSTACK-6594.rar, management-server.log Below exception observed while staring MS INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module context [system] from URL [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml] INFO [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability enabled? Ans : false INFO [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352 INFO [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for database upgrade. INFO [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code Version = 4.4.0-SNAPSHOT INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be performed from 4.0.0 to 4.4.0-SNAPSHOT WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key last_sent on table alert com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'last_sent'; check that column/key exists at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
[jira] [Updated] (CLOUDSTACK-6594) [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-6594: - Environment: RHEL 6.3, Build - 4.4-forward, Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 was: RHEL 6.3 Build - 4.4-forward [Automation] Observed many DB Exception while starting MS Can't DROP 'last_sent'; check that column/key exists Key: CLOUDSTACK-6594 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: RHEL 6.3, Build - 4.4-forward, Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Fix For: 4.4.0 Attachments: CLOUDSTACK-6594.rar Below exception observed while staring MS INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module context [system] from URL [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml] INFO [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability enabled? Ans : false INFO [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352 INFO [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for database upgrade. INFO [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code Version = 4.4.0-SNAPSHOT INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be performed from 4.0.0 to 4.4.0-SNAPSHOT WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when trying to drop key last_sent on table alert com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'last_sent'; check that column/key exists at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37) at com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28) at com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543) at com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) at org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) at org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) at
[jira] [Updated] (CLOUDSTACK-5946) SSL: Fail to find the generated keystore. Loading fail-safe one to continue.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-5946: - Affects Version/s: 4.3.0 SSL: Fail to find the generated keystore. Loading fail-safe one to continue. Key: CLOUDSTACK-5946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5946 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1, 4.3.0 Environment: CentOS 6.4 x64 Reporter: Vadim Kim. Priority: Minor Management logs are full of this warning. deleting file /etc/cloudstack/management/cloudmanagementserver.keystore seems to fix the problem. System re-crates it later and does not issue warnings anymore -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5946) SSL: Fail to find the generated keystore. Loading fail-safe one to continue.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990465#comment-13990465 ] Milamber commented on CLOUDSTACK-5946: -- This bug is aslo on CS 4.3.0 fresh install. SSL: Fail to find the generated keystore. Loading fail-safe one to continue. Key: CLOUDSTACK-5946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5946 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1, 4.3.0 Environment: CentOS 6.4 x64 Reporter: Vadim Kim. Priority: Minor Management logs are full of this warning. deleting file /etc/cloudstack/management/cloudmanagementserver.keystore seems to fix the problem. System re-crates it later and does not issue warnings anymore -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-5946) SSL: Fail to find the generated keystore. Loading fail-safe one to continue.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990465#comment-13990465 ] Milamber edited comment on CLOUDSTACK-5946 at 5/6/14 9:24 AM: -- This bug is aslo on CS 4.3.0 current trunk (2014-05-05) install. (Ubuntu 14.04) was (Author: milamber): This bug is aslo on CS 4.3.0 fresh install. SSL: Fail to find the generated keystore. Loading fail-safe one to continue. Key: CLOUDSTACK-5946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5946 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1, 4.3.0 Environment: CentOS 6.4 x64 Reporter: Vadim Kim. Priority: Minor Management logs are full of this warning. deleting file /etc/cloudstack/management/cloudmanagementserver.keystore seems to fix the problem. System re-crates it later and does not issue warnings anymore -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-5214) Potential bug with CS 4.1.1 to 4.2.1 db upgrade
Milamber created CLOUDSTACK-5214: Summary: Potential bug with CS 4.1.1 to 4.2.1 db upgrade Key: CLOUDSTACK-5214 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5214 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.1.1 Environment: CloudStack 4.1.1 to 4.2.1, CentOS 6.4 KVM Reporter: Milamber Priority: Blocker Fix For: Future Hello, Yesterday, I've upgrade a CloudStack 4.1.1 installation to CloudStack 4.2.1, I've received this error when I started the management service the first time after upgrade (below). To fix it, I've change this line in schema-410to420.sql CREATE TABLE `cloud`.`vm_snapshots` ( to CREATE TABLE IF NOT EXISTS `cloud`.`vm_snapshots` ( And I restore the cloud db backup from the mysql dump execute just before upgrade, and (re-)start the management service. All is good after. = 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker managementServerNode 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker databaseUpgradeChecker 2013-11-20 00:12:31,057 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-11-20 00:12:31,059 DEBUG [upgrade.dao.VersionDaoImpl] (Timer-1:null) Checking to see if the database is at a version before it was the version table is created 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.1-SNAPSHOT 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT 2013-11-20 00:12:31,064 DEBUG [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Running upgrade Upgrade410to420 to upgrade from 4.1.0-4.1.1 to 4.2.0 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Looking for db/schema-410to420.sql in the classpath 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) System resource: file:/usr/share/cloudstack-management/setup/db/schema-410to420.sql 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Absolute path = /usr/share/cloudstack-management/setup/db/schema-410to420.sql [] 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) Error executing: CREATE TABLE `cloud`.`vm_snapshots` ( `id` bigint(20) unsigned NOT NULL auto_increment COMMENT 'Primary Key', `uuid` varchar(40) NOT NULL, `name` varchar(255) NOT NULL, `display_name` varchar(255) default NULL, `description` varchar(255) default NULL, `vm_id` bigint(20) unsigned NOT NULL, `account_id` bigint(20) unsigned NOT NULL, `domain_id` bigint(20) unsigned NOT NULL, `vm_snapshot_type` varchar(32) default NULL, `state` varchar(32) NOT NULL, `parent` bigint unsigned default NULL, `current` int(1) unsigned default NULL, `update_count` bigint unsigned NOT NULL DEFAULT 0, `updated` datetime default NULL, `created` datetime default NULL, `removed` datetime default NULL, PRIMARY KEY (`id`), CONSTRAINT UNIQUE KEY `uc_vm_snapshots_uuid` (`uuid`), INDEX `vm_snapshots_name` (`name`), INDEX `vm_snapshots_vm_id` (`vm_id`), INDEX `vm_snapshots_account_id` (`account_id`), INDEX `vm_snapshots_display_name` (`display_name`), INDEX `vm_snapshots_removed` (`removed`), INDEX `vm_snapshots_parent` (`parent`), CONSTRAINT `fk_vm_snapshots_vm_id__vm_instance_id` FOREIGN KEY `fk_vm_snapshots_vm_id__vm_instance_id` (`vm_id`) REFERENCES `vm_instance` (`id`), CONSTRAINT `fk_vm_snapshots_account_id__account_id` FOREIGN KEY `fk_vm_snapshots_account_id__account_id` (`account_id`) REFERENCES `account` (`id`), CONSTRAINT `fk_vm_snapshots_domain_id__domain_id` FOREIGN KEY `fk_vm_snapshots_domain_id__domain_id` (`domain_id`) REFERENCES `domain` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists 2013-11-20 00:12:32,549 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-410to420.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:204) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:265) at
[jira] [Updated] (CLOUDSTACK-5214) Potential bug with CS 4.1.1 to 4.2.1 db upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-5214: - Description: Hello, Yesterday, I've upgraded a CloudStack 4.1.1 installation to CloudStack 4.2.1, I've received this error when I started the management service the first time after upgrade (below). To fix it, I've changed this line in schema-410to420.sql CREATE TABLE `cloud`.`vm_snapshots` ( to CREATE TABLE IF NOT EXISTS `cloud`.`vm_snapshots` ( And I've restored the cloud db backup from the mysql dump executed just before upgrade, and (re-)start the management service. All is good after. = 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker managementServerNode 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker databaseUpgradeChecker 2013-11-20 00:12:31,057 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-11-20 00:12:31,059 DEBUG [upgrade.dao.VersionDaoImpl] (Timer-1:null) Checking to see if the database is at a version before it was the version table is created 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.1-SNAPSHOT 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT 2013-11-20 00:12:31,064 DEBUG [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Running upgrade Upgrade410to420 to upgrade from 4.1.0-4.1.1 to 4.2.0 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Looking for db/schema-410to420.sql in the classpath 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) System resource: file:/usr/share/cloudstack-management/setup/db/schema-410to420.sql 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Absolute path = /usr/share/cloudstack-management/setup/db/schema-410to420.sql [] 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) Error executing: CREATE TABLE `cloud`.`vm_snapshots` ( `id` bigint(20) unsigned NOT NULL auto_increment COMMENT 'Primary Key', `uuid` varchar(40) NOT NULL, `name` varchar(255) NOT NULL, `display_name` varchar(255) default NULL, `description` varchar(255) default NULL, `vm_id` bigint(20) unsigned NOT NULL, `account_id` bigint(20) unsigned NOT NULL, `domain_id` bigint(20) unsigned NOT NULL, `vm_snapshot_type` varchar(32) default NULL, `state` varchar(32) NOT NULL, `parent` bigint unsigned default NULL, `current` int(1) unsigned default NULL, `update_count` bigint unsigned NOT NULL DEFAULT 0, `updated` datetime default NULL, `created` datetime default NULL, `removed` datetime default NULL, PRIMARY KEY (`id`), CONSTRAINT UNIQUE KEY `uc_vm_snapshots_uuid` (`uuid`), INDEX `vm_snapshots_name` (`name`), INDEX `vm_snapshots_vm_id` (`vm_id`), INDEX `vm_snapshots_account_id` (`account_id`), INDEX `vm_snapshots_display_name` (`display_name`), INDEX `vm_snapshots_removed` (`removed`), INDEX `vm_snapshots_parent` (`parent`), CONSTRAINT `fk_vm_snapshots_vm_id__vm_instance_id` FOREIGN KEY `fk_vm_snapshots_vm_id__vm_instance_id` (`vm_id`) REFERENCES `vm_instance` (`id`), CONSTRAINT `fk_vm_snapshots_account_id__account_id` FOREIGN KEY `fk_vm_snapshots_account_id__account_id` (`account_id`) REFERENCES `account` (`id`), CONSTRAINT `fk_vm_snapshots_domain_id__domain_id` FOREIGN KEY `fk_vm_snapshots_domain_id__domain_id` (`domain_id`) REFERENCES `domain` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists 2013-11-20 00:12:32,549 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-410to420.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:204) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:265) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:394) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2013-11-20 00:12:32,552 ERROR
[jira] [Commented] (CLOUDSTACK-5214) Potential bug with CS 4.1.1 to 4.2.1 db upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13827529#comment-13827529 ] Milamber commented on CLOUDSTACK-5214: -- Yes of course, yesterday, I've made a drop/create table before the dump restore. The issue is the lake of IF NOT EXISTS in sql file. Potential bug with CS 4.1.1 to 4.2.1 db upgrade --- Key: CLOUDSTACK-5214 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5214 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.1.1 Environment: CloudStack 4.1.1 to 4.2.1, CentOS 6.4 KVM Reporter: Milamber Priority: Blocker Fix For: Future Hello, Yesterday, I've upgraded a CloudStack 4.1.1 installation to CloudStack 4.2.1, I've received this error when I started the management service the first time after upgrade (below). To fix it, I've changed this line in schema-410to420.sql CREATE TABLE `cloud`.`vm_snapshots` ( to CREATE TABLE IF NOT EXISTS `cloud`.`vm_snapshots` ( And I've restored the cloud db backup from the mysql dump executed just before upgrade, and (re-)start the management service. All is good after. = 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker managementServerNode 2013-11-20 00:12:31,057 INFO [utils.component.ComponentContext] (Timer-1:null) Running SystemIntegrityChecker databaseUpgradeChecker 2013-11-20 00:12:31,057 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-11-20 00:12:31,059 DEBUG [upgrade.dao.VersionDaoImpl] (Timer-1:null) Checking to see if the database is at a version before it was the version table is created 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.1-SNAPSHOT 2013-11-20 00:12:31,063 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT 2013-11-20 00:12:31,064 DEBUG [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Running upgrade Upgrade410to420 to upgrade from 4.1.0-4.1.1 to 4.2.0 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Looking for db/schema-410to420.sql in the classpath 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) System resource: file:/usr/share/cloudstack-management/setup/db/schema-410to420.sql 2013-11-20 00:12:31,069 DEBUG [utils.script.Script] (Timer-1:null) Absolute path = /usr/share/cloudstack-management/setup/db/schema-410to420.sql [] 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) Error executing: CREATE TABLE `cloud`.`vm_snapshots` ( `id` bigint(20) unsigned NOT NULL auto_increment COMMENT 'Primary Key', `uuid` varchar(40) NOT NULL, `name` varchar(255) NOT NULL, `display_name` varchar(255) default NULL, `description` varchar(255) default NULL, `vm_id` bigint(20) unsigned NOT NULL, `account_id` bigint(20) unsigned NOT NULL, `domain_id` bigint(20) unsigned NOT NULL, `vm_snapshot_type` varchar(32) default NULL, `state` varchar(32) NOT NULL, `parent` bigint unsigned default NULL, `current` int(1) unsigned default NULL, `update_count` bigint unsigned NOT NULL DEFAULT 0, `updated` datetime default NULL, `created` datetime default NULL, `removed` datetime default NULL, PRIMARY KEY (`id`), CONSTRAINT UNIQUE KEY `uc_vm_snapshots_uuid` (`uuid`), INDEX `vm_snapshots_name` (`name`), INDEX `vm_snapshots_vm_id` (`vm_id`), INDEX `vm_snapshots_account_id` (`account_id`), INDEX `vm_snapshots_display_name` (`display_name`), INDEX `vm_snapshots_removed` (`removed`), INDEX `vm_snapshots_parent` (`parent`), CONSTRAINT `fk_vm_snapshots_vm_id__vm_instance_id` FOREIGN KEY `fk_vm_snapshots_vm_id__vm_instance_id` (`vm_id`) REFERENCES `vm_instance` (`id`), CONSTRAINT `fk_vm_snapshots_account_id__account_id` FOREIGN KEY `fk_vm_snapshots_account_id__account_id` (`account_id`) REFERENCES `account` (`id`), CONSTRAINT `fk_vm_snapshots_domain_id__domain_id` FOREIGN KEY `fk_vm_snapshots_domain_id__domain_id` (`domain_id`) REFERENCES `domain` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 2013-11-20 00:12:32,546 ERROR [utils.db.ScriptRunner] (Timer-1:null) com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists 2013-11-20 00:12:32,549 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-410to420.sql
[jira] [Updated] (CLOUDSTACK-4892) KVM snapshots are failing on CLVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milamber updated CLOUDSTACK-4892:
-
Priority: Critical (was: Major)
KVM snapshots are failing on CLVM
-
Key: CLOUDSTACK-4892
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4892
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Snapshot
Affects Versions: 4.2.0
Environment: CentOS 6.4, KVM, CLVM
Reporter: Ivan Kozlov
Priority: Critical
Creating snaphot fails hanging with state CreatedOnPrimary. Sometimes
creating snaphot is successful.
Snapshot logical volume is created and not deleted.
When running snaphot with only single host snapshot is created normaly. Guess
snapshot backup is trying access snapshot LV from host on which snapshot LV
is not opened.
Here is management log:
2013-10-18 17:32:58,512 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-10:null) submit async job-41 = [
88ec27d7-78af-4664-a01b-eeca4469e37c ], details: AsyncJobVO {id:41, userId:
2, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 10,
cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd,
cmdOriginator: null, cmdInfo:
{id:10,response:json,sessionkey:HKb50xNHyZm2wJx/IHi5S7UWBGQ\u003d,cmdEventType:SNAPSHOT.CREATE,ctxUserId:2,httpmethod:GET,_:1382106777170,volumeid:560a9f6e-9864-43cc-8096-ed9cd6c97311,ctxAccountId:2,ctxStartEventId:126},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 161342718518,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-10-18 17:32:58,514 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-41
= [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]
2013-10-18 17:32:58,549 INFO [user.snapshot.CreateSnapshotCmd]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) VOLSS:
createSnapshotCmd starts:1382106778549
2013-10-18 17:32:58,925 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq
1-111542657: Sending { Cmd , MgmtId: 161342718518, via: 1, Ver: v1, Flags:
100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:560a9f6e-9864-43cc-8096-ed9cd6c97311,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},name:ROOT-5,size:8589934592,path:4f3e8cfc-d3be-4e55-bc13-5c236a689c83,volumeId:5,vmName:i-2-5-VM,accountId:2,format:RAW,id:5,hypervisorType:KVM},parentSnapshotPath:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/7e85ab28-4ea5-4b5e-8ec1-1abadf2d571e,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4a975c8c-997a-4d1d-aa88-810fd281cb04,id:1,poolType:CLVM,host:localhost,path:/vg_primary,port:0}},vmName:i-2-5-VM,name:test-100_ROOT-5_20131018143258,hypervisorType:KVM,id:10}},wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 1-111542657: Processing: { Ans: , MgmtId:
161342718518, via: 1, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/dev/vg_primary/4f3e8cfc-d3be-4e55-bc13-5c236a689c83/c6c900d1-1377-4347-ba69-9ba09f264f69,id:0}},result:true,wait:0}}]
}
2013-10-18 17:32:59,986 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq
1-111542657: Received: { Ans: , MgmtId: 161342718518, via: 1, Ver: v1,
Flags: 10, { CreateObjectAnswer } }
2013-10-18 17:33:00,497 DEBUG [storage.motion.AncientDataMotionStrategy]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) copyAsync
inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-10-18 17:33:00,547 DEBUG [agent.transport.Request]
(Job-Executor-22:job-41 = [ 88ec27d7-78af-4664-a01b-eeca4469e37c ]) Seq
4-1918238786: Sending { Cmd , MgmtId: 161342718518, via: 4, Ver: v1, Flags:
100111,
[jira] [Commented] (CLOUDSTACK-4892) KVM snapshots are failing on CLVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13819197#comment-13819197 ] Milamber commented on CLOUDSTACK-4892: -- With the lastest 4.2 branch (4.2.1-SNASHOT - 2013-11-11), the issue stills. (sometimes works / sometimes not works) 2013-11-11 18:18:15,894 INFO [user.snapshot.CreateSnapshotCmd] (Job-Executor-8:job-123 = [ 058ec85e-4ce1-42a1-aa22-9fa936c01b03 ]) VOLSS: createSnapshotCmd starts:1384193895894 com.cloud.utils.exception.CloudRuntimeException: Disk /dev/vg_baie/8d4626a2-c282-4a70-9e57-db5ad54b819a has no snapshot called a221071f6f7a198975b0907d79fa054d. at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:280) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:139) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:277) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1315) at com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2773) at org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) com.cloud.utils.exception.CloudRuntimeException: Failed to create snapshot at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1040) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1315) at com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2773) at org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) Caused by: com.cloud.utils.exception.CloudRuntimeException: Disk /dev/vg_baie/8d4626a2-c282-4a70-9e57-db5ad54b819a has no snapshot called a221071f6f7a198975b0907d79fa054d. at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:280) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:139) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:277) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013) ... 16 more KVM snapshots are failing on CLVM - Key: CLOUDSTACK-4892 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4892 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.2.0 Environment: CentOS 6.4, KVM, CLVM Reporter: Ivan Kozlov Priority: Critical Creating snaphot fails hanging with state CreatedOnPrimary. Sometimes creating snaphot is successful. Snapshot logical volume is created and not deleted. When running snaphot with only single host snapshot is created normaly. Guess snapshot backup is trying access snapshot LV from
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798922#comment-13798922 ] Milamber commented on CLOUDSTACK-4792: -- It's would be better to add in Global configuration these new timeout settings? At least add some doc/comments that says the timeout value to 30 secs? Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799101#comment-13799101 ] Milamber commented on CLOUDSTACK-4792: -- I think we need 2 new parameters only (connecttimeout and timeout - the same for http/https). I'm not sure if is an acceptable change for minor version 4.2.1 in all cases (hard coding in code or set by global conf). I think with that 30 sec timeout (instead of infinite), you introduce a new behavior which may prejudicial for current installation CS 4.2. For example, if I have a CS installation with a good smtp server but it's very slow ( 30 secs) to accept a new email, then the 30 secs timeout will break the email sending. To respect the current behavior (CS 4.X), in my mind, we need to add these new settings in global conf, with the default value 'infinite' (default value from javamail), and allows user to change this in the Web UI. If we select (or prefer to have) the default value to 30 secs, it's must be annotated in Release Notes of 4.2.1. I thinks that the master (4.3) branch must have too this new settings. Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-2413) The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-2413: - Fix Version/s: (was: 4.2.0) 4.2.1 The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering Key: CLOUDSTACK-2413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.1.0, 4.2.0 Reporter: Milamber Assignee: Milamber Fix For: 4.1.0, 4.2.1 The dialog box Change Compute Offering for a instance, display the Description (instead of the Name) of compute offering. I think would be better to display the Name. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber reassigned CLOUDSTACK-4792: Assignee: Milamber (was: Anshul Gangwar) Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Milamber Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13798316#comment-13798316 ] Milamber commented on CLOUDSTACK-4792: -- Need to add some properties to javamail in the file /cloud-server/src/com/cloud/alert/AlertManagerImpl.java props.put(mail.smtp.connectiontimeout,2); props.put(mail.smtp.timeout,2); props.put(mail.smtps.connectiontimeout,2); props.put(mail.smtps.timeout,2); I will works to add these properties in CS Global Properties Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4777) NullPointerException instead of working KVM HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-4777: - Fix Version/s: (was: Future) 4.2.1 NullPointerException instead of working KVM HA -- Key: CLOUDSTACK-4777 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4777 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.2.0 Environment: KVM (CentOS 6.4) with CloudStack 4.2 Reporter: Valery Ciareszka Assignee: edison su Priority: Critical Fix For: 4.2.1 If KVM host goes down, CloudStack management does not start HA-enabled VM on the other hosts. There is NullPointerException in management.log: 2013-09-24 11:21:25,500 ERROR [cloud.ha.HighAvailabilityManagerImpl] (HA-Worker-4:work-4) Terminating HAWork[4-HA-6-Running-Scheduled] java.lang.NullPointerException at com.cloud.storage.VolumeManagerImpl.canVmRestartOnAnotherServer(VolumeManagerImpl.java:2641) at com.cloud.ha.HighAvailabilityManagerImpl.restart(HighAvailabilityManagerImpl.java:516) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831) see full log at http://pastebin.com/upnEA601 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4777) NullPointerException instead of working KVM HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber resolved CLOUDSTACK-4777. -- Resolution: Fixed Fixed for the version 4.2.1 by Edison Su (in 4.2-forward branch that has been merged into current 4.2 branch) CLOUDSTACK-4627: fix NPE in vm migration Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/cb170d6a Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/cb170d6a Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/cb170d6a Branch: refs/heads/4.2-forward Commit: cb170d6afdab20bd63f17728b8f04a05f14ebcec Parents: 37c87a8 Author: Edison Su sudi...@gmail.com Authored: Mon Sep 9 15:58:22 2013 -0700 Committer: Edison Su sudi...@gmail.com Committed: Mon Sep 9 15:58:22 2013 -0700 -- server/src/com/cloud/storage/VolumeManagerImpl.java | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- NullPointerException instead of working KVM HA -- Key: CLOUDSTACK-4777 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4777 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.2.0 Environment: KVM (CentOS 6.4) with CloudStack 4.2 Reporter: Valery Ciareszka Assignee: edison su Priority: Critical Fix For: 4.2.1 If KVM host goes down, CloudStack management does not start HA-enabled VM on the other hosts. There is NullPointerException in management.log: 2013-09-24 11:21:25,500 ERROR [cloud.ha.HighAvailabilityManagerImpl] (HA-Worker-4:work-4) Terminating HAWork[4-HA-6-Running-Scheduled] java.lang.NullPointerException at com.cloud.storage.VolumeManagerImpl.canVmRestartOnAnotherServer(VolumeManagerImpl.java:2641) at com.cloud.ha.HighAvailabilityManagerImpl.restart(HighAvailabilityManagerImpl.java:516) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831) see full log at http://pastebin.com/upnEA601 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4627) HA not working, User VM wasn't Migrated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-4627: - Fix Version/s: 4.2.1 HA not working, User VM wasn't Migrated --- Key: CLOUDSTACK-4627 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4627 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.2.0 Environment: CentOS 6.3 64bit Reporter: Naoki Sakamoto Assignee: edison su Fix For: 4.2.1 Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, 20130909_HA_UserVM_Migration_NG.zip 1. We made one of KVM Host Power OFF by push power button of hardware for High Availability Test. 2. Vritual Router / Secodary Storage VM / Console Proxy VM is Migrated. But User VM wasn't Migrated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4627) HA not working, User VM wasn't Migrated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13795295#comment-13795295 ] Milamber commented on CLOUDSTACK-4627: -- Fixed for the version 4.2.1 by Edison Su (in 4.2-forward branch that has been merged into current 4.2 branch) CLOUDSTACK-4627: fix NPE in vm migration Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/cb170d6a Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/cb170d6a Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/cb170d6a Branch: refs/heads/4.2-forward Commit: cb170d6afdab20bd63f17728b8f04a05f14ebcec Parents: 37c87a8 Author: Edison Su sudi...@gmail.com Authored: Mon Sep 9 15:58:22 2013 -0700 Committer: Edison Su sudi...@gmail.com Committed: Mon Sep 9 15:58:22 2013 -0700 -- server/src/com/cloud/storage/VolumeManagerImpl.java | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- HA not working, User VM wasn't Migrated --- Key: CLOUDSTACK-4627 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4627 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.2.0 Environment: CentOS 6.3 64bit Reporter: Naoki Sakamoto Assignee: edison su Fix For: 4.2.1 Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, 20130909_HA_UserVM_Migration_NG.zip 1. We made one of KVM Host Power OFF by push power button of hardware for High Availability Test. 2. Vritual Router / Secodary Storage VM / Console Proxy VM is Migrated. But User VM wasn't Migrated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4777) NullPointerException instead of working KVM HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-4777: - Assignee: edison su NullPointerException instead of working KVM HA -- Key: CLOUDSTACK-4777 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4777 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.2.0 Environment: KVM (CentOS 6.4) with CloudStack 4.2 Reporter: Valery Ciareszka Assignee: edison su Priority: Critical Fix For: Future If KVM host goes down, CloudStack management does not start HA-enabled VM on the other hosts. There is NullPointerException in management.log: 2013-09-24 11:21:25,500 ERROR [cloud.ha.HighAvailabilityManagerImpl] (HA-Worker-4:work-4) Terminating HAWork[4-HA-6-Running-Scheduled] java.lang.NullPointerException at com.cloud.storage.VolumeManagerImpl.canVmRestartOnAnotherServer(VolumeManagerImpl.java:2641) at com.cloud.ha.HighAvailabilityManagerImpl.restart(HighAvailabilityManagerImpl.java:516) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831) see full log at http://pastebin.com/upnEA601 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13786516#comment-13786516 ] Milamber commented on CLOUDSTACK-4793: -- For the case of Redundant Virtual Router, restart the virtual routers sequentially, with the Backup router first. Improve VR Upgrade -- Key: CLOUDSTACK-4793 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Fix For: Future Give admin control to sequence the upgrade of the cloud by: Infrastructure hierarchy: by Cluster, Pod, and Zone etc. Administrative hierarchy: by Tenant or Domain Minimize service interruption to users Improve the speed of the upgrade time by making as many upgrade operations in parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4645) There is no upgrade path from 4.1.1 to 4.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13766631#comment-13766631 ] Milamber commented on CLOUDSTACK-4645: -- Ok for me, works fine. There is no upgrade path from 4.1.1 to 4.2.0 Key: CLOUDSTACK-4645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4645 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.2.0 Reporter: Milamber Assignee: Venkata Siva Vijayendra Bhamidipati Priority: Blocker I've try to upgrade my CS test platform from 4.1.1 to 4.2.0 (from Commit: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02 + CLVM issue cherry-pick from 4.2-forward with commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9.) The path 4.1.1-4.2.0 seems miss? 2013-09-11 14:32:55,619 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-09-11 14:32:55,631 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.0 2013-09-11 14:32:55,632 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.0 2013-09-11 14:32:55,632 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 4.1.1 to 4.2.0 2013-09-11 14:32:55,639 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.1.1 to 4.2.0 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:221) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:389) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- 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-4645) There is no upgrade path from 4.1.1 to 4.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber closed CLOUDSTACK-4645. Thanks There is no upgrade path from 4.1.1 to 4.2.0 Key: CLOUDSTACK-4645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4645 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.2.0 Reporter: Milamber Assignee: Venkata Siva Vijayendra Bhamidipati Priority: Blocker I've try to upgrade my CS test platform from 4.1.1 to 4.2.0 (from Commit: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02 + CLVM issue cherry-pick from 4.2-forward with commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9.) The path 4.1.1-4.2.0 seems miss? 2013-09-11 14:32:55,619 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-09-11 14:32:55,631 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.0 2013-09-11 14:32:55,632 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.0 2013-09-11 14:32:55,632 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 4.1.1 to 4.2.0 2013-09-11 14:32:55,639 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.1.1 to 4.2.0 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:221) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:389) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- 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-4645) There is no upgrade path from 4.1.1 to 4.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765262#comment-13765262 ] Milamber commented on CLOUDSTACK-4645: -- Thanks for commit, but don't works. Below the SQL errors: 2013-09-12 09:07:07,796 INFO [utils.component.ComponentContext] (main:null) Configuring com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_3d484fca 2013-09-12 09:07:07,796 INFO [utils.component.ComponentContext] (main:null) Configuring com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_8fd5347a 2013-09-12 09:07:08,254 INFO [utils.component.ComponentContext] (main:null) Configuring com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_bb05ceef 2013-09-12 09:07:20,680 ERROR [utils.db.ScriptRunner] (Timer-1:null) Error executing: CREATE TABLE `cloud`.`vm_snapshots` ( `id` bigint(20) unsigned NOT NULL auto_increment COMMENT 'Primary Key', `uuid` varchar(40) NOT NULL, `name` varchar(255) NOT NULL, `display_name` varchar(255) default NULL, `description` varchar(255) default NULL, `vm_id` bigint(20) unsigned NOT NULL, `account_id` bigint(20) unsigned NOT NULL, `domain_id` bigint(20) unsigned NOT NULL, `vm_snapshot_type` varchar(32) default NULL, `state` varchar(32) NOT NULL, `parent` bigint unsigned default NULL, `current` int(1) unsigned default NULL, `update_count` bigint unsigned NOT NULL DEFAULT 0, `updated` datetime default NULL, `created` datetime default NULL, `removed` datetime default NULL, PRIMARY KEY (`id`), CONSTRAINT UNIQUE KEY `uc_vm_snapshots_uuid` (`uuid`), INDEX `vm_snapshots_name` (`name`), INDEX `vm_snapshots_vm_id` (`vm_id`), INDEX `vm_snapshots_account_id` (`account_id`), INDEX `vm_snapshots_display_name` (`display_name`), INDEX `vm_snapshots_removed` (`removed`), INDEX `vm_snapshots_parent` (`parent`), CONSTRAINT `fk_vm_snapshots_vm_id__vm_instance_id` FOREIGN KEY `fk_vm_snapshots_vm_id__vm_instance_id` (`vm_id`) REFERENCES `vm_instance` (`id`), CONSTRAINT `fk_vm_snapshots_account_id__account_id` FOREIGN KEY `fk_vm_snapshots_account_id__account_id` (`account_id`) REFERENCES `account` (`id`), CONSTRAINT `fk_vm_snapshots_domain_id__domain_id` FOREIGN KEY `fk_vm_snapshots_domain_id__domain_id` (`domain_id`) REFERENCES `domain` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 2013-09-12 09:07:20,680 ERROR [utils.db.ScriptRunner] (Timer-1:null) com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists 2013-09-12 09:07:20,682 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-411to420.sql com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:232) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:293) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:422) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) 2013-09-12 09:07:20,683 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Unable to upgrade the database com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade script: /usr/share/cloudstack-management/setup/db/schema-411to420.sql at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:241) at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:293) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:422) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'vm_snapshots' already exists at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193) at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87) at com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:232) ... 6 more 2013-09-12 09:07:20,685 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup
[jira] [Commented] (CLOUDSTACK-4645) There is no upgrade path from 4.1.1 to 4.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765546#comment-13765546 ] Milamber commented on CLOUDSTACK-4645: -- Perhaps that is a remaining from my previous test... Sorry I can't put DB dump (security issue for some private data even if it's test platform) In all case, I've suppose that adding the drop table before will not be a problem if that is the first introduction of this table in the database. There is no upgrade path from 4.1.1 to 4.2.0 Key: CLOUDSTACK-4645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4645 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.2.0 Reporter: Milamber Assignee: Venkata Siva Vijayendra Bhamidipati Priority: Blocker I've try to upgrade my CS test platform from 4.1.1 to 4.2.0 (from Commit: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02 + CLVM issue cherry-pick from 4.2-forward with commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9.) The path 4.1.1-4.2.0 seems miss? 2013-09-11 14:32:55,619 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-09-11 14:32:55,631 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.0 2013-09-11 14:32:55,632 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.0 2013-09-11 14:32:55,632 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 4.1.1 to 4.2.0 2013-09-11 14:32:55,639 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.1.1 to 4.2.0 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:221) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:389) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- 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-4645) There is no upgrade path from 4.1.1 to 4.2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13764369#comment-13764369 ] Milamber commented on CLOUDSTACK-4645: -- From: Wei ZHOU ustcweiz...@gmail.com To: d...@cloudstack.apache.org d...@cloudstack.apache.org I do not find anything related in ./engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java, and no Upgrade411to420.java in ./engine/schema/src/com/cloud/upgrade/dao/ as well. This should be a blocker issue. There is no upgrade path from 4.1.1 to 4.2.0 Key: CLOUDSTACK-4645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4645 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.2.0 Reporter: Milamber Priority: Blocker I've try to upgrade my CS test platform from 4.1.1 to 4.2.0 (from Commit: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02 + CLVM issue cherry-pick from 4.2-forward with commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9.) The path 4.1.1-4.2.0 seems miss? 2013-09-11 14:32:55,619 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-09-11 14:32:55,631 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.0 2013-09-11 14:32:55,632 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.0 2013-09-11 14:32:55,632 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 4.1.1 to 4.2.0 2013-09-11 14:32:55,639 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.1.1 to 4.2.0 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:221) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:389) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- 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-4645) There is no upgrade path from 4.1.1 to 4.2.0
Milamber created CLOUDSTACK-4645: Summary: There is no upgrade path from 4.1.1 to 4.2.0 Key: CLOUDSTACK-4645 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4645 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.2.0 Reporter: Milamber Priority: Blocker I've try to upgrade my CS test platform from 4.1.1 to 4.2.0 (from Commit: e39a7d8e0d3f2fd3e326b1bdf4aaf9ba5d900b02 + CLVM issue cherry-pick from 4.2-forward with commitId f2c5b5fbfe45196dfad2821fca513ddd6efa25c9.) The path 4.1.1-4.2.0 seems miss? 2013-09-11 14:32:55,619 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Grabbing lock to check for database upgrade. 2013-09-11 14:32:55,631 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 4.1.1 Code Version = 4.2.0 2013-09-11 14:32:55,632 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 4.1.1 to 4.2.0 2013-09-11 14:32:55,632 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 4.1.1 to 4.2.0 2013-09-11 14:32:55,639 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to startup com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.1.1 to 4.2.0 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:221) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:389) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:90) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- 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-3535) No HA actions are performed when a KVM host goes offline
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13751499#comment-13751499 ] Milamber commented on CLOUDSTACK-3535: -- Paul, You have made your test with CS 4.2? or another version? No HA actions are performed when a KVM host goes offline Key: CLOUDSTACK-3535 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.1.0, 4.1.1, 4.2.0 Environment: KVM (CentOS 6.3) with CloudStack 4.1 Reporter: Paul Angus Assignee: edison su Priority: Blocker Fix For: 4.2.0 Attachments: extract-management-server.log.2013-08-09, KVM-HA-4.1.1.2013-08-09-v1.patch, management-server.log.Agent If a KVM host 'goes down', CloudStack does not perform HA for instances which are marked as HA enabled on that host (including system VMs) CloudStack does not show the host as disconnected. -- 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-3535) No HA actions are performed when a KVM host goes offline
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736736#comment-13736736
]
Milamber commented on CLOUDSTACK-3535:
--
I try to backport this patch on 4.1 branch (I attach the patch file). I've
tested this patch with 4.1.1 tag (4.1.1+patch only) but the KVM HA don't works
when I pulls off the ethernet cable.
Here the logs:
2013-08-09 18:29:20,418 INFO [agent.manager.AgentMonitor] (Thread-6:null)
Found the following agents behind on ping: [10]
2013-08-09 18:29:20,430 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-3:null) Investigating why host 10 has disconnected with event
PingTimeout
2013-08-09 18:30:20,423 INFO [agent.manager.AgentMonitor] (Thread-6:null)
Found the following agents behind on ping: [10]
2013-08-09 18:30:20,428 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Investigating why host 10 has disconnected with event
PingTimeout
2013-08-09 18:31:00,447 INFO [utils.exception.CSExceptionErrorCode]
(AgentTaskPool-3:null) Could not find exception:
com.cloud.exception.OperationTimedoutException in error code list for exceptions
2013-08-09 18:31:00,448 WARN [agent.manager.AgentAttache]
(AgentTaskPool-3:null) Seq 10-1119682615: Timed out on Seq 10-1119682615: {
Cmd , MgmtId: 158525531671, via: 10, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-08-09 18:31:00,448 WARN [agent.manager.AgentManagerImpl]
(AgentTaskPool-3:null) Operation timed out: Commands 1119682615 to Host 10
timed out after 100
2013-08-09 18:31:12,722 WARN [agent.manager.AgentManagerImpl]
(AgentTaskPool-3:null) Unsupported Command: Unsupported command
issued:com.cloud.agent.api.CheckOnHostCommand. Are you sure you got the right
type of server?
2013-08-09 18:31:12,722 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-3:null) The state determined is Up
2013-08-09 18:31:12,722 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-3:null) Agent is determined to be up and running
2013-08-09 18:31:20,427 INFO [agent.manager.AgentMonitor] (Thread-6:null)
Found the following agents behind on ping: [10]
2013-08-09 18:31:20,431 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-5:null) Investigating why host 10 has disconnected with event
PingTimeout
2013-08-09 18:32:00,433 INFO [utils.exception.CSExceptionErrorCode]
(AgentTaskPool-4:null) Could not find exception:
com.cloud.exception.OperationTimedoutException in error code list for exceptions
2013-08-09 18:32:00,434 WARN [agent.manager.AgentAttache]
(AgentTaskPool-4:null) Seq 10-1119682616: Timed out on Seq 10-1119682616: {
Cmd , MgmtId: 158525531671, via: 10, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-08-09 18:32:00,434 WARN [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Operation timed out: Commands 1119682616 to Host 10
timed out after 100
2013-08-09 18:32:05,710 WARN [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Unsupported Command: Unsupported command
issued:com.cloud.agent.api.CheckOnHostCommand. Are you sure you got the right
type of server?
2013-08-09 18:32:05,711 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) The state determined is Up
2013-08-09 18:32:05,711 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Agent is determined to be up and running
2013-08-09 18:32:20,431 INFO [agent.manager.AgentMonitor] (Thread-6:null)
Found the following agents behind on ping: [10]
2013-08-09 18:32:20,435 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-6:null) Investigating why host 10 has disconnected with event
PingTimeout
After pull on the cable, the VM-HA are restarted to another host.
No HA actions are performed when a KVM host goes offline
Key: CLOUDSTACK-3535
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, KVM, Management Server
Affects Versions: 4.1.0, 4.1.1, 4.2.0
Environment: KVM (CentOS 6.3) with CloudStack 4.1
Reporter: Paul Angus
Assignee: edison su
Priority: Blocker
Fix For: 4.2.0
Attachments: KVM-HA-4.1.1.2013-08-09-v1.patch,
management-server.log.Agent
If a KVM host 'goes down', CloudStack does not perform HA for instances which
are marked as HA enabled on that host (including system VMs)
CloudStack does not show the host as disconnected.
--
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-3535) No HA actions are performed when a KVM host goes offline
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-3535: - Attachment: KVM-HA-4.1.1.2013-08-09-v1.patch Backport CLOUDSTACK-3535 on 4.1.1 tag No HA actions are performed when a KVM host goes offline Key: CLOUDSTACK-3535 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.1.0, 4.1.1, 4.2.0 Environment: KVM (CentOS 6.3) with CloudStack 4.1 Reporter: Paul Angus Assignee: edison su Priority: Blocker Fix For: 4.2.0 Attachments: KVM-HA-4.1.1.2013-08-09-v1.patch, management-server.log.Agent If a KVM host 'goes down', CloudStack does not perform HA for instances which are marked as HA enabled on that host (including system VMs) CloudStack does not show the host as disconnected. -- 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-3535) No HA actions are performed when a KVM host goes offline
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-3535: - Attachment: extract-management-server.log.2013-08-09 Full log with 4.1.1+patch No HA actions are performed when a KVM host goes offline Key: CLOUDSTACK-3535 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, KVM, Management Server Affects Versions: 4.1.0, 4.1.1, 4.2.0 Environment: KVM (CentOS 6.3) with CloudStack 4.1 Reporter: Paul Angus Assignee: edison su Priority: Blocker Fix For: 4.2.0 Attachments: extract-management-server.log.2013-08-09, KVM-HA-4.1.1.2013-08-09-v1.patch, management-server.log.Agent If a KVM host 'goes down', CloudStack does not perform HA for instances which are marked as HA enabled on that host (including system VMs) CloudStack does not show the host as disconnected. -- 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-688) UI Russian language
[ https://issues.apache.org/jira/browse/CLOUDSTACK-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-688: Fix Version/s: 4.1.0 4.1.1 UI Russian language --- Key: CLOUDSTACK-688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-688 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.0.0, 4.0.1 Environment: previous - CS 4.0.0. build 1234 current - CS 4.0.1 build 11 CentOS 6.3 x86_64 Reporter: Richard Shevel Priority: Trivial Fix For: 4.1.0, 4.1.1 Attachments: 1a.png, 2a.png, 3b.png When I select the Russian language and click on the login button, the interface is no longer drawn see screenshots error is present in any web browser such as : FF, IE, Chrome, Opera, Safari -- 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-688) UI Russian language
[ https://issues.apache.org/jira/browse/CLOUDSTACK-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber resolved CLOUDSTACK-688. - Resolution: Fixed Assignee: Milamber Already fixed UI Russian language --- Key: CLOUDSTACK-688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-688 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.0.0, 4.0.1 Environment: previous - CS 4.0.0. build 1234 current - CS 4.0.1 build 11 CentOS 6.3 x86_64 Reporter: Richard Shevel Assignee: Milamber Priority: Trivial Fix For: 4.1.1, 4.1.0 Attachments: 1a.png, 2a.png, 3b.png When I select the Russian language and click on the login button, the interface is no longer drawn see screenshots error is present in any web browser such as : FF, IE, Chrome, Opera, Safari -- 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-1780) Client UI: i18N files (messages_xx_XX.properties) needs to be convert in ASCII with unicode char \uxxxx (and perhaps keys needs to be in alphabetical order)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber updated CLOUDSTACK-1780: - Fix Version/s: 4.1.0 4.2.0 4.1.1 Client UI: i18N files (messages_xx_XX.properties) needs to be convert in ASCII with unicode char \u (and perhaps keys needs to be in alphabetical order) Key: CLOUDSTACK-1780 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1780 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.1.0, 4.2.0 Reporter: Milamber Assignee: Milamber Labels: i18n, translation, Fix For: 4.1.0, 4.1.1, 4.2.0 In 4.1 branch, the current file encoding for messages properties files don't allow a correct display in Client UI for non-latin / latin translation (except FR already patched). * The tools native2ascii (provide by jdk) can be used to convert the files with character encoded with the unicode code (\u) * To allow better diff in future, and avoid duplicate (currently they have some duplicates keys in EN file), it's would be better to have an alphabetical order. * The tools I18Nedit can edit all messages files, to make alphabetical order, make translation directly in unicode char and preserve the unicode char when saving.t -- 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-1783) Alteration of some messages i18n files (ja, zh_CN ...) since last commit with transifex export files
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milamber resolved CLOUDSTACK-1783. -- Resolution: Fixed Alrefeady fixed Alteration of some messages i18n files (ja, zh_CN ...) since last commit with transifex export files Key: CLOUDSTACK-1783 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1783 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.1.0, 4.2.0 Reporter: Milamber Assignee: Milamber Labels: i18n, translation, Fix For: 4.1.1, 4.2.0 Attachments: Selection_005.jpg, Selection_007.jpg, Selection_008.jpg Example for JA translation, last commit have altered a lot of values (exemple: the value of key confirm.enable.swift). This issue seems come with the transifex. Currently in transifex, this value isn't displaying correctly. In previous commit, the value is correct (see screenshot) -- 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
