[jira] [Assigned] (CLOUDSTACK-9808) 4.9->4.10 upgrade does not upgrade global settings to point to new template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-9808: - Assignee: Kishan Kavala > 4.9->4.10 upgrade does not upgrade global settings to point to new template > --- > > Key: CLOUDSTACK-9808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9808 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Assignee: Kishan Kavala >Priority: Blocker > > Following the same source of information > (http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.9.html) > I’ve registered the template with the right naming: "systemvm-kvm-4.10”, > waited until it was in Ready status. > Then upgraded management and the cloudstack-agent on all hosts. > Upon starting the management, the DB upgrade was successful. I’ve logged in > the system and observed that it was still using 4.6.0 ssvm templates. The > option to upgrade the VR wasn’t available as well. Checking global settings > it turns out minreq.sysvmtemplate.version = 4.6.0 and router.template.kvm was > pointing to the original ssmv template (not systemvm-kvm-4.10). The original > ssvm template is still in active state but it should be in InActive. > This basically leaves the user unable to upgrade ssvm (which are not working > btw) without hacking the DB and global settings -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CLOUDSTACK-9807) 4.5->4.10 upgrade fails. db upgrade script looking for ssvm template-4.6 when having 4.10 already installed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-9807: - Assignee: Kishan Kavala > 4.5->4.10 upgrade fails. db upgrade script looking for ssvm template-4.6 when > having 4.10 already installed. > > > Key: CLOUDSTACK-9807 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9807 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.10.0.0 >Reporter: Boris Stoyanov >Assignee: Kishan Kavala >Priority: Blocker > > Following the upgrade instructions from this page: > http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.5.html > I’ve registered the template with the right naming: "systemvm-kvm-4.10”, > waited until it was in Ready status. > Then following the upgrade procedure, upgraded the management and the > cs-agent. > Upon starting the management the db.upgrade kicked in, but it failed with the > following error: > com.cloud.utils.exception.CloudRuntimeException: 4.6.0KVM SystemVm template > not found. Cannot upgrade system Vms > It appears that the upgrade script is still looking for 4.6 ssvm template > while a newer version is installed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9800) Enable inline mode for NetScaler device
Kishan Kavala created CLOUDSTACK-9800: - Summary: Enable inline mode for NetScaler device Key: CLOUDSTACK-9800 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9800 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Reporter: Kishan Kavala Assignee: Kishan Kavala Only side-by-side mode is enabled for NetScaler devices. NetScaler can work in inline mode also along with other Firewall devices -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9232) Usage data does not reflect changes of VM parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114988#comment-15114988 ] Kishan Kavala commented on CLOUDSTACK-9232: --- Vm usage data contain service offering id. CPU/memory info can fetched using service offering. Only incase of custom service offering cpu/memory etc are populated in Vm usage records. > Usage data does not reflect changes of VM parameters > > > Key: CLOUDSTACK-9232 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9232 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.2 >Reporter: Norbert Klein > Labels: billing, usage > > The usage data is created without including the information of properties of > the usage object. For example if we want to bill a vm with usagetype 1 we > only see the time the vm was used. But we don't see in the usage data how > many cpus, etc. the vm had at the time the usage record was created. Thus we > cannot bill changes of the vm. For example if a customer adds a cpu core to > his vm and later removes it, this should be seen in the usage records. But as > far as I know the database records are all set to NULL and cloudmonkey does > not return these fields although they are availble in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-9232) Usage data does not reflect changes of VM parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114988#comment-15114988 ] Kishan Kavala edited comment on CLOUDSTACK-9232 at 1/25/16 10:00 AM: - Vm usage data contains service offering id. CPU/memory info can fetched using service offering. Only incase of custom service offering cpu/memory etc are populated in Vm usage records. was (Author: kishan): Vm usage data contain service offering id. CPU/memory info can fetched using service offering. Only incase of custom service offering cpu/memory etc are populated in Vm usage records. > Usage data does not reflect changes of VM parameters > > > Key: CLOUDSTACK-9232 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9232 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.5.2 >Reporter: Norbert Klein > Labels: billing, usage > > The usage data is created without including the information of properties of > the usage object. For example if we want to bill a vm with usagetype 1 we > only see the time the vm was used. But we don't see in the usage data how > many cpus, etc. the vm had at the time the usage record was created. Thus we > cannot bill changes of the vm. For example if a customer adds a cpu core to > his vm and later removes it, this should be seen in the usage records. But as > far as I know the database records are all set to NULL and cloudmonkey does > not return these fields although they are availble in the API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8654) CoreOS support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057802#comment-15057802 ] Kishan Kavala commented on CLOUDSTACK-8654: --- Supported Hypervisors: KVM - 6.5+ XenServer - 6.5 SP1 (http://docs.vmd.citrix.com/XenServer/6.5.0/1.0/en_gb/guest.html#id54) VmWare - ESXi 6.0 (http://blogs.vmware.com/guestosguide/guest-os/linux/coreos) HyperV - N/A > CoreOS support > -- > > Key: CLOUDSTACK-8654 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8654 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > - Support CoreOS OS type while registering template/ISO > - Add UI option to supply user data (cloud-config) while deploying Vm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8933) SSVm and CPVM do not survive a reboot from API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8933: -- Summary: SSVm and CPVM do not survive a reboot from API (was: SSVm and CPVM do not survice a reboot from API) > SSVm and CPVM do not survive a reboot from API > -- > > Key: CLOUDSTACK-8933 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8933 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.6.0 > Environment: KVM Advanced / Basic zone >Reporter: Remi Bergsma >Priority: Blocker > Fix For: 4.6.0 > > Attachments: Console screenshot.png, reboot.4.5.log, reboot.4.6.log > > > These tests fail: > - integration.smoke.test_ssvm.TestSSVMs.test_07_reboot_ssvm > - integration.smoke.test_ssvm.TestSSVMs.test_08_reboot_cpvm > Stopping works, then CloudStack successfully deploys a new one. Rebooting > doesn’t work as it doesn’t complete the boot sequence. Looking at the > agent.log I noticed the systemvm doesn’t get patched so it is probably > waiting for that to happen. > A successful start shows this: > 2015-10-05 21:26:12,748 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Executing: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy.1%proxy_vm=1%disable_rp_filter=true%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > 2015-10-05 21:26:12,777 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-4:null) Execution is successful. > The reboot doesn’t do this. When I hit reboot and run this command manually, > it works: > /usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n > v-1-VM -p > %template=domP%type=consoleproxy%host=192.168.22.61%port=8250%name=v-1-VM%zone=1%pod=1%guid=Proxy1%proxy_vm=1%disable_rp_filter=tru%eth2ip=192.168.23.2%eth2mask=255.255.255.0%gateway=192.168.23.1%eth0ip=169.254.1.20%eth0mask=255.255.0.0%eth1ip=192.168.22.137%eth1mask=255.255.255.0%mgmtcidr=192.168.22.0/24%localgw=192.168.22.1%internaldns1=8.8.4.4%dns1=8.8.8.8 > I basically copy/pasted the patch line from the stop/start and used it when > rebooting. Now everything works. > We need to figure out why it doesn’t patch the system vms on reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8880) Allocated memory more than total memory on a KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14804969#comment-14804969 ] Kishan Kavala commented on CLOUDSTACK-8880: --- Repro steps will be a little bit tricky, as it happened only when you start vms in parallel. 1. one kvm host in one cluster 2. create a few user vms in parallel: and make sure, the memory used by these vms will be slightly larger than the total memory of that kvm host, all the vms will be created successfully > Allocated memory more than total memory on a KVM host > - > > Key: CLOUDSTACK-8880 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8880 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > With memory over-provisioning set to 1, when mgmt server starts VMs in > parallel on one host, then the memory allocated on that kvm can be larger > than the actual physcial memory of the kvm host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8880) Allocated memory more than total memory on a KVM host
Kishan Kavala created CLOUDSTACK-8880: - Summary: Allocated memory more than total memory on a KVM host Key: CLOUDSTACK-8880 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8880 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Reporter: Kishan Kavala Assignee: Kishan Kavala With memory over-provisioning set to 1, when mgmt server starts VMs in parallel on one host, then the memory allocated on that kvm can be larger than the actual physcial memory of the kvm host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8882) Network offering usage is sometimes greater than aggregation range
Kishan Kavala created CLOUDSTACK-8882: - Summary: Network offering usage is sometimes greater than aggregation range Key: CLOUDSTACK-8882 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8882 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Usage Reporter: Kishan Kavala Assignee: Kishan Kavala Create a Vm with mutiple nics: - If 2 networks use same network offering, network offering usage will be 48hrs (assuming 24hrs aggregation) - Usage should be reported per Nic instead of network offering -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8870) external network device usage monitor runs even when there are no external devices
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747281#comment-14747281
]
Kishan Kavala commented on CLOUDSTACK-8870:
---
Following is an extract of the logs from MySQL slow query file:
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
Time: 150611 12:01:14
User@Host: cloud[cloud] @ x2 [10.81.28.127] Id: 4752998
Query_time: 20.000116 Lock_time: 0.00 Rows_sent: 1 Rows_examined: 0
SET timestamp=1434024074;
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
Time: 150611 12:06:14
User@Host: cloud[cloud] @ x2 [10.81.28.127] Id: 4756489
Query_time: 20.000102 Lock_time: 0.00 Rows_sent: 1 Rows_examined: 0
SET timestamp=1434024374;
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
Time: 150611 12:11:14
User@Host: cloud[cloud] @ x2 [10.81.28.127] Id: 4759411
Query_time: 20.000115 Lock_time: 0.00 Rows_sent: 1 Rows_examined: 0
SET timestamp=1434024674;
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
Time: 150611 12:16:14
User@Host: cloud[cloud] @ x2 [10.81.28.127] Id: 4762525
Query_time: 20.000117 Lock_time: 0.00 Rows_sent: 1 Rows_examined: 0
SET timestamp=1434024974;
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
Time: 150611 13:40:33
User@Host: cloud[cloud] @ x2 [10.81.28.127] Id: 4783985
Query_time: 16.206891 Lock_time: 0.00 Rows_sent: 1 Rows_examined: 0
SET timestamp=1434030033;
SELECT COALESCE(GET_LOCK('ExternalDeviceNetworkUsageManagerImpl', 20),0);
> external network device usage monitor runs even when there are no external
> devices
> --
>
> Key: CLOUDSTACK-8870
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8870
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Kishan Kavala
>Assignee: Kishan Kavala
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8870) external network device usage monitor runs even when there are no external devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14747279#comment-14747279 ] Kishan Kavala commented on CLOUDSTACK-8870: --- There is an external network device usage monitor thread that runs every 5mins by default (based on global config external.network.stats.interval) and runs coalesce query to acquire some lock. Currently the thread runs even when there are no external devices. > external network device usage monitor runs even when there are no external > devices > -- > > Key: CLOUDSTACK-8870 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8870 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8870) external network device usage monitor runs even when there are no external devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-8870: - Assignee: Kishan Kavala > external network device usage monitor runs even when there are no external > devices > -- > > Key: CLOUDSTACK-8870 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8870 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8870) external network device usage monitor runs even when there are no external devices
Kishan Kavala created CLOUDSTACK-8870: - Summary: external network device usage monitor runs even when there are no external devices Key: CLOUDSTACK-8870 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8870 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kishan Kavala -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8688) Default policy for INPUT and FORWARD chain is ACCEPT in VR filter table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8688: -- Fix Version/s: 4.6.0 Default policy for INPUT and FORWARD chain is ACCEPT in VR filter table --- Key: CLOUDSTACK-8688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8688 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 Environment: Latest build from ACS master. Zone type: Advanced Reporter: Sanjeev N Assignee: Wilder Rodrigues Priority: Critical Fix For: 4.6.0 Defualt policy for INPUT and FORWARD chain is ACCEPT in VR filter table Steps to reproduce the issue: === 1.Bring up CS in advanced zone with any supported hypervisor (e.g. Xenserver) 2.Create an isolated network with Network Offering DefaultIsolatedNetworkOfferingWithSourceNatService 3.Deploy one guest vm within that network Result: === IP tables rules on the VR created are as follows: root@r-7-VM:~# iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere ACCEPT all -- anywhere vrrp.mcast.net ACCEPT all -- anywhere 225.0.0.50 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere vrrp.mcast.net ACCEPT all -- anywhere 225.0.0.50 ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT udp -- anywhere anywhere udp dpt:bootps ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:http state NEW ACCEPT tcp -- anywhere anywhere tcp dpt:http-alt state NEW Chain FORWARD (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere state NEW ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chain OUTPUT (policy ACCEPT) target prot opt source destination NETWORK_STATS all -- anywhere anywhere Chain NETWORK_STATS (3 references) target prot opt source destination all -- anywhere anywhere all -- anywhere anywhere tcp -- anywhere anywhere tcp -- anywhere anywhere But the Default policy for INPUT and FORWARD chain should be DROP instead of ACCEPT. Otherwise all the traffic would be allowed to VR. Same is the case with VPC and Shared network as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8694) monitorServices.py is not running as a cron job in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8694: -- Fix Version/s: 4.6.0 monitorServices.py is not running as a cron job in VR - Key: CLOUDSTACK-8694 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8694 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Environment: Xenserver CS 4.6.0 Reporter: Sarath Kasi Fix For: 4.6.0 In the VR, monitorServerices.py which should be running as a cron job for every 3 minutes, is not visible INPUT : crontab -l -- EXPECTED RESULT : oot@r-6-VM:~# crontab -l #monitoringConfig SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin */3 * * * * /usr/bin/python /root/monitorServices.py -- ACTUAL OUTPUT : no crontab for root -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8697) Assign VPC Internal LB rule to a VM fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-8697:
--
Fix Version/s: 4.6.0
Assign VPC Internal LB rule to a VM fails
-
Key: CLOUDSTACK-8697
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8697
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.6.0
Reporter: Pavan Kumar Bandarupally
Priority: Critical
Fix For: 4.6.0
Attachments: MSLog.rar
Assigning an internal LB rule to a VM inside VPC network fails. Seems to be a
configuration issue.
2015-07-31 21:13:49,059 ERROR [c.c.u.s.SshHelper]
(DirectAgent-345:ctx-2bdddfcc) SSH execution of command
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.2.171
load_balancer.json has an error status code in return. result output:
2015-07-31 21:13:49,062 DEBUG [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-345:ctx-2bdddfcc) Processing ScriptConfigItem, executing
update_config.py load_balancer.json took 6656ms
2015-07-31 21:13:49,062 WARN [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-345:ctx-2bdddfcc) Expected 1 answers while executing
LoadBalancerConfigCommand but received 2
2015-07-31 21:13:49,062 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Response Received:
2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
(DirectAgent-345:ctx-2bdddfcc) Seq 7-4435764157983228083: Processing: { Ans:
, MgmtId: 6702933999656, via: 7, Ver: v1, Flags: 0,
[{com.cloud.agent.api.routing.GroupAnswer:{results:[null - failed:
,null - failed: ],result:false,wait:0}}] }
2015-07-31 21:13:49,063 DEBUG [c.c.a.t.Request]
(API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) Seq
7-4435764157983228083: Received: { Ans: , MgmtId: 6702933999656, via: 7,
Ver: v1, Flags: 0, { GroupAnswer } }
2015-07-31 21:13:49,133 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
(API-Job-Executor-9:ctx-4c2d49d3 job-315 ctx-06ebb5a1) LB Rollback rule id: 6
while attaching VM: [29]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8681) [Egress_Rules] CS does not honor the default deny egress policy in isolated network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8681: -- Fix Version/s: 4.6.0 [Egress_Rules] CS does not honor the default deny egress policy in isolated network --- Key: CLOUDSTACK-8681 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8681 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from master with commit ac9c2a224a78f413945e25fd7cf23364fbef00b5 Zone: Advanced Reporter: Sanjeev N Priority: Critical Fix For: 4.6.0 [Egress_Rules] CS does not honor the default deny egress policy in isolated network Steps to reproduce: = 1.Bring up CS in advanced zone with any of the supported hypervisors 2.Create an isolated network with network offering DefaultIsolatedNetworkOfferingWithSourceNatService so that defaul egress policy would be deny all 3.Deploy one guest vm in that network Expected Result: = VR forward chain in filter table should have the defualt DROP policy. Actual Result: === Following is the FORWARD chain from the VR: Chain FORWARD (policy ACCEPT 10282 packets, 1743K bytes) pkts bytes target prot opt in out source destination 46405 27M NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state NEW 27468 25M ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 2 104 ACCEPT tcp -- eth2 eth00.0.0.0/00.0.0.0/0 tcp dpt:22 state NEW It should be in the following way: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/ 0 0 0 ACCEPT all -- eth0 eth10.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state NEW 0 0 ACCEPT all -- eth0 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth2 eth00.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 FW_OUTBOUND all -- eth0 eth20.0.0.0/0 0.0.0.0/0 Chain FW_EGRESS_RULES (1 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 Chain FW_OUTBOUND (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 FW_EGRESS_RULES all -- * * 0.0.0.0/0 0.0.0. 0/0 Looks like now we are loading ip tables from /etc/iptables/router_rules.v4 . But the base for this file should be /etc/iptables/rules.v4 to persist the default behavior. -- 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 ] Kishan Kavala 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 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] [Updated] (CLOUDSTACK-8696) Create Region fails with endpoint parameter validation exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8696: -- Fix Version/s: 4.5.2 4.6.0 Create Region fails with endpoint parameter validation exception Key: CLOUDSTACK-8696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8696 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.6.0, 4.5.1 Reporter: Pavan Kumar Bandarupally Assignee: Rajani Karuturi Priority: Critical Fix For: 4.6.0, 4.5.2 Trying to add a new region fails with unhandled exception. The endpoint parameter validation seems to be failing. Problem with getting the ec attribute Exception: === 2015-07-31 19:48:32,669 DEBUG [c.c.a.ApiServlet] (catalina-exec-24:ctx-1106054b) ===START=== 10.252.193.9 -- GET command=addRegionresponse=jsonid=3name=teendpoint=http%3A%2F%2Flocalhost%3A8080%2Fclient_=1438333561026 2015-07-31 19:48:32,691 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-24:ctx-1106054b ctx-9e3359a9) Rolling back the transaction: Time = 3 Name = catalina-exec-24; called by -TransactionLegacy.rollback:879-TransactionLegacy.removeUpTo:822-TransactionLegacy.close:646-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy133.persist:-1-RegionManagerImpl.addRegion:113-RegionServiceImpl.addRegion:87-AddRegionCmd.execute:89 2015-07-31 19:48:32,699 ERROR [c.c.a.ApiServer] (catalina-exec-24:ctx-1106054b ctx-9e3359a9) unhandled exception executing api command: [Ljava.lang.String;@750f6a7c com.cloud.utils.exception.CloudRuntimeException: Problem with getting the ec attribute at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1403) 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 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy133.persist(Unknown Source) at org.apache.cloudstack.region.RegionManagerImpl.addRegion(RegionManagerImpl.java:113) at org.apache.cloudstack.region.RegionServiceImpl.addRegion(RegionServiceImpl.java:87) at org.apache.cloudstack.api.command.admin.region.AddRegionCmd.execute(AddRegionCmd.java:89) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:302) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at
[jira] [Updated] (CLOUDSTACK-8696) Create Region fails with endpoint parameter validation exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8696: -- Affects Version/s: 4.5.0 4.5.1 Create Region fails with endpoint parameter validation exception Key: CLOUDSTACK-8696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8696 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.5.0, 4.6.0, 4.5.1 Reporter: Pavan Kumar Bandarupally Assignee: Rajani Karuturi Priority: Critical Trying to add a new region fails with unhandled exception. The endpoint parameter validation seems to be failing. Problem with getting the ec attribute Exception: === 2015-07-31 19:48:32,669 DEBUG [c.c.a.ApiServlet] (catalina-exec-24:ctx-1106054b) ===START=== 10.252.193.9 -- GET command=addRegionresponse=jsonid=3name=teendpoint=http%3A%2F%2Flocalhost%3A8080%2Fclient_=1438333561026 2015-07-31 19:48:32,691 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-24:ctx-1106054b ctx-9e3359a9) Rolling back the transaction: Time = 3 Name = catalina-exec-24; called by -TransactionLegacy.rollback:879-TransactionLegacy.removeUpTo:822-TransactionLegacy.close:646-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy133.persist:-1-RegionManagerImpl.addRegion:113-RegionServiceImpl.addRegion:87-AddRegionCmd.execute:89 2015-07-31 19:48:32,699 ERROR [c.c.a.ApiServer] (catalina-exec-24:ctx-1106054b ctx-9e3359a9) unhandled exception executing api command: [Ljava.lang.String;@750f6a7c com.cloud.utils.exception.CloudRuntimeException: Problem with getting the ec attribute at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1403) 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 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy133.persist(Unknown Source) at org.apache.cloudstack.region.RegionManagerImpl.addRegion(RegionManagerImpl.java:113) at org.apache.cloudstack.region.RegionServiceImpl.addRegion(RegionServiceImpl.java:87) at org.apache.cloudstack.api.command.admin.region.AddRegionCmd.execute(AddRegionCmd.java:89) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:704) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:529) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:302) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:127) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:124) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[jira] [Updated] (CLOUDSTACK-6623) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6623: -- Assignee: (was: edison su) Register template does not work as expected, when deploying simulator and xen zones simultaneously on a single management server. - Key: CLOUDSTACK-6623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar Priority: Critical Fix For: 4.6.0 when we setup simulator and xenserver both in separate zones on a single management server, The register template always behaves as if it is executing on the simulator. i.e. register template is always successful and it dose not initiate the actual download when calling the register template API against xen-zone. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6698) listResourceDetals - normal user able to list details not belonging to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6698: -- Assignee: (was: Nitin Mehta) listResourceDetals - normal user able to list details not belonging to it - Key: CLOUDSTACK-6698 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6698 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Nitin Mehta Priority: Critical Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7289) Bugs seen when declaring a class variable as native type (long) and have its getter method returning the corresponding object (Long) and vice versa
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-7289:
--
Assignee: (was: Nitin Mehta)
Bugs seen when declaring a class variable as native type (long) and have its
getter method returning the corresponding object (Long) and vice versa
---
Key: CLOUDSTACK-7289
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7289
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Priority: Critical
Fix For: 4.6.0
Declare a variable as native type (long) and have its getter method
returning the corresponding object (Long). This is what I fixed with
CLOUDSTACK-7272.
Example below. This should be fixed in the entire code base.
Autoboxing causes NPE or defaults some values. The vice versa should be
fixed as well meaning declaring hostId as Long and returning as native
type (long).
long hostId
Long getHostId(){
return hostId;
}
Right Implementation (hostId is declared as Long)
Long hostId;
Long getHostId(){
return hostId;
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7290) VO classes shouldn¹t have any class variables declared as native type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7290: -- Assignee: (was: Nitin Mehta) VO classes shouldn¹t have any class variables declared as native type - Key: CLOUDSTACK-7290 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7290 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Nitin Mehta Priority: Critical Fix For: 4.6.0 VO classes which are the mapping of schema to Java objects shouldn¹t have any class variables declared as native type. Because native types have default values whereas schema columns can be null and declaring as native types masks that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-8683. --- Resolution: Fixed Shared network VR ssh on port 3922 is blocked - Key: CLOUDSTACK-8683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker ssh to Shared network VR on link_local_ip @ port 3922 is blocked. MS is not able to program any rules on the VR due to this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-8683: - Assignee: Kishan Kavala Shared network VR ssh on port 3922 is blocked - Key: CLOUDSTACK-8683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker ssh to Shared network VR on link_local_ip @ port 3922 is blocked. MS is not able to program any rules on the VR due to this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8685) [VPC_VR] Default route is not configured on VPC VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-8685:
--
Fix Version/s: 4.6.0
[VPC_VR] Default route is not configured on VPC VR
--
Key: CLOUDSTACK-8685
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8685
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.6.0
Environment: Advanced zone with VPC. Latest build from ACS master.
Reporter: Sanjeev N
Priority: Critical
Fix For: 4.6.0
Attachments: management-server.zip
[VPC_VR] Default route is not configured on VPC VR
Steps to reproduce:
1.Bring up CS in advanced zone
2.Create VPC and wait for the VR to come into running state
3.Connect to VR and verify route table information
Result:
==
Default route is not configured on VPC VR.
root@r-9-VM:/var/cache/cloud# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth2
10.1.2.00.0.0.0 255.255.255.0 U 0 00 eth3
10.220.128.00.0.0.0 255.255.224.0 U 0 00 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0
root@r-9-VM:/var/cache/cloud#
Observations:
===
When vr boots up, we run cloud-early-config. This will clean if there is any
default route exists on VR. Then we execute vpc_ipassoc.sh to configure
public nic and default route via public nic. However, in the latest ACS
master we are not executing vpc_ipassoc.sh.
For any configuration on VR , we are creating configuration file and applying
it with update_config.py.
Looks like adding default route is missing in the confguration file.
Following is the configuration file genearted on VR :
015-07-29 05:20:39,132 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-402:ctx-83549002) VR Config file
VR-d3b73941-7b3d-489a-bcc6-47c6a777c950.cfg got created in VR, ip
169.254.0.54 with content
#Apache CloudStack Virtual Router Config File
version
1.0
/version
file
/var/cache/cloud/ip_associations.json
{ip_address:[{public_ip:10.220.135.97,source_nat:false,add:true,one_to_one_nat:false,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false},{public_ip:10.220.135.99,source_nat:false,add:true,one_to_one_nat:true,first_i_p:false,gateway:10.220.128.1,netmask:255.255.224.0,vif_mac_address:06:dd:e0:00:00:0e,nic_dev_id:1,new_nic:false}],type:ips}
/file
script
/opt/cloud/bin/update_config.py ip_associations.json
/script
file
/var/cache/cloud/staticnat_rules.json
{rules:[{revoke:false,source_ip_address:10.220.135.99,source_port_range:0:0,destination_ip_address:10.1.1.36}],type:staticnatrules}
/file
script
/opt/cloud/bin/update_config.py staticnat_rules.json
/script
file
/var/cache/cloud/forwarding_rules.json
{rules:[{revoke:false,protocol:tcp,source_ip_address:10.220.135.97,source_port_range:22:22,destination_ip_address:10.1.1.194,destination_port_range:22:22}],type:forwardrules}
/file
script
/opt/cloud/bin/update_config.py forwarding_rules.json
/script
file
/var/cache/cloud/network_acl.json
{device:eth2,mac_address:02:00:7c:a8:00:02,private_gateway_acl:false,nic_ip:10.1.1.1,nic_netmask:24,ingress_rules:[{type:tcp,first_port:22,last_port:22,cidr:0.0.0.0/0,allowed:true}],egress_rules:[{type:icmp,icmp_type:-1,icmp_code:-1,cidr:0.0.0.0/0,allowed:true}],type:networkacl}
/file
script
/opt/cloud/bin/update_config.py network_acl.json
/script
file
/var/cache/cloud/vm_dhcp_entry.json
{host_name:VM-403a0536-ba54-404f-a664-1b14d039497c,mac_address:02:00:10:ca:00:01,ipv4_adress:10.1.1.194,ipv6_duid:00:03:00:01:02:00:10:ca:00:01,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_dhcp_entry.json
{host_name:VM-4c5e69ab-65dd-4315-b8fb-702f5599ede0,mac_address:02:00:0f:22:00:03,ipv4_adress:10.1.1.36,ipv6_duid:00:03:00:01:02:00:0f:22:00:03,default_gateway:10.1.1.1,default_entry:true,type:dhcpentry}
/file
script
/opt/cloud/bin/update_config.py vm_dhcp_entry.json
/script
file
/var/cache/cloud/vm_metadata.json
{vm_ip_address:10.1.1.194,vm_metadata:[[userdata,user-data,null],[metadata,service-offering,Tiny
[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644133#comment-14644133 ] Kishan Kavala commented on CLOUDSTACK-8668: --- Issue is due to router type in cmdline. For VR in shared network type is dhcpsrvr and not router. I'll create a PR for this fix VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Wilder Rodrigues Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644265#comment-14644265 ] Kishan Kavala commented on CLOUDSTACK-8683: --- root@r-27-VM:~# cat /etc/iptables/router_rules.v4 # Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015 *mangle :PREROUTING ACCEPT [85:12336] :INPUT ACCEPT [85:12336] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [78:13012] :POSTROUTING ACCEPT [78:13012] -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 0x0/0x COMMIT # Completed on Tue Jul 28 10:22:49 2015 # Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015 *filter :INPUT ACCEPT [83:12168] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [78:13012] :NETWORK_STATS - [0:0] -A INPUT -j NETWORK_STATS -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT -A FORWARD -j NETWORK_STATS -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j NETWORK_STATS -A NETWORK_STATS -i eth0 -o eth2 -A NETWORK_STATS -i eth2 -o eth0 -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp COMMIT # Completed on Tue Jul 28 10:22:49 2015 # Generated by iptables-save v1.4.14 on Tue Jul 28 10:22:49 2015 *nat :PREROUTING ACCEPT [17:1384] :INPUT ACCEPT [15:1304] :OUTPUT ACCEPT [4:268] :POSTROUTING ACCEPT [4:268] COMMIT # Completed on Tue Jul 28 10:22:49 2015 Shared network VR ssh on port 3922 is blocked - Key: CLOUDSTACK-8683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Priority: Blocker ssh to Shared network VR on link_local_ip @ port 3922 is blocked. MS is not able to program any rules on the VR due to this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked
Kishan Kavala created CLOUDSTACK-8683: - Summary: Shared network VR ssh on port 3922 is blocked Key: CLOUDSTACK-8683 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8683 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kishan Kavala Priority: Blocker ssh to Shared network VR on link_local_ip @ port 3922 is blocked. MS is not able to program any rules on the VR due to this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8683) Shared network VR ssh on port 3922 is blocked
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644263#comment-14644263
]
Kishan Kavala commented on CLOUDSTACK-8683:
---
VR started successfully:
2015-07-28 14:59:19,348 DEBUG [c.c.a.t.Request] (DirectAgent-77:ctx-f7624550)
Seq 3-4390446686732812409: Processing: { Ans: , MgmtId: 233845178473044, via:
3, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:27,name:r-27-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,arch:x86_64,os:Debian
GNU/Linux 7(64-bit),platformEmulator:Debian Wheezy 7.0
(64-bit),bootArgs: template=domP name=r-27-VM eth0ip=10.147.52.121
eth0mask=255.255.255.0 gateway=10.147.52.1 domain=cs1cloud.internal cidrsize=24
dhcprange=10.147.52.1 eth1ip=169.254.0.180 eth1mask=255.255.0.0 type=dhcpsrvr
disable_rp_filter=true dns1=4.2.2.2
baremetalnotificationsecuritykey=s67s-w0ooifUaTiCWhF24OUfj8JSRhTKTs6N-2rlWY2tkkPo-F0nZOv1lKTIyXXs0ir4vv0hatiUHFaddZxiDw
baremetalnotificationapikey=c9SUcsu8zctnSQmy43yhQB0HJM2HTDsRjEXd85s9IJOobOBRLaGZBa22vDH4IozJpIW8PHXVAFWu_W9qtdvYIA
host=10.147.28.47
port=8080,enableHA:true,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:NgZKb896siNBSaMS6m9y8A,params:{},uuid:2d2cc793-7ddc-49be-811c-86e859c31b11,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:206adec6-37e6-4596-a052-4a2e38d62d1e,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:4edf56a8-1f93-513a-4bb7-e859915dfa15,id:1,poolType:LVM,host:10.147.28.44,path:lvm,port:0,url:LVM://10.147.28.44/lvm/?ROLE=PrimarySTOREUUID=4edf56a8-1f93-513a-4bb7-e859915dfa15}},name:ROOT-27,size:3145728000,path:fe290765-5d3a-4547-84c6-14acb8a03f71,volumeId:27,vmName:r-27-VM,accountId:1,format:VHD,provisioningType:THIN,id:27,deviceId:0,hypervisorType:XenServer}},diskSeq:0,path:fe290765-5d3a-4547-84c6-14acb8a03f71,type:ROOT,_details:{managed:false,storagePort:0,storageHost:10.147.28.44,volumeSize:3145728000}}],nics:[{deviceId:0,networkRateMbps:200,defaultNic:true,pxeDisable:true,nicUuid:1ab3d3d9-008c-4c20-a34d-a15978a00fac,uuid:09c5c631-7164-42f6-a5ad-30826734305c,ip:10.147.52.121,netmask:255.255.255.0,gateway:10.147.52.1,mac:06:27:98:00:00:16,dns1:4.2.2.2,broadcastType:Vlan,type:Guest,broadcastUri:vlan://52,isolationUri:vlan://52,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,pxeDisable:true,nicUuid:b63b0fa9-de99-47d8-a913-f66215ef2e06,uuid:4c825977-669f-4777-9a44-a312952321c8,ip:169.254.0.180,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:00:b4,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},_iqnToPath:{},result:true,wait:0}},{com.cloud.agent.api.check.CheckSshAnswer:{result:true,wait:0}},{com.cloud.agent.api.GetDomRVersionAnswer:{templateVersion:Cloudstack
Release 4.6.0 Sun Jul 26 22:08:05 UTC
2015,scriptsVersion:34389714eff6bb4cbfd2c8cc1cbaac85\n,result:true,details:Cloudstack
Release 4.6.0 Sun Jul 26 22:08:05 UTC
201534389714eff6bb4cbfd2c8cc1cbaac85\n,wait:0}},{com.cloud.agent.api.NetworkUsageAnswer:{routerName:r-27-VM,bytesSent:0,bytesReceived:0,result:true,details:,wait:0}},{com.cloud.agent.api.Answer:{result:true,details:Command
aggregation
started,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,wait:0}},{com.cloud.agent.api.Answer:{result:true,details:Command
aggregation finished,wait:0}}] }
2015-07-28 14:59:19,348 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-8:ctx-1de01f8b job-209/job-210 ctx-d40f9c75) Seq
3-4390446686732812409: Received: { Ans: , MgmtId: 233845178473044, via: 3,
Ver: v1, Flags: 10, { StartAnswer, CheckSshAnswer, GetDomRVersionAnswer,
NetworkUsageAnswer, Answer, Answer, Answer, Answer, Answer, Answer, Answer } }
SSH timed out while adding DHCP entry:
2015-07-28 15:01:27,099 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-81:ctx-6421786c) VR Config file vm_dhcp_entry.json got created in
VR, ip 169.254.0.180 with content
{host_name:VM-b2364fd7-92ce-4ccc-89bc-842aabaa9a6e,mac_address:06:df:8a:00:00:18,ipv4_adress:10.147.52.123,ipv6_duid:00:03:00:01:06:df:8a:00:00:18,dns_adresses:10.147.52.120,default_gateway:10.147.52.1,default_entry:true,type:dhcpentry}
2015-07-28 15:01:27,099 DEBUG [c.c.a.r.v.VirtualRoutingResource]
(DirectAgent-81:ctx-6421786c) Processing FileConfigItem, copying 266 characters
to vm_dhcp_entry.json took 127595ms
2015-07-28 15:01:27,099 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-81:ctx-6421786c) Executing command in VR:
/opt/cloud/bin/router_proxy.sh update_config.py 169.254.0.180 vm_dhcp_entry.json
2015-07-28 15:03:27,204 ERROR [c.c.u.s.SshHelper] (DirectAgent-81:ctx-6421786c)
Timed out in waiting SSH execution result
[jira] [Updated] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8668: -- Fix Version/s: 4.6.0 VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Kishan Kavala Priority: Blocker Fix For: 4.6.0 VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-8668. --- Resolution: Fixed VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Kishan Kavala Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14644290#comment-14644290 ] Kishan Kavala commented on CLOUDSTACK-8668: --- Yes Wilder VR started successfully . But port 3922 is not open. Once I add iptables rule to allow 3922, MS is able to program rules. I'm looking at CLOUDSTACK-8683, but might take a while for me to find the root cause. VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Wilder Rodrigues Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8668: -- Comment: was deleted (was: Yes Wilder VR started successfully . But port 3922 is not open. Once I add iptables rule to allow 3922, MS is able to program rules. I'm looking at CLOUDSTACK-8683, but might take a while for me to find the root cause.) VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Wilder Rodrigues Priority: Blocker VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-8668: -- Assignee: Kishan Kavala (was: Wilder Rodrigues) VR does not start in basic zone since ip address are not being configured on it --- Key: CLOUDSTACK-8668 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.6.0 Environment: Latest build from ACS master Reporter: Sanjeev N Assignee: Kishan Kavala Priority: Blocker Fix For: 4.6.0 VR does not start in basic zone since ip address are not being configured on it Steps to reproduce: 1.Bring up CS in basic zone with xen server cluster 2.Try to deploy one guest vm using default cent os template Expected Result: == VR should come up as part of vm deployment and vm deployment should be successfull Actual Result: VR creation failed since the IP addresses not are getting assigned to VR's guest and link local interfaces. Observations: === 1.During vr boot time, cloud-early-config ran successfully and VR console output showed that ping to gateway was successful. However, after VR boot we don't see any ip addresses on the VRs guest and link local ip address. 2. If we run cloud-early-config manually from VR , ip addresses will be assigned and persistent. Impact: = VM deployments will fail since VR remains in stopped state. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8668) VR does not start in basic zone since ip address are not being configured on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14640389#comment-14640389
]
Kishan Kavala commented on CLOUDSTACK-8668:
---
VR Config file:
#Apache CloudStack Virtual Router Config File version
1.0
/version
file
/var/cache/cloud/monitor_service.json
{config:[dhcp]:processname=dnsmasq:servicename=dnsmasq:pidfile=/var/run/dnsmasq/dnsmasq.pid:,[ssh]:processname=sshd:servicename=ssh:pidfile=/var/run/sshd.pid:,[webserver]:processname=apache2:servicename=apache2:pidfile=/var/run/apache2.pid:,,type:monitorservice}
/file
script
/opt/cloud/bin/update_config.py monitor_service.json /script
/var/log/cloud.log:
2015-07-24 09:29:28,997 Loading data bag type monitorservice
2015-07-24 09:29:28,998 Command of type monitorservice received
2015-07-24 09:29:28,999 Writing data bag type monitorservice
2015-07-24 09:29:28,999 Creating data bag type ips
2015-07-24 09:29:28,999 Loading data bag type cmdline
2015-07-24 09:29:29,000 Executing ip addr show dev eth1
2015-07-24 09:29:29,019 Will remove all configured addresses on device eth1
2015-07-24 09:29:29,019 Removing addresses from device eth1
2015-07-24 09:29:29,036 Removed address 169.254.2.130/16 from device eth1
2015-07-24 09:29:29,056 Removed address 169.254.2.130/16 from device eth1
2015-07-24 09:29:29,057 Executing ip addr show dev eth0
2015-07-24 09:29:29,075 Will remove all configured addresses on device eth0
2015-07-24 09:29:29,076 Removing addresses from device eth0
2015-07-24 09:29:29,093 Removed address 10.220.39.131/19 from device eth0
2015-07-24 09:29:29,112 Removed address 10.220.39.131/19 from device eth
VR does not start in basic zone since ip address are not being configured on
it
---
Key: CLOUDSTACK-8668
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8668
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.6.0
Environment: Latest build from ACS master
Reporter: Sanjeev N
Priority: Blocker
VR does not start in basic zone since ip address are not being configured on
it
Steps to reproduce:
1.Bring up CS in basic zone with xen server cluster
2.Try to deploy one guest vm using default cent os template
Expected Result:
==
VR should come up as part of vm deployment and vm deployment should be
successfull
Actual Result:
VR creation failed since the IP addresses not are getting assigned to VR's
guest and link local interfaces.
Observations:
===
1.During vr boot time, cloud-early-config ran successfully and VR console
output showed that ping to gateway was successful. However, after VR boot we
don't see any ip addresses on the VRs guest and link local ip address.
2. If we run cloud-early-config manually from VR , ip addresses will be
assigned and persistent.
Impact:
=
VM deployments will fail since VR remains in stopped state.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-8573) Manage CoreOS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-8573: - Assignee: Kishan Kavala Manage CoreOS - Key: CLOUDSTACK-8573 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8573 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Reporter: Keerthiraja Assignee: Kishan Kavala Fix For: Future, 4.6.0 Hi All, I would like bring up an idea to manage to support the CoreOS to Manage via Cloudstack. This will be our next major focus on Dockers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8654) CoreOS support
Kishan Kavala created CLOUDSTACK-8654: - Summary: CoreOS support Key: CLOUDSTACK-8654 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8654 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala - Support CoreOS OS type while registering template/ISO - Add UI option to supply user data (cloud-config) while deploying Vm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8614) Usage records have no valid records for migrated volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616581#comment-14616581 ] Kishan Kavala commented on CLOUDSTACK-8614: --- This is fixed in CLOUDSTACK-7792 for 4.6 https://issues.apache.org/jira/browse/CLOUDSTACK-7792 May not be easy to backport it to 4.5 Usage records have no valid records for migrated volumes Key: CLOUDSTACK-8614 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8614 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.5.1 Reporter: Norbert Klein Priority: Minor Labels: usage If a volume is migrated to another storage pool the usage records do not reflect this move. If a volume is migrated to another storage pool the cloud.volumes table gets a new record for the volume. The uuid of the old record is set to null. The uuid of the new record is the same as in the old record. So far this seems to be the normal procedure within the cloud database. Now, the usage records for this volume are still created but they don't point to the new record in the cloud.volumes table: if you make an api call with listUsageRecords you find usage records but without the usageid field and the description field contains the old Id of the cloud.volumes record. So it is hard to associate the usage data to the migrated volumes. What should happen imho is that the usage records for migrated volumes contain the uuid in the usageid field and the description field should be updated so that it contains the new Id. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8605) KVM: Config Drive and getVmIp support
Kishan Kavala created CLOUDSTACK-8605: - Summary: KVM: Config Drive and getVmIp support Key: CLOUDSTACK-8605 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8605 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.6.0 Reporter: Kishan Kavala Assignee: Kishan Kavala Fix For: 4.6.0 Add support for - creating config drive - Fetch IP from guest Vm which is assigned by external DHCP -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-5409) Project created in a VPC does not display s2s VPN Gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-5409: - Assignee: Kishan Kavala Project created in a VPC does not display s2s VPN Gateway - Key: CLOUDSTACK-5409 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5409 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.4.1 Environment: Confirmed in 4.1.0 production environment and 4.2.0 testing enviornment Reporter: Mitchell Rinzel Assignee: Kishan Kavala Priority: Minor 1.Created Project 2.Created VPC under the Project 3.Created Tier under VPC 4.Clicked on Site-to-Site VPN 5.Selected yes to create the s2s gateway Expected Result: Gateway created and visible Actual result Gateway is created, but not visible If you attempt create the gateway again it will error saying it already exists Checking in the Database shows the gateway is created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7948) [Automation] Two VOLUME.DELETE Events are being registered instead of one - On Destroying a User VM belonging to a Project
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362745#comment-14362745
]
Kishan Kavala commented on CLOUDSTACK-7948:
---
Review request.
https://reviews.apache.org/r/28325/
[Automation] Two VOLUME.DELETE Events are being registered instead of one -
On Destroying a User VM belonging to a Project
Key: CLOUDSTACK-7948
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7948
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Kishan Kavala
Fix For: 4.5.1
==
User VM in Project Events Information in the Database:
==
{noformat}
mysql select * from usage_event where account_id=6;
++-++-+-+-++-+-+-++---+--+
| id | type| account_id | created | zone_id |
resource_id | resource_name | offering_id | template_id | size|
resource_type | processed | virtual_size |
++-++-+-+-++-+-+-++---+--+
| 19 | TEMPLATE.CREATE | 6 | 2014-11-19 21:28:14 | 1 |
202 | TestTemplate-1 |NULL |NULL | 1708331520 | NULL
| 0 | 8589934592 |
| 20 | VOLUME.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
9 | ROOT-9 | 1 | 5 | 21474836480 | NULL
| 0 | NULL |
| 21 | VM.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 22 | NET.IPASSIGN| 6 | 2014-11-19 21:32:25 | 1 |
6 | 10.219.196.151 |NULL | 0 | 0 |
DirectAttached | 0 | NULL |
| 23 | NETWORK.OFFERING.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
9 | 19 | 6 |NULL | 1 | NULL
| 0 | NULL |
| 24 | SG.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
9 | NULL | 4 |NULL |NULL | NULL
| 0 | NULL |
| 25 | VM.START| 6 | 2014-11-19 21:32:33 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 26 | SG.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
9 | NULL | 4 |NULL |NULL | NULL
| 0 | NULL |
| 27 | VM.STOP | 6 | 2014-11-19 21:33:10 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 28 | NETWORK.OFFERING.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
9 | 19 | 6 |NULL | 0 | NULL
| 0 | NULL |
| 31 | VM.DESTROY | 6 | 2014-11-20 00:08:37 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 32 | VOLUME.DELETE | 6 | 2014-11-20 00:08:37 | 1 |
9 | ROOT-9 |NULL |NULL |NULL | NULL
| 0 | NULL |
| 33 | NET.IPRELEASE | 6 | 2014-11-20 00:08:39 | 1 |
6 | 10.219.196.151 |NULL | 0 | 0 |
DirectAttached | 0 | NULL |
| 34 | VOLUME.DELETE | 6 | 2014-11-20 00:08:39 | 1 |
9 | ROOT-9 |NULL |NULL |NULL | NULL
| 0 | NULL |
++-++-+-+-++-+-+-++---+--+
14 rows in set (0.00 sec)
{noformat}
=
Destroy VM Job Log:
=
{noformat}
2014-11-20 00:08:35,021 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
[jira] [Commented] (CLOUDSTACK-8200) Secondary storage and systemvm template detection fails with KVM and LocalStorage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14304885#comment-14304885
]
Kishan Kavala commented on CLOUDSTACK-8200:
---
Looks like zone is not enabled. (allocationstate:Disabled)
2015-02-03 22:34:25,437 INFO [a.c.c.a.ApiServer]
(2081539129@qtp-244683398-4:ctx-8b656409 ctx-c9e8898f) (userId=2 accountId=2
sessionId=14qtcvkji8ttb69yrzz8eqglg) 127.0.0.1 -- GET
command=listZonesresponse=jsonsessionkey=HSMPtrlusV3ept0%2F3GUHkQBRDzE%3Dpage=1pagesize=1_=1422983065424
200
{listzonesresponse:{count:1,zone:[{id:40157c8e-bd55-48d3-85e1-97783cb0bb7a,name:MyZone,dns1:8.8.8.8,internaldns1:192.168.1.1,networktype:Basic,securitygroupsenabled:true,allocationstate:Disabled,zonetoken:93be424f-9c3a-30db-9c0a-12e469929a06,dhcpprovider:VirtualRouter,localstorageenabled:true,tags:[]}]}}
Secondary storage and systemvm template detection fails with KVM and
LocalStorage
-
Key: CLOUDSTACK-8200
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8200
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: Blocker
Fix For: 4.5.0, 4.6.0
Attachments: api.log.gz, vmops.log.gz
With KVM, when a zone is deployed with localstorage - it fails to detect
systemvm template of the added secondary storage and does not do anything:
120453 2015-02-03 22:33:57,691 DEBUG [c.c.s.StatsCollector]
(StatsCollector-3:ctx-206849e1) There is no secondary storage VM for
secondary storage host Seclkj
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7320) [LXC] Provide default centos template for lxc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7320. --- Resolution: Fixed [LXC] Provide default centos template for lxc -- Key: CLOUDSTACK-7320 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7320 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: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 We generally provide default template with all our hypervisor support . similarly we need to provide a default template for LXC as well -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Fix Version/s: (was: 4.5.0) (was: 4.4.0) Future Persist VR nic details in DB for additional public ranges - Key: CLOUDSTACK-3952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Kishan Kavala Assignee: Kishan Kavala Fix For: Future For non-vpcs VR, nics are dynamically created for addtional IP ranges with different Vlan. Prepare fro migration doesn't setup the destination host correctly due to this and migration fails. Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14219020#comment-14219020 ] Kishan Kavala commented on CLOUDSTACK-7746: --- Template with flask installed is available here: http://jenkins.buildacloud.org/job/build-systemvm64-master/443/ Baremetal related script erros seen on router console - Key: CLOUDSTACK-7746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from master Reporter: Sangeetha Hariharan Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.5.0 Attachments: router.png Baremetal related script erros seen on router console. Advanced zone set up with 3 xenserver hosts in a cluster. When logging into the console view of router , following script errors are seen: /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned to before glocal declaration. .. Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7746. --- Resolution: Fixed Baremetal related script erros seen on router console - Key: CLOUDSTACK-7746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from master Reporter: Sangeetha Hariharan Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.5.0 Attachments: router.png Baremetal related script erros seen on router console. Advanced zone set up with 3 xenserver hosts in a cluster. When logging into the console view of router , following script errors are seen: /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned to before glocal declaration. .. Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5324. --- Resolution: Fixed error message not proper when start VM fails because router requires upgrade - Key: CLOUDSTACK-5324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 Repro steps: Create a VM on 3.07 setup Upgrade to 4.3.0 but dont upgrade routers Stop user VM Start user VM Bug: Error message shows Unable to start a VM due to concurrent operation Expectation : Error message should show router requires upgrade MS log snippet : 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. Unable to send command to router:4 at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) 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.$Proxy239.applyDhcpEntry(Unknown Source) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) 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
[jira] [Resolved] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5578. --- Resolution: Won't Fix Cannot be fixed based on discussion in https://issues.apache.org/jira/browse/CLOUDSTACK-5429 KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6703) [Windows] Try to install as a normal java service (Spawn a java thread)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6703: -- Affects Version/s: (was: 4.5.0) [Windows] Try to install as a normal java service (Spawn a java thread) --- Key: CLOUDSTACK-6703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6703 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future 1, Currently it is started as s tomcat service. Instead of that try to spawn a java thread service 2. Try to add Cloud stack Version some where in the service name or in the registry keys -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6704) [Windows] Localization of the windows installer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6704: -- Affects Version/s: (was: 4.5.0) [Windows] Localization of the windows installer --- Key: CLOUDSTACK-6704 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6704 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Damodar Reddy T Assignee: Damodar Reddy T Fix For: Future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6978) CLONE - [Windows] Can not create Template from ROOT snapshot For S3 Storage Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6978: -- Affects Version/s: (was: 4.5.0) CLONE - [Windows] Can not create Template from ROOT snapshot For S3 Storage Server -- Key: CLOUDSTACK-6978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6978 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Damodar Reddy T Assignee: Damodar Reddy T Steps to reproduce the issue 1. Create a snapshot from ROOT disk 2. Goto the above created snapshot 3. Try to create template out of it. It is failing with the following trace. 014-05-12 04:02:01,813 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-428:ctx-2ece4baa) null due to Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd java.net.URISyntaxException: Illegal character in path at index 47: nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd at java.net.URI$Parser.fail(Unknown Source) at java.net.URI$Parser.checkChars(Unknown Source) at java.net.URI$Parser.parseHierarchical(Unknown Source) at java.net.URI$Parser.parse(Unknown Source) at java.net.URI.init(Unknown Source) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createVolumeFromSnapshot(XenServerStorageProcessor.java:1617) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:96) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) 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(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7460) [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7460: -- Fix Version/s: Future [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine -- Key: CLOUDSTACK-7460 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7460 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Damodar Reddy T Fix For: Future Repro steps: on rhel 7 Machine. First install MS and try installing Agent on the same machine Bug: Agent installation will fail with following error : Transaction check error: file /var/log/cloudstack/agent from install of cloudstack-agent-4.5.0-SNAPSHOT.el7.x86_64 conflicts with file from package cloudstack-management-4.5.0-SNAPSHOT.el7.x86_64 Error Summary - Done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Attachment: nfsUmount.jpg Reboot stuck while umounting primary KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213467#comment-14213467 ] Kishan Kavala edited comment on CLOUDSTACK-5578 at 11/15/14 8:50 AM: - Reboot stuck while umounting primary: screenshot attached was (Author: kishan): Reboot stuck while umounting primary KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213468#comment-14213468 ] Kishan Kavala commented on CLOUDSTACK-5578: --- This is happening consistently. Force reboot reboot -f is an option. kvmheartbeat script should use -f option while rebooting. KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar, nfsUmount.jpg KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213503#comment-14213503
]
Kishan Kavala commented on CLOUDSTACK-7530:
---
2014-11-15 15:23:19,364 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-97:ctx-cf13ccba job-31/job-613) Remove job-613 from job
monitoring
2014-11-15 15:23:19,366 DEBUG [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) VM is already
stopped: VM[DomainRouter|r-127-VM]
2014-11-15 15:23:19,366 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Done executing
VM work job:
com.cloud.vm.VmWorkStop{cleanup:false,userId:1,accountId:1,vmId:127,handlerName:VirtualMachineManagerImpl}
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Complete async
job-615, jobStatus: SUCCEEDED, resultCode: 0, result: null
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Publish async
job-615 complete on message bus
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Wake up jobs
related to job-615
2014-11-15 15:23:19,366 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Update db
status for job-615
2014-11-15 15:23:19,367 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615 ctx-9751a4a7) Wake up jobs
joined with job-615 and disjoin all subjobs created from job- 615
2014-11-15 15:23:19,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615) Done with run of VM work
job: com.cloud.vm.VmWorkStop for VM 127, job origin: 480
2014-11-15 15:23:19,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-98:ctx-619c9467 job-480/job-615) Done executing
com.cloud.vm.VmWorkStop for job-615
2014-11-15 15:23:19,451 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[204|Guest|8]...
2014-11-15 15:23:19,451 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=204 is already implemented
2014-11-15 15:23:19,452 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[202|Control|3]...
2014-11-15 15:23:19,453 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=202 is already implemented
2014-11-15 15:23:19,453 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Starting network Ntwk[200|Public|1]...
2014-11-15 15:23:19,454 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(RouterMonitor-1:ctx-b081e6ea) Network id=200 is already implemented
2014-11-15 15:23:19,455 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(RouterMonitor-1:ctx-b081e6ea) Starting router VM[DomainRouter|r-127-VM]
[LXC] router VMs are not migrating to other cluster if we put its original
host into maintenance
-
Key: CLOUDSTACK-7530
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps:
Create a Zone with two LXC clusters each having one host
Launch a VM in this cluster
Put LXC host to maintenance which has router VM
Bug;
Router VM does not migrates to other available host in another cluster
Expected Result:
Router VM should migrate to other host in the 2nd cluster
Additional info to support my case :
1. When i started manually router vm it started in other cluster without issue
2. Other system vm like CPVM and SSVM in similar situation moves/recreated
for one cluster to another cluster .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14213502#comment-14213502 ] Kishan Kavala commented on CLOUDSTACK-7530: --- If there are no user Vms running in the network, router Vm won't start after migration. Verified that VR started automatically in the other cluster when there are user Vms running in the same network. [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance - Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 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: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7530) [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7530. --- Resolution: Not a Problem [LXC] router VMs are not migrating to other cluster if we put its original host into maintenance - Key: CLOUDSTACK-7530 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7530 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: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a Zone with two LXC clusters each having one host Launch a VM in this cluster Put LXC host to maintenance which has router VM Bug; Router VM does not migrates to other available host in another cluster Expected Result: Router VM should migrate to other host in the 2nd cluster Additional info to support my case : 1. When i started manually router vm it started in other cluster without issue 2. Other system vm like CPVM and SSVM in similar situation moves/recreated for one cluster to another cluster . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6320) Upgrade 4.1.1 - 4.3.0 OVS provider should be inserted to the physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6320: -- Assignee: (was: Kishan Kavala) Upgrade 4.1.1 - 4.3.0 OVS provider should be inserted to the physical network -- Key: CLOUDSTACK-6320 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6320 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Upgrading from CS 4.1.1 to CS 4.3.0, using Xenserver 6.1.0 Advanced zone with GRE isolation is configured before upgrade. Reporter: Florin Dumitrascu Fix For: 4.4.0, 4.5.0 When you create an Advanced zone in 4.3 code, server-side will automatically add OVS provider to its physical network. However, since your zone was created in 4.1 code and upgraded to 4.3, server-side won't automatically add OVS provider to its physical network. Full message thread: -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 4:18 PM To: Jessica Wang; Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Then its a DB upgrade bug. If the GRE isolation is supported on the network in 4.1.1, DB upgrade should have inserted the provider to physical network. On 3/21/14, 3:51 PM, Jessica Wang jessica.w...@citrix.com wrote: [Alena] Not exactly like that. [Alena] None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. [Alena] Our CS UI does this job - adding the providers to the network - for you by calling addNetworkServiceProvider call. Actually, OVS provider is an exception. UI doesn't do the job because server-side already does the job. When you create an Advanced zone in 4.3 code, server-side will automatically add OVS provider to its physical network. However, since your zone was created in 4.1 code and upgraded to 4.3, server-side won't automatically add OVS provider to its physical network. Murali, please confirm. -Original Message- From: Alena Prokharchyk Sent: Friday, March 21, 2014 2:44 PM To: Florin Dumitrascu; Jessica Wang; Murali Reddy; Florin Dumitrascu Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org Subject: Re: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) On 3/21/14, 2:34 PM, Florin Dumitrascu florin.dumitra...@intunenetworks.com wrote: Hi, Alena, my assumption is that the Ovs provider is created when you create the physical network with GRE isolation (if someone can confirm ...). When I configured CS RC8 from scratch, I could see the provider and enable it in the GUI. Not exactly like that. None of the providers are added to the physical network by default if execute createPhysicalNetwork call via API. Our CS UI does this job - adding the providers to the network - for you by calling addNetworkServiceProvider call. But when I have upgraded from CS 4.1.1 to 4.3.0 RC9, I have preserved the existing configuration with the existing physical network. So my assumption is that the physical network was not updated with the OVS provider (such a provider was not needed in CS 4.1.1). So while you were on 4.1.1, GRE isolation was disabled? Did you enable it on 4.3? If there is a way to enable new isolation on the physical network, on my opinion - the UI should perform the background call and add all the providers associated with this option, to the physical network. So it would be a UI issue. Or the case was the following - the GRE isolation was enabled on your network while on 4.1.1, but new provider - OVS - was added in 4.3. And this provider wasn't added to existing physical networks during the upgrade. Then its a database upgrade bug. Please confirm which one from the above is correct. Jessica, I am building CentOS RPM packages from the RC source, using package.sh script in the source packaging folder. Not aware about the difference between oss and noredist. Also, my setup is for an advanced zone. Kind Regards, Florin -Original Message- From: Jessica Wang [mailto:jessica.w...@citrix.com] Sent: Friday, March 21, 2014 8:28 PM To: Florin Dumitrascu; Murali Reddy Cc: Nguyen Anh Tu (t...@apache.org); d...@cloudstack.apache.org; Alena Prokharchyk Subject: RE: GRE isolation - no in service upgrade (4.1.1 to 4.3.0) - Is your zone an Advanced zone or Basic zone? (2) Florin, UI
[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6719: -- Assignee: (was: Kishan Kavala) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC Key: CLOUDSTACK-6719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: sadhu suresh Fix For: 4.5.0 problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network to VPC created with OVS+distributed VPC VR Steps to Reprodude: 1.Bring up CS in advanced zon 2.create a vpc offering with OVS and along with other all supported services 3. create a VPC with above network offering 4.try to create non ovs network(i.e network created default isolated vpc offering) on ovs based VPC. actual result: allowing to add non OVS enabled network to OVS enabled VPC expected result: it should not allow to add non OVS enabled network to OVS enabled VPC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7004: -- Assignee: Bharat Kumar (was: Kishan Kavala) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail Key: CLOUDSTACK-7004 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Automation, KVM Affects Versions: 4.4.0 Environment: KVM Reporter: Gaurav Aradhye Assignee: Bharat Kumar Labels: api, automation, kvm Fix For: 4.4.0, 4.5.0 Deploy a VM with parameter rootdisksize less than the template size. API should throw error for this but it succeeds. Although the root disk size of deployed VM is equal to template size in this case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212026#comment-14212026 ] Kishan Kavala commented on CLOUDSTACK-3952: --- Temporary workaround was added as part of CLOUDSTACK-3439 Persist VR nic details in DB for additional public ranges - Key: CLOUDSTACK-3952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Kishan Kavala Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 For non-vpcs VR, nics are dynamically created for addtional IP ranges with different Vlan. Prepare fro migration doesn't setup the destination host correctly due to this and migration fails. Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Assignee: (was: Kishan Kavala) Persist VR nic details in DB for additional public ranges - Key: CLOUDSTACK-3952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Kishan Kavala Fix For: 4.4.0, 4.5.0 For non-vpcs VR, nics are dynamically created for addtional IP ranges with different Vlan. Prepare fro migration doesn't setup the destination host correctly due to this and migration fails. Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-252) UpdateNetwork Operation on a guest network that is currently using Virtual Router for Lb services to a network offering that uses F5 for Lb services Fails due to My
[ https://issues.apache.org/jira/browse/CLOUDSTACK-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-252: - Assignee: Jayapal Reddy (was: Kishan Kavala) UpdateNetwork Operation on a guest network that is currently using Virtual Router for Lb services to a network offering that uses F5 for Lb services Fails due to MySQLIntegrityConstraintViolationException. --- Key: CLOUDSTACK-252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-252 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: pre-4.0.0 Reporter: Chandan Purushothama Assignee: Jayapal Reddy Fix For: 4.4.0, 4.5.0 Attachments: managementserverlog_mysqldumps.zip === Steps to Reproduce: === 1. On an Advanced Zone with two physical networks, create a guest network from a network offering with services as mentioned below mysql select * from network_offerings where id=13 \G *** 1. row *** id: 13 name: Network-SNAT-guest1 uuid: 277b7b7a-8aeb-46f8-94e9-e83de34912a8 unique_name: Network-SNAT-guest1 display_text: Network-SNAT-guest1 nw_rate: 500 mc_rate: 10 traffic_type: Guest tags: guest1 system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 0 created: 2012-09-26 18:43:35 removed: NULL default: 0 availability: Optional dedicated_lb_service: 1 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Isolated elastic_ip_service: 0 elastic_lb_service: 0 specify_ip_ranges: 0 1 row in set (0.00 sec) mysql select * from ntwk_offering_service_map where network_offering_id=13; ++-++---+-+ | id | network_offering_id | service| provider | created | ++-++---+-+ | 48 | 13 | Dhcp | VirtualRouter | 2012-09-26 18:43:35 | | 51 | 13 | Dns| VirtualRouter | 2012-09-26 18:43:35 | | 52 | 13 | Firewall | VirtualRouter | 2012-09-26 18:43:35 | | 49 | 13 | Lb | VirtualRouter | 2012-09-26 18:43:35 | | 50 | 13 | PortForwarding | VirtualRouter | 2012-09-26 18:43:35 | | 53 | 13 | SourceNat | VirtualRouter | 2012-09-26 18:43:35 | | 46 | 13 | StaticNat | VirtualRouter | 2012-09-26 18:43:35 | | 54 | 13 | UserData | VirtualRouter | 2012-09-26 18:43:35 | | 47 | 13 | Vpn| VirtualRouter | 2012-09-26 18:43:35 | ++-++---+-+ 9 rows in set (0.00 sec) mysql 2, Deploy three VMs on a guest network that is created from the above mentioned network offering. 3. Create a Load balancing rule servicing the VMs on the guest network. 4. Stop All the VMs and UpdateNetwork to the Network offering with services as mentioned below. Notice that the LB Service is provided by F5 in the new network offering. mysql select * from network_offerings where id=18 \G *** 1. row *** id: 18 name: Network-F5-guest1 uuid: 5c7746b8-e29f-4a74-8369-e88647081053 unique_name: Network-F5-guest1 display_text: Network-F5-guest1 nw_rate: 535 mc_rate: 10 traffic_type: Guest tags: guest1 system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 0 created: 2012-09-27 01:13:38 removed: NULL default: 0 availability: Optional dedicated_lb_service: 0 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Isolated elastic_ip_service:
[jira] [Commented] (CLOUDSTACK-7484) [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a LXC VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212083#comment-14212083
]
Kishan Kavala commented on CLOUDSTACK-7484:
---
Logs now say:
Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to find
suitable primary storage when creating volume d1
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:468)
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:774)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1204)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2586)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43
[LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a
LXC VM
Key: CLOUDSTACK-7484
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7484
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: shweta agarwal
Assignee: Kishan Kavala
Priority: Minor
Fix For: 4.5.0
Repro steps:
Create a LXC VM
Create a data disk on nfs storage
Attach the created disk to LXC VM
Bug:
We gets message unexpected exception
Expected Result :
1. Message should be more meaningful
2. We see exception raised in MS logs which should not be the case. we should
handle it gracefully.
Ms log hows :
2014-09-04 10:45:33,826 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
4-433471464134412663: Sending { Cmd , MgmtId: 233845178472723, via:
4(Rack3Pod1Host49), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:47e710d5-c35f-4926-9be9-351f5f6a9955,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:Gunjan
Das,size:5368709120,path:47e710d5-c35f-4926-9be9-351f5f6a9955,volumeId:23,accountId:2,format:QCOW2,provisioningType:THIN,id:23,hypervisorType:LXC}},diskSeq:1,path:47e710d5-c35f-4926-9be9-351f5f6a9955,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-18-VM,inSeq:false,wait:0}}]
}
2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-3:ctx-66f694f1) Seq 4-433471464134412663: Processing:
{ Ans: , MgmtId: 233845178472723, via: 4, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.AttachAnswer:{result:false,details:org.libvirt.LibvirtException:
unsupported configuration: Can't setup disk for non-block
device,wait:0}}] }
2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
4-433471464134412663: Received: { Ans: , MgmtId: 233845178472723, via: 4,
Ver: v1, Flags: 10, { AttachAnswer } }
2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Invocation
exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
to attach volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
non-block device
2014-09-04 10:45:33,900 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Rethrow
exception com.cloud.utils.exception.CloudRuntimeException: Failed to attach
volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
non-block device
2014-09-04 10:45:33,900 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Done with run of VM work
job: com.cloud.storage.VmWorkAttachVolume for VM 18, job origin: 324
2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Unable to complete
AsyncJobVO {id:325, userId: 2, accountId: 2, instanceType: null,
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7501: -- Assignee: Bharat Kumar (was: Kishan Kavala) System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Bharat Kumar Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7484) [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a LXC VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-7484:
--
Fix Version/s: (was: 4.5.0)
Future
[LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a
LXC VM
Key: CLOUDSTACK-7484
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7484
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: shweta agarwal
Assignee: Kishan Kavala
Priority: Minor
Fix For: Future
Repro steps:
Create a LXC VM
Create a data disk on nfs storage
Attach the created disk to LXC VM
Bug:
We gets message unexpected exception
Expected Result :
1. Message should be more meaningful
2. We see exception raised in MS logs which should not be the case. we should
handle it gracefully.
Ms log hows :
2014-09-04 10:45:33,826 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
4-433471464134412663: Sending { Cmd , MgmtId: 233845178472723, via:
4(Rack3Pod1Host49), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:47e710d5-c35f-4926-9be9-351f5f6a9955,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:Gunjan
Das,size:5368709120,path:47e710d5-c35f-4926-9be9-351f5f6a9955,volumeId:23,accountId:2,format:QCOW2,provisioningType:THIN,id:23,hypervisorType:LXC}},diskSeq:1,path:47e710d5-c35f-4926-9be9-351f5f6a9955,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:5368709120}},vmName:i-2-18-VM,inSeq:false,wait:0}}]
}
2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-3:ctx-66f694f1) Seq 4-433471464134412663: Processing:
{ Ans: , MgmtId: 233845178472723, via: 4, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.AttachAnswer:{result:false,details:org.libvirt.LibvirtException:
unsupported configuration: Can't setup disk for non-block
device,wait:0}}] }
2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
4-433471464134412663: Received: { Ans: , MgmtId: 233845178472723, via: 4,
Ver: v1, Flags: 10, { AttachAnswer } }
2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Invocation
exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
to attach volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
non-block device
2014-09-04 10:45:33,900 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Rethrow
exception com.cloud.utils.exception.CloudRuntimeException: Failed to attach
volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
non-block device
2014-09-04 10:45:33,900 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Done with run of VM work
job: com.cloud.storage.VmWorkAttachVolume for VM 18, job origin: 324
2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Unable to complete
AsyncJobVO {id:325, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACABJ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABgAX,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845178472723, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Thu Sep 04 10:45:32 IST 2014}, job origin:324
com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume
Gunjan Das to VM
[jira] [Updated] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-245: - Fix Version/s: (was: 4.5.0) (was: 4.4.0) Future VPC ACLs are not stored and programmed consistently --- Key: CLOUDSTACK-245 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: pre-4.0.0 Reporter: David Noland Assignee: Kishan Kavala Priority: Minor Fix For: Future If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent to store one thing in the database and program the firewall using another rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , it is not able to fence itself.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14212217#comment-14212217 ] Kishan Kavala commented on CLOUDSTACK-5578: --- KVM fence command does heartbeat check on primary storage. When network is not available Fence command will fail. This is expected. KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , it is not able to fence itself.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5578. --- Resolution: Not a Problem KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5324: -- Summary: error message not proper when start VM fails because router requires upgrade (was: error message not proper when start VM fails because router reuires upgrade) error message not proper when start VM fails because router requires upgrade - Key: CLOUDSTACK-5324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 Repro steps: Create a VM on 3.07 setup Upgrade to 4.3.0 but dont upgrade routers Stop user VM Start user VM Bug: Error message shows Unable to start a VM due to concurrent operation Expectation : Error message should show router requires upgrade MS log snippet : 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. Unable to send command to router:4 at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) 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.$Proxy239.applyDhcpEntry(Unknown Source) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) 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
[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Summary: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary. (was: KVM - Network down - When the host looses network connectivity , it is not able to fence itself.) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary. --- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Summary: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary (was: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary.) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary -- Key: CLOUDSTACK-5578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar KVM - Network down - When the host looses network connectivity , it is not able to fence itself. Steps to reproduce the problem: Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. Deploy ~10 Vms. Simulate network disconnect on the host ( ifdown em1) Host gets marked as Down and all the Vms gets HA-ed to the other host. On the KVM host which lost connectivity , attempt to shutdown itself fails. It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211893#comment-14211893 ] Kishan Kavala commented on CLOUDSTACK-7501: --- Looks like default hypervisor for the zone is being selected always for deploying systemVm. System VM fails to move from one cluster to another cluster when hypervisor type differs Key: CLOUDSTACK-7501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 Attachments: Ms.tar.gz Repro steps: 1. Create a LXC advance zone setup with one LXC cluster 2. When system vms are up .add one more KVM cluster 3. Put LXC host to maintenance Bug: System VM is not coming up on KVM cluster Expected result: System VMs should come up on KVM cluster Ms log shows : Cluster: 2 has HyperVisorType that does not match the VM, skipping this cluster which should not be the case in case of SSVM and CPVM attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7485) [LXC] Debian VMs fails to start in LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7485.
---
Resolution: Invalid
Template doesn't have OS root file system
[LXC] Debian VMs fails to start in LXC host
---
Key: CLOUDSTACK-7485
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7485
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Attachments: agent.tar.gz
Repro steps:
Create a LXC setup
Register debian Template
Create Debian VM
Bug:
Debian VMs fails to start
Agent log shows:
2014-09-04 17:34:01,902 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-5:null) starting i-2-5-VM: domain type='lxc'
namei-2-5-VM/name
uuid6c3618c2-0189-4678-8242-f53bc1099cee/uuid
descriptionDebian GNU/Linux 6(64-bit)/description
clock offset='utc'
timer name='kvmclock' present='no' //clock
features
pae/
apic/
acpi/
/features
devices
emulator/emulator
interface type='bridge'
source bridge='brem1-533'/
mac address='02:00:22:4f:00:03'/
model type='virtio'/
bandwidth
inbound average='25600' peak='25600'/
outbound average='25600' peak='25600'/
/bandwidth
/interface
filesystem type='mount'
source
dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/3ddee90e-6037-489c-b4ac-1df9867bf378'/
target dir='/'/
/filesystem
serial type='pty'
target port='0'/
/serial
console type='pty'
target port='0'/
/console
/devices
memory524288/memory
devices
memballoon model='none'/
/devices
vcpu1/vcpu
os
typeexe/type
init/sbin/init/init
/os
cputune
shares500/shares
/cputune
cpu/cpuon_rebootrestart/on_reboot
on_poweroffdestroy/on_poweroff
on_crashdestroy/on_crash
/domain
2014-09-04 17 at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
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)
2014-09-04 17:34:02,207 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-5:null) Disconnecting disk
3ddee90e-6037-489c-b4ac-1df9867bf378
2014-09-04 17:34:02,208 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-5:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-04 17:34:02,231 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-5:null) Seq 1-8326029811101205191: { Ans: , MgmtId:
233845178472723, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:5,name:i-2-5-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Debian
GNU/Linux 6(64-bit),platfo:34:02,207 WARN
[kvm.resource.LibvirtComputingResource] (agentRequest-Handler-5:null)
LibvirtException
org.libvirt.LibvirtException: internal error: guest failed to start: cannot
find init path '/sbin/init' relative to container root: No such file or
directory
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7486) [LXC] Fedora VM fails to start on LXc host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7486.
---
Resolution: Invalid
Template doesn't have OS root file system
[LXC] Fedora VM fails to start on LXc host
---
Key: CLOUDSTACK-7486
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7486
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Attachments: agent.tar.gz
Repro Steps:
Repro steps:
Create a LXC setup
Register debian Template
Create Debian VM
Bug:
Debian VMs fails to start
Agent log shows:
2014-09-04 17:29:08,581 DEBUG [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) starting i-2-3-VM: domain type='lxc'
namei-2-3-VM/name
uuida2dafe32-9d8c-47a8-abe5-9af100987155/uuid
descriptionFedora 9/description
clock offset='utc'
timer name='kvmclock' present='no' //clock
features
pae/
apic/
acpi/
/features
devices
emulator/emulator
interface type='bridge'
source bridge='brem1-533'/
mac address='02:00:1a:7c:00:01'/
model type='virtio'/
bandwidth
inbound average='25600' peak='25600'/
outbound average='25600' peak='25600'/
/bandwidth
/interface
filesystem type='mount'
source
dir='/mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/36d7a92b-a78b-4f30-83bb-c65ea7768627'/
target dir='/'/
/filesystem
serial type='pty'
target port='0'/
/serial
console type='pty'
target port='0'/
/console
/devices
memory524288/memory
devices
memballoon model='none'/
/devices
vcpu1/vcpu
os
typeexe/type
init/sbin/init/init
/os
cputune
shares500/shares
/cputune
cpu/cpuon_rebootrestart/on_reboot
on_poweroffdestroy/on_poweroff
on_crashdestroy/on_crash
/domain
2014-09-04 17:29:08,944 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) LibvirtExceptionon_crashdestroy/on_crash
/domain
2014-09-04 17:29:08,944 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-2:null) LibvirtException
org.libvirt.LibvirtException: internal error: guest failed to start: cannot
find init path '/sbin/init' relative to container root: No such file or
directory
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1238)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3766)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1332)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
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)
2014-09-04 17:29:08,945 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-2:null) Disconnecting disk
36d7a92b-a78b-4f30-83bb-c65ea7768627
2014-09-04 17:29:08,945 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-2:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-04 17:29:08,971 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Seq 1-8326029811101205165: { Ans: , MgmtId:
233845178472723, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:3,name:i-2-3-VM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Fedora
9,platformEmulator:Fedora
[jira] [Comment Edited] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208003#comment-14208003 ] Kishan Kavala edited comment on CLOUDSTACK-7804 at 11/12/14 12:52 PM: -- Listing pools directly on the monitor node is also failing. Below command was stuck. [root@MonitorNode ~]# rbd ls shwetapool This is issue with ceph setup. was (Author: kishan): Listing pools directly on the monitor node is also failing. Below command was stuck. [root@MonitorNode ~]# rbd ls shwetapool This issue with ceph setup. [CEPH] Adding RBD primary storage is failing -- Key: CLOUDSTACK-7804 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, agent.tar.gz Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . attached MS log and Agents log for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208003#comment-14208003 ] Kishan Kavala commented on CLOUDSTACK-7804: --- Listing pools directly on the monitor node is also failing. Below command was stuck. [root@MonitorNode ~]# rbd ls shwetapool This issue with ceph setup. [CEPH] Adding RBD primary storage is failing -- Key: CLOUDSTACK-7804 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, agent.tar.gz Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . attached MS log and Agents log for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7804) [CEPH] Adding RBD primary storage is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7804. --- Resolution: Won't Fix [CEPH] Adding RBD primary storage is failing -- Key: CLOUDSTACK-7804 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7804 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, agent.tar.gz Repro steps : 1. Create a LXC zone with NFS primary storage 2. Once System VMs are up add Ceph storage as another primary storage Bug: Storage addition is failing. It goes to initialized state but after some time gets message storage addition failed . attached MS log and Agents log for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7806) Agent state remians connecting for secondary storage VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7806.
---
Resolution: Cannot Reproduce
unable to repo this issue with latest 4.5
Agent state remians connecting for secondary storage VM
---
Key: CLOUDSTACK-7806
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7806
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Attachments: cloud.log
Repro steps :
Create a LXC Zone setup.
Notice Agent status of Secondary storage VM will be connecting once Sceondary
Storage VM is in running state .
SSVM cloud log shows :
2014-10-28 09:38:10,340 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Executing: /usr/local/cloud/systemvm/config_ssl.sh -i 10.147.30.190 -h
s-1-VM
2014-10-28 09:38:10,377 DEBUG [cloud.agent.Agent] (Agent-Handler-4:null)
Receivee
d response: Seq 0-159: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
Flagss
: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{hostType:Storage,
hostId:0,wait:0},result:true,wait:0}}] }
2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Execution is successful.
2014-10-28 09:38:11,487 DEBUG [utils.script.Script]
(agentRequest-Handler-1:nulll
) Stopping web server: apache2apache2: Could not reliably determine the
server'ss
fully qualified domain name, using 10.147.30.190 for ServerName
... waiting .
Starting web server: apache2apache2: Could not reliably determine the
server's ff
ully qualified domain name, using 10.147.30.190 for ServerName
.
2014-10-28 09:38:11,487 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-1:null)
Seq 1-7097954487712612353: { Ans: , MgmtId: 233845178472723, via: 1, Ver:
v1, FF
lags: 110,
[{com.cloud.agent.api.SecStorageSetupAnswer:{_dir:4a409f9f-33f8--
3898-b4b8-39a2e3d01cb1,result:true,details:success,wait:0}}] }
attaching entire cloud.log
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Fix Version/s: (was: 4.5.0) RBD pool secret should be masked in logs Key: CLOUDSTACK-7537 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Kishan Kavala Assignee: Kishan Kavala RBD pool authentication secret key is logged in plain text in management server and agent logs at the following places: - While adding pool to MS - When MS send modifyStorage pool command to agent secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Affects Version/s: 4.2.0 RBD pool secret should be masked in logs Key: CLOUDSTACK-7537 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Kishan Kavala Assignee: Kishan Kavala RBD pool authentication secret key is logged in plain text in management server and agent logs at the following places: - While adding pool to MS - When MS send modifyStorage pool command to agent secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7537: -- Assignee: (was: Kishan Kavala) RBD pool secret should be masked in logs Key: CLOUDSTACK-7537 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Kishan Kavala RBD pool authentication secret key is logged in plain text in management server and agent logs at the following places: - While adding pool to MS - When MS send modifyStorage pool command to agent secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Assignee: (was: Kishan Kavala) Persist VR nic details in DB for additional public ranges - Key: CLOUDSTACK-3952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Kishan Kavala Fix For: 4.4.0, 4.5.0 For non-vpcs VR, nics are dynamically created for addtional IP ranges with different Vlan. Prepare fro migration doesn't setup the destination host correctly due to this and migration fails. Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7253) [LXC]getting java NPE server internal error on accessing console view of VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7253.
---
Resolution: Fixed
[LXC]getting java NPE server internal error on accessing console view of VM
---
Key: CLOUDSTACK-7253
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7253
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro step:
createa LXC VM and try accessing its console
Bug:
gets internal server error
MS log shows:
014-08-05 06:46:25,902 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-13:null) Ping from 3
2014-08-05 06:46:26,487 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-10:null) SeqA 2-46206: Processing Seq 2-46206: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:1,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-08-05 06:46:26,599 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-10:null) SeqA 2-46206: Sending Seq 2-46206: { Ans: ,
MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-08-05 06:46:27,652 WARN [o.a.c.f.j.AsyncJobExecutionContext]
(catalina-exec-6:null) Job is executed without a context, setup psudo job for
the executing thread
2014-08-05 06:46:27,718 DEBUG [c.c.a.t.Request]
(catalina-exec-6:ctx-857528e3) Seq 1-8575416640466847185: Sending { Cmd ,
MgmtId: 233845177509765, via: 1(Rack1Pod1Host23), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.GetVncPortCommand:{id:16,name:i-2-16-VM,wait:0}}]
}
2014-08-05 06:46:27,769 DEBUG [c.c.a.t.Request] (AgentManager-Handler-9:null)
Seq 1-8575416640466847185: Processing: { Ans: , MgmtId: 233845177509765,
via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2861)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1296)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:501)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)\n\tat
com.cloud.utils.nio.Task.run(Task.java:84)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
java.lang.Thread.run(Thread.java:722)\n,wait:0}}] }
2014-08-05 06:46:27,769 DEBUG [c.c.a.t.Request]
(catalina-exec-6:ctx-857528e3) Seq 1-8575416640466847185: Received: { Ans: ,
MgmtId: 233845177509765, via: 1, Ver: v1, Flags: 10, { Answer } }
2014-08-05 06:46:27,769 DEBUG [c.c.a.m.AgentManagerImpl]
(catalina-exec-6:ctx-857528e3) Details from executing class
com.cloud.agent.api.GetVncPortCommand: java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2861)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1296)
at com.cloud.agent.Agent.processRequest(Agent.java:501)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
at com.cloud.utils.nio.Task.run(Task.java:84)
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)
2014-08-05 06:46:27,769 ERROR [c.c.s.ConsoleProxyServlet]
(catalina-exec-6:ctx-857528e3) Unexepected exception in ConsoleProxyServlet
java.lang.ClassCastException: com.cloud.agent.api.Answer cannot be cast to
com.cloud.agent.api.GetVncPortAnswer
at
com.cloud.server.ManagementServerImpl.getVncPort(ManagementServerImpl.java:2206)
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
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
[jira] [Resolved] (CLOUDSTACK-7265) [LXC] snapshot creation errored out but notification shows task completed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7265.
---
Resolution: Fixed
[LXC] snapshot creation errored out but notification shows task completed
-
Key: CLOUDSTACK-7265
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7265
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Attachments: error.png
Repro stesp:
Create a LXC VM
Try creating snapshot of root disk of VM
Bug:
Snapshot results in error but Notification window shows take snapshot task
completed
attaching snapshot
MS log shows:
2014-08-06 04:50:29,131 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271) Executing AsyncJobVO
{id:271, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.storage.VmWorkTakeVolumeSnapshot, cmdInfo:
rO0ABXNyACpjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtUYWtlVm9sdW1lU25hcHNob3QEvmAbguLVzwIABFoACXF1aWVzY2VWbUwACHBvbGljeUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACnNuYXBzaG90SWRxAH4AAUwACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAA50ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbABzcgAOamF2YS5sYW5nLkxvbmc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAABzcQB-AAYAAnNxAH4ABgAP,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Aug 06 04:50:27 EDT 2014}
2014-08-06 04:50:29,131 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271) Run VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 14, job origin: 270
2014-08-06 04:50:29,132 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271 ctx-6b30aba5) Execute VM
work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot{volumeId:15,policyId:0,snapshotId:2,quiesceVm:false,userId:2,accountId:2,vmId:14,handlerName:VolumeApiServiceImpl}
2014-08-06 04:50:29,430 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271 ctx-6b30aba5) Seq
1-8575416640466852795: Sending { Cmd , MgmtId: 233845177509765, via:
1(Rack1Pod1Host23), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:b438d5f4-3193-4549-b315-7745cdfa4bd8,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-14,size:0,path:b438d5f4-3193-4549-b315-7745cdfa4bd8,volumeId:15,vmName:i-2-14-VM,accountId:2,provisioningType:THIN,id:15,deviceId:0,hypervisorType:LXC},dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},vmName:i-2-14-VM,name:VM-aa982368-63c6-4dfa-96ac-2607b2cb06de_ROOT-14_20140806085026,hypervisorType:LXC,id:2,quiescevm:false,physicalSize:0}},wait:0}}]
}
2014-08-06 04:50:29,613 DEBUG [c.c.a.t.Request] (AgentManager-Handler-4:null)
Seq 1-8575416640466852795: Processing: { Ans: , MgmtId: 233845177509765,
via: 1, Ver: v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:Failed
to manage snapshot: org.libvirt.LibvirtException: this function is not
supported by the connection driver: virDomainSnapshotCreateXML,wait:0}}] }
2014-08-06 04:50:29,613 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271 ctx-6b30aba5) Seq
1-8575416640466852795: Received: { Ans: , MgmtId: 233845177509765, via: 1,
Ver: v1, Flags: 10, { CreateObjectAnswer } }
2014-08-06 04:50:29,614 DEBUG [o.a.c.s.s.SnapshotServiceImpl]
(Work-Job-Executor-52:ctx-e002fe97 job-270/job-271 ctx-6b30aba5) create
snapshot VM-aa982368-63c6-4dfa-96ac-2607b2cb06de_ROOT-14_20140806085026
failed: Failed to manage snapshot: org.libvirt.LibvirtException: this
function is not supported by the connection
[jira] [Resolved] (CLOUDSTACK-7267) [LXC] message should be more meaningful in case of failure of template creation from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7267. --- Resolution: Fixed [LXC] message should be more meaningful in case of failure of template creation from root volume Key: CLOUDSTACK-7267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7267 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: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: 1. Create a LXC VM 2. Stop VM 3. Create a template from root data disk 4. Template creation will fail with the message:Failed to create templateroot disk file /mnt/dfa2ec3c-d133-3284-8583-0a0845aa4424/d377b54e-d337-4e9c-9adb-5ed1ccc3b84a doesn't exist Bug: message shoulld be meaningful for failure .. may be not supported in LXC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7318) [UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7318: -- Summary: [UI] processing wheel continue to spin even after error messaage during VM snapshot creation (was: [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation) [UI] processing wheel continue to spin even after error messaage during VM snapshot creation Key: CLOUDSTACK-7318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 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: shweta agarwal Fix For: 4.5.0 Attachments: processingwheel.png Repro steps: Create a LXC VM When VM is running try to createa VM snapshot Bug: Notice you get message VM snapshot is not enabled for hypervisor type: LXC but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7318) [UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14195757#comment-14195757 ] Kishan Kavala commented on CLOUDSTACK-7318: --- This is not specific to LXC. Any Vm snapshot failure during allocSnapshot will result in the same error. Steps to repo on any hypervisor: 1. Create Vm 2. Take snapshot of ROOT volume 3. Take Vm snapshot Vm snapshot will fail, but processing wheel will continue to spin. [UI] processing wheel continue to spin even after error messaage during VM snapshot creation Key: CLOUDSTACK-7318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 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: shweta agarwal Fix For: 4.5.0 Attachments: processingwheel.png Repro steps: Create a LXC VM When VM is running try to createa VM snapshot Bug: Notice you get message VM snapshot is not enabled for hypervisor type: LXC but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7317) wrong message when trying to upgrade a running VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7317.
---
Resolution: Not a Problem
wrong message when trying to upgrade a running VM
-
Key: CLOUDSTACK-7317
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7317
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps:
1. Create a VM with small service offerings ( i did it on LXC hypervisor)
2. While VM is running change service offering
Bug:
We get message This operation not permitted for this hypervisor of the vm
Expected Result :
Message should be related to VM should be stopped while changing service
offerings
MS log shows :
2014-08-12 05:26:21,708 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-36:ctx-b9835d0e job-439) Executing AsyncJobVO {id:439,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin, cmdInfo:
{id:033042b7-0973-4e00-b4b8-d9f3af49c3ac,response:json,sessionkey:HEgqZRWcriIz5k+MxuauDaQK6Wc\u003d,serviceofferingid:b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c,ctxDetails:{\com.cloud.vm.VirtualMachine\:\033042b7-0973-4e00-b4b8-d9f3af49c3ac\,\com.cloud.offering.ServiceOffering\:\b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c\},cmdEventType:VM.UPGRADE,ctxUserId:2,httpmethod:GET,_:1407835578042,uuid:033042b7-0973-4e00-b4b8-d9f3af49c3ac,ctxAccountId:2,ctxStartEventId:278},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-08-12 05:26:21,709 DEBUG [c.c.a.ApiServlet]
(catalina-exec-11:ctx-ee357ccc ctx-490ac18f) ===END=== 10.146.0.131 -- GET
command=scaleVirtualMachineresponse=jsonsessionkey=HEgqZRWcriIz5k%2BMxuauDaQK6Wc%3Did=033042b7-0973-4e00-b4b8-d9f3af49c3acserviceofferingid=b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c_=1407835578042
2014-08-12 05:26:21,880 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-36:ctx-b9835d0e job-439) Unexpected exception while
executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin
com.cloud.exception.InvalidParameterValueException: This operation not
permitted for this hypervisor of the vm
at
com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264)
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
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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy211.upgradeVirtualMachine(Unknown Source)
at
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at
[jira] [Commented] (CLOUDSTACK-7317) wrong message when trying to upgrade a running VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181432#comment-14181432
]
Kishan Kavala commented on CLOUDSTACK-7317:
---
When Vm is running, change service offering does dynamic scaling which is not
supported for LXC.
wrong message when trying to upgrade a running VM
-
Key: CLOUDSTACK-7317
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7317
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps:
1. Create a VM with small service offerings ( i did it on LXC hypervisor)
2. While VM is running change service offering
Bug:
We get message This operation not permitted for this hypervisor of the vm
Expected Result :
Message should be related to VM should be stopped while changing service
offerings
MS log shows :
2014-08-12 05:26:21,708 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-36:ctx-b9835d0e job-439) Executing AsyncJobVO {id:439,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin, cmdInfo:
{id:033042b7-0973-4e00-b4b8-d9f3af49c3ac,response:json,sessionkey:HEgqZRWcriIz5k+MxuauDaQK6Wc\u003d,serviceofferingid:b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c,ctxDetails:{\com.cloud.vm.VirtualMachine\:\033042b7-0973-4e00-b4b8-d9f3af49c3ac\,\com.cloud.offering.ServiceOffering\:\b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c\},cmdEventType:VM.UPGRADE,ctxUserId:2,httpmethod:GET,_:1407835578042,uuid:033042b7-0973-4e00-b4b8-d9f3af49c3ac,ctxAccountId:2,ctxStartEventId:278},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-08-12 05:26:21,709 DEBUG [c.c.a.ApiServlet]
(catalina-exec-11:ctx-ee357ccc ctx-490ac18f) ===END=== 10.146.0.131 -- GET
command=scaleVirtualMachineresponse=jsonsessionkey=HEgqZRWcriIz5k%2BMxuauDaQK6Wc%3Did=033042b7-0973-4e00-b4b8-d9f3af49c3acserviceofferingid=b2a6ba7f-2f05-4a9b-ac2f-8e2f1c7dee1c_=1407835578042
2014-08-12 05:26:21,880 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-36:ctx-b9835d0e job-439) Unexpected exception while
executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin
com.cloud.exception.InvalidParameterValueException: This operation not
permitted for this hypervisor of the vm
at
com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1339)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1328)
at
com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1264)
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
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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy211.upgradeVirtualMachine(Unknown Source)
at
org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:46)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at
[jira] [Updated] (CLOUDSTACK-7318) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7318: -- Assignee: (was: Kishan Kavala) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation - Key: CLOUDSTACK-7318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 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: shweta agarwal Fix For: 4.5.0 Attachments: processingwheel.png Repro steps: Create a LXC VM When VM is running try to createa VM snapshot Bug: Notice you get message VM snapshot is not enabled for hypervisor type: LXC but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7318) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181437#comment-14181437
]
Kishan Kavala commented on CLOUDSTACK-7318:
---
API response contains proper error.
{ createvmsnapshotresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:VM snapshot is
not enabled for hypervisor type: LXC} }
Issue has to be fixed in UI
[LXC][UI] processing wheel continue to spin even after error messaage during
VM snapshot creation
-
Key: CLOUDSTACK-7318
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318
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: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Attachments: processingwheel.png
Repro steps:
Create a LXC VM
When VM is running try to createa VM snapshot
Bug:
Notice you get message VM snapshot is not enabled for hypervisor type: LXC
but spinnign wheel continue to spin . attaching snapshot
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7382) [LXC] [UI] add rhel 7 in OS type dropdown of register templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7382: -- Fix Version/s: (was: 4.5.0) Future [LXC] [UI] add rhel 7 in OS type dropdown of register templates --- Key: CLOUDSTACK-7382 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7382 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Minor Fix For: Future Repro steps Try to register rhel 7 template on rhel 7 LXC setup . Bug: OS types rhel 7 not shown in UI in drop down We should also remove other non Linux based OS from this list in case of LXC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7382) [LXC] [UI] add rhel 7 in OS type dropdown of register templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7382: -- Assignee: (was: Kishan Kavala) [LXC] [UI] add rhel 7 in OS type dropdown of register templates --- Key: CLOUDSTACK-7382 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7382 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, UI Affects Versions: 4.5.0 Reporter: shweta agarwal Priority: Minor Fix For: Future Repro steps Try to register rhel 7 template on rhel 7 LXC setup . Bug: OS types rhel 7 not shown in UI in drop down We should also remove other non Linux based OS from this list in case of LXC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7382) [LXC] [UI] add rhel 7 in OS type dropdown of register templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7382: -- Priority: Minor (was: Major) [LXC] [UI] add rhel 7 in OS type dropdown of register templates --- Key: CLOUDSTACK-7382 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7382 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Minor Fix For: Future Repro steps Try to register rhel 7 template on rhel 7 LXC setup . Bug: OS types rhel 7 not shown in UI in drop down We should also remove other non Linux based OS from this list in case of LXC -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181458#comment-14181458 ] Kishan Kavala commented on CLOUDSTACK-7515: --- Fixed along with CLOUDSTACK-7569 [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network -- Key: CLOUDSTACK-7515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Network Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, management-server.log.2014-09-08.gz Repro steps: 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having one host and other having two host .all host are LXC 2. Create a shared Network 3. Create a VM using only shared network as default network Bug: Notice mac address that VM has is different than the one Router has for the same vm router VM shows cat /etc/dhcphosts.txt 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite For USER VM with IP 10.147.31.144 router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 Ifconfig on VM shows ifconfig eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20link ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) RX packets 1938 bytes 414054 (404.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2700 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Additional information : dumpxml of LXC vm shows same mac which is available with router Notice even IP is not set for such VMs Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
