[jira] [Closed] (CLOUDSTACK-8702) HttpUtils: refactor/add method to validate http session
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-8702. --- Resolution: Fixed Merged on master and 4.5 > HttpUtils: refactor/add method to validate http session > --- > > Key: CLOUDSTACK-8702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8702 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > The method that does sessionkey checks in apiservlet needs to be refactored > and move to httputils to be accessed by other api authenticator apicmds -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696587#comment-14696587 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 1e3e67451489789949e1b50e1f0732bcba0596b5 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e3e674 ] CLOUDSTACK-8701: Add administrative contact block as per SAML IDP expectations Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696589#comment-14696589 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 5f06ef77d8275602a45285c64854314d5ec9dbf5 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5f06ef7 ] CLOUDSTACK-8701: Add unit test for SAML2AuthManagerImpl Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696588#comment-14696588 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit b30977911dbfb1eae86d53ff1b848c5812b68c07 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b309779 ] CLOUDSTACK-8701: Add listandswitchsamlaccount API test and add boundary checks - Adds unit test for ListAndSwitchSAMLAccountCmd - Checks and logs in user only if they are enabled - If saml user switches to a locked account, send appropriate error message Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696586#comment-14696586 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit a3e6942e854230980e976294fa0686b85b6dd803 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a3e6942 ] CLOUDSTACK-8701: Add unit test for SAML2AuthManagerImpl (cherry picked from commit 5f06ef77d8275602a45285c64854314d5ec9dbf5) Signed-off-by: Rohit Yadav This closes #650 > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696585#comment-14696585 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 25ccf4126d4729c1361855eaeef8e58acdebc70f in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=25ccf41 ] CLOUDSTACK-8701: Add listandswitchsamlaccount API test and add boundary checks - Adds unit test for ListAndSwitchSAMLAccountCmd - Checks and logs in user only if they are enabled - If saml user switches to a locked account, send appropriate error message Signed-off-by: Rohit Yadav (cherry picked from commit b30977911dbfb1eae86d53ff1b848c5812b68c07) Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-8701. --- Resolution: Fixed Merged on master and 4.5 > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696543#comment-14696543 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 81e20ef22c1bedce9b302cd54f643316e501620c in cloudstack's branch refs/heads/4.5-samlfixes from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81e20ef ] CLOUDSTACK-8701: Add unit test for SAML2AuthManagerImpl Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14696454#comment-14696454
]
ASF GitHub Bot commented on CLOUDSTACK-8725:
Github user bvbharatk commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/692#discussion_r37048693
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsRedundant.py ---
@@ -96,7 +96,7 @@ def _redundant_on(self):
d = s.replace(".templ", "")
CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR, s),
"%s/%s" % (self.CS_ROUTER_DIR, d))
CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR,
"keepalived.conf.templ"), self.KEEPALIVED_CONF)
-CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR,
"conntrackd.conf.templ"), self.CONNTRACKD_CONF)
+CsHelper.copy("%s/%s" % (self.CS_TEMPLATES_DIR,
"conntrackd.conf.templ"), self.CONNTRACKD_CONF)
--- End diff --
Hi Daan,
This will be needed only in case of redundant router. The current code
tries to copy this file only if it is a rvr. It will not be copied for normal
routers.
> RVR functionality is broken in case of isolated networks, conntrackd fails to
> start.
>
>
> Key: CLOUDSTACK-8725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.6.0
>
>
> I tried setting up a rvr enabled isolated network. In the startup logs of the
> router i can see that conntrackd is failing to start. Below are the startup
> logs
> [info] Setting console screen modes.
> setterm: cannot (un)set powersave mode: Invalid argument
> [info] Skipping font and keymap setup (handled by console-setup).
> [] Loading IPsec SA/SP database:
> [ ok etc/ipsec-tools.conf.
> INIT: Entering runlevel: 2
> [info] Using makefile-style concurrent boot in runlevel 2.
> [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm.
> [ ok ] Loading iptables rules... IPv4... IPv6...done.
> [ ok ] Starting rpcbind daemon...[] Already running..
> sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
> open-vm-tools: not starting as this is not a VMware VM
> [ ok ] Starting enhanced syslogd: rsyslogd.
> [] Starting ACPI services...RTNETLINK1 answers: No such file or directory
> acpid: error talking to the kernel via netlink
> . ok
> [] Starting conntrackdERROR: parsing config file in line (102), symbol
> 'Multicast': syntax error
> failed!
> [ ok ] Starting DNS forwarder and DHCP server: dnsmasq.
> [] Starting web server: apache2apache2: Could not reliably determine the
> server's fully qualified domain name, using 10.1.1.247 for ServerName
> . ok
> [ ok ] Starting periodic command scheduler: cron.
> [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config :
> 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> . ok
> [FAIL] Starting keepalived: keepalived failed!
> [ ok ] Starting NTP server: ntpd.
> [ ok ] Starting OpenBSD Secure Shell server: sshd.
> [ ok ] Starting the system activity data collector: sadc.
> Detecting Linux distribution version: OK
> Starting xe daemon: OK
> [ ok ] Starting OpenBSD Secure Shell server: sshd.
> [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config :
> 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> . ok
> [] Starting web server: apache2apache2: Could not reliably determine the
> server's fully qualified domain name, using 10.1.1.247 for ServerName
> httpd (pid 3351) already running
> . ok
> [FAIL] Starting keepalived: keepalived failed!
> [] Starting conntrackdERROR: parsing config file in line (102), symbol
> 'Multicast': syntax error
> failed!
> sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
> Failed
> [ ok ] Stopping NFS common utilities: idmapd statd.
> -On router.
> root@r-93-VM:~# service conntra
[jira] [Updated] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma updated CLOUDSTACK-8710: - Assignee: Jayapal Reddy (was: Remi Bergsma) > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695749#comment-14695749 ] ASF GitHub Bot commented on CLOUDSTACK-8710: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/690#issuecomment-130798498 Forgot to update this.. tested it and the rules are applied OK now. LGTM. I will add more firewall rules so the feature will work again. Let's also look at the tests (if any). > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695181#comment-14695181
]
ASF GitHub Bot commented on CLOUDSTACK-8725:
Github user DaanHoogland commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/692#discussion_r36970870
--- Diff: systemvm/patches/debian/config/opt/cloud/bin/cs/CsRedundant.py ---
@@ -96,7 +96,7 @@ def _redundant_on(self):
d = s.replace(".templ", "")
CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR, s),
"%s/%s" % (self.CS_ROUTER_DIR, d))
CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR,
"keepalived.conf.templ"), self.KEEPALIVED_CONF)
-CsHelper.copy_if_needed("%s/%s" % (self.CS_TEMPLATES_DIR,
"conntrackd.conf.templ"), self.CONNTRACKD_CONF)
+CsHelper.copy("%s/%s" % (self.CS_TEMPLATES_DIR,
"conntrackd.conf.templ"), self.CONNTRACKD_CONF)
--- End diff --
would it make sense to make sure it is marked as needed, or is this always
needed (even in non redundant routers)?
> RVR functionality is broken in case of isolated networks, conntrackd fails to
> start.
>
>
> Key: CLOUDSTACK-8725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.6.0
>
>
> I tried setting up a rvr enabled isolated network. In the startup logs of the
> router i can see that conntrackd is failing to start. Below are the startup
> logs
> [info] Setting console screen modes.
> setterm: cannot (un)set powersave mode: Invalid argument
> [info] Skipping font and keymap setup (handled by console-setup).
> [] Loading IPsec SA/SP database:
> [ ok etc/ipsec-tools.conf.
> INIT: Entering runlevel: 2
> [info] Using makefile-style concurrent boot in runlevel 2.
> [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm.
> [ ok ] Loading iptables rules... IPv4... IPv6...done.
> [ ok ] Starting rpcbind daemon...[] Already running..
> sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
> open-vm-tools: not starting as this is not a VMware VM
> [ ok ] Starting enhanced syslogd: rsyslogd.
> [] Starting ACPI services...RTNETLINK1 answers: No such file or directory
> acpid: error talking to the kernel via netlink
> . ok
> [] Starting conntrackdERROR: parsing config file in line (102), symbol
> 'Multicast': syntax error
> failed!
> [ ok ] Starting DNS forwarder and DHCP server: dnsmasq.
> [] Starting web server: apache2apache2: Could not reliably determine the
> server's fully qualified domain name, using 10.1.1.247 for ServerName
> . ok
> [ ok ] Starting periodic command scheduler: cron.
> [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config :
> 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> . ok
> [FAIL] Starting keepalived: keepalived failed!
> [ ok ] Starting NTP server: ntpd.
> [ ok ] Starting OpenBSD Secure Shell server: sshd.
> [ ok ] Starting the system activity data collector: sadc.
> Detecting Linux distribution version: OK
> Starting xe daemon: OK
> [ ok ] Starting OpenBSD Secure Shell server: sshd.
> [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config :
> 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
> [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy
> 'cloud-default' as it requires HTTP mode.
> . ok
> [] Starting web server: apache2apache2: Could not reliably determine the
> server's fully qualified domain name, using 10.1.1.247 for ServerName
> httpd (pid 3351) already running
> . ok
> [FAIL] Starting keepalived: keepalived failed!
> [] Starting conntrackdERROR: parsing config file in line (102), symbol
> 'Multicast': syntax error
> failed!
> sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
> Failed
> [ ok ] Stopping NFS common utilities: idmapd statd.
> -On router.
> root@r-93-VM:~# service conntrackd restart
> [] Stopping conntrackdERROR: parsing conf
[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695175#comment-14695175 ] ASF GitHub Bot commented on CLOUDSTACK-8725: GitHub user bvbharatk opened a pull request: https://github.com/apache/cloudstack/pull/692 CLOUDSTACK-8725 RVR functionality is broken in case of isolated netwo… CLOUDSTACK-8725 RVR functionality is broken in case of isolated networks, conntrackd fails to start. You can merge this pull request into a Git repository by running: $ git pull https://github.com/bvbharatk/cloudstack CLOUDSTACK-8725 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/692.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #692 commit fbebfd76ca774281e80c72e9141cd179a9d31bed Author: Bharat Kumar Date: 2015-08-13T12:28:15Z CLOUDSTACK-8725 RVR functionality is broken in case of isolated networks, conntrackd fails to start. > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.6.0 > > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695173#comment-14695173 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 38d6baee862a87e05c793fbc26f167469dca7aae in cloudstack's branch refs/heads/4.5-samlfixes from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=38d6bae ] CLOUDSTACK-8701: Add listandswitchsamlaccount API test and add boundary checks - Adds unit test for ListAndSwitchSAMLAccountCmd - Checks and logs in user only if they are enabled - If saml user switches to a locked account, send appropriate error message Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695172#comment-14695172 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit 3a8785b7c05a20b0b33bc506c5be74a845a6 in cloudstack's branch refs/heads/4.5-samlfixes from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3a8785b ] CLOUDSTACK-8701: Add administrative contact block as per SAML IDP expectations Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695170#comment-14695170 ] ASF GitHub Bot commented on CLOUDSTACK-8580: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/680#issuecomment-130659980 @remibergsma Done. > Users should be able to expunge VMs > --- > > Key: CLOUDSTACK-8580 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Lennert den Teuling >Priority: Minor > > When automating deployments of CloudStack (with for example Terraform) there > are situations where VMs get recreated with the same name (and hostname). > When VMs are destroyed by a user, the name will be reserved on the network > until the VM truly gets expunged (depending on expunge.delay). Because of > this, some automation tools cannot work because a new deployment with the > same name gives an error. > Users do not have the ability to directly expunge VMs (Only admin and > domain-admins can), but they can destroy them and the admin can configure the > expunge.delay where VMs truly get removed (expunged). > Working with the expunge delay is very safe in case users accidentally remove > a VM, but in some cases (when users know what they are doing) there should > also be a option to completely remove the VM when destroying it (expunge). > Ideally the admin should be able to configure this behavior trough the global > settings, cause i believe the admin deliberately needs to turn it on (off by > default). > We have looked into making our clients domain-admin by default, but that > gives them abilities we do not want to give, so we see no other way then just > enabling expunge for the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8701) Allow SAML users to switch accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695171#comment-14695171 ] ASF subversion and git services commented on CLOUDSTACK-8701: - Commit a1a6bc7dc9d06f73063ff03bb91cccacf84fa7d8 in cloudstack's branch refs/heads/4.5-samlfixes from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1a6bc7 ] CLOUDSTACK-8701: Allow SAML users to switch accounts SAML authorized accounts might be across various domains, this allows for switching of accounts only in case of SAML authenticated user accounts across other accounts with the same SAML uid/username. Moves the previous switch account logic to its own ui-custom module Signed-off-by: Rohit Yadav > Allow SAML users to switch accounts > --- > > Key: CLOUDSTACK-8701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8701 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0, 4.5.2 > > > SAML authenticated users may have multiple accounts across domains as there > may be user accounts with same usernames, the current way in 4.5/master is to > grab the domain information beforehand which provides a bad UX as users would > need to remember their domain path names (difficult than remembering the > domain name). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8580) Users should be able to expunge VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695162#comment-14695162 ] ASF GitHub Bot commented on CLOUDSTACK-8580: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/680#issuecomment-130656396 @borisroman Please squash the commits here as well > Users should be able to expunge VMs > --- > > Key: CLOUDSTACK-8580 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8580 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Lennert den Teuling >Priority: Minor > > When automating deployments of CloudStack (with for example Terraform) there > are situations where VMs get recreated with the same name (and hostname). > When VMs are destroyed by a user, the name will be reserved on the network > until the VM truly gets expunged (depending on expunge.delay). Because of > this, some automation tools cannot work because a new deployment with the > same name gives an error. > Users do not have the ability to directly expunge VMs (Only admin and > domain-admins can), but they can destroy them and the admin can configure the > expunge.delay where VMs truly get removed (expunged). > Working with the expunge delay is very safe in case users accidentally remove > a VM, but in some cases (when users know what they are doing) there should > also be a option to completely remove the VM when destroying it (expunge). > Ideally the admin should be able to configure this behavior trough the global > settings, cause i believe the admin deliberately needs to turn it on (off by > default). > We have looked into making our clients domain-admin by default, but that > gives them abilities we do not want to give, so we see no other way then just > enabling expunge for the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695160#comment-14695160 ] Rohit Yadav commented on CLOUDSTACK-8669: - we can revert it or work around that findbug fix. > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > --- > > Key: CLOUDSTACK-8669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWares >Reporter: Sanjeev N >Assignee: Rajani Karuturi >Priority: Critical > Attachments: management-server.zip > > > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy one guest vm using default cent os template > 3.Create one data disk with shared disk offering > 4.Attach the data disk to the vm created in step 2 > Result: > = > Attach volume failed with NPE: > 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > 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.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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received: > 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) > Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, > via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq > 2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported > data object (VOLUME, > org.apache.cloudstack.st
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695155#comment-14695155 ] ASF GitHub Bot commented on CLOUDSTACK-8710: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/690#issuecomment-130654437 @jayapalu happy you're helping out! If you found out more stuff already, feel free to post. Thanks! :-) > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland reopened CLOUDSTACK-8656: --- not done by far, though the commits so far did get us through a long list. > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695149#comment-14695149 ] Rajani Karuturi commented on CLOUDSTACK-8669: - The root cause for CLOUDSTACK-8671 and CLOUDSTACK-8669 is same. Its a regression from the below commit. commit f03411ca0436c8b52f5e60b0c8820fd1d1ba2ff6 Author: Rafael da Fonseca AuthorDate: Sun Jun 14 12:31:06 2015 +0200 Commit: Rohit Yadav CommitDate: Mon Jun 15 12:05:16 2015 +0300 Fix 2 findbugs encoding warnings in VmwareContext.java StreamReaders should use encoding specified in the connection object Signed-off-by: Rohit Yadav This closes #405 > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > --- > > Key: CLOUDSTACK-8669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWares >Reporter: Sanjeev N >Assignee: Rajani Karuturi >Priority: Critical > Attachments: management-server.zip > > > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy one guest vm using default cent os template > 3.Create one data disk with shared disk offering > 4.Attach the data disk to the vm created in step 2 > Result: > = > Attach volume failed with NPE: > 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > 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.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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received: > 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) > Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, > via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:06:58,105 DEBU
[jira] [Commented] (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-tabpanel&focusedCommentId=14695140#comment-14695140 ] ASF GitHub Bot commented on CLOUDSTACK-8427: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/686#issuecomment-130646010 LGTM > 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-8209) VM migration fails across KVM hosts if hosts have same hostname even if different libvirt uuid or IPs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695138#comment-14695138
]
Rohit Yadav commented on CLOUDSTACK-8209:
-
A simple fix could be to make UUID from bytes based on hostname+ip; will try to
get a fix; though it's a minor improvement, and not a major bug.
> VM migration fails across KVM hosts if hosts have same hostname even if
> different libvirt uuid or IPs
> -
>
> Key: CLOUDSTACK-8209
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8209
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.6.0, 4.5.2
>
>
> In case KVM hosts have same hostname but different libvirtd host uuid or IPs,
> VM migration fails with:
> 2015-02-04 15:22:18,042 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-13:ctx-ae4c1ba1 job-37/job-38) Unable to complete
> AsyncJobVO {id:38, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwACcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 5071960016, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Feb 04 15:22:15 IST 2015}, job origin:37
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: internal error: Attempt to migrate guest to the
> same host kvm-test
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1956)
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1854)
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4501)
> >---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:4633)
> >---at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
> >
> >---at
> >org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
> >---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:493)
> >---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)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8322) Make Python based password server use SSL cert and listen on secure socket (443, or 4443) if enabled by admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695136#comment-14695136 ] Rohit Yadav commented on CLOUDSTACK-8322: - Running the password server on https has all sorts of certificate and backward compatibility issues (wrt the client/user vm scripts), will do it future when those are quite clear. For now, the python based password server is significantly better than the socat based one. > Make Python based password server use SSL cert and listen on secure socket > (443, or 4443) if enabled by admin > - > > Key: CLOUDSTACK-8322 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8322 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future > > > VR can pick same SSL cert used for CPVM/SSVM and use that to listen on a > secure socket (along with the HTTP port) to serve password. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8043) Have all CloudStack tables's primary keys auto-increment to avoid multi-master DB setup issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-8043. --- > Have all CloudStack tables's primary keys auto-increment to avoid > multi-master DB setup issues > -- > > Key: CLOUDSTACK-8043 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8043 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > In multi-master DB setup, tables where primary keys don't auto-increment can > conflict in case of concurrent insert operations. This was partially fixed in > https://issues.apache.org/jira/browse/CLOUDSTACK-6212 > The following tables have a primary key without the auto_increment flag, > should we alter those columns to have auto_increment? > cluster_vsm_map > op_host > op_host_tranfer > op_host_upgrade > op_it_work > op_lock > op_networks > op_router_monitoring_services > op_user_stats_log > user_vm_clone_setting > vm_work_job -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8349) Implement a general purpose VR-UserVM Agents Framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8349: Fix Version/s: (was: 4.6.0) Future > Implement a general purpose VR-UserVM Agents Framework > -- > > Key: CLOUDSTACK-8349 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8349 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future > > > Scope and Design Doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework > Aims to: > - Refactor VR codebase, provide better test-ability and scalability in > developing features in VR and for user VMs > - Provide user VM based granular orchestration such as reset password, reset > SSH key, installation of software such as monitoring and backup etc. > - Secure/TLS based connection between VR and user VMs > - Easy to use orchestration based on Ansible, Chef or Puppet and recipes > based on that > - Provides a way to monitor VR and do VR VM maintenance such as upgrade > packages and apply security patches (such as openssl packages), cleanup > /var/log files and monitor VR health > - Available in Isolated, VPC and Shared networks > - Make it easier for sys admins to debug issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8322) Make Python based password server use SSL cert and listen on secure socket (443, or 4443) if enabled by admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8322: Fix Version/s: (was: 4.6.0) Future > Make Python based password server use SSL cert and listen on secure socket > (443, or 4443) if enabled by admin > - > > Key: CLOUDSTACK-8322 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8322 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future > > > VR can pick same SSL cert used for CPVM/SSVM and use that to listen on a > secure socket (along with the HTTP port) to serve password. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8349) Implement a general purpose VR-UserVM Agents Framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695134#comment-14695134 ] Rohit Yadav commented on CLOUDSTACK-8349: - Post 4.6, maybe 4.7 or later > Implement a general purpose VR-UserVM Agents Framework > -- > > Key: CLOUDSTACK-8349 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8349 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future > > > Scope and Design Doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework > Aims to: > - Refactor VR codebase, provide better test-ability and scalability in > developing features in VR and for user VMs > - Provide user VM based granular orchestration such as reset password, reset > SSH key, installation of software such as monitoring and backup etc. > - Secure/TLS based connection between VR and user VMs > - Easy to use orchestration based on Ansible, Chef or Puppet and recipes > based on that > - Provides a way to monitor VR and do VR VM maintenance such as upgrade > packages and apply security patches (such as openssl packages), cleanup > /var/log files and monitor VR health > - Available in Isolated, VPC and Shared networks > - Make it easier for sys admins to debug issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8671. - Resolution: Duplicate The root cause for CLOUDSTACK-8671 and CLOUDSTACK-8669 is same. Its a regression from the below commit. closing this and keeping the other one open. commit f03411ca0436c8b52f5e60b0c8820fd1d1ba2ff6 Author: Rafael da Fonseca AuthorDate: Sun Jun 14 12:31:06 2015 +0200 Commit: Rohit Yadav CommitDate: Mon Jun 15 12:05:16 2015 +0300 Fix 2 findbugs encoding warnings in VmwareContext.java StreamReaders should use encoding specified in the connection object Signed-off-by: Rohit Yadav This closes #405 > [VMWare] VM deployment from iso fails > - > > Key: CLOUDSTACK-8671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, VMware >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWare >Reporter: Sanjeev N >Assignee: Rajani Karuturi >Priority: Critical > Attachments: management-server.zip > > > Failed to deploy vm from ISO > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Register one bootable iso > 3.Try to deploy vm using that iso > Result: > == > VM Deployment failed due to failure in creating volume: > 2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > 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.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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received: > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing: { Ans: > , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq > 2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 201
[jira] [Assigned] (CLOUDSTACK-8669) [VMWare] create volume failed due to Exception: java.lang.NullPointerException Message: charsetName
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reassigned CLOUDSTACK-8669: --- Assignee: Rajani Karuturi > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > --- > > Key: CLOUDSTACK-8669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8669 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Volumes >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWares >Reporter: Sanjeev N >Assignee: Rajani Karuturi >Priority: Critical > Attachments: management-server.zip > > > [VMWare] create volume failed due to Exception: > java.lang.NullPointerException Message: charsetName > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Deploy one guest vm using default cent os template > 3.Create one data disk with shared disk offering > 4.Attach the data disk to the vm created in step 2 > Result: > = > Attach volume failed with NPE: > 2015-07-23 16:06:58,103 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-64:ctx-6becb596 10.81.28.111, job-48/job-49, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > 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.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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:06:58,104 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-64:ctx-6becb596) Seq 2-8089027880710832216: Response Received: > 2015-07-23 16:06:58,104 DEBUG [c.c.a.t.Request] (DirectAgent-64:ctx-6becb596) > Seq 2-8089027880710832216: Processing: { Ans: , MgmtId: 187822473365406, > via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:06:58,105 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Seq > 2-8089027880710832216: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 2015-07-23 16:06:58,112 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (Work-Job-Executor-10:ctx-d0586dc9 job-48/job-49 ctx-7737cd68) Unsupported > data object (VOLUME, > org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@58dd2323), no > need to d
[jira] [Assigned] (CLOUDSTACK-8671) [VMWare] VM deployment from iso fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reassigned CLOUDSTACK-8671: --- Assignee: Rajani Karuturi > [VMWare] VM deployment from iso fails > - > > Key: CLOUDSTACK-8671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8671 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, VMware >Affects Versions: 4.6.0 > Environment: Latest build from ACS master with commit > 2984acca83fff03c2ad8bdd28c097e797d4ce087 > Hypervisor: VMWare >Reporter: Sanjeev N >Assignee: Rajani Karuturi >Priority: Critical > Attachments: management-server.zip > > > Failed to deploy vm from ISO > Steps to reproduce: > > 1.Bring up CS in advanced zone with vmware cluster > 2.Register one bootable iso > 3.Try to deploy vm using that iso > Result: > == > VM Deployment failed due to failure in creating volume: > 2015-07-23 16:48:29,712 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-196:ctx-18de08d8 10.81.28.111, job-322/job-323, cmd: > CreateObjectCommand) create volume failed due to Exception: > java.lang.NullPointerException > Message: charsetName > java.lang.NullPointerException: charsetName > at java.io.InputStreamReader.(InputStreamReader.java:99) > at > com.cloud.hypervisor.vmware.util.VmwareContext.uploadResourceContent(VmwareContext.java:486) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.detachDisk(VirtualMachineMO.java:1217) > at > com.cloud.storage.resource.VmwareStorageProcessor.createVolume(VmwareStorageProcessor.java:1545) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:113) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:56) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:470) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:302) > 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.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.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2015-07-23 16:48:29,713 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Response Received: > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (DirectAgent-196:ctx-18de08d8) Seq 2-8089027880710832600: Processing: { Ans: > , MgmtId: 187822473365406, via: 2, Ver: v1, Flags: 10, > [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"result":false,"details":"java.lang.NullPointerException: > charsetName","wait":0}}] } > 2015-07-23 16:48:29,713 DEBUG [c.c.a.t.Request] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Seq > 2-8089027880710832600: Received: { Ans: , MgmtId: 187822473365406, via: 2, > Ver: v1, Flags: 10, { CreateObjectAnswer } } > 2015-07-23 16:48:29,720 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unsupported > data object (VOLUME, > org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@392f6f34), no > need to delete from object in store ref table > 2015-07-23 16:48:29,720 DEBUG [o.a.c.e.o.VolumeOrchestrator] > (Work-Job-Executor-113:ctx-a7571bd0 job-322/job-323 ctx-e5ca76c6) Unable to > create Vol[55|vm=50|ROOT]:java.lang.NullPointerException: charsetName >
[jira] [Commented] (CLOUDSTACK-8731) automation:checking usage event generation for delete volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695114#comment-14695114 ] ASF GitHub Bot commented on CLOUDSTACK-8731: GitHub user cloudsadhu opened a pull request: https://github.com/apache/cloudstack/pull/691 CLOUDSTACK-8731-checking usage event for delete volume @summary: Test volume delete event generation in error state condition ... === TestName: test_volume_delete_event_errorState | Status : SUCCESS === ok -- Ran 1 test in 490.221s OK You can merge this pull request into a Git repository by running: $ git pull https://github.com/cloudsadhu/cloudstack cs Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/691.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #691 commit 84c6d7fcb62dbb0886345bd9d14a0bdb980f61b5 Author: sadhu Date: 2015-08-13T11:36:04Z CLOUDSTACK-8731-checking usage event for delete volume > automation:checking usage event generation for delete volume > > > Key: CLOUDSTACK-8731 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8731 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sadhu suresh >Assignee: sadhu suresh > > usage event not generated for delete volume when VM creation failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8150) No MySQL-HA package in debian builds
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8150: Priority: Major (was: Critical) > No MySQL-HA package in debian builds > > > Key: CLOUDSTACK-8150 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8150 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > There is mysql-ha package in rpm builds but not in debian builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8150) No MySQL-HA package in debian builds
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-8150: --- Assignee: (was: Rohit Yadav) > No MySQL-HA package in debian builds > > > Key: CLOUDSTACK-8150 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8150 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav > Fix For: 4.6.0 > > > There is mysql-ha package in rpm builds but not in debian builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8150) No MySQL-HA package in debian builds
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8150: Fix Version/s: (was: 4.5.2) > No MySQL-HA package in debian builds > > > Key: CLOUDSTACK-8150 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8150 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.6.0 > > > There is mysql-ha package in rpm builds but not in debian builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7364: Fix Version/s: (was: Future) > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-8133) Add instance count to listSecurityGroups API call.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Schrijver closed CLOUDSTACK-8133. --- Resolution: Fixed https://github.com/apache/cloudstack/pull/679 > Add instance count to listSecurityGroups API call. > -- > > Key: CLOUDSTACK-8133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8133 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Kevin Dierkx >Assignee: Boris Schrijver >Priority: Minor > Fix For: 4.6.0 > > > Currently the listSecurityGroups call doesn't return an instance count of > some sort. There is no way of knowing without polling all VMs if the security > group is empty and will result in an exception on removal. > It would be awesome if this information could be provided with the above call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8732) Unable to resize RBD volume: "Cannot determine resize type from pool type RBD"
Darren Worrall created CLOUDSTACK-8732:
--
Summary: Unable to resize RBD volume: "Cannot determine resize
type from pool type RBD"
Key: CLOUDSTACK-8732
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8732
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.1
Environment: Ubuntu 14.04, libvirt 1.2.2, qemu 2.0.0, ceph 0.94.2,
Cloudstack 4.5.1, Kernel 3.16.0, KVM hypervisor
Reporter: Darren Worrall
First time reporter, so apologies early on if I've gotten anything wrong here.
While trying to resize a RBD backed volume in our 4.5.1 installation (using the
{{resizeVolume}} api call), the job fails with the error above. A [pull
request|https://github.com/apache/cloudstack/pull/281] was merged in this space
but it seems incomplete - you can see that {{getResizeScriptType}} in the
source branch [returns
null|https://github.com/remibergsma/cloudstack/blob/a26bbc2ce2f99e706895f9c0bbc6bdb5a522c37f/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1824],
but currently in master the above exception [is
thrown|https://github.com/apache/cloudstack/blob/792c27c9bd97bc703ceb28fa8db24db7d0d46012/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1428]
You can see a management server log snippet
[here|https://gist.githubusercontent.com/DazWorrall/3bfcb153dea8b137f38b/raw/1f41096b247221e26b5407ae777f5fe278614d54/management-server.log],
compete with traces.
This was discussed on the [mailing
list|http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3ccamvtbpou4tkan2kzknzpl0scu3y032ghu3av2qzgtsfas3t...@mail.gmail.com%3E]
but I cant see if anything came of it. I can confirm the findings there though
- going underneath Cloudstack and dealing with libvirt directly works fine, I
can live resize root and data volumes without issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8133) Add instance count to listSecurityGroups API call.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695098#comment-14695098 ] ASF subversion and git services commented on CLOUDSTACK-8133: - Commit aa7f8e57c592cd3e4f3e222697c0fe3cc5eef7b4 in cloudstack's branch refs/heads/master from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa7f8e5 ] Added unit tests for CLOUDSTACK-8133 Tests will confirm the behaviour of the newly added response fields of listSecurityGroups. Signed-off-by: Wido den Hollander This closes #679 > Add instance count to listSecurityGroups API call. > -- > > Key: CLOUDSTACK-8133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8133 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Kevin Dierkx >Assignee: Boris Schrijver >Priority: Minor > Fix For: 4.6.0 > > > Currently the listSecurityGroups call doesn't return an instance count of > some sort. There is no way of knowing without polling all VMs if the security > group is empty and will result in an exception on removal. > It would be awesome if this information could be provided with the above call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8133) Add instance count to listSecurityGroups API call.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695097#comment-14695097 ] ASF subversion and git services commented on CLOUDSTACK-8133: - Commit 03f48872d602c64bd74c40a2cd93f17acc746236 in cloudstack's branch refs/heads/master from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03f4887 ] CLOUDSTACK-8133 Added Virtualmachine count and ID's to listSecurityGroups response. See issue CLOUDSTACK-8133 for more information. Added null check by comment of Koushik Das. Added brackets by comment of Wido den Hollander. Removed a call to findById() by comment of Koushik Das. Signed-off-by: Wido den Hollander > Add instance count to listSecurityGroups API call. > -- > > Key: CLOUDSTACK-8133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8133 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Kevin Dierkx >Assignee: Boris Schrijver >Priority: Minor > Fix For: 4.6.0 > > > Currently the listSecurityGroups call doesn't return an instance count of > some sort. There is no way of knowing without polling all VMs if the security > group is empty and will result in an exception on removal. > It would be awesome if this information could be provided with the above call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8133) Add instance count to listSecurityGroups API call.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695096#comment-14695096 ] ASF subversion and git services commented on CLOUDSTACK-8133: - Commit 03f48872d602c64bd74c40a2cd93f17acc746236 in cloudstack's branch refs/heads/master from [~bo...@pcextreme.nl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03f4887 ] CLOUDSTACK-8133 Added Virtualmachine count and ID's to listSecurityGroups response. See issue CLOUDSTACK-8133 for more information. Added null check by comment of Koushik Das. Added brackets by comment of Wido den Hollander. Removed a call to findById() by comment of Koushik Das. Signed-off-by: Wido den Hollander > Add instance count to listSecurityGroups API call. > -- > > Key: CLOUDSTACK-8133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8133 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Kevin Dierkx >Assignee: Boris Schrijver >Priority: Minor > Fix For: 4.6.0 > > > Currently the listSecurityGroups call doesn't return an instance count of > some sort. There is no way of knowing without polling all VMs if the security > group is empty and will result in an exception on removal. > It would be awesome if this information could be provided with the above call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8133) Add instance count to listSecurityGroups API call.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695099#comment-14695099 ] ASF GitHub Bot commented on CLOUDSTACK-8133: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/679 > Add instance count to listSecurityGroups API call. > -- > > Key: CLOUDSTACK-8133 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8133 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Kevin Dierkx >Assignee: Boris Schrijver >Priority: Minor > Fix For: 4.6.0 > > > Currently the listSecurityGroups call doesn't return an instance count of > some sort. There is no way of knowing without polling all VMs if the security > group is empty and will result in an exception on removal. > It would be awesome if this information could be provided with the above call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8731) automation:checking usage event generation for delete volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sadhu suresh updated CLOUDSTACK-8731: - Summary: automation:checking usage event generation for delete volume (was: automating usage event generation for delete volume) > automation:checking usage event generation for delete volume > > > Key: CLOUDSTACK-8731 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8731 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sadhu suresh >Assignee: sadhu suresh > > usage event not generated for delete volume when VM creation failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8729) Unable to start a VM due to concurrent operation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695091#comment-14695091
]
Rajani Karuturi commented on CLOUDSTACK-8729:
-
I see this in the log
{quote}
Router requires upgrade. Unable to send command to router:140, router template
version : Cloudstack Release 4.4.0 Wed Jul 30 15:11:52 UTC 2014, minimal
required version : 4.5.0
{quote}
> Unable to start a VM due to concurrent operation
>
>
> Key: CLOUDSTACK-8729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8729
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Nagaraju
>
> While creating Instance getting the Error "Unable to start a VM due to
> concurrent operation"
> below is the log details ,can any one help me in this ?
> tal: 270766178304; new used: 2415919104, reserved: 0; requested mem:
> 536870912,alloc_from_last:false
> 2015-08-13 14:56:08,805 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) VM is being
> created in podId: 1
> 2015-08-13 14:56:08,809 DEBUG [o.a.c.e.o.NetworkOrchestrator]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Network
> id=205 is already implemented
> 2015-08-13 14:56:08,813 DEBUG [c.c.n.NetworkModelImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service
> SecurityGroup is not supported in the network id=205
> 2015-08-13 14:56:08,815 DEBUG [o.a.c.e.o.NetworkOrchestrator]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Changing
> active number of nics for network id=205 on 1
> 2015-08-13 14:56:08,819 DEBUG [o.a.c.e.o.NetworkOrchestrator]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Asking
> VirtualRouter to prepare for Nic[560-145-null-10.96.162.3]
> 2015-08-13 14:56:08,824 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Lock is
> acquired for network id 205 as a part of router startup in
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(145|ROOT-->Pool(1))]
> 2015-08-13 14:56:08,826 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Lock is
> released for network id 205 as a part of router startup in
> Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))]
> : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(145|ROOT-->Pool(1))]
> 2015-08-13 14:56:08,830 DEBUG [c.c.n.NetworkModelImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service
> SecurityGroup is not supported in the network id=205
> 2015-08-13 14:56:08,836 DEBUG [c.c.n.NetworkModelImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service
> SecurityGroup is not supported in the network id=205
> 2015-08-13 14:56:08,839 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Applying dhcp
> entry in network Ntwk[205|Guest|7]
> 2015-08-13 14:56:08,845 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Router
> requires upgrade. Unable to send command to router:140, router template
> version : Cloudstack Release 4.4.0 Wed Jul 30 15:11:52 UTC 2014, minimal
> required version : 4.5.0
> 2015-08-13 14:56:08,846 ERROR [c.c.v.VirtualMachineManagerImpl]
> (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Failed to
> start instance VM[User|i-2-145-VM]
> com.cloud.utils.exception.CloudRuntimeException: Unable to send command.
> Upgrade in progress. Please contact administrator.
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3796)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:3217)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4079)
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3209)
> 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(
[jira] [Created] (CLOUDSTACK-8731) automating usage event generation for delete volume
sadhu suresh created CLOUDSTACK-8731: Summary: automating usage event generation for delete volume Key: CLOUDSTACK-8731 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8731 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: sadhu suresh Assignee: sadhu suresh usage event not generated for delete volume when VM creation failed . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6811: Fix Version/s: (was: 4.6.0) > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-8725: Assignee: Bharat Kumar > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8725: - Fix Version/s: 4.6.0 > RVR functionality is broken in case of isolated networks, conntrackd fails to > start. > > > Key: CLOUDSTACK-8725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.6.0 > > > I tried setting up a rvr enabled isolated network. In the startup logs of the > router i can see that conntrackd is failing to start. Below are the startup > logs > [info] Setting console screen modes. > setterm: cannot (un)set powersave mode: Invalid argument > [info] Skipping font and keymap setup (handled by console-setup). > [] Loading IPsec SA/SP database: > [ ok etc/ipsec-tools.conf. > INIT: Entering runlevel: 2 > [info] Using makefile-style concurrent boot in runlevel 2. > [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm. > [ ok ] Loading iptables rules... IPv4... IPv6...done. > [ ok ] Starting rpcbind daemon...[] Already running.. > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > open-vm-tools: not starting as this is not a VMware VM > [ ok ] Starting enhanced syslogd: rsyslogd. > [] Starting ACPI services...RTNETLINK1 answers: No such file or directory > acpid: error talking to the kernel via netlink > . ok > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [ ok ] Starting DNS forwarder and DHCP server: dnsmasq. > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > . ok > [ ok ] Starting periodic command scheduler: cron. > [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy > 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [FAIL] Starting keepalived: keepalived failed! > [ ok ] Starting NTP server: ntpd. > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [ ok ] Starting the system activity data collector: sadc. > Detecting Linux distribution version: OK > Starting xe daemon: OK > [ ok ] Starting OpenBSD Secure Shell server: sshd. > [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : > 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode. > [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy > 'cloud-default' as it requires HTTP mode. > . ok > [] Starting web server: apache2apache2: Could not reliably determine the > server's fully qualified domain name, using 10.1.1.247 for ServerName > httpd (pid 3351) already running > . ok > [FAIL] Starting keepalived: keepalived failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory > Failed > [ ok ] Stopping NFS common utilities: idmapd statd. > -On router. > root@r-93-VM:~# service conntrackd restart > [] Stopping conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! > [] Starting conntrackdERROR: parsing config file in line (102), symbol > 'Multicast': syntax error > failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695032#comment-14695032 ] Saksham Srivastava commented on CLOUDSTACK-6811: Removed myself from the assignee so that someone else can pick it up. > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-6811: --- Assignee: (was: Saksham Srivastava) > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695014#comment-14695014 ] ASF GitHub Bot commented on CLOUDSTACK-8710: Github user jayapalu commented on the pull request: https://github.com/apache/cloudstack/pull/690#issuecomment-130602329 @remibergsma I thought you are only looking at the rules issue. You can look at the other issues in s2s vpn. You might have observed it but making it to your notice In below rule space is needed at '%s -m' . -self.fw.append(["nat", "front", "-A POSTROUTING -t nat -o %s-m mark --set-xmark 0x525/0x -j ACCEPT" % dev]) +self.fw.append(["nat", "front", "-A POSTROUTING -t nat -o %s -m mark --mark 0x525/0x -j ACCEPT" % dev]) I am actually looking at the ipsec with strongswan so I need s2s vpn iptables rules to applied for my testing. > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8209) VM migration fails across KVM hosts if hosts have same hostname even if different libvirt uuid or IPs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695009#comment-14695009
]
Rajani Karuturi commented on CLOUDSTACK-8209:
-
[~bhaisaab], are you planning to work on this for 4.6? if not can you please
triage it?
> VM migration fails across KVM hosts if hosts have same hostname even if
> different libvirt uuid or IPs
> -
>
> Key: CLOUDSTACK-8209
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8209
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Minor
> Fix For: 4.6.0, 4.5.2
>
>
> In case KVM hosts have same hostname but different libvirtd host uuid or IPs,
> VM migration fails with:
> 2015-02-04 15:22:18,042 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-13:ctx-ae4c1ba1 job-37/job-38) Unable to complete
> AsyncJobVO {id:38, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwACcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 5071960016, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Feb 04 15:22:15 IST 2015}, job origin:37
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: internal error: Attempt to migrate guest to the
> same host kvm-test
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1956)
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1854)
> >---at
> >com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4501)
> >---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:4633)
> >---at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
> >
> >---at
> >org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536)
> >---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:493)
> >---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)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8246) Add Cluster - Guest traffic label displayed Incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8246. - Resolution: Fixed > Add Cluster - Guest traffic label displayed Incorrectly > --- > > Key: CLOUDSTACK-8246 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8246 > 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: Ramamurti Subramanian >Assignee: Ramamurti Subramanian >Priority: Minor > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8726) Automation for Quickly attaching multiple data disks to a new VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8726: Issue Type: Test (was: Bug) > Automation for Quickly attaching multiple data disks to a new VM > > > Key: CLOUDSTACK-8726 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8726 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Pavan Kumar Bandarupally > Fix For: 4.6.0 > > > When trying to attach multiple data disks to a VM in quick succession, > Cloudstack Synchronizes the tasks of disk preparation and reconfiguration of > a VM with the disk. > This script automates the attach operation and verifies that the attach > operation is successfully completed without any issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8707) Site2Site vpn config esp policy set with esp lifetime
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8707. - Resolution: Fixed > Site2Site vpn config esp policy set with esp lifetime > - > > Key: CLOUDSTACK-8707 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8707 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.6.0 > > > In ipsec site to site vpn configuration esp policy on VR is mis configured. > The configuration file location is /etc/ipsec.d/*.conf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8693) Adding missing code in testpath_same_vm_name.py testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695007#comment-14695007 ] ASF subversion and git services commented on CLOUDSTACK-8693: - Commit af7e9b8decaaf93173f68a99e4d278cdebb8da93 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af7e9b8 ] Merge pull request #668 from pritisarap12/CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpatha CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpath-Adding "cls.hypervisor = cls.testClient.getHypervisorInfo()" -Fixed pep8 issues * pr/668: CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpatha Signed-off-by: Remi Bergsma > Adding missing code in testpath_same_vm_name.py testpath > - > > Key: CLOUDSTACK-8693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8693 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.1 >Reporter: Priti Sarap > Fix For: 4.2.1 > > > In continuation with CLOUDSTACK-8637 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8656) fill empty catch blocks with info messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8656. - Resolution: Fixed resolving based on the commits in the comments > fill empty catch blocks with info messages > -- > > Key: CLOUDSTACK-8656 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8656 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > Fix For: 4.6.0 > > > operators and other trouble shooters need to know if unhandled exceptions > happen. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8693) Adding missing code in testpath_same_vm_name.py testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695006#comment-14695006 ] ASF subversion and git services commented on CLOUDSTACK-8693: - Commit af7e9b8decaaf93173f68a99e4d278cdebb8da93 in cloudstack's branch refs/heads/master from [~remibergsma] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af7e9b8 ] Merge pull request #668 from pritisarap12/CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpatha CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpath-Adding "cls.hypervisor = cls.testClient.getHypervisorInfo()" -Fixed pep8 issues * pr/668: CLOUDSTACK-8693-Adding-missing-code-in-testpath_same_vm_name.py_testpatha Signed-off-by: Remi Bergsma > Adding missing code in testpath_same_vm_name.py testpath > - > > Key: CLOUDSTACK-8693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8693 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.1 >Reporter: Priti Sarap > Fix For: 4.2.1 > > > In continuation with CLOUDSTACK-8637 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8628) Ceph RBD only cluster with KVM does not fence properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8628. - Resolution: Fixed Fix Version/s: (was: Future) resolving based on the commits in the comments > Ceph RBD only cluster with KVM does not fence properly > -- > > Key: CLOUDSTACK-8628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0 > > > When a NFS storage pool is present on a KVM cluster that pool is used for > writing heartbeats to. > In case of a Ceph (RBD) only cluster such pools are not available and thus > the KVM hosts do not write any heartbeats. > Should the KVM Agent crash for any reason they will be fenced of directly and > this will cause a split-brain situation. > Fencing should not happen when no NFS storage pool is present as it is > dangerous for data consistency. A Instance could be running on two hosts at > the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8693) Adding missing code in testpath_same_vm_name.py testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695001#comment-14695001 ] ASF GitHub Bot commented on CLOUDSTACK-8693: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/668 > Adding missing code in testpath_same_vm_name.py testpath > - > > Key: CLOUDSTACK-8693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8693 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.1 >Reporter: Priti Sarap > Fix For: 4.2.1 > > > In continuation with CLOUDSTACK-8637 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8640) Uploads to S3 Secondary Storage fail, stay at 0% completed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8640. - Resolution: Fixed > Uploads to S3 Secondary Storage fail, stay at 0% completed > -- > > Key: CLOUDSTACK-8640 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8640 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: Future, 4.5.1 > Environment: Ceph RADOS Gateway with Civetweb as Secondary Storage >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: amazon, ceph, rados, s3, secondary_storage > Fix For: 4.6.0 > > > I noticed this after upgrading to 4.5.2 (build from 4.5 branch). > Uploads never completed when a template was downloaded en directly uploaded > to S3 secondary storage provided by Ceph's RADOS Gateway using Multipart. > After searching for hours I found this: > http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/event/ProgressEvent.html#getBytesTransferred() > The ProgressEvent of the returned that 0 bytes had been transferred. But when > using the getBytes() method it actually works. > The upload succeeds, but we check if the amount of uploaded bytes is equal or > more then what we expected. If not, we say the upload failed. > This happens inside S3TemplateDownloader (which really needs some fixes > btw) > Tracing this down if it's related to Ceph or actually something in > S3TemplateDownloader. > I also tried the Amazon SDK 1.9.34, but that didn't make a difference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8693) Adding missing code in testpath_same_vm_name.py testpath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694997#comment-14694997 ] ASF GitHub Bot commented on CLOUDSTACK-8693: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/668#issuecomment-130598324 LGTM > Adding missing code in testpath_same_vm_name.py testpath > - > > Key: CLOUDSTACK-8693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8693 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.1 >Reporter: Priti Sarap > Fix For: 4.2.1 > > > In continuation with CLOUDSTACK-8637 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8560) Images deployed from template do not have the correct size in database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8560. - Resolution: Fixed resolving based on the commits in the comments > Images deployed from template do not have the correct size in database > -- > > Key: CLOUDSTACK-8560 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8560 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: Future, 4.6.0, 4.4.4, 4.5.2 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0, 4.5.2 > > > When a Template from S3/Swift is deployed to RBD the resulting size in the > database could be eg 500MB. > I encountered this today, I uploaded a 50GB (virtual) QCOW2 image which was > 526MB in file size. > The resulted RBD disk was 500GB disk, but in the database it was stored as > 526MB. > We should return the resulting disk size to the management server so it can > update the database properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8448) Attach volume - throws an exception, preferably should give a proper error on UI. " PV drivers to be installed on the VM"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694994#comment-14694994
]
Rajani Karuturi commented on CLOUDSTACK-8448:
-
[~aprateek], are you planning to work on this for 4.6? if not can you please
triage it?
> Attach volume - throws an exception, preferably should give a proper error on
> UI. " PV drivers to be installed on the VM"
> -
>
> Key: CLOUDSTACK-8448
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8448
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.1
> Environment: MS 4.5.1 RC + Xenserver 6.5
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.6.0
>
>
> 2015-05-07 01:08:02,833 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-15:ctx-23658efb job-55/job-56) Run VM work job:
> com.cloud.vm.VmWorkAttachVolume for VM 8, job origin: 55
> 2015-05-07 01:08:02,834 DEBUG [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-15:ctx-23658efb job-55/job-56 ctx-95549691) Execute VM
> work job:
> com.cloud.vm.VmWorkAttachVolume{"volumeId":8,"deviceId":1,"userId":2,"accountId":2,"vmId":8,"handlerName":"VolumeApiServiceImpl"}
> 2015-05-07 01:08:02,862 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-15:ctx-23658efb job-55/job-56 ctx-95549691) Seq
> 1-5997950278727369144: Sending { Cmd , MgmtId: 345043735628, via: 1(xen651),
> Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.AttachCommand":{"disk":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e499088f-88be-4a17-a7a8-807ce56fa58b","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"e007c270-2b1b-3ce9-ae92-a98b94eef7eb","id":1,"poolType":"NetworkFilesystem","host":"192.168.217.11","path":"/exports/prim1","port":2049,"url":"NetworkFilesystem://192.168.217.11/exports/prim1/?ROLE=Primary&STOREUUID=e007c270-2b1b-3ce9-ae92-a98b94eef7eb"}},"name":"mach_vol","size":52428800,"path":"6f780380-c4bb-407e-9014-47f8cbf9e36e","volumeId":8,"accountId":2,"format":"VHD","provisioningType":"THIN","id":8,"hypervisorType":"XenServer"}},"diskSeq":1,"path":"6f780380-c4bb-407e-9014-47f8cbf9e36e","type":"DATADISK","_details":{"managed":"false","storagePort":"2049","storageHost":"192.168.217.11","volumeSize":"52428800"}},"vmName":"i-2-8-VM","inSeq":false,"wait":0}}]
> }
> 2015-05-07 01:08:02,862 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-15:ctx-23658efb job-55/job-56 ctx-95549691) Seq
> 1-5997950278727369144: Executing: { Cmd , MgmtId: 345043735628, via:
> 1(xen651), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.AttachCommand":{"disk":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e499088f-88be-4a17-a7a8-807ce56fa58b","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"e007c270-2b1b-3ce9-ae92-a98b94eef7eb","id":1,"poolType":"NetworkFilesystem","host":"192.168.217.11","path":"/exports/prim1","port":2049,"url":"NetworkFilesystem://192.168.217.11/exports/prim1/?ROLE=Primary&STOREUUID=e007c270-2b1b-3ce9-ae92-a98b94eef7eb"}},"name":"mach_vol","size":52428800,"path":"6f780380-c4bb-407e-9014-47f8cbf9e36e","volumeId":8,"accountId":2,"format":"VHD","provisioningType":"THIN","id":8,"hypervisorType":"XenServer"}},"diskSeq":1,"path":"6f780380-c4bb-407e-9014-47f8cbf9e36e","type":"DATADISK","_details":{"managed":"false","storagePort":"2049","storageHost":"192.168.217.11","volumeSize":"52428800"}},"vmName":"i-2-8-VM","inSeq":false,"wait":0}}]
> }
> 2015-05-07 01:08:02,863 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-343:ctx-68ff6403) Seq 1-5997950278727369144: Executing request
> 2015-05-07 01:08:02,913 WARN [c.c.h.x.r.XenServerStorageProcessor]
> (DirectAgent-343:ctx-68ff6403) : You attempted an operation on a VM which
> requires PV drivers to be installed but the drivers were not detected
> 2015-05-07 01:08:02,913 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-343:ctx-68ff6403) Seq 1-5997950278727369144: Response Received:
> 2015-05-07 01:08:02,913 DEBUG [c.c.a.t.Request]
> (DirectAgent-343:ctx-68ff6403) Seq 1-5997950278727369144: Processing: { Ans:
> , MgmtId: 345043735628, via: 1, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.AttachAnswer":{"result":false,"details":"You
> attempted an operation that requires PV drivers to be installed on the VM.
> Please install them by inserting xen-pv-drv.iso.","wait":0}}] }
> 2015-05-07 01:08:02,913 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-15:ctx-23658efb job-55/job-56 ctx-95549691) Seq
> 1-59
[jira] [Updated] (CLOUDSTACK-8560) Images deployed from template do not have the correct size in database
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8560: Fix Version/s: 4.5.2 4.6.0 > Images deployed from template do not have the correct size in database > -- > > Key: CLOUDSTACK-8560 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8560 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: Future, 4.6.0, 4.4.4, 4.5.2 >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: 4.6.0, 4.5.2 > > > When a Template from S3/Swift is deployed to RBD the resulting size in the > database could be eg 500MB. > I encountered this today, I uploaded a 50GB (virtual) QCOW2 image which was > 526MB in file size. > The resulted RBD disk was 500GB disk, but in the database it was stored as > 526MB. > We should return the resulting disk size to the management server so it can > update the database properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694986#comment-14694986 ] Rajani Karuturi commented on CLOUDSTACK-8353: - [~bharatkumar], are you planning to work on this for 4.6? if not can you please triage it? > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.6.0 > > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8349) Implement a general purpose VR-UserVM Agents Framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694984#comment-14694984 ] Rajani Karuturi commented on CLOUDSTACK-8349: - [~bhaisaab], are you planning to work on this for 4.6? if not can you please triage it? > Implement a general purpose VR-UserVM Agents Framework > -- > > Key: CLOUDSTACK-8349 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8349 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > Scope and Design Doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework > Aims to: > - Refactor VR codebase, provide better test-ability and scalability in > developing features in VR and for user VMs > - Provide user VM based granular orchestration such as reset password, reset > SSH key, installation of software such as monitoring and backup etc. > - Secure/TLS based connection between VR and user VMs > - Easy to use orchestration based on Ansible, Chef or Puppet and recipes > based on that > - Provides a way to monitor VR and do VR VM maintenance such as upgrade > packages and apply security patches (such as openssl packages), cleanup > /var/log files and monitor VR health > - Available in Isolated, VPC and Shared networks > - Make it easier for sys admins to debug issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8349) Implement a general purpose VR-UserVM Agents Framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8349: Fix Version/s: (was: Future) > Implement a general purpose VR-UserVM Agents Framework > -- > > Key: CLOUDSTACK-8349 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8349 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > Scope and Design Doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Agents+Framework > Aims to: > - Refactor VR codebase, provide better test-ability and scalability in > developing features in VR and for user VMs > - Provide user VM based granular orchestration such as reset password, reset > SSH key, installation of software such as monitoring and backup etc. > - Secure/TLS based connection between VR and user VMs > - Easy to use orchestration based on Ansible, Chef or Puppet and recipes > based on that > - Provides a way to monitor VR and do VR VM maintenance such as upgrade > packages and apply security patches (such as openssl packages), cleanup > /var/log files and monitor VR health > - Available in Isolated, VPC and Shared networks > - Make it easier for sys admins to debug issues -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8322) Make Python based password server use SSL cert and listen on secure socket (443, or 4443) if enabled by admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694982#comment-14694982 ] Rajani Karuturi commented on CLOUDSTACK-8322: - [~bhaisaab], are you planning to work on this for 4.6? if not can you please triage it? > Make Python based password server use SSL cert and listen on secure socket > (443, or 4443) if enabled by admin > - > > Key: CLOUDSTACK-8322 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8322 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > VR can pick same SSL cert used for CPVM/SSVM and use that to listen on a > secure socket (along with the HTTP port) to serve password. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8298) xenserver VR start failed when the VR start config size is more
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8298. - Resolution: Fixed > xenserver VR start failed when the VR start config size is more > --- > > Key: CLOUDSTACK-8298 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8298 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Network Devices >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.6.0, 4.5.1 > > > On VR restart/start CS sends the configuration to VR via vmops > 'createFileInDomr' method. The createFileInDomr method receives the content > and create temp file in xenserver and push this file to VR using SCP. > When the VR configuration is more than ARG_MAX size of the xenserver host > then it command got failed. > The below is the command to get the ARG_MAX value in the host. > #getconf ARG_MAX > 131072 > Reproducing steps: > 1. create an isolated network and deploy vm in that network. > 2. Create large size configuration to VR by creating more number of VMs or > configure more set of network rules on the network. > 3. After this restart the VR. On starting the VR CS sends the configuration > to VR, You can see the configuration in MS log. > Error: callHostPlugin failed for cmd: createFileInDomr with args > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8298) xenserver VR start failed when the VR start config size is more
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8298: Fix Version/s: 4.5.1 > xenserver VR start failed when the VR start config size is more > --- > > Key: CLOUDSTACK-8298 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8298 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Network Devices >Affects Versions: 4.5.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.6.0, 4.5.1 > > > On VR restart/start CS sends the configuration to VR via vmops > 'createFileInDomr' method. The createFileInDomr method receives the content > and create temp file in xenserver and push this file to VR using SCP. > When the VR configuration is more than ARG_MAX size of the xenserver host > then it command got failed. > The below is the command to get the ARG_MAX value in the host. > #getconf ARG_MAX > 131072 > Reproducing steps: > 1. create an isolated network and deploy vm in that network. > 2. Create large size configuration to VR by creating more number of VMs or > configure more set of network rules on the network. > 3. After this restart the VR. On starting the VR CS sends the configuration > to VR, You can see the configuration in MS log. > Error: callHostPlugin failed for cmd: createFileInDomr with args > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8142) [Hyper-V] While creating system vms attach systemvm.iso directly from sec storage folder instead from host local path
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694978#comment-14694978 ] Rajani Karuturi commented on CLOUDSTACK-8142: - [~devdeep], are you planning to work on this for 4.6? if not can you please triage it? > [Hyper-V] While creating system vms attach systemvm.iso directly from sec > storage folder instead from host local path > - > > Key: CLOUDSTACK-8142 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8142 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.6.0 >Reporter: Rajesh Battala >Assignee: Devdeep Singh > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8043) Have all CloudStack tables's primary keys auto-increment to avoid multi-master DB setup issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8043. - Resolution: Fixed Fix Version/s: (was: Future) fixed in eb666453f3bd4f9ff06d12fad94bf7a2ca427099 > Have all CloudStack tables's primary keys auto-increment to avoid > multi-master DB setup issues > -- > > Key: CLOUDSTACK-8043 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8043 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.6.0 > > > In multi-master DB setup, tables where primary keys don't auto-increment can > conflict in case of concurrent insert operations. This was partially fixed in > https://issues.apache.org/jira/browse/CLOUDSTACK-6212 > The following tables have a primary key without the auto_increment flag, > should we alter those columns to have auto_increment? > cluster_vsm_map > op_host > op_host_tranfer > op_host_upgrade > op_it_work > op_lock > op_networks > op_router_monitoring_services > op_user_stats_log > user_vm_clone_setting > vm_work_job -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Fix Version/s: (was: 4.6.0) Future > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Fix For: Future > > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8033) Cleanup old DevCloud build scripts, use new ones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8033: Fix Version/s: (was: 4.6.0) (was: Future) > Cleanup old DevCloud build scripts, use new ones > > > Key: CLOUDSTACK-8033 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8033 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: DevCloud >Reporter: Rohit Yadav >Assignee: Rohit Yadav > > This is in response to closing > https://issues.apache.org/jira/browse/CLOUDSTACK-1507 > Ian has developed new infra for building DevCloud we should use that, the > idea is to cleanup old code and work on DevCloud-KVM as well using some new > tools such as packer instead of veewee. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-7821.
-
Resolution: Won't Fix
Fix Version/s: 4.6.0
This will be fixed by replacing openswan with strongswan in bug CLOUDSTACK-8682
FS is at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Replacing+openswan+ipsec+with+strongswan+ipsec
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0, 4.6.0, 4.5.1
>Reporter: Sheng Yang
> Fix For: 4.6.0
>
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8682) Replace openswan ipsec with strongswan ipsec
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-8682: Fix Version/s: (was: 4.6.0) > Replace openswan ipsec with strongswan ipsec > > > Key: CLOUDSTACK-8682 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8682 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > > Currently VR is using openswan ipsec solution. Openswan is currently not > maintained by community. Where as stronswan is maintained by Debian > community. So updates are easy with the strongswan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8730) Site-to-site VPN functionality does not work
Remi Bergsma created CLOUDSTACK-8730: Summary: Site-to-site VPN functionality does not work Key: CLOUDSTACK-8730 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8730 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Remi Bergsma Assignee: Remi Bergsma Priority: Critical Fix For: 4.6.0 See CLOUDSTACK-8710, I tested the site-to-site VPN functionality but even with the iptables rules applied (as per CLOUDSTACK-8710) it does not work. This is because some iptables rules are missing, that were present in pre-4.6 version. The goal: have two VPCs, echt with a VM in a single tier, be able to talk to each other over the VPN (ipsec tunnel). [~rajanik] I will be working on this and will make sure it gets in 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-7821:
Fix Version/s: (was: Future)
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.5.0, 4.6.0, 4.5.1
>Reporter: Sheng Yang
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7716) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi closed CLOUDSTACK-7716. --- Resolution: Fixed Fix Version/s: (was: 4.6.0) > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7716 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7716 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Devdeep Singh > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7714) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi closed CLOUDSTACK-7714. --- Resolution: Fixed Fix Version/s: (was: 4.6.0) > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7714 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7714 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Sateesh Chodapuneedi > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7712) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7712: Fix Version/s: (was: 4.6.0) > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7712 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7712 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Rajesh Battala > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7712) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi closed CLOUDSTACK-7712. --- Resolution: Fixed > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7712 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7712 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Rajesh Battala > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4139) [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-4139:
Fix Version/s: (was: 4.6.0)
(was: Future)
> [VMWARE]Failed to resize the volumes which are created from snapshot of root
> volume with controller type IDE.
> -
>
> Key: CLOUDSTACK-4139
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4139
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
> Attachments: apilog.log, management-server.log, newdb.sql
>
>
> Steps:
> 1. Configure Adv zone with VMWARE cluster with Zone wide primary storage
> 2. Deploy instance
> 3. Create snapshot from ROOT volume
> 4. Attach the volume to an instance
> 5. Tried to resize the volume from 2 GB to 5 GB .
> Observation:
> 1. It Failed to resize the volumes which are created from snapshot .
> 2. Task notification says resize is completed from UI but it failed and no
> resize happened for this volume
> 3. I could resize the DATA volumes which are added by using the disk offering
> and attached to the instance.
> 2013-08-07 16:37:31,370 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) SeqA 3-785: Sending Seq 3-785: { Ans: ,
> MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-08-07 16:37:33,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
> ===START=== 10.144.6.19 -- GET
> command=resizeVolume&id=480c853c-e70a-46a0-a6d6-ae74b416f318&shrinkok=false&diskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d&response=json&sessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D&_=1375873540089
> 2013-08-07 16:37:33,296 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-21:null) submit async job-49 = [
> 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ], details: AsyncJobVO {id:49, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: null,
> cmd: org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"480c853c-e70a-46a0-a6d6-ae74b416f318","response":"json","sessionkey":"nmiUJgTgEEYHRt8hx5StkuJr5tA\u003d","shrinkok":"false","cmdEventType":"VOLUME.RESIZE","ctxUserId":"3","httpmethod":"GET","_":"1375873540089","ctxAccountId":"3","diskofferingid":"34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d","ctxStartEventId":"182"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 187767034175903,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-07 16:37:33,301 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null)
> ===END=== 10.144.6.19 -- GET
> command=resizeVolume&id=480c853c-e70a-46a0-a6d6-ae74b416f318&shrinkok=false&diskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d&response=json&sessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D&_=1375873540089
> 2013-08-07 16:37:33,342 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Executing
> org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd for job-49 = [
> 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]
> 2013-08-07 16:37:33,488 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Access to
> Vol[35|vm=16|DATADISK] granted to Acct[3-cdcuser1] by
> DomainChecker_EnhancerByCloudStack_ccb7a71
> 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
> (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
> 2-1287389738: Sending { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"path":"e9166262ee514a398028c04bf21d80b7","pool":{"id":2,"uuid":"004a6f4c-232c-3a09-9013-e47fe47da3fb","host":"10.102.192.100","path":"/cpg_vol/sailaja/finalps2","port":2049,"type":"NetworkFilesystem"},"vmInstance":"i-3-16-VM","newSize":5368709120,"currentSize":2147483648,"shrinkOk":false,"wait":0}}]
> }
> 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request]
> (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq
> 2-1287389738: Executing: { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"path":"e9166262ee514a398028c04bf21d80b7","pool":{"id":2,"uuid":"004a6f4c-232c-3a09-9013-e47fe47da3fb","host":"10.102.192.100","path":"/cpg_vol/sailaja/finalps2","port":2049,"type":"NetworkFilesystem"},"vmInstance":"i-
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694962#comment-14694962 ] ASF GitHub Bot commented on CLOUDSTACK-8710: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/690#issuecomment-130593053 Hi @jayapalu I also worked on this, and but even with the firewall rules applied, the functionality still doesn't work because some rules are missing. So, this might fix CLOUDSTACK-8710 as it applies the rules but I think the goal should be to make two VMs in two VPCs be able to reach each other through the VPN. Anyway, I'll make a separate issue for this and keep working on it. I already figured out what rules are missing. Some other issues are also impacting this, like the missing default gateway. Let's be clear on who works on what (by assigning the issue) or else we'll do duplicate work. That's why I assigned the issue to me yesterday. Will run test to verify your fix now. > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694963#comment-14694963 ] Rajani Karuturi commented on CLOUDSTACK-6811: - [~saksham], are you planning to work on this for 4.6? if not can you please triage it? > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra >Assignee: Saksham Srivastava > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8383) [Master Install] Unable to start VM due to error in finalizeStart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8383. - Resolution: Fixed I dont see this issue on current master with a xenserver 6.5 advanced zone setup. please reopen if you are still facing the issue > [Master Install] Unable to start VM due to error in finalizeStart > - > > Key: CLOUDSTACK-8383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Priority: Critical > > Following Exception is seen in the Management server log - > Error finalize start > 2015-04-13 08:12:11,018 ERROR [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-3:ctx-a3d21009 job-19/job-23 ctx-31b66d8c) Failed to start > instance VM[DomainRouter|r-7-VM] > com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-7-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1076) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4503) > 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:601) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4659) > at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) > 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:494) > 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:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8382) [Master Install] DB exception unknown column is seen in Management server log
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8382. - Resolution: Cannot Reproduce Assignee: Rajani Karuturi I didnt see this on my current master setup. please reopen if you are still facing the issue > [Master Install] DB exception unknown column is seen in Management server log > - > > Key: CLOUDSTACK-8382 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8382 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Rajani Karuturi >Priority: Critical > > Following DB Exception is seen in the Management server log - > DB exception – > 2015-04-13 07:49:25,128 ERROR [c.c.u.d.Upgrade410to420] (main:null) > migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in > 'field list' > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column > 'iso_id1' in 'field list' > 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:525) > 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.executeQuery(PreparedStatement.java:2283) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96) > at > com.cloud.upgrade.dao.Upgrade410to420.migrateDatafromIsoIdInVolumesTable(Upgrade410to420.java:2555) > at > com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:111) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:338) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:461) > 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 > org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339) > at > org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143) > at > org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108) > at > org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:947) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233) > at > org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSe
[jira] [Resolved] (CLOUDSTACK-8381) [Master Install] SQL exception are seen in Management server log
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8381. - Resolution: Cannot Reproduce Assignee: Rajani Karuturi I dont see these with the current master setup. $grep "Ignored SQL Exception" vmops.log returned nothing. > [Master Install] SQL exception are seen in Management server log > > > Key: CLOUDSTACK-8381 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8381 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Assignee: Rajani Karuturi >Priority: Critical > > Following error is seen in the Management server log - > SQL Exceptions > 2015-04-13 07:49:24,872 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) > Ignored SQL Exception when trying to drop key last_sent on table alert > exception: Can't DROP 'last_sent'; check that column/key exists > 2015-04-13 07:49:24,872 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) > Ignored SQL Exception when trying to drop key i_alert__last_sent on table > alert exception: Can't DROP 'i_alert__last_sent'; check that column/key exists > 2015-04-13 07:49:24,881 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Added > index i_alert__last_sent for table alert > 2015-04-13 07:49:24,888 DEBUG [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 exception: > Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,896 DEBUG [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 exception: > Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,902 DEBUG [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 exception: > Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,908 DEBUG [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 > exception: Error on rename of './cloud/baremetal_dhcp_devices' to > './cloud/#sql2-a94-15' (errno: 152) > 2015-04-13 07:49:24,915 DEBUG [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 exception: > Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,921 DEBUG [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 exception: > Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,927 DEBUG [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 exception: > Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,932 DEBUG [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 > exception: Error on rename of './cloud/baremetal_pxe_devices' to > './cloud/#sql2-a94-15' (errno: 152) > 2015-04-13 07:49:24,943 DEBUG [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 exception: > Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,949 DEBUG [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 exception: > Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-a94-15' > (errno: 152) > 2015-04-13 07:49:24,955 DEBUG [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 > exception: Error on rename of './cloud/baremetal_pxe_devices' to > './cloud/#sql2-a94-15
[jira] [Resolved] (CLOUDSTACK-8231) Fail to create load-balancing service on VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-8231. - Resolution: Fixed > Fail to create load-balancing service on VPC > > > Key: CLOUDSTACK-8231 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8231 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Pierre-Luc Dion >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.6.0, 4.5.2 > > Attachments: lb-algo.png > > > Using the uI, cannot create Load-Balancing rules on a VPC tier because the > load-balancing algorithm is empty and the drop down display nothing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8729) Unable to start a VM due to concurrent operation
Nagaraju created CLOUDSTACK-8729: Summary: Unable to start a VM due to concurrent operation Key: CLOUDSTACK-8729 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8729 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nagaraju While creating Instance getting the Error "Unable to start a VM due to concurrent operation" below is the log details ,can any one help me in this ? tal: 270766178304; new used: 2415919104, reserved: 0; requested mem: 536870912,alloc_from_last:false 2015-08-13 14:56:08,805 DEBUG [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) VM is being created in podId: 1 2015-08-13 14:56:08,809 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Network id=205 is already implemented 2015-08-13 14:56:08,813 DEBUG [c.c.n.NetworkModelImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service SecurityGroup is not supported in the network id=205 2015-08-13 14:56:08,815 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Changing active number of nics for network id=205 on 1 2015-08-13 14:56:08,819 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Asking VirtualRouter to prepare for Nic[560-145-null-10.96.162.3] 2015-08-13 14:56:08,824 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Lock is acquired for network id 205 as a part of router startup in Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(145|ROOT-->Pool(1))] 2015-08-13 14:56:08,826 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Lock is released for network id 205 as a part of router startup in Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] : Dest[Zone(1)-Pod(1)-Cluster(1)-Host(1)-Storage(Volume(145|ROOT-->Pool(1))] 2015-08-13 14:56:08,830 DEBUG [c.c.n.NetworkModelImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service SecurityGroup is not supported in the network id=205 2015-08-13 14:56:08,836 DEBUG [c.c.n.NetworkModelImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Service SecurityGroup is not supported in the network id=205 2015-08-13 14:56:08,839 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Applying dhcp entry in network Ntwk[205|Guest|7] 2015-08-13 14:56:08,845 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Router requires upgrade. Unable to send command to router:140, router template version : Cloudstack Release 4.4.0 Wed Jul 30 15:11:52 UTC 2014, minimal required version : 4.5.0 2015-08-13 14:56:08,846 ERROR [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-9:ctx-67395b21 job-501/job-503 ctx-cd154467) Failed to start instance VM[User|i-2-145-VM] com.cloud.utils.exception.CloudRuntimeException: Unable to send command. Upgrade in progress. Please contact administrator. at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3796) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:3217) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4079) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3209) 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 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(JdkDynam
[jira] [Commented] (CLOUDSTACK-8150) No MySQL-HA package in debian builds
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694948#comment-14694948 ] Rajani Karuturi commented on CLOUDSTACK-8150: - [~bhaisaab], are you planning to work on this for 4.6? if not can you please triage it? > No MySQL-HA package in debian builds > > > Key: CLOUDSTACK-8150 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8150 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Critical > Fix For: 4.6.0, 4.5.2 > > > There is mysql-ha package in rpm builds but not in debian builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8085) Fails to attach a volume (is made from a snapshot) to a VM with using local storage as primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-8085:
Affects Version/s: (was: Future)
> Fails to attach a volume (is made from a snapshot) to a VM with using local
> storage as primary storage.
> ---
>
> Key: CLOUDSTACK-8085
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8085
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Snapshot, Volumes
>Affects Versions: 4.5.0, 4.6.0, 4.4.3, 4.3.2
> Environment: - Builds up with 155 hosts and a cloudstack server.
> - Each host equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All hosts are networked by InfiniBand and 10GbE.
> - Using CentOS6.6 (64bit)
> - Using local storage on all hosts as primary storage.
> - Using S3 compatible storage (RadosGW) as secondary storage.
>Reporter: Keiichi Yusa
>Assignee: Rohit Yadav
>Priority: Critical
>
> CloudStack fails to attach a DATADISK volume (This DATADISK volume is made
> from a snapshot) to a VM with using local storage as primary storage.
> Reproduction procedure:
> # To use local storage as primary storage.
> # Take a snapshot of a VM's ROOT/DATADISK volume. (By clicking [Take
> Snapshot] button on WebUI.)
> # Create a new DATADISK volume from this snapshot. (By clicking [Create
> Volume] button on WebUI.)
> # Try to attach this new DATADISK volume to a VM. (By Clicking [Attach Disk]
> button on WebUI.)
> When we execute these, CloudStack fails attach this new DATADISK volume to
> the VM with occuring the following error:
> {noformat}
> "Failed to attach local data volume snapshot-test-std-stop to VM
> snapshot-test-0001 as migration of local data volume is not allowed"
> {noformat}
> At this time, Cloudstack puts a exception in management-server.log. (Please
> see [1])
> We investigate our CloudStack environment about this problem.
> We notice that Cloudstack behaves as follows:
> * CloudStack creates a new DATADISK volume at primary storage of any one of
> the hosts when a user creates the volume from a snapshot by executing [Create
> Volume]. (This primary storage is local storage on the host.)
> * Now, the user deploys a new VM (or uses a existing VM). In many cases, the
> new DATADISK volume is deployed to a host different from the host that is
> deployed the VM.
> * User will attach the new DATADISK volume to the VM. When the user executes
> [Attach Disk], CloudStack tries to migrate the new DATADISK volume to the
> host that is deployed the VM in order to attach the new DATADISK volume to
> the VM.
> * However, CloudStack fails this migration because we use local storage as
> primary storage.
> [1] Exception in managemnet-server.log
> {noformat}
> 2014-12-02 19:37:10,807 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (Job-Executor-50:ctx-a0ef6a5a) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach local data
> volume snapshot-test-std-stop to VM snapshot-test-0001 as migration of local
> data volume is not allowed
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1292)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1156)
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1126)
> 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:622)
> 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
> 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.$Proxy197.attachVolumeToVM(Unknown Source)
>
[jira] [Updated] (CLOUDSTACK-8085) Fails to attach a volume (is made from a snapshot) to a VM with using local storage as primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-8085:
Fix Version/s: (was: Future)
> Fails to attach a volume (is made from a snapshot) to a VM with using local
> storage as primary storage.
> ---
>
> Key: CLOUDSTACK-8085
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8085
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Snapshot, Volumes
>Affects Versions: 4.5.0, 4.6.0, 4.4.3, 4.3.2
> Environment: - Builds up with 155 hosts and a cloudstack server.
> - Each host equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All hosts are networked by InfiniBand and 10GbE.
> - Using CentOS6.6 (64bit)
> - Using local storage on all hosts as primary storage.
> - Using S3 compatible storage (RadosGW) as secondary storage.
>Reporter: Keiichi Yusa
>Assignee: Rohit Yadav
>Priority: Critical
>
> CloudStack fails to attach a DATADISK volume (This DATADISK volume is made
> from a snapshot) to a VM with using local storage as primary storage.
> Reproduction procedure:
> # To use local storage as primary storage.
> # Take a snapshot of a VM's ROOT/DATADISK volume. (By clicking [Take
> Snapshot] button on WebUI.)
> # Create a new DATADISK volume from this snapshot. (By clicking [Create
> Volume] button on WebUI.)
> # Try to attach this new DATADISK volume to a VM. (By Clicking [Attach Disk]
> button on WebUI.)
> When we execute these, CloudStack fails attach this new DATADISK volume to
> the VM with occuring the following error:
> {noformat}
> "Failed to attach local data volume snapshot-test-std-stop to VM
> snapshot-test-0001 as migration of local data volume is not allowed"
> {noformat}
> At this time, Cloudstack puts a exception in management-server.log. (Please
> see [1])
> We investigate our CloudStack environment about this problem.
> We notice that Cloudstack behaves as follows:
> * CloudStack creates a new DATADISK volume at primary storage of any one of
> the hosts when a user creates the volume from a snapshot by executing [Create
> Volume]. (This primary storage is local storage on the host.)
> * Now, the user deploys a new VM (or uses a existing VM). In many cases, the
> new DATADISK volume is deployed to a host different from the host that is
> deployed the VM.
> * User will attach the new DATADISK volume to the VM. When the user executes
> [Attach Disk], CloudStack tries to migrate the new DATADISK volume to the
> host that is deployed the VM in order to attach the new DATADISK volume to
> the VM.
> * However, CloudStack fails this migration because we use local storage as
> primary storage.
> [1] Exception in managemnet-server.log
> {noformat}
> 2014-12-02 19:37:10,807 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (Job-Executor-50:ctx-a0ef6a5a) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach local data
> volume snapshot-test-std-stop to VM snapshot-test-0001 as migration of local
> data volume is not allowed
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1292)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1156)
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1126)
> 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:622)
> 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
> 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.$Proxy197.attachVolumeToVM(Unknown Source)
>
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694944#comment-14694944 ] Rajani Karuturi commented on CLOUDSTACK-7364: - [~rajesh_battala], are you planning to work on this for 4.6? if not can you triage it please? > NetScaler won't create the Public VLAN and Bind the IP to it > > > Key: CLOUDSTACK-7364 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Francois Gaudreault >Assignee: Rajesh Battala >Priority: Critical > Fix For: 4.6.0 > > Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, > management-server.log.debug.gz, screenshot-1.png, screenshot-2.png > > > When adding a Load Balancing rule with the NetScaler, the provider will tag > and bind the private IP to the appropriate interface. However, the behaviour > for the Public Interface is different. It simply adds the IP untagged on all > interfaces. This is wrong. > The public VLAN should be tagged, and the VIP bound to the right VLAN tag to > avoid unnecessary ARP on other VLANs. > NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7839) Unable to live migrate an instance to another host in a cluster from which the template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7839: Affects Version/s: (was: Future) > Unable to live migrate an instance to another host in a cluster from which > the template has been deleted > > > Key: CLOUDSTACK-7839 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7839 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0 >Reporter: Joris van Lieshout >Priority: Critical > > ACS throws an null pointer exception when you try to live migrate an instance > to another host in a cluster and the template of that instance has been > deleted. > I have pasted the exception below. > Steps to reproduce the issue: > 1. create an instance from iso > 2. stop the instance > 3. create a template from the root volume > 4. create a new instance from that template > 5. leave the instance running > 6. delete the template > 7. try the live migrate the instance to another host in the cluster > The migrate button in the web interface will not respond. > The exception below can be found in the management-server log > 2014-11-04 14:08:45,509 ERROR [cloud.api.ApiServer] > (TP-Processor49:ctx-35286d62 ctx-3de77f98) unhandled exception executing api > command: findHostsForMigration > java.lang.NullPointerException > at > com.cloud.storage.StorageManagerImpl.storagePoolHasEnoughSpace(StorageManagerImpl.java:1561) > at > org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.filter(AbstractStoragePoolAllocator.java:199) > at > org.apache.cloudstack.storage.allocator.ClusterScopeStoragePoolAllocator.select(ClusterScopeStoragePoolAllocator.java:110) > at > org.apache.cloudstack.storage.allocator.AbstractStoragePoolAllocator.allocateToPool(AbstractStoragePoolAllocator.java:109) > at > com.cloud.server.ManagementServerImpl.findSuitablePoolsForVolumes(ManagementServerImpl.java:1250) > at > com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1150) > at sun.reflect.GeneratedMethodAccessor643.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:622) > 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 > 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.$Proxy193.listHostsForMigrationOfVM(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:323) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:53) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:115) > 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:112) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:74) > 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.co
[jira] [Commented] (CLOUDSTACK-8726) Automation for Quickly attaching multiple data disks to a new VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694927#comment-14694927 ] ASF GitHub Bot commented on CLOUDSTACK-8726: Github user nitt10prashant commented on the pull request: https://github.com/apache/cloudstack/pull/683#issuecomment-130587552 LGTM > Automation for Quickly attaching multiple data disks to a new VM > > > Key: CLOUDSTACK-8726 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8726 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Pavan Kumar Bandarupally > Fix For: 4.6.0 > > > When trying to attach multiple data disks to a VM in quick succession, > Cloudstack Synchronizes the tasks of disk preparation and reconfiguration of > a VM with the disk. > This script automates the attach operation and verifies that the attach > operation is successfully completed without any issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694900#comment-14694900 ] Jayapal Reddy commented on CLOUDSTACK-8710: --- [~remibergsma] If you did not start working on this bug assign it to me. I found the issue and added patch for it. > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8710) site2site vpn iptables rules are not configured on VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694897#comment-14694897 ] ASF GitHub Bot commented on CLOUDSTACK-8710: GitHub user jayapalu opened a pull request: https://github.com/apache/cloudstack/pull/690 CLOUDSTACK-8710: Fixed applying iptables rules for s2s vpn @remibergsma @wilderrodrigues Moved applying iptables rules apply after vpn configuration so that vpn specific rules also get applied You can merge this pull request into a Git repository by running: $ git pull https://github.com/jayapalu/cloudstack vpn Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/690.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #690 commit da9e757b8e48c54a4ecbd3bdb027b573ac5a3314 Author: Jayapal Date: 2015-08-13T08:37:12Z CLOUDSTACK-8710: Fixed applying iptables rules for s2s vpn > site2site vpn iptables rules are not configured on VR > - > > Key: CLOUDSTACK-8710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.6.0 >Reporter: Jayapal Reddy >Assignee: Remi Bergsma >Priority: Critical > > 1. Configure vpc > 2. Configure site2site vpn > 3. After configuration go to VR and check the iptables rules of VR. > Observed that there no rules configured on ports 500, 4500. > In configure.py there is method 'configure_iptables' which is having rules > but these are not getting applied on VR on site2site vpn configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
