[jira] [Created] (CLOUDSTACK-5362) [Hyper-v] System vms does not come up with CIFS as the shared primary storage
Sanjeev N created CLOUDSTACK-5362:
-
Summary: [Hyper-v] System vms does not come up with CIFS as the
shared primary storage
Key: CLOUDSTACK-5362
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5362
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Latest build from 4.3
Storage: CIFS for both primary and secondary storage
Hypervisor: Hyperv
Reporter: Sanjeev N
Priority: Blocker
Fix For: 4.3.0
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
Steps to Reproduce:
1.Bring up CS in advanced zone using CIFS as the storage for both primary and
secondary with latest build from 4.3
2.Enable zone
Expected Result:
==
System vms (SSVM,CPVM) should come up without any issues
Actual Result:
===
System vms failed to come up
Observations:
Root disks for both ssvm and cpvm got created in the shared primary storage.
However vms start failed with the following error:
2013-12-04 07:50:47,399 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-26:ctx-50ca2fd8) Sending cmd to
http://10.147.40.14:8250/api/HypervResource/com.cloud.agent.api.StartCommand
cmd
data:{vm:{id:2,name:v-2-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003ddomP type\u003dconsoleproxy
host\u003d10.147.59.119 port\u003d8250 name\u003dv-2-VM premium\u003dtrue
zone\u003d1 pod\u003d1 guid\u003dProxy.2 proxy_vm\u003d2
disable_rp_filter\u003dtrue eth2ip\u003d10.147.48.22
eth2mask\u003d255.255.255.0 gateway\u003d10.147.48.1 eth0ip\u003d169.254.3.44
eth0mask\u003d255.255.0.0 eth1ip\u003d10.147.40.233 eth1mask\u003d255.255.254.0
mgmtcidr\u003d10.147.59.0/24 localgw\u003d10.147.40.1
internaldns1\u003d10.140.50.6
dns1\u003d10.140.50.6,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:60432484c5722fb2,params:{},uuid:f22fa132-7b2e-4fc2-aadc-f679ff5bc848,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2a7f9126-5115-4d29-aade-b45bdc4eefba,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fdd42fec-0e2e-32fe-adff-0d09bc73e8af,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR/?ROLE\u003dPrimary\u0026STOREUUID\u003dfdd42fec-0e2e-32fe-adff-0d09bc73e8af}},name:ROOT-2,size:0,volumeId:2,vmName:v-2-VM,accountId:1,id:2,deviceId:0,hypervisorType:Hyperv}},diskSeq:0,type:ROOT,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:c3cfb829-8964-4efd-b52c-da029d5ce326,ip:10.147.48.22,netmask:255.255.255.0,gateway:10.147.48.1,mac:06:8f:72:00:00:0c,dns1:10.140.50.6,broadcastType:Vlan,type:Public,broadcastUri:vlan://48,isolationUri:vlan://48,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:6f3a7adf-c403-4503-85b3-5b4d349f0579,ip:169.254.3.44,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:2c,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:e70d802c-0844-4fc7-89dc-66d1d4aa82d8,ip:10.147.40.233,netmask:255.255.254.0,gateway:10.147.40.1,mac:06:f4:8e:00:00:03,broadcastType:Native,type:Management,isSecurityGroupEnabled:false}]},hostIp:10.147.40.14,executeInSequence:false,contextMap:{},wait:0}
2013-12-04 07:50:50,929 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-12:ctx-c9224f52) POST response
is[{com.cloud.agent.api.StartAnswer:{result:false,details:com.cloud.agent.api.StartCommand
fail on exceptionHyper-V Job failed, Error Code:32768, Description: 's-4-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
7224DA02-67DF-46A7-9425-3DE9D6BAD26E)\n\nFailed to open attachment
'10.102.192.19\\HYPERV-SMB\\sanjeev-pri\\ROOT-4.vhd'. Error: 'The user name
or password is
incorrect.'.,vm:{id:4,name:s-4-VM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage
host=10.147.59.119 port=8250 name=s-4-VM zone=1 pod=1 guid=s-4-VM
resource=com.cloud.storage.resource.PremiumSecondaryStorageResource
instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
eth2ip=10.147.48.21 eth2mask=255.255.255.0 gateway=10.147.48.1
public.network.device=eth2 eth0ip=169.254.2.134
[jira] [Updated] (CLOUDSTACK-5362) [Hyper-v] System vms does not come up with CIFS as the shared primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-5362:
--
Labels: hyper-V, (was: )
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
-
Key: CLOUDSTACK-5362
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5362
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Latest build from 4.3
Storage: CIFS for both primary and secondary storage
Hypervisor: Hyperv
Reporter: Sanjeev N
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
Steps to Reproduce:
1.Bring up CS in advanced zone using CIFS as the storage for both primary and
secondary with latest build from 4.3
2.Enable zone
Expected Result:
==
System vms (SSVM,CPVM) should come up without any issues
Actual Result:
===
System vms failed to come up
Observations:
Root disks for both ssvm and cpvm got created in the shared primary storage.
However vms start failed with the following error:
2013-12-04 07:50:47,399 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-26:ctx-50ca2fd8) Sending cmd to
http://10.147.40.14:8250/api/HypervResource/com.cloud.agent.api.StartCommand
cmd
data:{vm:{id:2,name:v-2-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003ddomP
type\u003dconsoleproxy host\u003d10.147.59.119 port\u003d8250
name\u003dv-2-VM premium\u003dtrue zone\u003d1 pod\u003d1 guid\u003dProxy.2
proxy_vm\u003d2 disable_rp_filter\u003dtrue eth2ip\u003d10.147.48.22
eth2mask\u003d255.255.255.0 gateway\u003d10.147.48.1 eth0ip\u003d169.254.3.44
eth0mask\u003d255.255.0.0 eth1ip\u003d10.147.40.233
eth1mask\u003d255.255.254.0 mgmtcidr\u003d10.147.59.0/24
localgw\u003d10.147.40.1 internaldns1\u003d10.140.50.6
dns1\u003d10.140.50.6,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:60432484c5722fb2,params:{},uuid:f22fa132-7b2e-4fc2-aadc-f679ff5bc848,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2a7f9126-5115-4d29-aade-b45bdc4eefba,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fdd42fec-0e2e-32fe-adff-0d09bc73e8af,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR/?ROLE\u003dPrimary\u0026STOREUUID\u003dfdd42fec-0e2e-32fe-adff-0d09bc73e8af}},name:ROOT-2,size:0,volumeId:2,vmName:v-2-VM,accountId:1,id:2,deviceId:0,hypervisorType:Hyperv}},diskSeq:0,type:ROOT,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:c3cfb829-8964-4efd-b52c-da029d5ce326,ip:10.147.48.22,netmask:255.255.255.0,gateway:10.147.48.1,mac:06:8f:72:00:00:0c,dns1:10.140.50.6,broadcastType:Vlan,type:Public,broadcastUri:vlan://48,isolationUri:vlan://48,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:6f3a7adf-c403-4503-85b3-5b4d349f0579,ip:169.254.3.44,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:2c,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:e70d802c-0844-4fc7-89dc-66d1d4aa82d8,ip:10.147.40.233,netmask:255.255.254.0,gateway:10.147.40.1,mac:06:f4:8e:00:00:03,broadcastType:Native,type:Management,isSecurityGroupEnabled:false}]},hostIp:10.147.40.14,executeInSequence:false,contextMap:{},wait:0}
2013-12-04 07:50:50,929 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-12:ctx-c9224f52) POST response
is[{com.cloud.agent.api.StartAnswer:{result:false,details:com.cloud.agent.api.StartCommand
fail on exceptionHyper-V Job failed, Error Code:32768, Description: 's-4-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
7224DA02-67DF-46A7-9425-3DE9D6BAD26E)\n\nFailed to open attachment
'10.102.192.19\\HYPERV-SMB\\sanjeev-pri\\ROOT-4.vhd'. Error: 'The user
name or password is
incorrect.'.,vm:{id:4,name:s-4-VM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage
host=10.147.59.119 port=8250 name=s-4-VM
[jira] [Updated] (CLOUDSTACK-5362) [Hyper-v] System vms does not come up with CIFS as the shared primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-5362:
--
Attachment: management-server.rar
cloudstack-agent.rar
Attaching management server log file and agent log from hyper-v
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
-
Key: CLOUDSTACK-5362
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5362
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Latest build from 4.3
Storage: CIFS for both primary and secondary storage
Hypervisor: Hyperv
Reporter: Sanjeev N
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: cloudstack-agent.rar, management-server.rar
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
Steps to Reproduce:
1.Bring up CS in advanced zone using CIFS as the storage for both primary and
secondary with latest build from 4.3
2.Enable zone
Expected Result:
==
System vms (SSVM,CPVM) should come up without any issues
Actual Result:
===
System vms failed to come up
Observations:
Root disks for both ssvm and cpvm got created in the shared primary storage.
However vms start failed with the following error:
2013-12-04 07:50:47,399 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-26:ctx-50ca2fd8) Sending cmd to
http://10.147.40.14:8250/api/HypervResource/com.cloud.agent.api.StartCommand
cmd
data:{vm:{id:2,name:v-2-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003ddomP
type\u003dconsoleproxy host\u003d10.147.59.119 port\u003d8250
name\u003dv-2-VM premium\u003dtrue zone\u003d1 pod\u003d1 guid\u003dProxy.2
proxy_vm\u003d2 disable_rp_filter\u003dtrue eth2ip\u003d10.147.48.22
eth2mask\u003d255.255.255.0 gateway\u003d10.147.48.1 eth0ip\u003d169.254.3.44
eth0mask\u003d255.255.0.0 eth1ip\u003d10.147.40.233
eth1mask\u003d255.255.254.0 mgmtcidr\u003d10.147.59.0/24
localgw\u003d10.147.40.1 internaldns1\u003d10.140.50.6
dns1\u003d10.140.50.6,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:60432484c5722fb2,params:{},uuid:f22fa132-7b2e-4fc2-aadc-f679ff5bc848,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2a7f9126-5115-4d29-aade-b45bdc4eefba,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fdd42fec-0e2e-32fe-adff-0d09bc73e8af,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR/?ROLE\u003dPrimary\u0026STOREUUID\u003dfdd42fec-0e2e-32fe-adff-0d09bc73e8af}},name:ROOT-2,size:0,volumeId:2,vmName:v-2-VM,accountId:1,id:2,deviceId:0,hypervisorType:Hyperv}},diskSeq:0,type:ROOT,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:c3cfb829-8964-4efd-b52c-da029d5ce326,ip:10.147.48.22,netmask:255.255.255.0,gateway:10.147.48.1,mac:06:8f:72:00:00:0c,dns1:10.140.50.6,broadcastType:Vlan,type:Public,broadcastUri:vlan://48,isolationUri:vlan://48,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:6f3a7adf-c403-4503-85b3-5b4d349f0579,ip:169.254.3.44,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:2c,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:e70d802c-0844-4fc7-89dc-66d1d4aa82d8,ip:10.147.40.233,netmask:255.255.254.0,gateway:10.147.40.1,mac:06:f4:8e:00:00:03,broadcastType:Native,type:Management,isSecurityGroupEnabled:false}]},hostIp:10.147.40.14,executeInSequence:false,contextMap:{},wait:0}
2013-12-04 07:50:50,929 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-12:ctx-c9224f52) POST response
is[{com.cloud.agent.api.StartAnswer:{result:false,details:com.cloud.agent.api.StartCommand
fail on exceptionHyper-V Job failed, Error Code:32768, Description: 's-4-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
7224DA02-67DF-46A7-9425-3DE9D6BAD26E)\n\nFailed to open attachment
'10.102.192.19\\HYPERV-SMB\\sanjeev-pri\\ROOT-4.vhd'. Error: 'The user
name or password is
[jira] [Commented] (CLOUDSTACK-5317) associateIpAddress command doesnt fails on non upgraded router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838777#comment-13838777
]
manasaveloori commented on CLOUDSTACK-5317:
---
Observed the same for disassociateIpAddress command
2013-12-04 20:31:00,967 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-6202ba9a)
===START=== 10.252.192.19 -- GET
command=disassociateIpAddressresponse=jsonsessionkey=nncAp7MmSEoCXkbGG8kV51t91Js%3Did=88d00a57-8ceb-42bd-ad38-a430db6c963b_=1386149993732
2013-12-04 20:31:01,077 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-4:ctx-6202ba9a ctx-1f967611) submit async job-89, details:
AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: IpAddress,
instanceId: 11, cmd:
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd, cmdInfo:
{response:json,id:88d00a57-8ceb-42bd-ad38-a430db6c963b,sessionkey:nncAp7MmSEoCXkbGG8kV51t91Js\u003d,cmdEventType:NET.IPRELEASE,ctxUserId:2,httpmethod:GET,_:1386149993732,ctxAccountId:2,ctxStartEventId:364},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 6851580133501, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-04 20:31:01,079 DEBUG [c.c.a.ApiServlet] (catalina-exec-4:ctx-6202ba9a
ctx-1f967611) ===END=== 10.252.192.19 -- GET
command=disassociateIpAddressresponse=jsonsessionkey=nncAp7MmSEoCXkbGG8kV51t91Js%3Did=88d00a57-8ceb-42bd-ad38-a430db6c963b_=1386149993732
2013-12-04 20:31:01,084 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-10:ctx-0d24b239) Add job-89 into job monitoring
2013-12-04 20:31:01,084 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-10:ctx-0d24b239) Executing AsyncJobVO {id:89, userId: 2,
accountId: 2, instanceType: IpAddress, instanceId: 11, cmd:
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd, cmdInfo:
{response:json,id:88d00a57-8ceb-42bd-ad38-a430db6c963b,sessionkey:nncAp7MmSEoCXkbGG8kV51t91Js\u003d,cmdEventType:NET.IPRELEASE,ctxUserId:2,httpmethod:GET,_:1386149993732,ctxAccountId:2,ctxStartEventId:364},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 6851580133501, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2013-12-04 20:31:01,108 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-224: Processing Seq 5-224: { Cmd ,
MgmtId: -1, via: 5, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:3,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-12-04 20:31:01,122 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-224: Sending Seq 5-224: { Ans: , MgmtId:
6851580133501, via: 5, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-12-04 20:31:01,152 DEBUG [c.c.n.IpAddressManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Revoking all Firewallrules as a
part of public IP id=11 release...
2013-12-04 20:31:01,190 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Releasing 0 firewall rules for ip
id=11
2013-12-04 20:31:01,195 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) There are no firewall rules to apply
2013-12-04 20:31:01,201 DEBUG [c.c.n.f.FirewallManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Successfully released firewall
rules for ip id=11 and # of rules now = 0
2013-12-04 20:31:01,217 DEBUG [c.c.n.IpAddressManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Revoking all
PortForwarding/StaticNat rules as a part of public IP id=11 release...
2013-12-04 20:31:01,225 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Releasing 0 port forwarding rules
for ip id=11
2013-12-04 20:31:01,230 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Releasing 0 static nat rules for ip
id=11
2013-12-04 20:31:01,232 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) There are no port forwarding rules
to apply for ip id=11
2013-12-04 20:31:01,238 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) There are no static nat rules to
apply for ip id=11
2013-12-04 20:31:01,240 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Source ip id=Ip[10.147.47.13-1] is
not one to one nat
2013-12-04 20:31:01,248 DEBUG [c.c.n.r.RulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Successfully released rules for ip
id=11 and # of rules now = 0
2013-12-04 20:31:01,248 DEBUG [c.c.n.IpAddressManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Revoking all LoadBalancing rules as
a part of public IP id=11 release...
2013-12-04 20:31:01,256 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl]
(Job-Executor-10:ctx-0d24b239 ctx-1f967611) Found 0 lb rules to cleanup
2013-12-04 20:31:01,256 DEBUG
[jira] [Created] (CLOUDSTACK-5363) kvm:vmsync:vm state still show running even after host is poweredoff
sadhu suresh created CLOUDSTACK-5363: Summary: kvm:vmsync:vm state still show running even after host is poweredoff Key: CLOUDSTACK-5363 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5363 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.3.0 Reporter: sadhu suresh Priority: Critical STEPS: 1.Create an advanced zone with 2 kvm hosts 2.deploy 2 vms 3.migrae a vm from host1 to host2 4.once migration completed,power of the host2 5.check the vm state host state actual result: Vm state still shows running even after power off the host. host state is disconnected*vm state is running. mysql select * from vm_instance where id=3\G; *** 1. row *** id: 3 name: VM1sadhu uuid: 1ccb132a-55b2-48e3-b07d-42f8aa81255c instance_name: i-3-3-VM state: Running vm_template_id: 4 guest_os_id: 112 private_mac_address: NULL private_ip_address: NULL pod_id: 1 data_center_id: 1 host_id: 5 last_host_id: 1 proxy_id: 2 proxy_assign_time: 2013-12-02 13:33:58 vnc_password: DfZpD3rXt3L7bwjPxxRXTrMUfP37mznhRFPZDVWc0YY= ha_enabled: 0 limit_cpu_use: 0 update_count: 32 update_time: 2013-12-04 15:54:07 created: 2013-12-02 12:59:12 removed: NULL type: User vm_type: User account_id: 3 domain_id: 1 service_offering_id: 1 reservation_id: 16fb58da-3e58-4039-ba17-d1c65f21c94c hypervisor_type: KVM disk_offering_id: NULL cpu: NULL ram: NULL owner: 3 speed: 500 host_name: VM1sadhu display_name: VM1sadhu desired_state: NULL dynamically_scalable: 0 display_vm: 1 power_state: NULL power_state_update_time: NULL power_state_update_count: 0 power_host: NULL -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5181) Basic Zone - Host cannot do bridge firewalling
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy resolved CLOUDSTACK-5181.
---
Resolution: Invalid
In the host cloudstack security group package CSP is not installed.
Also the xenserver is not set to bridge mode.
Please refer the cloudstack install guide section 8.2.7
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/citrix-xenserver-installation.html
Basic Zone - Host cannot do bridge firewalling
--
Key: CLOUDSTACK-5181
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5181
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: Basic Zone
Reporter: Gaurav Aradhye
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.3.0
Sometimes the virtual machine deployment fails die to this.
Test case
component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
failing due to this issue.
Log:
2013-11-15 00:41:37,042 DEBUG [cloud.vm.UserVmManagerImpl]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
Destroying vm VM[User|a72dcfcd-6
a20-4327-91cf-d4c97d88bc7c] as it failed to create on Host with Id:null
2013-11-15 00:41:37,051 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-133:null) Host 10.223.251.3 cannot do bridge firewalling
2013-11-15 00:41:37,054 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-133:null) Seq 4-303891105: Response Received:
2013-11-15 00:41:37,054 DEBUG [agent.transport.Request]
(DirectAgent-133:null) Seq 4-303891105: Processing: { Ans: , MgmtId:
112957957439171, via: 4, Ver: v1,
Flags: 110,
[{com.cloud.agent.api.SecurityGroupRuleAnswer:{logSequenceNumber:1,vmId:136,reason:CANNOT_BRIDGE_FIREWALL,result:false,details:Host
1
0.223.251.3 cannot do bridge firewalling,wait:0}}] }
2013-11-15 00:41:37,056 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Failed to program rule
com.cloud.agent.api.SecurityGroupRuleAnswer
into host 4 due to Host 10.223.251.3 cannot do bridge firewalling and
updated jobs
2013-11-15 00:41:37,056 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Not retrying security group rules for vm 136 on
failure since host
4 cannot do bridge firewalling
2013-11-15 00:41:37,058 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Failed to program rule
com.cloud.agent.api.SecurityGroupRuleAnswer
into host 4 due to Host 10.223.251.3 cannot do bridge firewalling and
updated jobs
2013-11-15 00:41:37,058 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Not retrying security group rules for vm 136 on
failure since host
4 cannot do bridge firewalling
2013-11-15 00:41:37,058 DEBUG [agent.manager.AgentAttache]
(DirectAgent-133:null) Seq 4-303891105: No more commands found
2013-11-15 00:41:37,066 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ]) VM state
transitted from
:Stopped to Error with event: OperationFailedToErrorvm's original host id:
null new host id: null host id before state transition: null
2013-11-15 00:41:37,089 WARN [apache.cloudstack.alerts]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
alertType:: 8 // dataCenterId:: 1
// podId:: 1 // clusterId:: null // message:: Failed to deploy Vm with Id:
135, on Host with Id: null
2013-11-15 00:41:37,133 INFO [user.vm.DeployVMCmd] (Job-Executor-71:job-741
= [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
com.cloud.exception.InsufficientServerC
apacityException: Unable to create a deployment for
VM[User|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]Scope=interface
com.cloud.dc.DataCenter; id=1
2013-11-15 00:41:37,133 INFO [user.vm.DeployVMCmd] (Job-Executor-71:job-741
= [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ]) Unable to create a deployment for
VM[Us
er|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[User|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]Scope=interface
com.clou
d.dc.DataCenter; id=1
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:577)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237)
at
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
at
[jira] [Comment Edited] (CLOUDSTACK-5181) Basic Zone - Host cannot do bridge firewalling
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838815#comment-13838815
]
Jayapal Reddy edited comment on CLOUDSTACK-5181 at 12/4/13 11:09 AM:
-
In the host cloudstack security group package CSP is not installed.
Also the xenserver switch network mode is not set to bridge.
Please refer the cloudstack install guide section 8.2.7
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/citrix-xenserver-installation.html
was (Author: jayapal):
In the host cloudstack security group package CSP is not installed.
Also the xenserver is not set to bridge mode.
Please refer the cloudstack install guide section 8.2.7
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/citrix-xenserver-installation.html
Basic Zone - Host cannot do bridge firewalling
--
Key: CLOUDSTACK-5181
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5181
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: Basic Zone
Reporter: Gaurav Aradhye
Assignee: Jayapal Reddy
Priority: Critical
Fix For: 4.3.0
Sometimes the virtual machine deployment fails die to this.
Test case
component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
failing due to this issue.
Log:
2013-11-15 00:41:37,042 DEBUG [cloud.vm.UserVmManagerImpl]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
Destroying vm VM[User|a72dcfcd-6
a20-4327-91cf-d4c97d88bc7c] as it failed to create on Host with Id:null
2013-11-15 00:41:37,051 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-133:null) Host 10.223.251.3 cannot do bridge firewalling
2013-11-15 00:41:37,054 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-133:null) Seq 4-303891105: Response Received:
2013-11-15 00:41:37,054 DEBUG [agent.transport.Request]
(DirectAgent-133:null) Seq 4-303891105: Processing: { Ans: , MgmtId:
112957957439171, via: 4, Ver: v1,
Flags: 110,
[{com.cloud.agent.api.SecurityGroupRuleAnswer:{logSequenceNumber:1,vmId:136,reason:CANNOT_BRIDGE_FIREWALL,result:false,details:Host
1
0.223.251.3 cannot do bridge firewalling,wait:0}}] }
2013-11-15 00:41:37,056 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Failed to program rule
com.cloud.agent.api.SecurityGroupRuleAnswer
into host 4 due to Host 10.223.251.3 cannot do bridge firewalling and
updated jobs
2013-11-15 00:41:37,056 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Not retrying security group rules for vm 136 on
failure since host
4 cannot do bridge firewalling
2013-11-15 00:41:37,058 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Failed to program rule
com.cloud.agent.api.SecurityGroupRuleAnswer
into host 4 due to Host 10.223.251.3 cannot do bridge firewalling and
updated jobs
2013-11-15 00:41:37,058 DEBUG [network.security.SecurityGroupListener]
(DirectAgent-133:null) Not retrying security group rules for vm 136 on
failure since host
4 cannot do bridge firewalling
2013-11-15 00:41:37,058 DEBUG [agent.manager.AgentAttache]
(DirectAgent-133:null) Seq 4-303891105: No more commands found
2013-11-15 00:41:37,066 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ]) VM state
transitted from
:Stopped to Error with event: OperationFailedToErrorvm's original host id:
null new host id: null host id before state transition: null
2013-11-15 00:41:37,089 WARN [apache.cloudstack.alerts]
(Job-Executor-71:job-741 = [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
alertType:: 8 // dataCenterId:: 1
// podId:: 1 // clusterId:: null // message:: Failed to deploy Vm with Id:
135, on Host with Id: null
2013-11-15 00:41:37,133 INFO [user.vm.DeployVMCmd] (Job-Executor-71:job-741
= [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ])
com.cloud.exception.InsufficientServerC
apacityException: Unable to create a deployment for
VM[User|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]Scope=interface
com.cloud.dc.DataCenter; id=1
2013-11-15 00:41:37,133 INFO [user.vm.DeployVMCmd] (Job-Executor-71:job-741
= [ f08c55a6-a3e8-4ad0-b78a-d8411f78c13c ]) Unable to create a deployment for
VM[Us
er|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]
com.cloud.exception.InsufficientServerCapacityException: Unable to create a
deployment for VM[User|a72dcfcd-6a20-4327-91cf-d4c97d88bc7c]Scope=interface
com.clou
d.dc.DataCenter; id=1
at
[jira] [Assigned] (CLOUDSTACK-5144) Basic Zone Security Groups - SSH to VM is allowed even when there is no ingress rule defined for the security group
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy reassigned CLOUDSTACK-5144: - Assignee: Gaurav Aradhye (was: Jayapal Reddy) Hi, It is a regression. I don't think the code around SG ingress rules is changed. Can you please check your setup, if you still see the issue attach host iptables rules. Thanks, Jayapal Basic Zone Security Groups - SSH to VM is allowed even when there is no ingress rule defined for the security group --- Key: CLOUDSTACK-5144 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5144 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Priority: Critical Fix For: 4.3.0 In Basic Zone Setup: 1. Create an account 2. Deploy a VM in that account 3. Verify that any ingress rule is not defined for the security group belonging to the account 4. Try SSH to VM using the nic ipaddress from external client SSH is successful to the VM where as it should fail when the ingress rule is not defined. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4197) Allow creating a VM without virtual CD-ROM drive
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4197: - Fix Version/s: 4.3.0 Allow creating a VM without virtual CD-ROM drive Key: CLOUDSTACK-4197 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4197 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.0 Reporter: Kirk Kosinski Priority: Minor Labels: hypervisor, netscaler Fix For: 4.3.0 Currently all VMs that CloudStack creates will include a virtual CD-ROM drive. In some cases, such as with virtual appliances (e.g. NetScaler VPX), a CD-ROM drive is not needed or even unsupported. It would be useful if CloudStack could deploy a VM without a CD-ROM drive to allow such cases. Perhaps such functionality could be added using new OS Types, for example: Other - No CD-ROM (32-bit) Other - No CD-ROM (64-bit) Other PV - No CD-ROM (32-bit) Other PV - No CD-ROM (64-bit) Or maybe it could be added on a per VM or per template basis with a new configuration parameter. This might be more flexible since some customers might want to use arbitrary OS types for VMs with no CD-ROM. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
Ashutosk Kelkar created CLOUDSTACK-5364: --- Summary: Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Also, in that case, if one isolated network is present in the account, there is no need to create another network of the same type before deploying virtual machine. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar updated CLOUDSTACK-5364: Description: The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 was: The test cases failed with the error because the network from earlier test cases did not get deleted. Also, in that case, if one isolated network is present in the account, there is no need to create another network of the same type before deploying virtual machine. Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838847#comment-13838847
]
Jayapal Reddy commented on CLOUDSTACK-5342:
---
Can you please attach all required logs in this bug
Add NIC to virtual machine fails in KVM
---
Key: CLOUDSTACK-5342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: KVM advanced
Reporter: Gaurav Aradhye
Assignee: Jayapal Reddy
Fix For: 4.3.0
Add network to VM test cases fail in KVM with following error.
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
The same test cases execute successfully on XenServer. As per the feature
specification (see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
Add network to VM feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-5342:
--
Assignee: (was: Jayapal Reddy)
Add NIC to virtual machine fails in KVM
---
Key: CLOUDSTACK-5342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: KVM advanced
Reporter: Gaurav Aradhye
Fix For: 4.3.0
Add network to VM test cases fail in KVM with following error.
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
The same test cases execute successfully on XenServer. As per the feature
specification (see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
Add network to VM feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy reassigned CLOUDSTACK-5342:
-
Assignee: Gaurav Aradhye
Add NIC to virtual machine fails in KVM
---
Key: CLOUDSTACK-5342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: KVM advanced
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
Fix For: 4.3.0
Add network to VM test cases fail in KVM with following error.
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
The same test cases execute successfully on XenServer. As per the feature
specification (see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
Add network to VM feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5365) [Hyper-V] VR's control IP is not accessible from mgmt server, which results in VR start up failure
Sanjeev N created CLOUDSTACK-5365:
-
Summary: [Hyper-V] VR's control IP is not accessible from mgmt
server, which results in VR start up failure
Key: CLOUDSTACK-5365
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5365
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Build with commit
2d90ee469a047e8b42dd81f3723240f18b591d5e from 4.3
Zone: Advanced
Storage: Local for system vms ,cifs for guest and cifs for secondary
Hypervisor: Hyperv
Reporter: Sanjeev N
Priority: Blocker
Fix For: 4.3.0
[Hyper-V] VR's control IP is not accessible from mgmt server, which results in
VR start up failure
Steps to Reproduce:
1.Bring up CS in advanced zone with at-least one hyper-v host in the cluster
2.Register one cent os template
3.Try to deploy guest vm with the above template in an isolated network
Expected Result:
==
VR and guest vm should come up in the isolated network successfully
Actual Result:
===
VR failed to come up hence the guest vm deployment failed
Observations:
Initially VR booted up and configured with guest,control and public IP
addresses on eth0,eth1,eth2 inerfaces respectively.
As part of VR bring up process, mgmt server tried to ping/check the template
version on VR using its control IP to confirm the VR boot up. However mgmt
server failed to communicate with VRs control IP address. So it is stopping the
VR.
In another 4.3 setup I have added vmware cluster and tried the above scenario.
There mgmt server was able to communicate with VR on control ip address and VR
came up successfully.
Log snippet from agent log:
==
2013-12-04 04:14:54,275 [14] INFO HypervResource.WmiCallsV2
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - Started VM r-8-VM
2013-12-04 04:14:54,275 [14] INFO HypervResource.HypervResourceController
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - {
com.cloud.agent.api.StartAnswer: {
result: true,
details: null,
vm: {
id: 8,
name: r-8-VM,
type: DomainRouter,
cpus: 1,
minSpeed: 500,
maxSpeed: 500,
minRam: 134217728,
maxRam: 134217728,
arch: i686,
os: Debian GNU/Linux 5.0 (32-bit),
bootArgs: template=domP name=r-8-VM eth2ip=10.147.48.23
eth2mask=255.255.255.0 gateway=10.147.48.1 eth0ip=10.1.1.1
eth0mask=255.255.255.0 domain=cs2cloud.internal dhcprange=10.1.1.1
eth1ip=10.147.40.238 eth1mask=255.255.254.0 type=router disable_rp_filter=true
dns1=10.140.50.6 dns2=,
rebootOnCrash: false,
enableHA: true,
limitCpuUse: false,
enableDynamicallyScaleVm: false,
vncPassword: 33c76dca072011e6,
params: {},
uuid: 33b6472e-67cd-4aee-8556-b22d6e57d44b,
disks: [
{
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 9c48b406-b424-4b77-ae37-37248b454d0f,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: 20de3206-3585-3bb0-b536-a96b665df206-HypervResource,
id: 2,
poolType: Filesystem,
host: 10.147.40.14,
path: C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks,
port: 0,
url:
Filesystem://10.147.40.14/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks/?ROLE=PrimarySTOREUUID=20de3206-3585-3bb0-b536-a96b665df206-HypervResource
}
},
name: ROOT-8,
size: 2101252608,
volumeId: 8,
vmName: r-8-VM,
accountId: 2,
id: 8,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 0,
storageHost: 10.147.40.14,
volumeSize: 2101252608
}
}
],
nics: [
{
deviceId: 2,
networkRateMbps: 200,
defaultNic: true,
uuid: 645d73f8-ea2b-4329-9946-140c12059805,
ip: 10.147.48.23,
netmask: 255.255.255.0,
gateway: 10.147.48.1,
mac: 06:7d:94:00:00:0d,
dns1: 10.140.50.6,
dns2: ,
broadcastType: Vlan,
type: Public,
broadcastUri: vlan://48,
isolationUri: vlan://48,
isSecurityGroupEnabled: false
},
{
deviceId: 0,
networkRateMbps: 200,
defaultNic: false,
uuid: 223b14fa-88b5-4ed0-a804-d428d98205e0,
ip: 10.1.1.1,
[jira] [Updated] (CLOUDSTACK-5365) [Hyper-V] VR's control IP is not accessible from mgmt server, which results in VR start up failure
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-5365:
--
Attachment: management-server.rar
cloudstack-agent.rar
cloud.dmp
Attached mgmt server log file, agent log from hyper-v and cloud DB.
[Hyper-V] VR's control IP is not accessible from mgmt server, which results
in VR start up failure
--
Key: CLOUDSTACK-5365
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5365
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Build with commit
2d90ee469a047e8b42dd81f3723240f18b591d5e from 4.3
Zone: Advanced
Storage: Local for system vms ,cifs for guest and cifs for secondary
Hypervisor: Hyperv
Reporter: Sanjeev N
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: cloud.dmp, cloudstack-agent.rar, management-server.rar
[Hyper-V] VR's control IP is not accessible from mgmt server, which results
in VR start up failure
Steps to Reproduce:
1.Bring up CS in advanced zone with at-least one hyper-v host in the cluster
2.Register one cent os template
3.Try to deploy guest vm with the above template in an isolated network
Expected Result:
==
VR and guest vm should come up in the isolated network successfully
Actual Result:
===
VR failed to come up hence the guest vm deployment failed
Observations:
Initially VR booted up and configured with guest,control and public IP
addresses on eth0,eth1,eth2 inerfaces respectively.
As part of VR bring up process, mgmt server tried to ping/check the template
version on VR using its control IP to confirm the VR boot up. However mgmt
server failed to communicate with VRs control IP address. So it is stopping
the VR.
In another 4.3 setup I have added vmware cluster and tried the above
scenario. There mgmt server was able to communicate with VR on control ip
address and VR came up successfully.
Log snippet from agent log:
==
2013-12-04 04:14:54,275 [14] INFO HypervResource.WmiCallsV2
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - Started VM r-8-VM
2013-12-04 04:14:54,275 [14] INFO HypervResource.HypervResourceController
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - {
com.cloud.agent.api.StartAnswer: {
result: true,
details: null,
vm: {
id: 8,
name: r-8-VM,
type: DomainRouter,
cpus: 1,
minSpeed: 500,
maxSpeed: 500,
minRam: 134217728,
maxRam: 134217728,
arch: i686,
os: Debian GNU/Linux 5.0 (32-bit),
bootArgs: template=domP name=r-8-VM eth2ip=10.147.48.23
eth2mask=255.255.255.0 gateway=10.147.48.1 eth0ip=10.1.1.1
eth0mask=255.255.255.0 domain=cs2cloud.internal dhcprange=10.1.1.1
eth1ip=10.147.40.238 eth1mask=255.255.254.0 type=router
disable_rp_filter=true dns1=10.140.50.6 dns2=,
rebootOnCrash: false,
enableHA: true,
limitCpuUse: false,
enableDynamicallyScaleVm: false,
vncPassword: 33c76dca072011e6,
params: {},
uuid: 33b6472e-67cd-4aee-8556-b22d6e57d44b,
disks: [
{
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 9c48b406-b424-4b77-ae37-37248b454d0f,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid:
20de3206-3585-3bb0-b536-a96b665df206-HypervResource,
id: 2,
poolType: Filesystem,
host: 10.147.40.14,
path: C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,
port: 0,
url:
Filesystem://10.147.40.14/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard
Disks/?ROLE=PrimarySTOREUUID=20de3206-3585-3bb0-b536-a96b665df206-HypervResource
}
},
name: ROOT-8,
size: 2101252608,
volumeId: 8,
vmName: r-8-VM,
accountId: 2,
id: 8,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 0,
storageHost: 10.147.40.14,
volumeSize: 2101252608
}
}
],
nics: [
{
deviceId: 2,
networkRateMbps: 200,
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838864#comment-13838864 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit b2c89552226bd44b356d5bcd613f14ca3b9c90a7 in branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b2c8955 ] CLOUDSTACK-5364: Resolving network cleanup issue in egress fw rules test cases Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838865#comment-13838865 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit b1462e826aef2980ec12fef2fb89914c6a8606c5 in branch refs/heads/4.2 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b1462e8 ] CLOUDSTACK-5364: Resolving network cleanup issue in egress fw rules test cases Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838863#comment-13838863 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit 542858a88f147c9f830a60b85649f48a99546f9b in branch refs/heads/4.3 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=542858a ] CLOUDSTACK-5364: Resolving network cleanup issue in egress fw rules test cases Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5366) CIFS store is not getting added while adding from zone creation wizard
Rajesh Battala created CLOUDSTACK-5366: -- Summary: CIFS store is not getting added while adding from zone creation wizard Key: CLOUDSTACK-5366 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5366 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Rajesh Battala Priority: Critical Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838870#comment-13838870 ] ASF subversion and git services commented on CLOUDSTACK-5351: - Commit f0df405b8facefdc18ef270bd5d6d390ea8941c5 in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f0df405 ] CLOUDSTACK-5351: Fixed a regression where shared_ntwk_vlan was not changed to shared_vlan [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838869#comment-13838869 ] ASF subversion and git services commented on CLOUDSTACK-5351: - Commit d3968d5a968ced85c06041d9b5670aad571c84d3 in branch refs/heads/4.3 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d3968d5 ] CLOUDSTACK-5351: Fixed a regression where shared_ntwk_vlan was not changed to shared_vlan [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5351. -- Resolution: Fixed Fix Version/s: 4.4.0 4.2.1 [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838868#comment-13838868 ] ASF subversion and git services commented on CLOUDSTACK-5351: - Commit dfff362c116d69aaad52d7e907d19b9e11dac028 in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dfff362 ] CLOUDSTACK-5351: Fixed a regression where shared_ntwk_vlan was not changed to shared_vlan [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5367) component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with global name 'shared_ntwk_vlan' is not defined
Gaurav Aradhye created CLOUDSTACK-5367: -- Summary: component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with global name 'shared_ntwk_vlan' is not defined Key: CLOUDSTACK-5367 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5367 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 The test case is failing with global name 'shared_ntwk_vlan' is not defined. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5351: - Labels: automation (was: ) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Labels: automation Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5351) [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar reassigned CLOUDSTACK-5351: Assignee: Girish Shilamkar [Automation] Test case test_createSharedNetwork_usedVlan2 failed with error global name 'shared_ntwk_vlan' is not defined --- Key: CLOUDSTACK-5351 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5351 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Labels: automation Fix For: 4.2.1, 4.3.0, 4.4.0 Test cases integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_usedVlan2 failing with below error Error Message global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_networks.py, line 1995, in test_createSharedNetwork_usedVlan2 self.services[network][vlan] = shared_ntwk_vlan global name 'shared_ntwk_vlan' is not defined begin captured logging test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Admin account created: cc6771f1-603b-4039-8f0d-1611cddd20a3 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Physical Network found: 9106d77f-3cdc-450e-8c36-f23beee0c861 test_createSharedNetwork_usedVlan2 (integration.component.test_shared_networks.TestSharedNetworks): DEBUG: Shared Network Offering created: a0cb1740-84bb-4e70-a991-19c8457322fb - end captured logging - -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5340) [Hyper-V] Control IPs are not getting released when VRs are in stopped state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5340: --- Labels: (was: hyper-V,) [Hyper-V] Control IPs are not getting released when VRs are in stopped state Key: CLOUDSTACK-5340 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5340 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, Network Controller Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Priority: Critical Fix For: 4.3.0 Attachments: management-server.log.2013-12-02.gz [Hyper-V] Control IPs are not getting released when VRs are in stopped state Steps to Reproduce: = 1.Bring up Advanced zone with Hyperv using latest 4.3 build 2.Implement network and make sure Vr is in running state 3.Stop,start VR multiple times. Expected Result: == Each time VR is stopped, control IP should be released to the pool and when the VR is started again it should get one ip address from the pool. Actual Result: === When the VR is stopped, control IP is not getting released to the pool. It remains in the reserved state. Currently in the setup there are only 5 system vms (SSVM,CPVM,3VRs) are there. So in total there should be only 6 controls IPs in reserved state.However op_dc_ip_address_alloc tables shows only one IP in free state out of 10 Pod Ip addresses. mysql select * from op_dc_ip_address_alloc; ++---++++--+-+-+ | id | ip_address| data_center_id | pod_id | nic_id | reservation_id | taken | mac_address | ++---++++--+-+-+ | 1 | 10.147.40.231 | 1 | 1 | 7 | 2709a8d9-71af-4c9b-9139-75e47aad6c76 | 2013-12-02 10:38:36 | 1 | | 2 | 10.147.40.232 | 1 | 1 | NULL | NULL | NULL| 2 | | 3 | 10.147.40.233 | 1 | 1 | 15 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:37 | 3 | | 4 | 10.147.40.234 | 1 | 1 | 23 | 1a1d5501-5e94-46b0-a770-af6277715f74 | 2013-12-02 17:15:05 | 4 | | 5 | 10.147.40.235 | 1 | 1 | 18 | 02e7a340-d1f3-46ab-adb9-dd91c3549d30 | 2013-12-02 15:44:13 | 5 | | 6 | 10.147.40.236 | 1 | 1 | 28 | 762014f4-fcd8-41d9-906c-1b05dbf07df7 | 2013-12-02 17:54:00 | 6 | | 7 | 10.147.40.237 | 1 | 1 | 18 | ced340b8-a34e-43fe-829e-7b790e380387 | 2013-12-02 15:25:37 | 7 | | 8 | 10.147.40.238 | 1 | 1 | 14 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:36 | 8 | | 9 | 10.147.40.239 | 1 | 1 | 23 | c2e2d7b1-4b4f-48da-b9ba-a8e64255711b | 2013-12-02 17:36:45 | 9 | | 10 | 10.147.40.240 | 1 | 1 | 18 | cb036c69-1721-4d13-b61d-42b6f2e7a76c | 2013-12-02 17:50:20 | 10 | ++---++++--+-+-+ 10 rows in set (0.00 sec) mysql select id,name,state from vm_instance where removed is null and vm_type!='User'; ++-+--+ | id | name| state| ++-+--+ | 2 | v-2-VM | Running | | 4 | s-4-VM | Running | | 6 | r-6-VM | Stopped | | 9 | r-9-VM | Stopped | | 11 | r-11-VM | Starting | ++-+--+ 5 rows in set (0.00 sec) Attaching management server log file with this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5178) [Hyper-V] Deploy VM from ISO fails with Unsupported Command
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838943#comment-13838943
]
ASF subversion and git services commented on CLOUDSTACK-5178:
-
Commit 3744deab144b5118f4d231bdea9c7b80549725d7 in branch refs/heads/4.3 from
[~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3744dea ]
CLOUDSTACK-5178: DeployVm from ISO fails. Fixed the creation of root
volume and made sure the iso is attached when a vm is deployed.
[Hyper-V] Deploy VM from ISO fails with Unsupported Command
-
Key: CLOUDSTACK-5178
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5178
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, local storage
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Creation on VM from ISO fails on Hyper-V. From template it works fine.
Steps:
Register ISO of any supported OS
After it's downloaded and ready, Deploy VM from ISO
Also used local storage for this case.
The same goes fine with xen server.
DeployVM fails the following exception:
2013-11-15 13:10:42,505 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Sending cmd to
http://10.102.192.39:8250/api/HypervResou
rce/org.apache.cloudstack.storage.command.CreateObjectCommand cmd
data:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:43727cfc-3f64-4955
-87d9-77f2f840ab5c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource,id:1,poolType:Filesystem,host:10.102.192.39,path:C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,port:0,url:Filesyst
em://10.102.192.39/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks/?ROLE\u003dPrimary\u0026STOREUUID\u003d7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource}},name:ROOT-14,size:1073741824,volumeId:14,vmName:i-2-14-VM,accountId:2,id:14,deviceId:0,hypervisorType:Hyperv}},contextMa
p:{},wait:0}
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Failed to send : HTTP error code : 404
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) com.cloud.agent.api.UnsupportedAnswer
2013-11-15 13:10:42,537 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) executeRequest received response
[{com.cloud.agent.api.
UnsupportedAnswer:{result:false,details:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sur
e you got the right type of server?,contextMap:{},wait:0}}]
2013-11-15 13:10:42,537 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Response Received:
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Processing: { Ans: ,
MgmtId: 64538137909171, via: 1, Ver: v
1, Flags: 10,
[{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
command /api/HypervResource/org.apache.cloudstack.storage.comm
and.CreateObjectCommand. Are you sure you got the right type of
server?,wait:0}}] }
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-e0985065
ctx-6f6675d5) Seq 1-2024873304: Received: { Ans: , MgmtId: 64538137909171,
via
: 1, Ver: v1, Flags: 10, { UnsupportedAnswer } }
2013-11-15 13:10:42,538 WARN [c.c.a.m.AgentManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported Command: Unsupported
command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@81edb47), no
need to delete from object in store ref table
2013-11-15 13:10:42,542 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to create
Vol[14|vm=14|ROOT]:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to
[jira] [Commented] (CLOUDSTACK-5172) Removing disks from VMWare VMs with snapshots causes problems
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838952#comment-13838952 ] ASF subversion and git services commented on CLOUDSTACK-5172: - Commit 2794a9398f4dd224ce34e49a2318d1b92b234915 in branch refs/heads/4.3 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2794a93 ] CLOUDSTACK-5172. Detaching VM volume is not allowed if there are VM snapshots because any changes to the disk layout will break the semantics of VM-based snapshot Removing disks from VMWare VMs with snapshots causes problems - Key: CLOUDSTACK-5172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot, VMware Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Likitha Shetty Priority: Critical Labels: snapshot, snapshots, vmware Fix For: 4.3.0 We currently don’t allow volumes to be attached to VMs with snapshots and allowing volumes to be detached causes quite a bug: 1) Attach a data disk to a VM 2) Snapshot the VM 3) Detach the data disk 4) Attempt to restore the VM from the snapshot — FAILS since the data disk is no longer there, although it is expected to be 5) Attempt to re-attach the volume to the VM — FAILS since you cannot attach volumes to VMs with snapshots 6) Attempt to delete the VM snapshot — FAILS since the data disk is no longer there, although it is expected to be I have verified the above steps on VMWare, however Xen does not appear to fail on step 4, presumably because VMWare handles snapshots quite differently than Xen. After discussion on the dev list, it sounds like the proper course of action would be to prohibit disks from being detached from VMWare VMs with snapshots. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5172) Removing disks from VMWare VMs with snapshots causes problems
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838954#comment-13838954 ] ASF subversion and git services commented on CLOUDSTACK-5172: - Commit f37057a215c886369924c81352449bf4f5a27d2c in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f37057a ] CLOUDSTACK-5172. Detaching VM volume is not allowed if there are VM snapshots because any changes to the disk layout will break the semantics of VM-based snapshot Removing disks from VMWare VMs with snapshots causes problems - Key: CLOUDSTACK-5172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot, VMware Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Likitha Shetty Priority: Critical Labels: snapshot, snapshots, vmware Fix For: 4.3.0 We currently don’t allow volumes to be attached to VMs with snapshots and allowing volumes to be detached causes quite a bug: 1) Attach a data disk to a VM 2) Snapshot the VM 3) Detach the data disk 4) Attempt to restore the VM from the snapshot — FAILS since the data disk is no longer there, although it is expected to be 5) Attempt to re-attach the volume to the VM — FAILS since you cannot attach volumes to VMs with snapshots 6) Attempt to delete the VM snapshot — FAILS since the data disk is no longer there, although it is expected to be I have verified the above steps on VMWare, however Xen does not appear to fail on step 4, presumably because VMWare handles snapshots quite differently than Xen. After discussion on the dev list, it sounds like the proper course of action would be to prohibit disks from being detached from VMWare VMs with snapshots. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5172) Removing disks from VMWare VMs with snapshots causes problems
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-5172. Resolution: Fixed Detaching/attaching VM volume is not allowed if there are VM snapshots, because any changes to the disk layout will break the semantics of VM-based snapshot. refer - [https://cwiki.apache.org/confluence/display/CLOUDSTACK/VM+Snapshots] Therefore don't allow volume detach if the associated VM has snapshots Removing disks from VMWare VMs with snapshots causes problems - Key: CLOUDSTACK-5172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5172 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot, VMware Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Likitha Shetty Priority: Critical Labels: snapshot, snapshots, vmware Fix For: 4.3.0 We currently don’t allow volumes to be attached to VMs with snapshots and allowing volumes to be detached causes quite a bug: 1) Attach a data disk to a VM 2) Snapshot the VM 3) Detach the data disk 4) Attempt to restore the VM from the snapshot — FAILS since the data disk is no longer there, although it is expected to be 5) Attempt to re-attach the volume to the VM — FAILS since you cannot attach volumes to VMs with snapshots 6) Attempt to delete the VM snapshot — FAILS since the data disk is no longer there, although it is expected to be I have verified the above steps on VMWare, however Xen does not appear to fail on step 4, presumably because VMWare handles snapshots quite differently than Xen. After discussion on the dev list, it sounds like the proper course of action would be to prohibit disks from being detached from VMWare VMs with snapshots. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5178) [Hyper-V] Deploy VM from ISO fails with Unsupported Command
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838964#comment-13838964
]
ASF subversion and git services commented on CLOUDSTACK-5178:
-
Commit 13740ac135a3b4769af56690b4d1e82e36a35209 in branch refs/heads/master
from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=13740ac ]
CLOUDSTACK-5178: DeployVm from ISO fails. Fixed the creation of root
volume and made sure the iso is attached when a vm is deployed.
[Hyper-V] Deploy VM from ISO fails with Unsupported Command
-
Key: CLOUDSTACK-5178
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5178
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, local storage
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Creation on VM from ISO fails on Hyper-V. From template it works fine.
Steps:
Register ISO of any supported OS
After it's downloaded and ready, Deploy VM from ISO
Also used local storage for this case.
The same goes fine with xen server.
DeployVM fails the following exception:
2013-11-15 13:10:42,505 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Sending cmd to
http://10.102.192.39:8250/api/HypervResou
rce/org.apache.cloudstack.storage.command.CreateObjectCommand cmd
data:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:43727cfc-3f64-4955
-87d9-77f2f840ab5c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource,id:1,poolType:Filesystem,host:10.102.192.39,path:C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,port:0,url:Filesyst
em://10.102.192.39/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks/?ROLE\u003dPrimary\u0026STOREUUID\u003d7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource}},name:ROOT-14,size:1073741824,volumeId:14,vmName:i-2-14-VM,accountId:2,id:14,deviceId:0,hypervisorType:Hyperv}},contextMa
p:{},wait:0}
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Failed to send : HTTP error code : 404
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) com.cloud.agent.api.UnsupportedAnswer
2013-11-15 13:10:42,537 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) executeRequest received response
[{com.cloud.agent.api.
UnsupportedAnswer:{result:false,details:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sur
e you got the right type of server?,contextMap:{},wait:0}}]
2013-11-15 13:10:42,537 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Response Received:
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Processing: { Ans: ,
MgmtId: 64538137909171, via: 1, Ver: v
1, Flags: 10,
[{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
command /api/HypervResource/org.apache.cloudstack.storage.comm
and.CreateObjectCommand. Are you sure you got the right type of
server?,wait:0}}] }
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-e0985065
ctx-6f6675d5) Seq 1-2024873304: Received: { Ans: , MgmtId: 64538137909171,
via
: 1, Ver: v1, Flags: 10, { UnsupportedAnswer } }
2013-11-15 13:10:42,538 WARN [c.c.a.m.AgentManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported Command: Unsupported
command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@81edb47), no
need to delete from object in store ref table
2013-11-15 13:10:42,542 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to create
Vol[14|vm=14|ROOT]:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to
[jira] [Created] (CLOUDSTACK-5368) ListViews marked with 'needsRefresh' do not have loading overlay removed on error
Chris Suich created CLOUDSTACK-5368: --- Summary: ListViews marked with 'needsRefresh' do not have loading overlay removed on error Key: CLOUDSTACK-5368 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5368 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.3.0 ListView actions marked with 'needsRefresh' add a loading overlay before the action is performed. If the operation succeeds, the overlay is properly removed. If it fails, the overlay is NOT removed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5178) [Hyper-V] Deploy VM from ISO fails with Unsupported Command
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-5178.
---
Resolution: Fixed
[Hyper-V] Deploy VM from ISO fails with Unsupported Command
-
Key: CLOUDSTACK-5178
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5178
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: 4.3, Hyper-V, local storage
Reporter: Sowmya Krishnan
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Creation on VM from ISO fails on Hyper-V. From template it works fine.
Steps:
Register ISO of any supported OS
After it's downloaded and ready, Deploy VM from ISO
Also used local storage for this case.
The same goes fine with xen server.
DeployVM fails the following exception:
2013-11-15 13:10:42,505 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Sending cmd to
http://10.102.192.39:8250/api/HypervResou
rce/org.apache.cloudstack.storage.command.CreateObjectCommand cmd
data:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:43727cfc-3f64-4955
-87d9-77f2f840ab5c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource,id:1,poolType:Filesystem,host:10.102.192.39,path:C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,port:0,url:Filesyst
em://10.102.192.39/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual Hard
Disks/?ROLE\u003dPrimary\u0026STOREUUID\u003d7d3b7953-a8bd-3467-b5df-f3e906ea2ea0-Hype
rvResource}},name:ROOT-14,size:1073741824,volumeId:14,vmName:i-2-14-VM,accountId:2,id:14,deviceId:0,hypervisorType:Hyperv}},contextMa
p:{},wait:0}
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) Failed to send : HTTP error code : 404
2013-11-15 13:10:42,536 ERROR [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) com.cloud.agent.api.UnsupportedAnswer
2013-11-15 13:10:42,537 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-471:ctx-f8846b9b) executeRequest received response
[{com.cloud.agent.api.
UnsupportedAnswer:{result:false,details:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sur
e you got the right type of server?,contextMap:{},wait:0}}]
2013-11-15 13:10:42,537 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Response Received:
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request]
(DirectAgent-471:ctx-f8846b9b) Seq 1-2024873304: Processing: { Ans: ,
MgmtId: 64538137909171, via: 1, Ver: v
1, Flags: 10,
[{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
command /api/HypervResource/org.apache.cloudstack.storage.comm
and.CreateObjectCommand. Are you sure you got the right type of
server?,wait:0}}] }
2013-11-15 13:10:42,538 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-e0985065
ctx-6f6675d5) Seq 1-2024873304: Received: { Ans: , MgmtId: 64538137909171,
via
: 1, Ver: v1, Flags: 10, { UnsupportedAnswer } }
2013-11-15 13:10:42,538 WARN [c.c.a.m.AgentManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported Command: Unsupported
command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 WARN [o.a.c.s.d.ObjectInDataStoreManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unsupported data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@81edb47), no
need to delete from object in store ref table
2013-11-15 13:10:42,542 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to create
Vol[14|vm=14|ROOT]:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
2013-11-15 13:10:42,542 INFO [c.c.v.VirtualMachineManagerImpl]
(Job-Executor-14:ctx-e0985065 ctx-6f6675d5) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[14|vm=14|ROOT]:Unsupported command
/api/HypervResource/org.apache.cloudstack.storage.command.CreateObjectCommand.
Are you sure you got the right type of server?
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1105)
at
[jira] [Commented] (CLOUDSTACK-5368) ListViews marked with 'needsRefresh' do not have loading overlay removed on error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839002#comment-13839002 ] Brian Federle commented on CLOUDSTACK-5368: --- commit a00f1887c46632538b8390fa420cff4b1595f420 [4.3] Author: Chris Suich chris.su...@netapp.com Date: Wed Dec 4 10:06:05 2013 -0500 Fixed issue with ListView 'needsRefresh' overlays not being removed JIRA-5368 commit 4ecf6df5f64cc048cac110dbb73f11c66dc16750 [master] Author: Chris Suich chris.su...@netapp.com Date: Wed Dec 4 10:06:05 2013 -0500 Fixed issue with ListView 'needsRefresh' overlays not being removed JIRA-5368 ListViews marked with 'needsRefresh' do not have loading overlay removed on error - Key: CLOUDSTACK-5368 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5368 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.3.0 ListView actions marked with 'needsRefresh' add a loading overlay before the action is performed. If the operation succeeds, the overlay is properly removed. If it fails, the overlay is NOT removed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5369) upgrade from 4.0.2 to 4.2 fail
Jaro created CLOUDSTACK-5369: Summary: upgrade from 4.0.2 to 4.2 fail Key: CLOUDSTACK-5369 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5369 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.2.0, 4.0.2 Environment: CentOS release 6.4 Reporter: Jaro Hello I try to upgrade CloudStak 4.0.2 to 4.2. I go with procedure from DOC I run cloudstack-management start cloudstack successfully prepare database Upgrade completed for version 4.2.0 and try to start and stops on utils.crypt.DBEncryptionUtil] (Timer-2:null) Error while decrypting: true in mysql last log seen UPDATE configuration SET value = 'qUC9aJDgXXXMX1ST/ZA==' WHERE name = 'init' I decrypt all password in db.properties and password above and all is ok in catalina.out i found some error: in catalina.out Exception in thread Timer-2 org.jasypt.exceptions.EncryptionOperationNotPossibleException at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918) at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725) at com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65) at com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:92) at com.cloud.configuration.dao.ConfigurationDaoImpl.getConfiguration(ConfigurationDaoImpl.java:84) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.CGLIB$getConfiguration$6(generated) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a_FastClassByCloudStack_f2c2e518.invoke(generated) at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.getConfiguration(generated) at com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1287) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5369) upgrade from 4.0.2 to 4.2 fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaro updated CLOUDSTACK-5369: - Description: Hello I try to upgrade CloudStak 4.0.2 to 4.2. I go with procedure from DOC I run cloudstack-management start cloudstack successfully prepare database Upgrade completed for version 4.2.0 and try to start and stops on utils.crypt.DBEncryptionUtil] (Timer-2:null) Error while decrypting: true in mysql last log seen UPDATE configuration SET value = 'qUC9aJDgXXXMX1ST/ZA==' WHERE name = 'init' I decrypt all password in db.properties and password above and all is ok in catalina.out i found some error: Exception in thread Timer-2 org.jasypt.exceptions.EncryptionOperationNotPossibleException at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918) at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725) at com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65) at com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:92) at com.cloud.configuration.dao.ConfigurationDaoImpl.getConfiguration(ConfigurationDaoImpl.java:84) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.CGLIB$getConfiguration$6(generated) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a_FastClassByCloudStack_f2c2e518.invoke(generated) at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.getConfiguration(generated) at com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1287) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) was: Hello I try to upgrade CloudStak 4.0.2 to 4.2. I go with procedure from DOC I run cloudstack-management start cloudstack successfully prepare database Upgrade completed for version 4.2.0 and try to start and stops on utils.crypt.DBEncryptionUtil] (Timer-2:null) Error while decrypting: true in mysql last log seen UPDATE configuration SET value = 'qUC9aJDgXXXMX1ST/ZA==' WHERE name = 'init' I decrypt all password in db.properties and password above and all is ok in catalina.out i found some error: in catalina.out Exception in thread Timer-2 org.jasypt.exceptions.EncryptionOperationNotPossibleException at org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918) at org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725) at com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65) at com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:92) at com.cloud.configuration.dao.ConfigurationDaoImpl.getConfiguration(ConfigurationDaoImpl.java:84) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.CGLIB$getConfiguration$6(generated) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a_FastClassByCloudStack_f2c2e518.invoke(generated) at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.configuration.dao.ConfigurationDaoImpl_EnhancerByCloudStack_daa8e77a.getConfiguration(generated) at com.cloud.cluster.ClusterManagerImpl.configure(ClusterManagerImpl.java:1287) at com.cloud.utils.component.ComponentContext.initComponentsLifeCycle(ComponentContext.java:111) at com.cloud.servlet.CloudStartupServlet$1.run(CloudStartupServlet.java:54) at java.util.TimerThread.mainLoop(Timer.java:534) at java.util.TimerThread.run(Timer.java:484) upgrade from 4.0.2 to 4.2 fail -- Key: CLOUDSTACK-5369 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5369 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.0.2, 4.2.0 Environment: CentOS release 6.4 Reporter: Jaro Labels: fail, upgrade Hello I try to upgrade CloudStak 4.0.2 to 4.2. I go with
[jira] [Commented] (CLOUDSTACK-5266) QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839074#comment-13839074 ] ASF subversion and git services commented on CLOUDSTACK-5266: - Commit 59c3006ff17f76995d0fa4345189f84e58455577 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59c3006 ] CLOUDSTACK-5266: Fix quickview not working for VR sections QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well) Key: CLOUDSTACK-5266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Brian Federle Fix For: 4.3.0 Attachments: QuickView_in_groupByZonePodClusterView_in_VirtualRouters_page.jpg QuickView in group by zone/pod/cluster listView (in Virtual Routers page) doesn't work. QuickView in all other listView work well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5266) QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-5266. --- Resolution: Fixed QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well) Key: CLOUDSTACK-5266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Brian Federle Fix For: 4.3.0 Attachments: QuickView_in_groupByZonePodClusterView_in_VirtualRouters_page.jpg QuickView in group by zone/pod/cluster listView (in Virtual Routers page) doesn't work. QuickView in all other listView work well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5266) QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839075#comment-13839075 ] ASF subversion and git services commented on CLOUDSTACK-5266: - Commit 10cd11637afbc89915df4d22a3eaddecbbfc988e in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=10cd116 ] CLOUDSTACK-5266: Fix quickview not working for VR sections QuickView in group by zone/pod/cluster listView doesn't work. (QuickView in all other listView work well) Key: CLOUDSTACK-5266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5266 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Brian Federle Fix For: 4.3.0 Attachments: QuickView_in_groupByZonePodClusterView_in_VirtualRouters_page.jpg QuickView in group by zone/pod/cluster listView (in Virtual Routers page) doesn't work. QuickView in all other listView work well. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2570) [UI]Resource Name is mentioned twice with view VNMC devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839121#comment-13839121 ] ASF subversion and git services commented on CLOUDSTACK-2570: - Commit dd3a511c66709646c38f8acf628fd1087aba36b4 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dd3a511 ] CLOUDSTACK-2570: Fix duplicate resource name field [UI]Resource Name is mentioned twice with view VNMC devices Key: CLOUDSTACK-2570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2570 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Brian Federle Priority: Minor Fix For: 4.3.0 Attachments: screenshot-1.jpg Setup: Advanced Networking Zone with Nexus VMWARE Cluster Steps: 1. Access Management server as adimin 2. Infrastructure - Physical Network - Network service providers - Add VNMC provider 3. View VNMC devices - Select the device Observation: 1.Resource Name is mentioned twice with view VNMC devices . It has to be removed. (Attached the snapshot) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4046) Can't edit global settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle updated CLOUDSTACK-4046: -- Fix Version/s: (was: 4.3.0) Future This will be fixed in a future release, once several widget/UI refactor tasks have been completed. Can't edit global settings -- Key: CLOUDSTACK-4046 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4046 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.1.0 Reporter: Nicolas Lamirault Assignee: Brian Federle Priority: Minor Fix For: Future Attachments: CloudStack_GlobalSettingsOK.png, CloudStack_GlobalSettingsOK2.png, CloudStack_GlobalSettingsOK3.png Hi, in our Cloudstack, we've got a strange behavior. gradually as one moves down the settings, the Edit box disappears. See screenshots. Regards -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-2570) [UI]Resource Name is mentioned twice with view VNMC devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-2570. --- Resolution: Fixed [UI]Resource Name is mentioned twice with view VNMC devices Key: CLOUDSTACK-2570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2570 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Brian Federle Priority: Minor Fix For: 4.3.0 Attachments: screenshot-1.jpg Setup: Advanced Networking Zone with Nexus VMWARE Cluster Steps: 1. Access Management server as adimin 2. Infrastructure - Physical Network - Network service providers - Add VNMC provider 3. View VNMC devices - Select the device Observation: 1.Resource Name is mentioned twice with view VNMC devices . It has to be removed. (Attached the snapshot) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-2570) [UI]Resource Name is mentioned twice with view VNMC devices
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839120#comment-13839120 ] ASF subversion and git services commented on CLOUDSTACK-2570: - Commit 751d8d196670c8b615abefb3f5298de0514a5469 in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=751d8d1 ] CLOUDSTACK-2570: Fix duplicate resource name field [UI]Resource Name is mentioned twice with view VNMC devices Key: CLOUDSTACK-2570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2570 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Brian Federle Priority: Minor Fix For: 4.3.0 Attachments: screenshot-1.jpg Setup: Advanced Networking Zone with Nexus VMWARE Cluster Steps: 1. Access Management server as adimin 2. Infrastructure - Physical Network - Network service providers - Add VNMC provider 3. View VNMC devices - Select the device Observation: 1.Resource Name is mentioned twice with view VNMC devices . It has to be removed. (Attached the snapshot) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839135#comment-13839135 ] Nitin Mehta commented on CLOUDSTACK-5349: - Rayees - Was this working in the previous runs ? When did you last run the test where it was working ? [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 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: ALL branch 4.3 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5261) Ability to publish Alerts via CS Root API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839141#comment-13839141 ] ASF subversion and git services commented on CLOUDSTACK-5261: - Commit bd6f706b7261948ff44cffeebab0c7fcddfae857 in branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bd6f706 ] CLOUDSTACK-5261: added support for Alert publishing via ROOT Admin API Conflicts: engine/orchestration/src/com/cloud/agent/manager/AgentManagerImpl.java engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java engine/storage/image/src/org/apache/cloudstack/storage/image/TemplateServiceImpl.java engine/storage/volume/src/org/apache/cloudstack/storage/datastore/provider/DefaultHostListener.java engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java plugins/hypervisors/hyperv/src/com/cloud/hypervisor/hyperv/discoverer/HypervServerDiscoverer.java plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java server/src/com/cloud/alert/AlertManagerImpl.java server/src/com/cloud/alert/ConsoleProxyAlertAdapter.java server/src/com/cloud/alert/SecondaryStorageVmAlertAdapter.java server/src/com/cloud/configuration/ConfigurationManagerImpl.java server/src/com/cloud/ha/HighAvailabilityManagerExtImpl.java server/src/com/cloud/ha/HighAvailabilityManagerImpl.java server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java server/src/com/cloud/resourcelimit/ResourceLimitManagerImpl.java server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java server/src/com/cloud/vm/UserVmManagerImpl.java usage/src/com/cloud/usage/UsageAlertManagerImpl.java usage/src/com/cloud/usage/UsageManagerImpl.java listAlerts: introduced new parameter name to the alertResponse Conflicts: api/src/org/apache/cloudstack/api/command/admin/resource/ListAlertsCmd.java server/src/com/cloud/alert/AlertManagerImpl.java usage/src/com/cloud/usage/UsageAlertManagerImpl.java Added new Admin API - generateAlert. Available to ROOT admin only Conflicts: api/src/org/apache/cloudstack/alert/AlertService.java api/src/org/apache/cloudstack/api/BaseCmd.java usage/src/com/cloud/usage/UsageAlertManagerImpl.java listAlerts: implemented search by alert name Conflicts: api/src/org/apache/cloudstack/alert/AlertService.java api/src/org/apache/cloudstack/api/command/admin/resource/ListAlertsCmd.java engine/schema/src/com/cloud/alert/AlertVO.java Ability to publish Alerts via CS Root API - Key: CLOUDSTACK-5261 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5261 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.3.0 Third party systems integrating with CloudStack should be able to publish alerts in order to utilize CS Alert notification system. Currently there is no way to publish an alert through the web API; it can be done only by direct calls to the AlertManager. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4992) Domain/Account/User Sync Up Among Multiple Regions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Ough updated CLOUDSTACK-4992: -- Description: Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. Discussion http://markmail.org/thread/k4x63ef55chcj4y5 Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross was: Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. This is the title of the email for discuss. [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross Domain/Account/User Sync Up Among Multiple Regions -- Key: CLOUDSTACK-4992 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4992 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Alex Ough Assignee: Alex Ough Labels: features Fix For: Future Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. Discussion http://markmail.org/thread/k4x63ef55chcj4y5 Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5261) Ability to publish Alerts via CS Root API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-5261. --- Resolution: Fixed Ability to publish Alerts via CS Root API - Key: CLOUDSTACK-5261 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5261 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.3.0 Third party systems integrating with CloudStack should be able to publish alerts in order to utilize CS Alert notification system. Currently there is no way to publish an alert through the web API; it can be done only by direct calls to the AlertManager. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3190) action events message published on 'event bus' should have the UUID of the entity for which event generated and event type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839163#comment-13839163 ] Alex Ough commented on CLOUDSTACK-3190: --- It looks like the information has been missed in master because it worked ok during I was working on CLOUDSTACK-4992 with 4.2 codes, but now I don't have them after switching the codes to master. And after a little bit of investigation, 1. All the commands related with domain/account/user resources use the class instance for the keys when storing the the 'entity uuid' as below. CallContext.current().putContextParameter(Account.class, account.getUuid()); 2. But the ActionEventUtil class uses different key to get the 'entity uuid' as below. entityUuid = (String)context.getContextParameter(EntityUuid); // where EntityUuid is defined as entity_uuid So even if the uuids are stored in the context, they are failed to be retrieved from the context. action events message published on 'event bus' should have the UUID of the entity for which event generated and event type -- Key: CLOUDSTACK-3190 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3190 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Environment: action events message published on 'event bus' should have the UUID of the entity for which event generated and entity type details. as well Events bus framework with current AMQP default implementation, has routing key with format 'Eventsource.EventCategory.EventType.EntityType.EntityUUID'. For action events, EntityUUDI is not populated. Fix would required to ensure entity UUID is used in forming the routing key. Reporter: Murali Reddy Labels: newbie -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839161#comment-13839161 ] Will Stevens commented on CLOUDSTACK-5278: -- I am currently building workarounds for some of these bugs in my provider. How am I supposed to find the default egress firewall rule for my network when I am deleting the network? I can not find functions to get the firewall rules associated with a network. I was considering just calling 'revokeAllFirewallRulesForNetwork' in my provider's resource file, but for some reason this seems wrong. It does not seem right that I have to import a manager into my resource file in order to remove a firewall rule. Also, I think this function will not clean up the default egress rule because of the way it is implemented (ie: its not in the database)... I have not tried that approach yet. What functions should a provider's resource file implement in order to remove the default egress rule? Egress Firewall rules clarifications Key: CLOUDSTACK-5278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5278 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 These issues may also exist in the 4.2 branch, but I am currently testing/working on the 4.3 branch. I believe these bugs were introduced with the change to the Network Service Offering to add the 'Default egress policy' dropdown. https://issues.apache.org/jira/browse/CLOUDSTACK-1578 I am trying to resolve the bugs this change introduced in the Palo Alto plugin. There are two types of Egress rules (from what I can tell). - FirewallRule.FirewallRuleType.System : this appears to be set up by the system on network creation to correspond to the global network default allow/deny egress rule. - FirewallRule.FirewallRuleType.User : any rule that a user creates through the UI will get this type. There are bugs associated with both of the options in the dropdown (allow and deny). Case: 'deny' - When the network is setup, it does not try to create the global deny rule for the network, but it appears to register that it exists. Instead, when the first egress rule is created by a user, the system sees both the 'system' and 'user' rules, so it will create both rules then. Case: both 'allow' and 'deny' - The clean up of the network global 'system' egress rules are never done. So when a network is deleted, it will leave an orphaned egress rule associated with the previous network's cidr. This is bound to cause many issues. - Even worse, it appears that the ID for the network global 'system' egress rule is hardcoded to '0'. Every time I try to spin up a new network it will attempt to create a rule with a '0' ID, but since one already exists with that ID, there is a config collision. In my case (Palo Alto), the second rule with the same ID gets ignored because it checks to see if the rule exists and it gets a 'yes' back because the previous network has an egress rule with that ID already. Let me know if you have additional questions... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-3190) action events message published on 'event bus' should have the UUID of the entity for which event generated and event type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Ough updated CLOUDSTACK-3190: -- Assignee: Alex Ough action events message published on 'event bus' should have the UUID of the entity for which event generated and event type -- Key: CLOUDSTACK-3190 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3190 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Environment: action events message published on 'event bus' should have the UUID of the entity for which event generated and entity type details. as well Events bus framework with current AMQP default implementation, has routing key with format 'Eventsource.EventCategory.EventType.EntityType.EntityUUID'. For action events, EntityUUDI is not populated. Fix would required to ensure entity UUID is used in forming the routing key. Reporter: Murali Reddy Assignee: Alex Ough Labels: newbie -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5353) [Automation] listVpnUsers API returns null
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk resolved CLOUDSTACK-5353.
---
Resolution: Cannot Reproduce
Rayees, I can't reproduce the bug on the latest 4.3 build
(dd3a511c66709646c38f8acf628fd1087aba36b4). The newly created user is being
returned.
http://localhost:8096/?command=listVpnUserslistall=trueresponse=json{
listvpnusersresponse : { count:1 ,vpnuser : [
{id:e8173453-1ff5-4791-acda-db9869f72669,username:alena,account:admin,domainid:da74616a-4803-11e3-9920-b6bd92a47f90,domain:ROOT,state:Active}
] } }
From the code, I can see that the only situation when user is not returned,
when his state is not Active. Once you see the issue again, check vpn_users DB
table for the user state. If the state is not Active, we might have to debug
to see why the user was created and put in incorrect state. And you will have
to create a new bug if you experience it.
[Automation] listVpnUsers API returns null
---
Key: CLOUDSTACK-5353
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5353
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Management Server
Affects Versions: 4.3.0
Environment: Branch ; 4.3
Reporter: Rayees Namathponnan
Assignee: Alena Prokharchyk
Priority: Blocker
Fix For: 4.3.0
Steps:
***
1.deploy the advance zone with hypervisor as KVM
2.deployvm on new network
3. Acquire new IP
4.enable vpn on Ip
5.create Vpn users
Expected result
Newly created user should be displayed same page
Actual Result
New added user not displayed
also below API call does not return anything
http://10.223.49.195:8096/?command=listVpnUserslistall=true
Firebug
1)
http://10.223.49.195:8080/client/api?command=addVpnUserresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Daccount=admindomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8password=dsdsusername=sddsds
{ addvpnuserresponse :
{id:8cedbb84-e4fa-4508-9465-6ad993377e72,jobid:d3377654-ad52-4b61-b746-525e788224de}
}
2)
http://10.223.49.195:8080/client/api?command=queryAsyncJobResultjobId=d3377654-ad52-4b61-b746-525e788224deresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3D_=1386100530785
{ queryasyncjobresultresponse :
{accountid:d644a994-5bbb-11e3-a447-1a6f7bb0d0a8,userid:d644e0b2-5bbb-11e3-a447-1a6f7bb0d0a8,cmd:org.apache.cloudstack.api.command.user.vpn.AddVpnUserCmd,jobstatus:1,jobprocstatus:0,jobresultcode:0,jobresulttype:object,jobresult:{vpnuser:{id:8cedbb84-e4fa-4508-9465-6ad993377e72,username:sddsds,account:admin,domainid:8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8,domain:ROOT}},created:2013-12-03T11:55:27-0800,jobid:d3377654-ad52-4b61-b746-525e788224de}
3)
http://10.223.49.195:8080/client/api?command=listVpnUsersresponse=jsonsessionkey=RfqSp9FX7ZZhKDOc6CWZLEekFO4%3Ddomainid=8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8account=admin_=1386100530852
_ 1386100530852
account admin
command listVpnUsers
domainid 8c62b19a-5bbb-11e3-a447-1a6f7bb0d0a8
response json
sessionkeyRfqSp9FX7ZZhKDOc6CWZLEekFO4=
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4992) Domain/Account/User Sync Up Among Multiple Regions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839177#comment-13839177 ] Alex Ough commented on CLOUDSTACK-4992: --- After changing codes to master, I found there is an issue blocking this, CLOUDSTACK-3190. Currently, I'm trying to fix the blocker to move on this issue. Domain/Account/User Sync Up Among Multiple Regions -- Key: CLOUDSTACK-4992 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4992 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Alex Ough Assignee: Alex Ough Labels: features Fix For: Future Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. Discussion http://markmail.org/thread/k4x63ef55chcj4y5 Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation of the first approach, master-slave architecture. https://github.com/alexoughsg/albatross -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5276. -- Resolution: Fixed Commit b5527e1f157c7f5701e10f117c1d1e18bdbfee93 in branch refs/heads/4.3 from Brian Federle [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b5527e1 ] CLOUDSTACK-5114: Remove checkbox column from dialog list view ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid. Key: CLOUDSTACK-5276 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: manasaveloori Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: listview.jpg While configuring the portforwarding,LB and static NAT,we need to select the VMs. As per the new UI we are getting two options to select the VMS(listview on left side and individual select option on right side). While selecting the VMs using the listview widget, the rules are not getting applied in VR but just seen in UI.The correct functionality is with right hand side select buttons. I think the listview is not valid under these configuration pages. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839203#comment-13839203 ] ASF subversion and git services commented on CLOUDSTACK-5349: - Commit ee82870aa25b4202d2fbed21a41956cc1870d776 in branch refs/heads/4.3 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ee82870 ] CLOUDSTACK-5349: Volume create usage event and resource count werent getting registered. Check its type rather than it is UserVm since the code is coming from VirtualMachineManager. [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 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: ALL branch 4.3 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-5349. - Resolution: Fixed [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 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: ALL branch 4.3 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5349) [Automation] VOLUME.CREATE missing in events table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839212#comment-13839212 ] ASF subversion and git services commented on CLOUDSTACK-5349: - Commit b0a1528c5a73271ed862e307c9d43a8e6766158d in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b0a1528 ] CLOUDSTACK-5349: Volume create usage event and resource count werent getting registered. Check its type rather than it is UserVm since the code is coming from VirtualMachineManager. [Automation] VOLUME.CREATE missing in events table -- Key: CLOUDSTACK-5349 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5349 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: ALL branch 4.3 Reporter: Rayees Namathponnan Assignee: Nitin Mehta Priority: Blocker Fix For: 4.3.0 # Validate the following # 1. Create a VM. Verify usage_events table contains VM .create, VM.start , Network.offering.assign , Volume.create events # 2. Stop the VM. Verify usage_events table contains network.offerings.remove ,VM .stop Events for the created account. # 3. Destroy the VM after some time. Verify usage_events table containsVM.Destroy and volume .delete Event for the created account # 4. Delete the account VOLUME.CREATE missing in events table, below test case failing due to this integration.component.test_usage.TestVmUsage.test_01_vm_usage mysql select type from usage_event where account_id = '103'; +-+ | type| +-+ | VM.CREATE | | NETWORK.OFFERING.ASSIGN | | VM.START| | SG.ASSIGN | | VM.STOP | | NETWORK.OFFERING.REMOVE | | SG.REMOVE | | VM.DESTROY | | VOLUME.DELETE | +-+ 9 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3027) Object_Store_Refactor - Uploaded template S3 content-type is not appropriate.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839222#comment-13839222 ] Min Chen commented on CLOUDSTACK-3027: -- Hi Thomas, what you have seen is expected behavior. As I mentioned in this bug, the fix is using HEAD content type returned from HttpClient.GetMethod invoked on the URL given for the template to determine what content-type I should send before sending to S3. In your case, the template 1 (system vm template) is automatically downloaded to S3 when you register S3 as secondary storage. I tried localhost:cloud-asf minc$ curl -i -X HEAD http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2 HTTP/1.1 200 OK x-amz-id-2: dm/UlDs7TOFrxJoe7S6wGN5p1a4PuaHgv59/2UH3uySdhZ8S0iYs4ZXD9s+PlfIo x-amz-request-id: BDF70CC804E094C5 Date: Wed, 04 Dec 2013 18:57:18 GMT x-amz-meta-cb-modifiedtime: Mon, 05 Aug 2013 06:50:05 GMT Last-Modified: Mon, 05 Aug 2013 06:51:43 GMT ETag: 5e8f4deb290e1fbd2585fee7ded761fe-27 Accept-Ranges: bytes Content-Type: application/octet-stream Content-Length: 223003018 Server: AmazonS3 As you can see, application/octet-stream is given by the server which hosts this template file. For template 2, it is downloaded to S3 during template sync when secondary storage is up and running. The URL in the DB for this template is http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd. If you run curl HEAD command on this url, you will see that its content-type returned is text/plain, which may be wrong, but we have no control on that. For your template 3, it seems that your server which hosts ttylinux_pv.vhd returns application/octet-stream as its content-type, so we can set correctly. Object_Store_Refactor - Uploaded template S3 content-type is not appropriate. - Key: CLOUDSTACK-3027 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3027 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Environment: latest object_store branch on fedora 17 devcloud on same machine Cloudian (for S3 services) on separate machine. (expect similar result with other S3 object stores). Reporter: Thomas O'Dowd Assignee: Min Chen Fix For: 4.3.0 This bug is related to the object_store branch. Steps: 1. setup S3 object storage (can be amazon) 2. Add S3 as secondary storage 3. Upload a new template (I uploaded tinyLinux.vhd.gz) by giving a url on my local network where I had it hosted. 4. The template will be uploaded to S3. Next using s3cmd or other tool, have a look at the Content-Type of the object that is stored by issuing either a HEAD or a GET request on that object. Here is what I got when i captured the HEAD request using ngrep. === HEAD request and response === HEAD /template/tmpl/2/201/201-2-f9a12429-7cf4-3df5-b81c-420f09c1bbcd/tinyLinux.vhd.gz HTTP/1.1. Host: hello.s3.cloudian.com:18080. Accept-Encoding: identity. Date: Mon, 17 Jun 2013 05:06:19 GMT. Content-Length: 0. Authorization: AWS 00d25034c817eeb8c095:g/S63k9LHeZfz73l+moWm7MJ7z0=. User-Agent: Boto/2.9.4 (linux2). . ## T 10.181.164.132:18080 - 10.181.164.198:50450 [AP] HTTP/1.1 200 OK. Date: Mon, 17 Jun 2013 05:06:19 GMT. x-amz-request-id: A55A3220D70B11E2. Last-Modified: Fri, 14 Jun 2013 07:05:27 GMT. ETag: 5b5c3506aef231519d0434f9749c951d-5. Content-Type: application/x-www-form-urlencoded; charset=utf-8. Content-Length: 25712307. === end of HEAD request and response = Notice in the HTTP response that the Content-Type header is set to application/x-www-form-urlencoded; charset=utf-8. This does not correctly describe the template content type. The Content-Type was set by the client (Cloudstack) in the Multipart Upload Initiate request at the beginning of the upload and should be fixed at that point. I haven't looked at the code but perhaps we need to set a header or add another parameter when initiating the multipart upload. Of course, this begs the question... well what is the correct content type? I looked around to see if I could find one for .vhd files but with no luck. Perhaps application/octet-stream or even application/x-gzip (as this particular object is compressed). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-3027) Object_Store_Refactor - Uploaded template S3 content-type is not appropriate.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-3027. -- Resolution: Fixed Object_Store_Refactor - Uploaded template S3 content-type is not appropriate. - Key: CLOUDSTACK-3027 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3027 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.2.0 Environment: latest object_store branch on fedora 17 devcloud on same machine Cloudian (for S3 services) on separate machine. (expect similar result with other S3 object stores). Reporter: Thomas O'Dowd Assignee: Min Chen Fix For: 4.3.0 This bug is related to the object_store branch. Steps: 1. setup S3 object storage (can be amazon) 2. Add S3 as secondary storage 3. Upload a new template (I uploaded tinyLinux.vhd.gz) by giving a url on my local network where I had it hosted. 4. The template will be uploaded to S3. Next using s3cmd or other tool, have a look at the Content-Type of the object that is stored by issuing either a HEAD or a GET request on that object. Here is what I got when i captured the HEAD request using ngrep. === HEAD request and response === HEAD /template/tmpl/2/201/201-2-f9a12429-7cf4-3df5-b81c-420f09c1bbcd/tinyLinux.vhd.gz HTTP/1.1. Host: hello.s3.cloudian.com:18080. Accept-Encoding: identity. Date: Mon, 17 Jun 2013 05:06:19 GMT. Content-Length: 0. Authorization: AWS 00d25034c817eeb8c095:g/S63k9LHeZfz73l+moWm7MJ7z0=. User-Agent: Boto/2.9.4 (linux2). . ## T 10.181.164.132:18080 - 10.181.164.198:50450 [AP] HTTP/1.1 200 OK. Date: Mon, 17 Jun 2013 05:06:19 GMT. x-amz-request-id: A55A3220D70B11E2. Last-Modified: Fri, 14 Jun 2013 07:05:27 GMT. ETag: 5b5c3506aef231519d0434f9749c951d-5. Content-Type: application/x-www-form-urlencoded; charset=utf-8. Content-Length: 25712307. === end of HEAD request and response = Notice in the HTTP response that the Content-Type header is set to application/x-www-form-urlencoded; charset=utf-8. This does not correctly describe the template content type. The Content-Type was set by the client (Cloudstack) in the Multipart Upload Initiate request at the beginning of the upload and should be fixed at that point. I haven't looked at the code but perhaps we need to set a header or add another parameter when initiating the multipart upload. Of course, this begs the question... well what is the correct content type? I looked around to see if I could find one for .vhd files but with no luck. Perhaps application/octet-stream or even application/x-gzip (as this particular object is compressed). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5050) [Automation] Failed to attach ISO to running vm with NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen reassigned CLOUDSTACK-5050:
Assignee: Min Chen (was: edison su)
[Automation] Failed to attach ISO to running vm with NPE
Key: CLOUDSTACK-5050
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5050
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: ISO
Affects Versions: 4.3.0
Environment: KVM
branch : master
Reporter: Rayees Namathponnan
Assignee: Min Chen
Priority: Blocker
Fix For: 4.3.0
Attachments: CLOUDSTACK-5050.rar
BVT failure
integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
Steps to reproduce
1) register ISO http://people.apache.org/~tsp/dummy.iso
2) Deploy VM
3 ) Attach ISO to running
ISO attach failed with NPE
2013-11-05 15:52:29,213 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-134:ctx-57b6c4c6) Executing AsyncJobVO {id:317, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd: org.apache
.cloudstack.api.command.user.iso.AttachIsoCmd, cmdInfo:
{id:579c330e-06bf-4911-887a-fb5146af9aad,response:json,sessionkey:vw2jRz7SFgLbxiXNx8E0BUF7mO4\u003d,virtualmachineid:63de9e37-cf3f-4f
f1-8175-f12d224a2a24,cmdEventType:ISO.ATTACH,ctxUserId:2,httpmethod:GET,_:1383695548497,ctxAccountId:2,ctxStartEventId:2626},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 29066118877352, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-11-05 15:52:29,217 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-14:ctx-865f8152 ctx-93cf9205) submit async job-317, details:
AsyncJobVO {id:317, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd:
org.apache.cloudstack.api.command.user.iso.AttachIsoCmd, cmdInfo:
{id:579c330e-06bf-4911-887a-fb5146af9aad,response:json,sessionkey:vw2jRz7SFgLbxiXNx8E0BUF7mO4\u003d,v
irtualmachineid:63de9e37-cf3f-4ff1-8175-f12d224a2a24,cmdEventType:ISO.ATTACH,ctxUserId:2,httpmethod:GET,_:1383695548497,ctxAccountId:2,ctxStartEventId:2626},
cmdVersion: 0, stat
us: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid:
29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2013-11-05 15:52:29,218 DEBUG [c.c.a.ApiServlet]
(catalina-exec-14:ctx-865f8152 ctx-93cf9205) ===END=== 10.214.5.33 -- GET
command=attachIsovirtualmachineid=63de9e37-cf3f-4ff1-8175-f12d224a2a24id=579c
330e-06bf-4911-887a-fb5146af9aadresponse=jsonsessionkey=vw2jRz7SFgLbxiXNx8E0BUF7mO4%3D_=1383695548497
2013-11-05 15:52:29,232 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-134:ctx-57b6c4c6) Unexpected exception while executing
org.apache.cloudstack.api.command.user.iso.AttachIsoCmd
java.lang.NullPointerException
at
com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:383)
at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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 $Proxy82.checkAccess(Unknown Source)
at
com.cloud.template.TemplateManagerImpl.attachIso(TemplateManagerImpl.java:973)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.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] [Assigned] (CLOUDSTACK-5268) [Automation] There is no option to create snapshot from volume of running vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-5268: Assignee: Min Chen (was: edison su) [Automation] There is no option to create snapshot from volume of running vm - Key: CLOUDSTACK-5268 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5268 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Environment: KVM Branch 4.3 Reporter: Rayees Namathponnan Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 Steps to reproduce Step 1 : Deploy VM Step 2 : Once VM is up, select the root volume Step 3 : Create snapshot Actual Result There is no option to create snapshot from volume; you need to stop vm first to create snapshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5152) Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839257#comment-13839257 ] ASF subversion and git services commented on CLOUDSTACK-5152: - Commit 06d2e768b61890f69daa197f64d9fb4991523792 in branch refs/heads/4.3 from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06d2e76 ] CLOUDSTACK-5152: when deployVm with SG, verify that vm and sg belong to the same account. Do this verification even when the call is done by the ROOT admin Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account) Key: CLOUDSTACK-5152 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5152 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 In basic zone, Create an account and a project in that account. Create a security group which belongs to this project. Try to deploy VM using this security group outside the project. Creation of VM is successful and if you list the virtual machines, in response it will show the security group in the sec groups list and it will show the account of security group as the account in which you have deployed the instance (instead it should list the project to which security group belongs) This is an issue, security group belonging to a project should not be allowed to be used outside the project. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4224) UCS:UI: Delete UCS returns unknown API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839265#comment-13839265 ] ASF subversion and git services commented on CLOUDSTACK-4224: - Commit d4b068d2d885964eb69b73961709ab438d3fbbda in branch refs/heads/4.3 from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d4b068d ] CloudStack CLOUDSTACK-4224 UCS:UI: Delete UCS returns unknown API UCS:UI: Delete UCS returns unknown API -- Key: CLOUDSTACK-4224 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4224 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, UCS, UI Affects Versions: 4.2.0 Reporter: Parth Jagirdar Assignee: frank zhang Priority: Critical Attachments: delete UCS.jpeg Please refer to screen. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5370) Xenserver - Snapshots - vhd entries get accumulated on the primary store when snapshot creation fails becasue of not being able to reach the secondary store.
Sangeetha Hariharan created CLOUDSTACK-5370: --- Summary: Xenserver - Snapshots - vhd entries get accumulated on the primary store when snapshot creation fails becasue of not being able to reach the secondary store. Key: CLOUDSTACK-5370 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5370 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: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Set up: Advanced Zone with 2 Xenserver 6.2 hosts: 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Start concurrent snapshots for ROOT volumes of all the Vms. 3. Shutdown the Secondary storage server when the snapshots are in the progress. ( In my case i stopped the nfs server) 4. Bring the Secondary storage server up after 12 hours. ( In my case started the nfs server). When secondary server was down (NFS server down) for about 12 hours , I see that hourly snapshots get attempted every hour and fail with “CreatedOnPrimary state . I see many entries being created on the primary store ( I see 120 entries , but I have only 14 vms). We accumulate 2 vhd files on the primary store for every snapshot that is attempted. When secondary store is brought up , and when another snapshot is attempted and it succeeds, we see the vhd files are all being cleared out. This is a problem that we accumulate so many vhd files ( In case of vmware and kvm where there are no delta snapshots this size would be significantly higher) on primary store. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5152) Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839288#comment-13839288 ] ASF subversion and git services commented on CLOUDSTACK-5152: - Commit f1973340d30042ae39c7465adfbc5a9537b3e3fa in branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f197334 ] CLOUDSTACK-5152: when deployVm with SG, verify that vm and sg belong to the same account. Do this verification even when the call is done by the ROOT admin Conflicts: server/src/com/cloud/user/AccountManagerImpl.java Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account) Key: CLOUDSTACK-5152 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5152 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 In basic zone, Create an account and a project in that account. Create a security group which belongs to this project. Try to deploy VM using this security group outside the project. Creation of VM is successful and if you list the virtual machines, in response it will show the security group in the sec groups list and it will show the account of security group as the account in which you have deployed the instance (instead it should list the project to which security group belongs) This is an issue, security group belonging to a project should not be allowed to be used outside the project. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5152) Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-5152. --- Resolution: Fixed Basic Zone - Security group belonging to a project can be used to deploy VM outside the project (in same account, and also in different account) Key: CLOUDSTACK-5152 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5152 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 In basic zone, Create an account and a project in that account. Create a security group which belongs to this project. Try to deploy VM using this security group outside the project. Creation of VM is successful and if you list the virtual machines, in response it will show the security group in the sec groups list and it will show the account of security group as the account in which you have deployed the instance (instead it should list the project to which security group belongs) This is an issue, security group belonging to a project should not be allowed to be used outside the project. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5368) ListViews marked with 'needsRefresh' do not have loading overlay removed on error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich resolved CLOUDSTACK-5368. - Resolution: Fixed ListViews marked with 'needsRefresh' do not have loading overlay removed on error - Key: CLOUDSTACK-5368 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5368 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Chris Suich Fix For: 4.3.0 ListView actions marked with 'needsRefresh' add a loading overlay before the action is performed. If the operation succeeds, the overlay is properly removed. If it fails, the overlay is NOT removed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5371) Maitenance mode for secondary store.
Sangeetha Hariharan created CLOUDSTACK-5371: --- Summary: Maitenance mode for secondary store. Key: CLOUDSTACK-5371 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5371 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: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Set up: Advanced Zone with 2 Xenserver 6.2 hosts: 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we start with 10 Vms. 2. Start concurrent snapshots for ROOT volumes of all the Vms by creating hourly snapshots. 3. Shutdown the Secondary storage server when the snapshots are in the progress. ( In my case i stopped the nfs server) 4. Bring the Secondary storage server up after 12 hours. ( In my case started the nfs server). When secondary server was down (NFS server down) for about 12 hours , I see that hourly snapshots get attempted every hour and fail with “CreatedOnPrimary state . I see many entries ( 2 per failed snapshot attempt) being created on the primary store. In such cases , if the admin is aware of connectivity issues/ running out of disk space on secondary store , he should be able to set “Maintenance Mode” for secondary store , so that we have to ability to not even attempt snapshots instead of attempting and failing and leaving behind snapshots in failed state. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839388#comment-13839388 ] ASF subversion and git services commented on CLOUDSTACK-5200: - Commit 19e855e5dca314ac119646da12029d843eba376a in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=19e855e ] CLOUDSTACK-5200: UI Infrastructure Sockets listView fix a bug that Hosts and Sockets displayed wrong number. UI displays wrong values for the socket information and number of hosts. Key: CLOUDSTACK-5200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Kiran Koneti Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: Socket_info.jpg In the infrastructure tab view of the CS when we click the Sockets tab it always displays a constant value of 3 for all the hosts and unknown under the sockets value.In my current setup i have only one Xen server with single socket but it still shows the same value. The api output displays the correct value but the UI has the different value. The API output is as below: listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT count1/count host idb7d32c8c-9872-4b74-864b-665e65d46442/id nameRack1Pod1Host9/name stateUp/state typeRouting/type ipaddress10.147.40.9/ipaddress zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid zonenameZ1/zonename podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid podnamePod1/podname version4.3.0-SNAPSHOT/version hypervisorXenServer/hypervisor cpusockets1/cpusockets cpunumber4/cpunumber cpuspeed2394/cpuspeed cpuallocated0%/cpuallocated cpuused0.06%/cpuused cpuwithoverprovisioning9576.0/cpuwithoverprovisioning networkkbsread3976/networkkbsread networkkbswrite24403/networkkbswrite memorytotal16001266176/memorytotal memoryallocated2550136832/memoryallocated memoryused3687684/memoryused capabilities xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64 /capabilities lastpinged1970-01-16T21:08:33+0530/lastpinged managementserverid7614406590488/managementserverid clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid clusternameC1/clustername clustertypeCloudManaged/clustertype islocalstorageactivefalse/islocalstorageactive created2013-11-18T15:34:31+0530/created events AgentConnected; HostDown; AgentDisconnected; PingTimeout; StartAgentRebalance; ShutdownRequested; Remove; ManagementServerDown; Ping /events resourcestateEnabled/resourcestate hypervisorversion6.2.0/hypervisorversion hahostfalse/hahost /host /listhostsresponse Attaching the UI screen shot for the same. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839389#comment-13839389 ] ASF subversion and git services commented on CLOUDSTACK-5200: - Commit 4e7487366968578f5e9418c92208f12b5775580b in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e74873 ] CLOUDSTACK-5200: UI Infrastructure Sockets listView fix a bug that Hosts and Sockets displayed wrong number. UI displays wrong values for the socket information and number of hosts. Key: CLOUDSTACK-5200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Kiran Koneti Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: Socket_info.jpg In the infrastructure tab view of the CS when we click the Sockets tab it always displays a constant value of 3 for all the hosts and unknown under the sockets value.In my current setup i have only one Xen server with single socket but it still shows the same value. The api output displays the correct value but the UI has the different value. The API output is as below: listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT count1/count host idb7d32c8c-9872-4b74-864b-665e65d46442/id nameRack1Pod1Host9/name stateUp/state typeRouting/type ipaddress10.147.40.9/ipaddress zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid zonenameZ1/zonename podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid podnamePod1/podname version4.3.0-SNAPSHOT/version hypervisorXenServer/hypervisor cpusockets1/cpusockets cpunumber4/cpunumber cpuspeed2394/cpuspeed cpuallocated0%/cpuallocated cpuused0.06%/cpuused cpuwithoverprovisioning9576.0/cpuwithoverprovisioning networkkbsread3976/networkkbsread networkkbswrite24403/networkkbswrite memorytotal16001266176/memorytotal memoryallocated2550136832/memoryallocated memoryused3687684/memoryused capabilities xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64 /capabilities lastpinged1970-01-16T21:08:33+0530/lastpinged managementserverid7614406590488/managementserverid clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid clusternameC1/clustername clustertypeCloudManaged/clustertype islocalstorageactivefalse/islocalstorageactive created2013-11-18T15:34:31+0530/created events AgentConnected; HostDown; AgentDisconnected; PingTimeout; StartAgentRebalance; ShutdownRequested; Remove; ManagementServerDown; Ping /events resourcestateEnabled/resourcestate hypervisorversion6.2.0/hypervisorversion hahostfalse/hahost /host /listhostsresponse Attaching the UI screen shot for the same. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5200. -- Resolution: Fixed UI displays wrong values for the socket information and number of hosts. Key: CLOUDSTACK-5200 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Kiran Koneti Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: Socket_info.jpg In the infrastructure tab view of the CS when we click the Sockets tab it always displays a constant value of 3 for all the hosts and unknown under the sockets value.In my current setup i have only one Xen server with single socket but it still shows the same value. The api output displays the correct value but the UI has the different value. The API output is as below: listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT count1/count host idb7d32c8c-9872-4b74-864b-665e65d46442/id nameRack1Pod1Host9/name stateUp/state typeRouting/type ipaddress10.147.40.9/ipaddress zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid zonenameZ1/zonename podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid podnamePod1/podname version4.3.0-SNAPSHOT/version hypervisorXenServer/hypervisor cpusockets1/cpusockets cpunumber4/cpunumber cpuspeed2394/cpuspeed cpuallocated0%/cpuallocated cpuused0.06%/cpuused cpuwithoverprovisioning9576.0/cpuwithoverprovisioning networkkbsread3976/networkkbsread networkkbswrite24403/networkkbswrite memorytotal16001266176/memorytotal memoryallocated2550136832/memoryallocated memoryused3687684/memoryused capabilities xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64 /capabilities lastpinged1970-01-16T21:08:33+0530/lastpinged managementserverid7614406590488/managementserverid clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid clusternameC1/clustername clustertypeCloudManaged/clustertype islocalstorageactivefalse/islocalstorageactive created2013-11-18T15:34:31+0530/created events AgentConnected; HostDown; AgentDisconnected; PingTimeout; StartAgentRebalance; ShutdownRequested; Remove; ManagementServerDown; Ping /events resourcestateEnabled/resourcestate hypervisorversion6.2.0/hypervisorversion hahostfalse/hahost /host /listhostsresponse Attaching the UI screen shot for the same. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839387#comment-13839387 ] ASF subversion and git services commented on CLOUDSTACK-5352: - Commit e85334ff515b6e640d61666998a08774ddcfb9f3 in branch refs/heads/4.3 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e85334f ] CLOUDSTACK-5352: CPU cap calculated incorrectly for VMs on XenServer hosts. It should not be limited by the overprovisioning and should set the cap as service offering CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5267: --- Assignee: Girish Shilamkar [Automation] instance.name name should not append with VM's Name Key: CLOUDSTACK-5267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Branch : 4.3.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Priority: Blocker Labels: automation Fix For: 4.3.0 Steps to reproduce Step 1 : set instance.name=TestVM in global parameter Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the VM Actual Result UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be deployed with name 56276ab1-3353-473c-8b35-f27f81f68bd8 vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here instance.name also included We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5191) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5191: --- Assignee: Girish Shilamkar [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed -- Key: CLOUDSTACK-5191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5191 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Labels: automation,, product, x Fix For: 4.3.0 Test case integration.component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failed in KVM basic zone setup Test cases failed while ping outside from VM, observed below error in log Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py, line 1067, in test_revoke_egress_rule Ping to outside world from VM should be successful File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Ping to outside world from VM should be successful begin captured logging test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Created security group with ID: 020865e7-d87b-4da9-b157-c315dc42e33d test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing ingress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing egress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Deploying VM in account: test-TestStartStopVMWithEgressRule-test_multiple_account_egress_rule_negative-Q4UAPL test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: SSH into VM: 10.223.250.230 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 paramiko.transport: DEBUG: starting thread (client mode): 0xd9d0ad0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.250.230: 0f8b3ff9dc4dce10340227dab3cac032 paramiko.transport: DEBUG: Trying discovered key a0114fddd71936946702c57069b4175b in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO:
[jira] [Updated] (CLOUDSTACK-5362) [Hyper-v] System vms does not come up with CIFS as the shared primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5362:
---
Assignee: Devdeep Singh
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
-
Key: CLOUDSTACK-5362
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5362
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Latest build from 4.3
Storage: CIFS for both primary and secondary storage
Hypervisor: Hyperv
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: cloudstack-agent.rar, management-server.rar
[Hyper-v] System vms does not come up with CIFS as the shared primary storage
Steps to Reproduce:
1.Bring up CS in advanced zone using CIFS as the storage for both primary and
secondary with latest build from 4.3
2.Enable zone
Expected Result:
==
System vms (SSVM,CPVM) should come up without any issues
Actual Result:
===
System vms failed to come up
Observations:
Root disks for both ssvm and cpvm got created in the shared primary storage.
However vms start failed with the following error:
2013-12-04 07:50:47,399 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-26:ctx-50ca2fd8) Sending cmd to
http://10.147.40.14:8250/api/HypervResource/com.cloud.agent.api.StartCommand
cmd
data:{vm:{id:2,name:v-2-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:i686,os:Debian
GNU/Linux 5.0 (32-bit),bootArgs: template\u003ddomP
type\u003dconsoleproxy host\u003d10.147.59.119 port\u003d8250
name\u003dv-2-VM premium\u003dtrue zone\u003d1 pod\u003d1 guid\u003dProxy.2
proxy_vm\u003d2 disable_rp_filter\u003dtrue eth2ip\u003d10.147.48.22
eth2mask\u003d255.255.255.0 gateway\u003d10.147.48.1 eth0ip\u003d169.254.3.44
eth0mask\u003d255.255.0.0 eth1ip\u003d10.147.40.233
eth1mask\u003d255.255.254.0 mgmtcidr\u003d10.147.59.0/24
localgw\u003d10.147.40.1 internaldns1\u003d10.140.50.6
dns1\u003d10.140.50.6,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:60432484c5722fb2,params:{},uuid:f22fa132-7b2e-4fc2-aadc-f679ff5bc848,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2a7f9126-5115-4d29-aade-b45bdc4eefba,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fdd42fec-0e2e-32fe-adff-0d09bc73e8af,id:1,poolType:NetworkFilesystem,host:10.102.192.19,path:/HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR,port:445,url:NetworkFilesystem://10.102.192.19//HYPERV-SMB/sanjeev-pri?user\u003dabhinav\u0026password\u003dfreebsd@123\u0026domain\u003dBLR/?ROLE\u003dPrimary\u0026STOREUUID\u003dfdd42fec-0e2e-32fe-adff-0d09bc73e8af}},name:ROOT-2,size:0,volumeId:2,vmName:v-2-VM,accountId:1,id:2,deviceId:0,hypervisorType:Hyperv}},diskSeq:0,type:ROOT,_details:{managed:false,storagePort:445,storageHost:10.102.192.19,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:c3cfb829-8964-4efd-b52c-da029d5ce326,ip:10.147.48.22,netmask:255.255.255.0,gateway:10.147.48.1,mac:06:8f:72:00:00:0c,dns1:10.140.50.6,broadcastType:Vlan,type:Public,broadcastUri:vlan://48,isolationUri:vlan://48,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:6f3a7adf-c403-4503-85b3-5b4d349f0579,ip:169.254.3.44,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:2c,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:e70d802c-0844-4fc7-89dc-66d1d4aa82d8,ip:10.147.40.233,netmask:255.255.254.0,gateway:10.147.40.1,mac:06:f4:8e:00:00:03,broadcastType:Native,type:Management,isSecurityGroupEnabled:false}]},hostIp:10.147.40.14,executeInSequence:false,contextMap:{},wait:0}
2013-12-04 07:50:50,929 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-12:ctx-c9224f52) POST response
is[{com.cloud.agent.api.StartAnswer:{result:false,details:com.cloud.agent.api.StartCommand
fail on exceptionHyper-V Job failed, Error Code:32768, Description: 's-4-VM'
failed to add device 'Virtual Hard Disk'. (Virtual machine ID
7224DA02-67DF-46A7-9425-3DE9D6BAD26E)\n\nFailed to open attachment
'10.102.192.19\\HYPERV-SMB\\sanjeev-pri\\ROOT-4.vhd'. Error: 'The user
name or password is
[jira] [Updated] (CLOUDSTACK-5344) [Hyper-V] Console access does not work for any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5344: --- Assignee: Devdeep Singh [Hyper-V] Console access does not work for any VM - Key: CLOUDSTACK-5344 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5344 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Assignee: Devdeep Singh Priority: Blocker Labels: hyper-V, Fix For: 4.3.0 [Hyperv-V] Console access does not work for any VM Steps to Reproduce: 1.Bring up CS with latest build from 4.3 using hyperv 2.Wait for the CPVM to come up. 3.Deploy guest vm and try to access the vm's console Result: === Server Internal Error -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5365) [Hyper-V] VR's control IP is not accessible from mgmt server, which results in VR start up failure
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5365:
---
Assignee: Devdeep Singh
[Hyper-V] VR's control IP is not accessible from mgmt server, which results
in VR start up failure
--
Key: CLOUDSTACK-5365
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5365
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
Environment: Build with commit
2d90ee469a047e8b42dd81f3723240f18b591d5e from 4.3
Zone: Advanced
Storage: Local for system vms ,cifs for guest and cifs for secondary
Hypervisor: Hyperv
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Blocker
Labels: hyper-V,
Fix For: 4.3.0
Attachments: cloud.dmp, cloudstack-agent.rar, management-server.rar
[Hyper-V] VR's control IP is not accessible from mgmt server, which results
in VR start up failure
Steps to Reproduce:
1.Bring up CS in advanced zone with at-least one hyper-v host in the cluster
2.Register one cent os template
3.Try to deploy guest vm with the above template in an isolated network
Expected Result:
==
VR and guest vm should come up in the isolated network successfully
Actual Result:
===
VR failed to come up hence the guest vm deployment failed
Observations:
Initially VR booted up and configured with guest,control and public IP
addresses on eth0,eth1,eth2 inerfaces respectively.
As part of VR bring up process, mgmt server tried to ping/check the template
version on VR using its control IP to confirm the VR boot up. However mgmt
server failed to communicate with VRs control IP address. So it is stopping
the VR.
In another 4.3 setup I have added vmware cluster and tried the above
scenario. There mgmt server was able to communicate with VR on control ip
address and VR came up successfully.
Log snippet from agent log:
==
2013-12-04 04:14:54,275 [14] INFO HypervResource.WmiCallsV2
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - Started VM r-8-VM
2013-12-04 04:14:54,275 [14] INFO HypervResource.HypervResourceController
[fcfffec6-3b06-4bda-b22c-afa6c2014803] - {
com.cloud.agent.api.StartAnswer: {
result: true,
details: null,
vm: {
id: 8,
name: r-8-VM,
type: DomainRouter,
cpus: 1,
minSpeed: 500,
maxSpeed: 500,
minRam: 134217728,
maxRam: 134217728,
arch: i686,
os: Debian GNU/Linux 5.0 (32-bit),
bootArgs: template=domP name=r-8-VM eth2ip=10.147.48.23
eth2mask=255.255.255.0 gateway=10.147.48.1 eth0ip=10.1.1.1
eth0mask=255.255.255.0 domain=cs2cloud.internal dhcprange=10.1.1.1
eth1ip=10.147.40.238 eth1mask=255.255.254.0 type=router
disable_rp_filter=true dns1=10.140.50.6 dns2=,
rebootOnCrash: false,
enableHA: true,
limitCpuUse: false,
enableDynamicallyScaleVm: false,
vncPassword: 33c76dca072011e6,
params: {},
uuid: 33b6472e-67cd-4aee-8556-b22d6e57d44b,
disks: [
{
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 9c48b406-b424-4b77-ae37-37248b454d0f,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid:
20de3206-3585-3bb0-b536-a96b665df206-HypervResource,
id: 2,
poolType: Filesystem,
host: 10.147.40.14,
path: C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard Disks,
port: 0,
url:
Filesystem://10.147.40.14/C:\\Users\\Public\\Documents\\Hyper-V\\Virtual
Hard
Disks/?ROLE=PrimarySTOREUUID=20de3206-3585-3bb0-b536-a96b665df206-HypervResource
}
},
name: ROOT-8,
size: 2101252608,
volumeId: 8,
vmName: r-8-VM,
accountId: 2,
id: 8,
deviceId: 0,
hypervisorType: Hyperv
}
},
diskSeq: 0,
type: ROOT,
_details: {
managed: false,
storagePort: 0,
storageHost: 10.147.40.14,
volumeSize: 2101252608
}
}
],
nics: [
{
deviceId: 2,
networkRateMbps: 200,
defaultNic: true,
uuid: 645d73f8-ea2b-4329-9946-140c12059805,
[jira] [Updated] (CLOUDSTACK-5340) [Hyper-V] Control IPs are not getting released when VRs are in stopped state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5340: --- Assignee: Devdeep Singh [Hyper-V] Control IPs are not getting released when VRs are in stopped state Key: CLOUDSTACK-5340 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5340 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, Network Controller Affects Versions: 4.3.0 Environment: Latest build from 4.3 Reporter: Sanjeev N Assignee: Devdeep Singh Priority: Critical Fix For: 4.3.0 Attachments: management-server.log.2013-12-02.gz [Hyper-V] Control IPs are not getting released when VRs are in stopped state Steps to Reproduce: = 1.Bring up Advanced zone with Hyperv using latest 4.3 build 2.Implement network and make sure Vr is in running state 3.Stop,start VR multiple times. Expected Result: == Each time VR is stopped, control IP should be released to the pool and when the VR is started again it should get one ip address from the pool. Actual Result: === When the VR is stopped, control IP is not getting released to the pool. It remains in the reserved state. Currently in the setup there are only 5 system vms (SSVM,CPVM,3VRs) are there. So in total there should be only 6 controls IPs in reserved state.However op_dc_ip_address_alloc tables shows only one IP in free state out of 10 Pod Ip addresses. mysql select * from op_dc_ip_address_alloc; ++---++++--+-+-+ | id | ip_address| data_center_id | pod_id | nic_id | reservation_id | taken | mac_address | ++---++++--+-+-+ | 1 | 10.147.40.231 | 1 | 1 | 7 | 2709a8d9-71af-4c9b-9139-75e47aad6c76 | 2013-12-02 10:38:36 | 1 | | 2 | 10.147.40.232 | 1 | 1 | NULL | NULL | NULL| 2 | | 3 | 10.147.40.233 | 1 | 1 | 15 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:37 | 3 | | 4 | 10.147.40.234 | 1 | 1 | 23 | 1a1d5501-5e94-46b0-a770-af6277715f74 | 2013-12-02 17:15:05 | 4 | | 5 | 10.147.40.235 | 1 | 1 | 18 | 02e7a340-d1f3-46ab-adb9-dd91c3549d30 | 2013-12-02 15:44:13 | 5 | | 6 | 10.147.40.236 | 1 | 1 | 28 | 762014f4-fcd8-41d9-906c-1b05dbf07df7 | 2013-12-02 17:54:00 | 6 | | 7 | 10.147.40.237 | 1 | 1 | 18 | ced340b8-a34e-43fe-829e-7b790e380387 | 2013-12-02 15:25:37 | 7 | | 8 | 10.147.40.238 | 1 | 1 | 14 | 2f25a307-9b87-44ae-a6a0-0f97dceada4b | 2013-12-02 10:38:36 | 8 | | 9 | 10.147.40.239 | 1 | 1 | 23 | c2e2d7b1-4b4f-48da-b9ba-a8e64255711b | 2013-12-02 17:36:45 | 9 | | 10 | 10.147.40.240 | 1 | 1 | 18 | cb036c69-1721-4d13-b61d-42b6f2e7a76c | 2013-12-02 17:50:20 | 10 | ++---++++--+-+-+ 10 rows in set (0.00 sec) mysql select id,name,state from vm_instance where removed is null and vm_type!='User'; ++-+--+ | id | name| state| ++-+--+ | 2 | v-2-VM | Running | | 4 | s-4-VM | Running | | 6 | r-6-VM | Stopped | | 9 | r-9-VM | Stopped | | 11 | r-11-VM | Starting | ++-+--+ 5 rows in set (0.00 sec) Attaching management server log file with this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839437#comment-13839437 ] ASF subversion and git services commented on CLOUDSTACK-5352: - Commit fee41bad417cc34d3cf5df8fb7f691ec4f6d7edf in branch refs/heads/4.3 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fee41ba ] CLOUDSTACK-5352: CPU cap calculated incorrectly for VMs on XenServer hosts. It should not be limited by the overprovisioning and should set the cap as service offering CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5251) No Error message is displayed when nonexistent NFS secondary storage is added to CS.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-5251:
-
Assignee: edison su (was: Alena Prokharchyk)
Edison, related to your image store feature. Please fix it so the error
returned by the backend, is treated as an error to the API. Also we have to add
more logging, currently its hard to track the errors by the job-id
No Error message is displayed when nonexistent NFS secondary storage is
added to CS.
-
Key: CLOUDSTACK-5251
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5251
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: manasaveloori
Assignee: edison su
Fix For: 4.3.0
Attachments: management-server.log
Steps:
1.Deploy a CS .
2.After the UI comes up,try to add the another NFS secondary storage
which is not existing in the path added.
Observation:
Secondary storage got added in the UI .
Observing the below Debug messages and not ERROR messages in log:
2013-11-25 07:47:28,352 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-a89b587d) ===START=== 10.252.192.19 -- GET
command=addImageStoreresponse=jsonsessionkey=pDnp1RLy0kkw5icS9lA1JS34SR8%3Dname=test5provider=NFSzoneid=79124a51-3510-4bf7-b17c-4b8e4818b515url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Fmanasa%2Fdummy_=1385364241867
2013-11-25 07:47:28,367 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl]
(catalina-exec-18:ctx-a89b587d ctx-8dbd09ee) Trying to add a new data store
at nfs://10.147.28.7/export/home/manasa/dummy to data center 1
2013-11-25 07:47:28,480 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-a89b587d ctx-8dbd09ee) ===END=== 10.252.192.19 -- GET
command=addImageStoreresponse=jsonsessionkey=pDnp1RLy0kkw5icS9lA1JS34SR8%3Dname=test5provider=NFSzoneid=79124a51-3510-4bf7-b17c-4b8e4818b515url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Fmanasa%2Fdummy_=1385364241867
2013-11-25 07:47:33,608 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-325: Processing Seq 5-325: { Cmd ,
MgmtId: -1, via: 5, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:7,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-11-25 07:47:33,618 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) SeqA 5-325: Sending Seq 5-325: { Ans: ,
MgmtId: 6758231703598, via: 5, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-11-25 07:47:38,911 DEBUG [c.c.s.StatsCollector]
(StatsCollector-3:ctx-ca134799) StorageCollector is running...
2013-11-25 07:47:38,988 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-ca134799) Seq 4-628555880: Received: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
2013-11-25 07:48:39,942 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-0b21c1ed) Seq 4-628555883: Received: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
2013-11-25 07:48:40,038 DEBUG [c.c.a.t.Request]
(AgentManager-Handler-15:null) Seq 4-628555884: Processing: { Ans: , MgmtId:
6758231703598, via: 4, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for nfs://10.147.28.7/export/home/manasa/sectest failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to mount
10.147.28.7:/export/home/manasa/sectest at
/mnt/SecStorage/5885435a-769d-360d-87fa-63f1a925e11b due to mount.nfs:
mounting 10.147.28.7:/export/home/manasa/sectest failed, reason given by
server: No such file or directory\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1939)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:1692)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:216)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
[jira] [Created] (CLOUDSTACK-5372) Xenserver - SR not being recreated when the Primary storage is brought down and brought back up again resulting in not being able to start the Vms that have their vo
Sangeetha Hariharan created CLOUDSTACK-5372:
---
Summary: Xenserver - SR not being recreated when the Primary
storage is brought down and brought back up again resulting in not being able
to start the Vms that have their volumes in this primary store.
Key: CLOUDSTACK-5372
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5372
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: Build from 4.3
Reporter: Sangeetha Hariharan
Priority: Critical
Fix For: 4.3.0
Xenserver - SR not being recreated when the Primary storage is brought down and
brought back up again resulting in not being able to start the Vms that have
their volumes in this primary store.
Set up:
1 cluster with 2 hosts and 2 Primary storages (PS1 and PS2).
Start snapshot for couple of VMs which have primary store in PS1.
Reboot PS2. ( After this nfs server was still down)
I see that host1 and host2 reboot. But HA is not triggered , since host status
remains as “UP”.
After about 10 mts – Vmsync kicks in and stops all the Vms.
After about 12 mts (from the time snaoshots were created) , I see the snapshot
job failing (read timeouts).
I start nfs server now.
Issues:
I was not able to take another snapshot for the ROOT volume of the Vms that
reside in PS2.
I try to start the VM , Vm also fails to start.
I see the SR for PS2 is still in not in Connected state in Xenserver side.
Following exception seen when attempting to take a snapshot:
2013-12-04 15:48:19,502 WARN [c.c.h.x.r.XenServerStorageProcessor]
(DirectAgent-311:ctx-59768803) create snapshot operation Failed for snapshotId:
251, reason: The SR has no attached PBDs
The SR has no attached PBDs
at com.xensource.xenapi.Types.checkResponse(Types.java:510)
at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
at com.xensource.xenapi.VDI.miamiSnapshot(VDI.java:1217)
at com.xensource.xenapi.VDI.snapshot(VDI.java:1192)
at
com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createSnapshot(XenServerStorageProcessor.java:426)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:107)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:613)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
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(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2013-12-04 15:48:19,503 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-311:ctx-59768803) Seq 2-1599671754: Response Received:
2013-12-04 15:48:19,503 DEBUG [c.c.a.t.Request] (DirectAgent-311:ctx-59768803)
Seq 2-1599671754: Processing: { Ans: , MgmtId: 112516401760401, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CreateObjectAnswer:{result:false,details:create
snapshot operation Failed for snapshotId: 251, reason: The SR has no attached
PBDs,wait:0}}]
Following exception
[jira] [Commented] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839445#comment-13839445 ] ASF subversion and git services commented on CLOUDSTACK-5352: - Commit 71d547ba875c1a7d936710512464a4343c66f28b in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=71d547b ] CLOUDSTACK-5352: CPU cap calculated incorrectly for VMs on XenServer hosts. It should not be limited by the overprovisioning and should set the cap as service offering CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839444#comment-13839444 ] ASF subversion and git services commented on CLOUDSTACK-5139: - Commit 019316b002077223ce60fb3530a72636cadc63e5 in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=019316b ] CLOUDSTACK-5139: UI Infrastructure Secondary Storage Add Secondary Storage providers dropdown - hardcode options instead of get them from listStorageProviderstype=image since not all of returned values are handled by UI (e.g. NetApp is not handled by UI). Provision Secondary Storage Dialog incorrectly displays all storage providers - Key: CLOUDSTACK-5139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Jessica Wang Priority: Critical Labels: ui Fix For: 4.3.0 Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot 2013-10-30 at 2.59.48 PM.png The secondary storage provisioning dialog currently assumes any storage provider returned by listStorageProviders will be able to be handled by the UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The secondary storage provisioning dropdown should only display the providers which it knows how to handle. See attached images for example -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839446#comment-13839446 ] ASF subversion and git services commented on CLOUDSTACK-5139: - Commit 15c30059435667162c71b3cd1e3514bd378df8c6 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=15c3005 ] CLOUDSTACK-5139: UI Infrastructure Secondary Storage Add Secondary Storage providers dropdown - hardcode options instead of get them from listStorageProviderstype=image since not all of returned values are handled by UI (e.g. NetApp is not handled by UI). Provision Secondary Storage Dialog incorrectly displays all storage providers - Key: CLOUDSTACK-5139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Jessica Wang Priority: Critical Labels: ui Fix For: 4.3.0 Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot 2013-10-30 at 2.59.48 PM.png The secondary storage provisioning dialog currently assumes any storage provider returned by listStorageProviders will be able to be handled by the UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The secondary storage provisioning dropdown should only display the providers which it knows how to handle. See attached images for example -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839453#comment-13839453 ] ASF subversion and git services commented on CLOUDSTACK-5352: - Commit 71323f15c66a71fa2276987dda690761149f6fc9 in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=71323f1 ] CLOUDSTACK-5352: CPU cap calculated incorrectly for VMs on XenServer hosts. It should not be limited by the overprovisioning and should set the cap as service offering CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5352) CPU cap calculated incorrectly for VMs on XenServer hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-5352. - Resolution: Fixed CPU cap calculated incorrectly for VMs on XenServer hosts - Key: CLOUDSTACK-5352 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5352 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 The CPU cap assigned to VMs on XenServer hosts (via VCPUs-params parameter) is not calculated correctly. The assigned values are too low and can result in performance problems. This seems related to CPU overprovisioning. The assigned CPU cap is approximately the expected cap / CPU overprovisioning value. The customer is using CloudStack 4.2.0 with XenServer 6.1. On the customer environment they have several VMs that were created before upgrading to 4.2.0 from 3.0.6 and never rebooted, and those VMs appear to have the expected CPU cap. I see similar results on a CS 4.2.1 setup with a XS 6.2 host with 1x E31220L CPU – 2x physical cores / 4x logical cores (with hyperthreading) at 2.20GHz – 8800 MHz total (confirmed in op_host_capacity), a Compute Offering with 2200 MHz and 4 cores gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : 7cd5893e-728a-a0f3-c2cf-f3464cb8b9cb name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 131 And with a Compute Offering with 2200 MHz and 1 core gives a VM with: [root@csdemo-xen2 ~]# xe vm-list params=name-label,uuid,VCPUs-params name-label=i-2-87-VM uuid ( RO) : c17cd63a-f6d5-8f76-d7f1-eb34d574e0dd name-label ( RW): i-2-87-VM VCPUs-params (MRW): weight: 84; cap: 32 The configured cap does not make sense in either example. In this environment, cpu.overprovisioning.factor is 3 for the cluster and 1 in Global Settings. In example 1 the cap should be: 2200 * 0.99 * 4 / 2200 * 100 = 396 But it is: 2200 * 0.99 * 4 / (3*2200) * 100 = 132 For example 2 it should be: 2200 * 0.99 * 1 / 2200 * 100 = 99 But it is: 2200 * 0.99 * 1 / (3*2200) * 100 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839457#comment-13839457 ] ASF subversion and git services commented on CLOUDSTACK-5139: - Commit 9a0de4333424fd23cc3e5e7059bec0787bf57990 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a0de43 ] CLOUDSTACK-5139: UI zone wizard secondary storage step providers dropdown - hardcode options instead of get them from listStorageProviderstype=image since not all of returned values are handled by UI (e.g. NetApp is not handled by UI). Provision Secondary Storage Dialog incorrectly displays all storage providers - Key: CLOUDSTACK-5139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Jessica Wang Priority: Critical Labels: ui Fix For: 4.3.0 Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot 2013-10-30 at 2.59.48 PM.png The secondary storage provisioning dialog currently assumes any storage provider returned by listStorageProviders will be able to be handled by the UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The secondary storage provisioning dropdown should only display the providers which it knows how to handle. See attached images for example -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5372) Xenserver - SR not being recreated when the Primary storage is brought down and brought back up again resulting in not being able to start the Vms that have their vo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-5372: Attachment: primarydown.rar Xenserver - SR not being recreated when the Primary storage is brought down and brought back up again resulting in not being able to start the Vms that have their volumes in this primary store. --- Key: CLOUDSTACK-5372 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5372 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: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Attachments: primarydown.rar Xenserver - SR not being recreated when the Primary storage is brought down and brought back up again resulting in not being able to start the Vms that have their volumes in this primary store. Set up: 1 cluster with 2 hosts and 2 Primary storages (PS1 and PS2). Start snapshot for couple of VMs which have primary store in PS1. Reboot PS2. ( After this nfs server was still down) I see that host1 and host2 reboot. But HA is not triggered , since host status remains as “UP”. After about 10 mts – Vmsync kicks in and stops all the Vms. After about 12 mts (from the time snaoshots were created) , I see the snapshot job failing (read timeouts). I start nfs server now. Issues: I was not able to take another snapshot for the ROOT volume of the Vms that reside in PS2. I try to start the VM , Vm also fails to start. I see the SR for PS2 is still in not in Connected state in Xenserver side. Following exception seen when attempting to take a snapshot: 2013-12-04 15:48:19,502 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-311:ctx-59768803) create snapshot operation Failed for snapshotId: 251, reason: The SR has no attached PBDs The SR has no attached PBDs at com.xensource.xenapi.Types.checkResponse(Types.java:510) at com.xensource.xenapi.Connection.dispatch(Connection.java:368) at com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909) at com.xensource.xenapi.VDI.miamiSnapshot(VDI.java:1217) at com.xensource.xenapi.VDI.snapshot(VDI.java:1192) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createSnapshot(XenServerStorageProcessor.java:426) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:107) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:613) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) 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(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2013-12-04 15:48:19,503 DEBUG [c.c.a.m.DirectAgentAttache]
[jira] [Commented] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839455#comment-13839455 ] ASF subversion and git services commented on CLOUDSTACK-5139: - Commit 3ed7831d876b2aee02a7c162ae3c6067b0e1672a in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3ed7831 ] CLOUDSTACK-5139: UI zone wizard secondary storage step providers dropdown - hardcode options instead of get them from listStorageProviderstype=image since not all of returned values are handled by UI (e.g. NetApp is not handled by UI). Provision Secondary Storage Dialog incorrectly displays all storage providers - Key: CLOUDSTACK-5139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Jessica Wang Priority: Critical Labels: ui Fix For: 4.3.0 Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot 2013-10-30 at 2.59.48 PM.png The secondary storage provisioning dialog currently assumes any storage provider returned by listStorageProviders will be able to be handled by the UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The secondary storage provisioning dropdown should only display the providers which it knows how to handle. See attached images for example -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5139. -- Resolution: Fixed Provision Secondary Storage Dialog incorrectly displays all storage providers - Key: CLOUDSTACK-5139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Jessica Wang Priority: Critical Labels: ui Fix For: 4.3.0 Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot 2013-10-30 at 2.59.48 PM.png The secondary storage provisioning dialog currently assumes any storage provider returned by listStorageProviders will be able to be handled by the UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The secondary storage provisioning dropdown should only display the providers which it knows how to handle. See attached images for example -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Reopened] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in Up state because of com.cloud.utils.exception.CloudRuntimeException: Unable to r
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan reopened CLOUDSTACK-2428:
-
HA - When the master host is disconnected , the host status contines to
remain in Up state because of
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave
-
Key: CLOUDSTACK-2428
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
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, 4.3.0
Environment: Build from pvaln
Reporter: Sangeetha Hariharan
Assignee: Koushik Das
Priority: Critical
Fix For: 4.2.0, 4.3.0
Attachments: logs.rar, logs_7_29, management-server.rar
1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
private vlan.
2. Deploy few HA enabled Vms in this network.
3. pull network cable for one of the host.
When cloudstack detects that the host is disconnected , it is not able to out
the host in disconnected state and start HA for Vms that are HA enabeld,
I see the following exception in the management server logs:
2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-267:null) Seq 1-1435828229: Executing request
2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Catch Exception:
com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
You attempted an operation which involves a host which could not be contacted.
2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
10.223.81.61
2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-265:null) can not ping xenserver
520d4994-8b1f-4dda-b51d-2ee63750abf6
2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-265:null) Unable to get current status on 1
2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
AgentDisconnected
2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) checking if agent (1) is alive
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-271:null) Seq 1-1435828294: Executing request
2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
is the current command
2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-268:null) localLogout has problem Failed to read server's
response: connect timed out
2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
command
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
[jira] [Updated] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in Up state because of com.cloud.utils.exception.CloudRuntimeException: Unable to re
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-2428:
Fix Version/s: 4.3.0
HA - When the master host is disconnected , the host status contines to
remain in Up state because of
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave
-
Key: CLOUDSTACK-2428
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
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, 4.3.0
Environment: Build from pvaln
Reporter: Sangeetha Hariharan
Assignee: Koushik Das
Priority: Critical
Fix For: 4.2.0, 4.3.0
Attachments: logs.rar, logs_7_29, management-server.rar
1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
private vlan.
2. Deploy few HA enabled Vms in this network.
3. pull network cable for one of the host.
When cloudstack detects that the host is disconnected , it is not able to out
the host in disconnected state and start HA for Vms that are HA enabeld,
I see the following exception in the management server logs:
2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-267:null) Seq 1-1435828229: Executing request
2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Catch Exception:
com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
You attempted an operation which involves a host which could not be contacted.
2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
10.223.81.61
2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-265:null) can not ping xenserver
520d4994-8b1f-4dda-b51d-2ee63750abf6
2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-265:null) Unable to get current status on 1
2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
AgentDisconnected
2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) checking if agent (1) is alive
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-271:null) Seq 1-1435828294: Executing request
2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
is the current command
2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-268:null) localLogout has problem Failed to read server's
response: connect timed out
2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
command
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
[jira] [Updated] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in Up state because of com.cloud.utils.exception.CloudRuntimeException: Unable to re
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-2428:
Affects Version/s: 4.3.0
HA - When the master host is disconnected , the host status contines to
remain in Up state because of
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave
-
Key: CLOUDSTACK-2428
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
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, 4.3.0
Environment: Build from pvaln
Reporter: Sangeetha Hariharan
Assignee: Koushik Das
Priority: Critical
Fix For: 4.2.0, 4.3.0
Attachments: logs.rar, logs_7_29, management-server.rar
1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
private vlan.
2. Deploy few HA enabled Vms in this network.
3. pull network cable for one of the host.
When cloudstack detects that the host is disconnected , it is not able to out
the host in disconnected state and start HA for Vms that are HA enabeld,
I see the following exception in the management server logs:
2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-267:null) Seq 1-1435828229: Executing request
2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Catch Exception:
com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
You attempted an operation which involves a host which could not be contacted.
2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
10.223.81.61
2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-265:null) can not ping xenserver
520d4994-8b1f-4dda-b51d-2ee63750abf6
2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-265:null) Unable to get current status on 1
2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
AgentDisconnected
2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) checking if agent (1) is alive
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-271:null) Seq 1-1435828294: Executing request
2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
is the current command
2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-268:null) localLogout has problem Failed to read server's
response: connect timed out
2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
command
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
[jira] [Commented] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in Up state because of com.cloud.utils.exception.CloudRuntimeException: Unable to
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839512#comment-13839512
]
Sangeetha Hariharan commented on CLOUDSTACK-2428:
-
Tested with build from 4.3
Set up - Advanced zone set up with 2 Xenserver 6.2 hosts.
I had few hourly snapshots that are scheduled.
Shutdown master host.
Both the host continue to show up as being in Up state:
I see the following exception in the logs:
Both hosts show the status as being UP in the cloud platform and following
exception is seen:
2013-12-04 18:13:15,510 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-59:ctx-0bb6ad1e) Seq 1-2071592963: Exception Caught while
executing command
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.59.66 to 10.223.59.67 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5985)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:8248)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:587)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
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(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
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)
2013-12-04 18:13:15,511 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-59:ctx-0bb6ad1e) Seq 1-2071592963: Response Received:
2013-12-04 18:13:15,511 DEBUG [c.c.a.t.Request] (DirectAgent-59:ctx-0bb6ad1e)
Seq 1-2071592963: Processing: { Ans: , MgmtId: 112516401760401, via: 1, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
Unable to reset master of slave 10.223.59.66 to 10.223.59.67 due to
org.apache.xmlrpc.XmlRpcException: Failed to read server's response: connect
timed out,wait:0}}] }
Also all the snapshots that were sent to the host that is currently down fails
with following exception:
2013-12-04 18:10:24,856 DEBUG [o.a.c.s.s.SnapshotServiceImpl]
(Job-Executor-27:ctx-6cb3f72a ctx-dedf771a) create snapshot TestVM-1_ROOT-3_201
31204231014 failed: com.cloud.utils.exception.CloudRuntimeException: Unable to
reset master of slave 10.223.59.66 to 10.223.59.67 due to org.
apache.xmlrpc.XmlRpcException: Failed to read server's response: connect timed
out
2013-12-04 18:10:24,867 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy]
(Job-Executor-27:ctx-6cb3f72a ctx-dedf771a) Failed to take snapshot: com.
cloud.utils.exception.CloudRuntimeException: Unable to reset master of slave
10.223.59.66 to 10.223.59.67 due to org.apache.xmlrpc.XmlRpcExce
ption: Failed to read server's response: connect timed out
2013-12-04 18:10:24,872 DEBUG [c.c.s.s.SnapshotManagerImpl]
(Job-Executor-27:ctx-6cb3f72a ctx-dedf771a) Failed to create snapshot
com.cloud.utils.exception.CloudRuntimeException:
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.59.66 to 10.223.59.67 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
[jira] [Updated] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in Up state because of com.cloud.utils.exception.CloudRuntimeException: Unable to re
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-2428:
Attachment: hostdown.rar
HA - When the master host is disconnected , the host status contines to
remain in Up state because of
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave
-
Key: CLOUDSTACK-2428
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
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, 4.3.0
Environment: Build from pvaln
Reporter: Sangeetha Hariharan
Assignee: Koushik Das
Priority: Critical
Fix For: 4.2.0, 4.3.0
Attachments: hostdown.rar, logs.rar, logs_7_29, management-server.rar
1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
private vlan.
2. Deploy few HA enabled Vms in this network.
3. pull network cable for one of the host.
When cloudstack detects that the host is disconnected , it is not able to out
the host in disconnected state and start HA for Vms that are HA enabeld,
I see the following exception in the management server logs:
2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-267:null) Seq 1-1435828229: Executing request
2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Catch Exception:
com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
You attempted an operation which involves a host which could not be contacted.
2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
10.223.81.61
2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-265:null) can not ping xenserver
520d4994-8b1f-4dda-b51d-2ee63750abf6
2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-265:null) Unable to get current status on 1
2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
AgentDisconnected
2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-11:null) checking if agent (1) is alive
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
(AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
7647994577963, via: 1, Ver: v1, Flags: 100011,
[{CheckHealthCommand:{wait:50}}] }
2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-271:null) Seq 1-1435828294: Executing request
2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
is the current command
2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
(DirectAgent-268:null) localLogout has problem Failed to read server's
response: connect timed out
2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
(DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
command
com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
Failed to read server's response: connect timed out
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
[jira] [Resolved] (CLOUDSTACK-5268) [Automation] There is no option to create snapshot from volume of running vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-5268. -- Resolution: Fixed [Automation] There is no option to create snapshot from volume of running vm - Key: CLOUDSTACK-5268 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5268 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Environment: KVM Branch 4.3 Reporter: Rayees Namathponnan Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 Steps to reproduce Step 1 : Deploy VM Step 2 : Once VM is up, select the root volume Step 3 : Create snapshot Actual Result There is no option to create snapshot from volume; you need to stop vm first to create snapshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5268) [Automation] There is no option to create snapshot from volume of running vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839640#comment-13839640 ] Min Chen commented on CLOUDSTACK-5268: -- Based on Jessica, here is the UI logic for determining whether to display snapshot option or not for KVM: 1. If VM is not running, then always shows snapshot option. 2. If VM is running, it will only show snapshot option when the global setting kvm.snapshot.enabled is set to true. Please try this with latest code since Jessica made a fix on this on 11/26 with commit 06929343447da69b54041e506ee0f6d4b735c3bb. Otherwise, re-open this as an UI bug since this is pure UI logic. [Automation] There is no option to create snapshot from volume of running vm - Key: CLOUDSTACK-5268 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5268 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Environment: KVM Branch 4.3 Reporter: Rayees Namathponnan Assignee: Min Chen Priority: Blocker Fix For: 4.3.0 Steps to reproduce Step 1 : Deploy VM Step 2 : Once VM is up, select the root volume Step 3 : Create snapshot Actual Result There is no option to create snapshot from volume; you need to stop vm first to create snapshot -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5050) [Automation] Failed to attach ISO to running vm with NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-5050.
--
Resolution: Cannot Reproduce
Cannot reproduce this on latest 4.3.
[Automation] Failed to attach ISO to running vm with NPE
Key: CLOUDSTACK-5050
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5050
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: ISO
Affects Versions: 4.3.0
Environment: KVM
branch : master
Reporter: Rayees Namathponnan
Assignee: Min Chen
Priority: Blocker
Fix For: 4.3.0
Attachments: CLOUDSTACK-5050.rar
BVT failure
integration.smoke.test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso
Steps to reproduce
1) register ISO http://people.apache.org/~tsp/dummy.iso
2) Deploy VM
3 ) Attach ISO to running
ISO attach failed with NPE
2013-11-05 15:52:29,213 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-134:ctx-57b6c4c6) Executing AsyncJobVO {id:317, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd: org.apache
.cloudstack.api.command.user.iso.AttachIsoCmd, cmdInfo:
{id:579c330e-06bf-4911-887a-fb5146af9aad,response:json,sessionkey:vw2jRz7SFgLbxiXNx8E0BUF7mO4\u003d,virtualmachineid:63de9e37-cf3f-4f
f1-8175-f12d224a2a24,cmdEventType:ISO.ATTACH,ctxUserId:2,httpmethod:GET,_:1383695548497,ctxAccountId:2,ctxStartEventId:2626},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0,
resultCode: 0, result: null, initMsid: 29066118877352, completeMsid: null,
lastUpdated: null, lastPolled: null, created: null}
2013-11-05 15:52:29,217 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-14:ctx-865f8152 ctx-93cf9205) submit async job-317, details:
AsyncJobVO {id:317, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd:
org.apache.cloudstack.api.command.user.iso.AttachIsoCmd, cmdInfo:
{id:579c330e-06bf-4911-887a-fb5146af9aad,response:json,sessionkey:vw2jRz7SFgLbxiXNx8E0BUF7mO4\u003d,v
irtualmachineid:63de9e37-cf3f-4ff1-8175-f12d224a2a24,cmdEventType:ISO.ATTACH,ctxUserId:2,httpmethod:GET,_:1383695548497,ctxAccountId:2,ctxStartEventId:2626},
cmdVersion: 0, stat
us: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid:
29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2013-11-05 15:52:29,218 DEBUG [c.c.a.ApiServlet]
(catalina-exec-14:ctx-865f8152 ctx-93cf9205) ===END=== 10.214.5.33 -- GET
command=attachIsovirtualmachineid=63de9e37-cf3f-4ff1-8175-f12d224a2a24id=579c
330e-06bf-4911-887a-fb5146af9aadresponse=jsonsessionkey=vw2jRz7SFgLbxiXNx8E0BUF7mO4%3D_=1383695548497
2013-11-05 15:52:29,232 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-134:ctx-57b6c4c6) Unexpected exception while executing
org.apache.cloudstack.api.command.user.iso.AttachIsoCmd
java.lang.NullPointerException
at
com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:383)
at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
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 $Proxy82.checkAccess(Unknown Source)
at
com.cloud.template.TemplateManagerImpl.attachIso(TemplateManagerImpl.java:973)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
[jira] [Created] (CLOUDSTACK-5373) Web UI (non-English) is corrupted by text expansion
Kimihiko Kitase created CLOUDSTACK-5373: --- Summary: Web UI (non-English) is corrupted by text expansion Key: CLOUDSTACK-5373 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5373 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: management server: ACS 4.3 / CentOS 6.2 hypervisor: XenServer 6.2 browser: Chrome 31.0.1650.57 Reporter: Kimihiko Kitase Web UI is corrupted by text expansion when using japanese, russian and brazilian) https://www.clipular.com/users/4850842330988544/collections/front-ui-brazilian https://www.clipular.com/users/4850842330988544/collections/front-ui-japanese https://www.clipular.com/users/4850842330988544/collections/front-ui-russian https://www.clipular.com/users/4850842330988544/collections/front-ui-enlgish Other languages might be possible (although I don't test yet). I just tested front ui, but every text filed should be checked. In future, localization test should be done by more strategic technique like pseudo localization test. -- This message was sent by Atlassian JIRA (v6.1#6144)
