[jira] [Resolved] (CLOUDSTACK-4612) Specified keyboard language is not showing as default in consoleView passed during deployVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-4612. - Resolution: Fixed > Specified keyboard language is not showing as default in consoleView passed > during deployVM > --- > > Key: CLOUDSTACK-4612 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4612 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.1.0, 4.2.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.2.1 > > > While deploying a VM, user passes the "keyboard" parameter to specify the > default language for that VM but in the consoleView, the default language > selected is en-us irrespective of the default language of the VM. > To change the language, user has to navigate through the dropdown menu > provided in consoleView. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4962) router VM failed to start on KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-4962.
--
Verified .fixed.
> router VM failed to start on KVM
> -
>
> Key: CLOUDSTACK-4962
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4962
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Virtual Router
>Affects Versions: 4.2.1
> Environment: have a advance zone with KVM
> KVM on centos6.4
> MS on centos6.4
> SystemVM templete seeded
> http://nfs1.lab.vmops.com/templates/campo_qa/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
> Build :
> CloudPlatform-4.2.1-22-rhel6.4.tar.gz
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: agent.log, management-server.log.tar.gz
>
>
> Repro steps:
> Setup an advance zone and try to create a VM
> Bug: Router VM failed to start
> MS shows :
> 2013-10-25 15:48:11,672 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 1-580780059: Processing: { Ans: , MgmtId:
> 233845177509810, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":4,"name":"r-4-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-4-VM
> eth2ip=10.147.51.12 eth2mask=255.255.255.0 gateway=10.147.51.1
> eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
> dhcprange=10.1.1.1 eth1ip=169.254.1.72 eth1mask=255.255.0.0 type=router
> disable_rp_filter=true
> dns1=10.103.128.16","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"942ed47654205cb4","vncAddr":"10.147.40.27","params":{},"uuid":"065375b6-d32d-4bfe-8b6e-e4dcc23f158e","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cf634689-b1f5-45d6-807e-9b78689612b1","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96cdf130-10ea-3765-9017-315b02d94ec4","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/dixon.kvm.primary","port":2049}},"name":"ROOT-4","size":276162048,"path":"148d97cd-c173-4904-a7ff-e6dafc7420bd","volumeId":5,"vmName":"r-4-VM","accountId":2,"format":"QCOW2","id":5,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"}],"nics":[{"deviceId":2,"networkRateMbps":200,"defaultNic":true,"uuid":"223a9278-ba80-4271-81cd-55f0bffd6852","ip":"10.147.51.12","netmask":"255.255.255.0","gateway":"10.147.51.1","mac":"06:6c:be:00:00:0d","dns1":"10.103.128.16","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://51","isolationUri":"vlan://51","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":200,"defaultNic":false,"uuid":"f73b4717-680c-4c78-833e-f79c355d4229","ip":"10.1.1.1","netmask":"255.255.255.0","mac":"02:00:13:c1:00:02","dns1":"10.103.128.16","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://1049","isolationUri":"vlan://1049","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"0ceaa1a8-31ab-49bd-94a3-414603c5fca2","ip":"169.254.1.72","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:01:48","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"result":true,"wait":0}},{"com.cloud.agent.api.check.CheckSshAnswer":{"result":true,"wait":0}},{"com.cloud.agent.api.GetDomRVersionAnswer":{"result":false,"details":"GetDomRVersionCmd
>
> failed","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
> by previous
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
> by previous failure","wait":0}}] }
> 2013-10-25 15:48:11,673 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-1:null) Seq 1-580780059: No more commands found
> 2013-10-25 15:48:11,673 DEBUG [agent.transport.Request]
> (Job-Executor-1:job-13 = [ 2d4992a5-4bc1-4dc2-8640-dfb0ed16c4a4 ]) Seq
> 1-580780059: Received: { Ans: , MgmtId: 233845177509810, via: 1, Ver: v1,
> Flags: 110, { StartAnswer, CheckSshAnswer, GetDomRVersionAnswer, Answer,
> Answer } }
> 2013-10-25 15:48:11,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
> ===END=== 10.146.0.132 -- GET
> command=queryAsyncJobResult&jobId=2d4992a5-4bc1-4dc2-8640-dfb0ed16c4a4&response=json&sessionkey=C9YivQ93YtZ4O2Bi53wlAMx9E5Q%3D&_=1382696291074
> 2013-10-25 15:48:11,788 WARN
> [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-1:job-13 =
> [ 2d4992a5-4bc1-4dc2-8640-dfb0ed16c4a4 ]) Unable to get the template/scripts
> version of router r-4-VM due to: GetDomRVersionCmd
[jira] [Updated] (CLOUDSTACK-3243) [DOC]Wrong NFS mount point in documentation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair updated CLOUDSTACK-3243: - Status: Ready To Review (was: In Progress) > [DOC]Wrong NFS mount point in documentation > --- > > Key: CLOUDSTACK-3243 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3243 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0, 4.2.0 > Environment: KVM >Reporter: Ron Wheeler >Assignee: Radhika Nair >Priority: Blocker > Fix For: 4.2.1 > > > At "4.5.8. Prepare the System VM Template" the instructions give the > following command. > > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 > -h kvm -s -F > In "4.5.6.2. Using the Management Server as the NFS Server" the following > commands were give > # mkdir /primarymount > # mount -t nfs :/export/primary /primarymount > # umount /primarymount > # mkdir /secondarymount > # mount -t nfs :/export/secondary /secondarymount > # umount /secondarymount > This results in a mismatch betweenthe location of the NSF storage which > causes the error: > mount point /mnt/secondary doesn't exist\n > Installation failed > "4.5.6.1. Using a Separate NFS Server" has the storage mounted at > /mnt/secondary > The documentation needs to be made consistent. > Probably "4.5.6.2. Using the Management Server as the NFS Server" needs > fixing. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3243) [DOC]Wrong NFS mount point in documentation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807724#comment-13807724 ] Radhika Nair commented on CLOUDSTACK-3243: -- checked in to 4.2 https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=shortlog;h=refs/heads/4.2 and Master https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=commit;h=b74319385fc1f18faf0a733ba230738dfe81eb1b > [DOC]Wrong NFS mount point in documentation > --- > > Key: CLOUDSTACK-3243 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3243 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0, 4.2.0 > Environment: KVM >Reporter: Ron Wheeler >Assignee: Radhika Nair >Priority: Blocker > Fix For: 4.2.1 > > > At "4.5.8. Prepare the System VM Template" the instructions give the > following command. > > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /mnt/secondary -u > http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 > -h kvm -s -F > In "4.5.6.2. Using the Management Server as the NFS Server" the following > commands were give > # mkdir /primarymount > # mount -t nfs :/export/primary /primarymount > # umount /primarymount > # mkdir /secondarymount > # mount -t nfs :/export/secondary /secondarymount > # umount /secondarymount > This results in a mismatch betweenthe location of the NSF storage which > causes the error: > mount point /mnt/secondary doesn't exist\n > Installation failed > "4.5.6.1. Using a Separate NFS Server" has the storage mounted at > /mnt/secondary > The documentation needs to be made consistent. > Probably "4.5.6.2. Using the Management Server as the NFS Server" needs > fixing. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4943) Can't create cluster in CS 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807723#comment-13807723 ] Denis Finko commented on CLOUDSTACK-4943: - yes, great idea! > Can't create cluster in CS 4.2 > -- > > Key: CLOUDSTACK-4943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: CloudStack 4.2 + Centos6.4 + vmware 5.1 >Reporter: Denis Finko >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > I am tring to configure CloudStack 4.2 (installed from cloudstack repo > baseurl=http://cloudstack.apt-get.eu/rhel/4.2/) with VMware 5.1. During > adding new zone into user interface I have got following error: > "Unable to add the external cluster" > We have following networking configuration in vSphere Client: > Standard Switch: vSwitch0 > -Virtual Machine Port Group (VM Network) --vmnic0 > -VMkernel Port (Management Network) > Standard Switch: vSwitch1 > -VMkernel Port (Storage1) --vmnic2 > management-server.log: > 2013-10-23 05:36:03,534 DEBUG [cloud.api.ApiServlet] > (catalina-exec-22:null) ===START=== 193.142.124.9 -- GET > command=addCluster&zoneId=4f28654f-e767-4be2-b32f-39f634a01746&hypervisor=VMware&clustertype=ExternalManaged&podId=94e55d0c-3ea9-4dbc-800b-854262fd2674&username=Administrator&url=http%3A%2F%2F10.199.0.40%2Fcs4%2Fcs4it&clustername=10.199.0.40%2Fcs4%2Fcs4it&response=json&sessionkey=uAl68djojOPwUBfhwxw8OwodZuE%3D&_=1382520964075 > 2013-10-23 05:36:03,643 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Discover host. dc: 1, pod: 1, cluster: 1, uri > host: 10.199.0.40 > 2013-10-23 05:36:03,689 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Detected private network label : vSwitch0, > 2013-10-23 05:36:03,689 DEBUG [vmware.resource.VmwareContextFactory] > (catalina-exec-22:null) initialize VmwareContext. url: > https://10.199.0.40/sdk/vimService, username: Administrator, password: > r*** > 2013-10-23 05:36:03,817 INFO [vmware.util.VmwareContext] > (catalina-exec-22:null) New VmwareContext object, current outstanding > count: 1 > 2013-10-23 05:36:03,952 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-22:null) Preparing network on host > com.cloud.hypervisor.vmware.util.VmwareContext@60e2e3d4 for vSwitch0, > 2013-10-23 05:36:03,999 ERROR [vmware.mo.HypervisorHostHelper] > (catalina-exec-22:null) Unable to find vSwitchvSwitch0, > 2013-10-23 05:36:03,999 WARN [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Unable to connect to Vmware vSphere server. > service address: 10.199.0.40 > 2013-10-23 05:36:04,012 WARN [cloud.resource.ResourceManagerImpl] > (catalina-exec-22:null) Unable to find the server resources at > http://10.199.0.40/cs4/cs4it > 2013-10-23 05:36:04,014 INFO [utils.exception.CSExceptionErrorCode] > (catalina-exec-22:null) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2013-10-23 05:36:04,095 WARN [admin.cluster.AddClusterCmd] > (catalina-exec-22:null) Exception: > com.cloud.exception.DiscoveryException: Unable to add the external cluster > at > com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:533) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:181) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at >
[jira] [Updated] (CLOUDSTACK-4943) Can't create cluster in CS 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-4943: Fix Version/s: 4.3.0 4.2.1 > Can't create cluster in CS 4.2 > -- > > Key: CLOUDSTACK-4943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: CloudStack 4.2 + Centos6.4 + vmware 5.1 >Reporter: Denis Finko >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > I am tring to configure CloudStack 4.2 (installed from cloudstack repo > baseurl=http://cloudstack.apt-get.eu/rhel/4.2/) with VMware 5.1. During > adding new zone into user interface I have got following error: > "Unable to add the external cluster" > We have following networking configuration in vSphere Client: > Standard Switch: vSwitch0 > -Virtual Machine Port Group (VM Network) --vmnic0 > -VMkernel Port (Management Network) > Standard Switch: vSwitch1 > -VMkernel Port (Storage1) --vmnic2 > management-server.log: > 2013-10-23 05:36:03,534 DEBUG [cloud.api.ApiServlet] > (catalina-exec-22:null) ===START=== 193.142.124.9 -- GET > command=addCluster&zoneId=4f28654f-e767-4be2-b32f-39f634a01746&hypervisor=VMware&clustertype=ExternalManaged&podId=94e55d0c-3ea9-4dbc-800b-854262fd2674&username=Administrator&url=http%3A%2F%2F10.199.0.40%2Fcs4%2Fcs4it&clustername=10.199.0.40%2Fcs4%2Fcs4it&response=json&sessionkey=uAl68djojOPwUBfhwxw8OwodZuE%3D&_=1382520964075 > 2013-10-23 05:36:03,643 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Discover host. dc: 1, pod: 1, cluster: 1, uri > host: 10.199.0.40 > 2013-10-23 05:36:03,689 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Detected private network label : vSwitch0, > 2013-10-23 05:36:03,689 DEBUG [vmware.resource.VmwareContextFactory] > (catalina-exec-22:null) initialize VmwareContext. url: > https://10.199.0.40/sdk/vimService, username: Administrator, password: > r*** > 2013-10-23 05:36:03,817 INFO [vmware.util.VmwareContext] > (catalina-exec-22:null) New VmwareContext object, current outstanding > count: 1 > 2013-10-23 05:36:03,952 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-22:null) Preparing network on host > com.cloud.hypervisor.vmware.util.VmwareContext@60e2e3d4 for vSwitch0, > 2013-10-23 05:36:03,999 ERROR [vmware.mo.HypervisorHostHelper] > (catalina-exec-22:null) Unable to find vSwitchvSwitch0, > 2013-10-23 05:36:03,999 WARN [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Unable to connect to Vmware vSphere server. > service address: 10.199.0.40 > 2013-10-23 05:36:04,012 WARN [cloud.resource.ResourceManagerImpl] > (catalina-exec-22:null) Unable to find the server resources at > http://10.199.0.40/cs4/cs4it > 2013-10-23 05:36:04,014 INFO [utils.exception.CSExceptionErrorCode] > (catalina-exec-22:null) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2013-10-23 05:36:04,095 WARN [admin.cluster.AddClusterCmd] > (catalina-exec-22:null) Exception: > com.cloud.exception.DiscoveryException: Unable to add the external cluster > at > com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:533) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:181) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valv
[jira] [Resolved] (CLOUDSTACK-4968) Support multiple subnets in shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-4968. -- Resolution: Invalid > Support multiple subnets in shared network > -- > > Key: CLOUDSTACK-4968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4968 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nux >Assignee: Bharat Kumar > Labels: features, ip, network > > Hello, > I'm testing CS for selling VPSes and would like to use the newly "shared > network with SG" feature, but there's one problem - it does not accept > multiple subnets or IP allocations. > Right now when the active subnet runs out that's it, one can no longer create > VMs, this is bad for business. :) > This problem is handled well in the "basic network zone" where one can simply > add more subnets as required. Can something similar be done to solve this > issue? > Thanks, > Lucian -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-3583) Management server stop is not removing the PID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-3583. This issue is fixed now. Hence closing the bug. [root@rhelASA management]# service cloudstack-management status cloudstack-management (pid 26357) is running... [root@rhelASA management]# service cloudstack-management stop Stopping cloudstack-management:[ OK ] [root@rhelASA management]# service cloudstack-management status cloudstack-management is stopped [root@rhelASA management]# service cloudstack-management start Starting cloudstack-management:[ OK ] [root@rhelASA management]# service cloudstack-management status cloudstack-management (pid 26847) is running... [root@rhelASA management]# > Management server stop is not removing the PID > --- > > Key: CLOUDSTACK-3583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3583 > 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 >Reporter: Sailaja Mada >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.2.1 > > > Steps: > 1. Configure Adv Zone with VMWARE > 2. Deploy VM's 3. Update expunge interval GC value > 3. Stop the Management server > [root@ec2 management]# service cloudstack-management stop > Stopping cloudstack-management:[ OK ] > 4. Check the status > cloudstack-management dead but pid file exists > The pid file locates at /var/run/cloudstack-management.pid and lock file at > /var/lock/subsys/cloudstack-management. > Starting cloudstack-management will take care of them or you can > manually clean up. > [root@ec2 management]# > 5. Start the management server > [root@ec2 management]# service cloudstack-management start > Starting cloudstack-management:[ OK ] > 6. Check the status > [root@ec2 management]# service cloudstack-management status > cloudstack-management (pid 350) is running... > [root@ec2 management]# > But when Management server stopped , status shows as its not a clean stop > [root@ec2 management]# service cloudstack-management stop > Stopping cloudstack-management:[ OK ] > [root@ec2 management]# service cloudstack-management status > cloudstack-management dead but pid file exists > The pid file locates at /var/run/cloudstack-management.pid and lock file at > /var/lock/subsys/cloudstack-management. > Starting cloudstack-management will take care of them or you can > manually clean up. > [root@ec2 management]# service cloudstack-management status > cloudstack-management dead but pid file exists > The pid file locates at /var/run/cloudstack-management.pid and lock file at > /var/lock/subsys/cloudstack-management. > Starting cloudstack-management will take care of them or you can > manually clean up. > [root@ec2 management]# service cloudstack-management start > Starting cloudstack-management:[ OK ] > [root@ec2 management]# service cloudstack-management status > cloudstack-management (pid 350) is running... > [root@ec2 management]# > [root@ec2 management]# cat /var/run/cloudstack-management.pid > 350 > [root@ec2 management]# cat /var/lock/subsys/cloudstack-management -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4985) NPE while deleting old root volumes of a restored VM during storage garbage collection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-4985. Resolution: Fixed > NPE while deleting old root volumes of a restored VM during storage garbage > collection > -- > > Key: CLOUDSTACK-4985 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4985 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.2.1 > > > When VM is restored using restoreVirtualMachine API, old root volume of the > VM is marked as destroyed, a new volume is created and made the root volume > of the VM . > During the next run of storage garbage collector it tries to expunge the old > root volume which has been marked as destroyed. But In case of VMware, since > the VMDK files of the new root volume have replaced the VMDK files of the old > root volume we see the below error, > 2013-10-29 09:43:53,479 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-21:10.102.192.12) delete volume failed due to Exception: > java.lang.RuntimeException > Message: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c] > i-2-20-VM/ROOT-20-flat.vmdk > java.lang.RuntimeException: Cannot delete file > [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk > at > com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411) > at > com.cloud.hypervisor.vmware.mo.DatastoreMO.deleteFile(DatastoreMO.java:175) > at > com.cloud.storage.resource.VmwareStorageLayoutHelper.deleteVolumeVmdkFiles(VmwareStorageLayoutHelper.java:276) > at > com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1548) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:114) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) > Hence in case of VMware, once the state of the old root volume has been > updated to destroyed force expunge it from primary storage to avoid the > garbage collector from trying to delete the new root volume. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4985) NPE while deleting old root volumes of a restored VM during storage garbage collection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807716#comment-13807716 ] Likitha Shetty commented on CLOUDSTACK-4985: Branch 4.2 - 375a59d2f73e23194e1dae5b9ee11ae111a28027 > NPE while deleting old root volumes of a restored VM during storage garbage > collection > -- > > Key: CLOUDSTACK-4985 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4985 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.2.1 > > > When VM is restored using restoreVirtualMachine API, old root volume of the > VM is marked as destroyed, a new volume is created and made the root volume > of the VM . > During the next run of storage garbage collector it tries to expunge the old > root volume which has been marked as destroyed. But In case of VMware, since > the VMDK files of the new root volume have replaced the VMDK files of the old > root volume we see the below error, > 2013-10-29 09:43:53,479 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-21:10.102.192.12) delete volume failed due to Exception: > java.lang.RuntimeException > Message: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c] > i-2-20-VM/ROOT-20-flat.vmdk > java.lang.RuntimeException: Cannot delete file > [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk > at > com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411) > at > com.cloud.hypervisor.vmware.mo.DatastoreMO.deleteFile(DatastoreMO.java:175) > at > com.cloud.storage.resource.VmwareStorageLayoutHelper.deleteVolumeVmdkFiles(VmwareStorageLayoutHelper.java:276) > at > com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1548) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:114) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) > Hence in case of VMware, once the state of the old root volume has been > updated to destroyed force expunge it from primary storage to avoid the > garbage collector from trying to delete the new root volume. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4985) NPE while deleting old root volumes of a restored VM during storage garbage collection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807715#comment-13807715 ] ASF subversion and git services commented on CLOUDSTACK-4985: - Commit cc4b612bf604addb1ad903ef8adc504c569abe55 in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cc4b612 ] CLOUDSTACK-4985. NPE while deleting old root volumes of a restored VM during storage garbage collection. In case of VMware, once the state of the old root volume has been updated to destroyed force expunge it from primary storage to avoid the garbage collector from trying to delete the new root volume > NPE while deleting old root volumes of a restored VM during storage garbage > collection > -- > > Key: CLOUDSTACK-4985 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4985 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.2.1 > > > When VM is restored using restoreVirtualMachine API, old root volume of the > VM is marked as destroyed, a new volume is created and made the root volume > of the VM . > During the next run of storage garbage collector it tries to expunge the old > root volume which has been marked as destroyed. But In case of VMware, since > the VMDK files of the new root volume have replaced the VMDK files of the old > root volume we see the below error, > 2013-10-29 09:43:53,479 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-21:10.102.192.12) delete volume failed due to Exception: > java.lang.RuntimeException > Message: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c] > i-2-20-VM/ROOT-20-flat.vmdk > java.lang.RuntimeException: Cannot delete file > [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk > at > com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411) > at > com.cloud.hypervisor.vmware.mo.DatastoreMO.deleteFile(DatastoreMO.java:175) > at > com.cloud.storage.resource.VmwareStorageLayoutHelper.deleteVolumeVmdkFiles(VmwareStorageLayoutHelper.java:276) > at > com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1548) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:114) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) > Hence in case of VMware, once the state of the old root volume has been > updated to destroyed force expunge it from primary storage to avoid the > garbage collector from trying to delete the new root volume. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4985) NPE while deleting old root volumes of a restored VM during storage garbage collection
Likitha Shetty created CLOUDSTACK-4985: -- Summary: NPE while deleting old root volumes of a restored VM during storage garbage collection Key: CLOUDSTACK-4985 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4985 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.2.1 When VM is restored using restoreVirtualMachine API, old root volume of the VM is marked as destroyed, a new volume is created and made the root volume of the VM . During the next run of storage garbage collector it tries to expunge the old root volume which has been marked as destroyed. But In case of VMware, since the VMDK files of the new root volume have replaced the VMDK files of the old root volume we see the below error, 2013-10-29 09:43:53,479 ERROR [storage.resource.VmwareStorageProcessor] (DirectAgent-21:10.102.192.12) delete volume failed due to Exception: java.lang.RuntimeException Message: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk java.lang.RuntimeException: Cannot delete file [de9821955e1f3e009b3f2a4529d7439c] i-2-20-VM/ROOT-20-flat.vmdk at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:411) at com.cloud.hypervisor.vmware.mo.DatastoreMO.deleteFile(DatastoreMO.java:175) at com.cloud.storage.resource.VmwareStorageLayoutHelper.deleteVolumeVmdkFiles(VmwareStorageLayoutHelper.java:276) at com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1548) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:114) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559) at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) 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$101(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Hence in case of VMware, once the state of the old root volume has been updated to destroyed force expunge it from primary storage to avoid the garbage collector from trying to delete the new root volume. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807711#comment-13807711 ] Marcus Sorensen commented on CLOUDSTACK-4967: - Hmm, I'm wishing I hadn't found the problem now :-) I don't really like the option where we limit to 4 or less characters, it's severely limiting. I think the odds of people wanting to use 'bond' adapters are much higher than the odds of someone using VNI 10,000,000. Worse, I think the odds of someone wanting to use 'eth0.1000' as you mention are also much higher, but 'breth0.1000-' only leaves three characters for VNI. There might be another solution: To have vxlan use it's own bridge naming scheme. All bridges in cloudstack used to be 'cloudVirBrX', where X was the vlan id. This was changed to include the eth device, so that vlan ids could be reused in situations where they were on different physical networks (e.g. eth0.300 and eth1.300 could both be used). I'm suggesting that vxlan use 'brvx-'. The only drawback is that there can then only be one vxlan-isolated guest network per zone (as it was with cloudVirBrX). I don't think that's a very big drawback, considering the scalability of vxlan, combined with the likelihood of people even using multiple physical networks for guest traffic. I'm testing a patch right now, it does two things. 1) allows traffic label for guest networks to be the actual eth/bond device if desired, and 2) changes bridge name for vxlan to be brvx- as mentioned. What do you guys think? > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4024) Provide a way to upgrade from existing NFS secondary storage to S3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807664#comment-13807664 ] ASF subversion and git services commented on CLOUDSTACK-4024: - Commit 6be228a438e5ce3fba831be8130c73603cb0457b in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6be228a ] CLOUDSTACK-4024:Provide a way to upgrade from existing NFS secondary storage to S3. > Provide a way to upgrade from existing NFS secondary storage to S3 > -- > > Key: CLOUDSTACK-4024 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4024 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: edison su >Assignee: Min Chen >Priority: Critical > Labels: enhancement > Fix For: 4.3.0 > > > We'd better provide a tool to upgrade templates/snapshots/volumes stored on > existing NFS secondary storage to S3, so users can smoothly upgrade to S3 > from existing NFS setup. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4817) Backup snapshot on Xen should take global setting s3.multipart.enabled.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807653#comment-13807653 ] ASF subversion and git services commented on CLOUDSTACK-4817: - Commit 89d6e7ed66e92ded84e85d57a7b2681fd088c20b in branch refs/heads/object_store_migration from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=89d6e7e ] CLOUDSTACK-4817: fix s3 multipart uplaod Conflicts: plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageProcessor.java > Backup snapshot on Xen should take global setting s3.multipart.enabled. > --- > > Key: CLOUDSTACK-4817 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4817 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: XenServer >Reporter: Min Chen >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > > Currently backsnapshot to S3 on Xen only used single part upload in s3xen > plugin code, which will result in failure in case of snapshot is > 5GB. We > need that plugin code to check the configuration setting s3.multipart.enabled > to choose multipart or singlepart upload. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807640#comment-13807640 ] Yoshikazu Nojima commented on CLOUDSTACK-4967: -- Note: It seems Linux vxlan interface doesn't accept VNI:16777215. https://issues.apache.org/jira/browse/CLOUDSTACK-4984 > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4984) CloudStack accepts VNI 16777215 which cannot be used in Linux vxlan implementation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoshikazu Nojima updated CLOUDSTACK-4984: - Priority: Trivial (was: Major) > CloudStack accepts VNI 16777215 which cannot be used in Linux vxlan > implementation > -- > > Key: CLOUDSTACK-4984 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4984 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: Future >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima >Priority: Trivial > > Linux vxlan interface doesn't accept VNI:16777215. > https://github.com/torvalds/linux/blob/master/drivers/net/vxlan.c#L2140 > As far as I read internet draft ( > http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-05 ), > 16777215 is a valid VNI, but it cannot be used in Linux now. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4984) CloudStack accepts VNI 16777215 which cannot be used in Linux vxlan implementation
Yoshikazu Nojima created CLOUDSTACK-4984: Summary: CloudStack accepts VNI 16777215 which cannot be used in Linux vxlan implementation Key: CLOUDSTACK-4984 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4984 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: Future Reporter: Yoshikazu Nojima Assignee: Yoshikazu Nojima Linux vxlan interface doesn't accept VNI:16777215. https://github.com/torvalds/linux/blob/master/drivers/net/vxlan.c#L2140 As far as I read internet draft ( http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-05 ), 16777215 is a valid VNI, but it cannot be used in Linux now. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4983) VMWare:MS: Dynamic scaling doesnt work with vCenter 5.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-4983. -- Resolution: Not A Problem Fix Version/s: 4.2.0 We do not poll for VMware tools status on VM's. So given that fact we introduced a check box that Admin's must check before attempting a dynamic scaling. ( A Trust feature that VMWare tools is now installed). Subsequent tests revealed that scaling can be successful with this flag set and VMWare tools not installed at all. However it is still recommended that we install the VMWare tools and then set the Flag (Which acts as a way of telling CS that VMWare tools is now successfully installed). Then perform a dynamic scaling. Closing as not a problem, But would certainly wish for a cleaner implementation that doesn't rely on Trust. There are high chances that we could pull VMWare tools status from vCenter instead of relying on manual flag. Would raise a separate enhancement request for this. > VMWare:MS: Dynamic scaling doesnt work with vCenter 5.1 > --- > > Key: CLOUDSTACK-4983 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4983 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server, VMware >Affects Versions: 4.2.0 > Environment: VCenter 5.1 with ESX 5.1 >Reporter: Parth Jagirdar >Priority: Critical > Fix For: 4.2.0 > > > Dynamic scaling complains about VMWare tools not installed although its > installed on VM and vCenter reports it as installed. > Is VMWare-tools detection not happening correctly on vCenter 5.1/ESXi 5.1? > -487b-9226-cba948735665 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd > com.cloud.utils.exception.CloudRuntimeException: Unable to Scale the vm: > 7c70a918-d6c1-4a23-91ff-524cafe9613d as vm does not have tools to support > dynamic scaling > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1281) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1226) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1160) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-10-28 17:09:22,721 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-30:job-50 = [ 984aac12-7908-487b-9226-cba948735665 ]) Complete > async job-50 = [ 984aac12-7908-487b-9226-cba948735665 ], jobStatus: 2, > resultCode: 530, result: Error Code: 530 Error text: Unable to Scale the vm: > 7c70a918-d6c1-4a23-91ff-524cafe9613d as vm does not have tools to support > dynamic scaling > 2013-10-28 17:09:25,730 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) > ===START=== 10.215.2.19 -- GET > command=queryAsyncJobResult&jobId=984aac12-7908-487b-9226-cba948735665&response=json&sessionkey=uH7v1HeDZJF1y9NFekMzJzhwF78%3D&_=1383005365709 > 2013-10-28 17:09:25,741 DEBUG [cloud.async.AsyncJobManagerImpl] > (catalina-exec-2:null) Async job-50 = [ 984aac12-7908-487b-9226-cba948735665 > ] completed > 2013-10-28 17:09:25,748 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) > ===END=== 10.215.2.19 -- GET > command=queryAsyncJobResult&jobId=984aac12-7908-487b-9226-cba948735665&response=json&sessionkey=uH7v1HeDZJF1y9NFekMzJzhwF78%3D&_=1383005365709 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807544#comment-13807544 ] Yoshikazu Nojima commented on CLOUDSTACK-4967: -- It seems option 2 is nice, but for workaround, I prefer option 3. I made reveiew request for this issue: https://reviews.apache.org/r/15001/ > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4952) [event framework] The topic grammar - eventSource.eventCategory.eventType.resourceType.resourceUuid is incorrect, eventType.resourceType should swap
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-4952. - Resolution: Not A Problem Yep, you are right. I understand what you are saying and that should be feasible. > [event framework] The topic grammar - > eventSource.eventCategory.eventType.resourceType.resourceUuid is incorrect, > eventType.resourceType should swap > - > > Key: CLOUDSTACK-4952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4877) Pluggable VM snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-4877. --- Resolution: Fixed fixed in 465c9ec5c3916009a6f87d1d450a5fe39e57b8fe > Pluggable VM snapshot > -- > > Key: CLOUDSTACK-4877 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4877 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: edison su >Assignee: edison su >Priority: Blocker > Fix For: 4.3.0 > > > See the design doc: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Pluggable+VM+snapshot+related+operations -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4817) Backup snapshot on Xen should take global setting s3.multipart.enabled.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807526#comment-13807526 ] ASF subversion and git services commented on CLOUDSTACK-4817: - Commit 89d6e7ed66e92ded84e85d57a7b2681fd088c20b in branch refs/heads/master from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=89d6e7e ] CLOUDSTACK-4817: fix s3 multipart uplaod Conflicts: plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageProcessor.java > Backup snapshot on Xen should take global setting s3.multipart.enabled. > --- > > Key: CLOUDSTACK-4817 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4817 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: XenServer >Reporter: Min Chen >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > > Currently backsnapshot to S3 on Xen only used single part upload in s3xen > plugin code, which will result in failure in case of snapshot is > 5GB. We > need that plugin code to check the configuration setting s3.multipart.enabled > to choose multipart or singlepart upload. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4817) Backup snapshot on Xen should take global setting s3.multipart.enabled.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-4817. --- Resolution: Fixed > Backup snapshot on Xen should take global setting s3.multipart.enabled. > --- > > Key: CLOUDSTACK-4817 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4817 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: XenServer >Reporter: Min Chen >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > > Currently backsnapshot to S3 on Xen only used single part upload in s3xen > plugin code, which will result in failure in case of snapshot is > 5GB. We > need that plugin code to check the configuration setting s3.multipart.enabled > to choose multipart or singlepart upload. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4817) Backup snapshot on Xen should take global setting s3.multipart.enabled.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807524#comment-13807524 ] ASF subversion and git services commented on CLOUDSTACK-4817: - Commit 9672a45ea164e7bd37fe947fae90b7a397434e10 in branch refs/heads/4.2 from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9672a45 ] CLOUDSTACK-4817: fix s3 multipart uplaod > Backup snapshot on Xen should take global setting s3.multipart.enabled. > --- > > Key: CLOUDSTACK-4817 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4817 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: XenServer >Reporter: Min Chen >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > > Currently backsnapshot to S3 on Xen only used single part upload in s3xen > plugin code, which will result in failure in case of snapshot is > 5GB. We > need that plugin code to check the configuration setting s3.multipart.enabled > to choose multipart or singlepart upload. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4983) VMWare:MS: Dynamic scaling doesnt work with vCenter 5.1
Parth Jagirdar created CLOUDSTACK-4983: -- Summary: VMWare:MS: Dynamic scaling doesnt work with vCenter 5.1 Key: CLOUDSTACK-4983 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4983 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Management Server, VMware Affects Versions: 4.2.0 Environment: VCenter 5.1 with ESX 5.1 Reporter: Parth Jagirdar Priority: Critical Dynamic scaling complains about VMWare tools not installed although its installed on VM and vCenter reports it as installed. Is VMWare-tools detection not happening correctly on vCenter 5.1/ESXi 5.1? -487b-9226-cba948735665 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.ScaleVMCmd com.cloud.utils.exception.CloudRuntimeException: Unable to Scale the vm: 7c70a918-d6c1-4a23-91ff-524cafe9613d as vm does not have tools to support dynamic scaling at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1281) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1226) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1160) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:102) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-10-28 17:09:22,721 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-30:job-50 = [ 984aac12-7908-487b-9226-cba948735665 ]) Complete async job-50 = [ 984aac12-7908-487b-9226-cba948735665 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Unable to Scale the vm: 7c70a918-d6c1-4a23-91ff-524cafe9613d as vm does not have tools to support dynamic scaling 2013-10-28 17:09:25,730 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) ===START=== 10.215.2.19 -- GET command=queryAsyncJobResult&jobId=984aac12-7908-487b-9226-cba948735665&response=json&sessionkey=uH7v1HeDZJF1y9NFekMzJzhwF78%3D&_=1383005365709 2013-10-28 17:09:25,741 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-2:null) Async job-50 = [ 984aac12-7908-487b-9226-cba948735665 ] completed 2013-10-28 17:09:25,748 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) ===END=== 10.215.2.19 -- GET command=queryAsyncJobResult&jobId=984aac12-7908-487b-9226-cba948735665&response=json&sessionkey=uH7v1HeDZJF1y9NFekMzJzhwF78%3D&_=1383005365709 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-754) nTier Apps 2.0 : Remote access VPN to VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807508#comment-13807508 ] Animesh Chaturvedi commented on CLOUDSTACK-754: --- i see your commit should the ticket be now resolved? > nTier Apps 2.0 : Remote access VPN to VPC > - > > Key: CLOUDSTACK-754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-754 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Kishan Kavala >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.3.0 > > > This item is a sub task (2.9) of > https://issues.apache.org/jira/browse/CLOUDSTACK-621 > This would enable remote-users to login to their VPC network -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807448#comment-13807448 ] Marcus Sorensen commented on CLOUDSTACK-4967: - Good points. The physical nic name won't be known, however, until we get all the way to implementing the network via the agent. That might be a bad place to find out that everything is configured in an unsupported fashion. We could: 1) limit the max VNI range, documenting such. That is a bit distasteful to me, but would probably work for the majority of installations. 2) Require the physical nic name as the traffic label, rather than the bridge. This always struck me as unnecessary, to set up a bridge on the interface that hosts guests, to register that bridge name, and then have the agent go figure out which physical nic hosts that bridge so we can make guest bridges on it. All of my systems have unused bridges set up just for this purpose. Now, with vxlan, it's even more silly because there are layer 3 interfaces that don't even work on bridges, but do host vxlan just fine (ipoib, etc). I will probably implement something in the pif code that will allow the kvm traffic label to be a physical device (fallback if no such bridge exists). Vxlan could play off of that by requiring that it be a physical device rather than a bridge, which would allow you to check the length of the interface name during zone setup. 3) Just document the limitations and let the end user deal with it. > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4978) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807295#comment-13807295 ] Daniel Niasoff commented on CLOUDSTACK-4978: I can see that somewhere that the original cloned VM has a 01 added to the VMDK file names and cloudstack isn't expecting this so this is why it's failing. Enabling linked clones works around this > Provisioning VMs from templates fails on VMWare with error > ROOT-249/ROOT-249.vmdk was not found > --- > > Key: CLOUDSTACK-4978 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4978 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0, 4.2.1 >Reporter: Daniel Niasoff > Attachments: apilog.log, management-server.log > > > I am unable to provision VMs from templates. > Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. > I downloaded and built 4.2.1 but still getting same issue. > Tried creating new templates and it always fails on a move file task. > Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4674) [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to recognize various ipmi version and BMC type of server
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
frank zhang resolved CLOUDSTACK-4674.
-
Resolution: Fixed
> [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to
> recognize various ipmi version and BMC type of server
> --
>
> Key: CLOUDSTACK-4674
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4674
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS 4.2 campo
> baremetal
>Reporter: angeline shen
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
>
> On MS: ./usr/share/cloudstack-common/scripts/util/ipmi.py :
> o = ipmitool("-H", hostname, "-U", usrname, "-P", password, "chassis",
> "bootdev", dev)
> need to include -l lanplus option :
> o = ipmitool("-H", hostname, "-U", usrname, "-P", password, "-l",
> "lanplus", "chassis", "bootdev", dev)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4674) [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to recognize various ipmi version and BMC type of server
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807277#comment-13807277
]
ASF subversion and git services commented on CLOUDSTACK-4674:
-
Commit 16a51ee47925eeaafb27bee5f0610800b79f93fc in branch refs/heads/4.2 from
[~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=16a51ee ]
CLOUDSTACK-4674
[baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script
need to recognize various ipmi version and BMC type of server
> [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to
> recognize various ipmi version and BMC type of server
> --
>
> Key: CLOUDSTACK-4674
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4674
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS 4.2 campo
> baremetal
>Reporter: angeline shen
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
>
> On MS: ./usr/share/cloudstack-common/scripts/util/ipmi.py :
> o = ipmitool("-H", hostname, "-U", usrname, "-P", password, "chassis",
> "bootdev", dev)
> need to include -l lanplus option :
> o = ipmitool("-H", hostname, "-U", usrname, "-P", password, "-l",
> "lanplus", "chassis", "bootdev", dev)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-4982) Top of dialogs cut off
Mike Tutkowski created CLOUDSTACK-4982: -- Summary: Top of dialogs cut off Key: CLOUDSTACK-4982 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4982 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: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3 Reporter: Mike Tutkowski Priority: Minor Fix For: 4.3.0 Attachments: Top of Dialog.png Please see the attached screen shot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4982) Top of dialogs cut off
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-4982: --- Attachment: Top of Dialog.png > Top of dialogs cut off > -- > > Key: CLOUDSTACK-4982 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4982 > 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: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3 >Reporter: Mike Tutkowski >Priority: Minor > Fix For: 4.3.0 > > Attachments: Top of Dialog.png > > > Please see the attached screen shot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CLOUDSTACK-4967) vxlan doesn't scale
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807245#comment-13807245
]
Yoshikazu Nojima edited comment on CLOUDSTACK-4967 at 10/28/13 9:37 PM:
{quote}
The max size of a bridge device name is 15 characters.
{quote}
Thank you for let me know the length limitation.
If we use hex for vxlan, I think we need to append the prefix "0x" not to be
mistaken to decimal, because we keep using decimal for vlan, but it consumes 2
more length.
Moreover, user may use vlan interface like "eth0.1000" for underlay network,
and the bridge name will be "breth0.1000-". It's too long even if we use
hex.
I think raising error when the physical nic's name is longer than 4 is better
workaround.
How do you think, Marcus?
was (Author: ynojima):
{quote}
The max size of a bridge device name is 15 characters.
{quote}
Thank you for let me know the length limitation.
If we use hex for vxlan, I think we need to append the prefix "0x" not to be
mistaken to decimal, because we keep using decimal for vlan, but it consumes 2
more length.
Moreover, user may use vlan interface like "eth0.1000" for underlay network,
and the bridge name will be "breth0.1000-". It's too long even if we use
hex.
I think raising error when the physical nic's name is longer than 6 is better
workaround.
How do you think, Marcus?
> vxlan doesn't scale
> ---
>
> Key: CLOUDSTACK-4967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 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: Marcus Sorensen
>Assignee: Yoshikazu Nojima
> Fix For: 4.3.0
>
>
> com.cloud.exception.InternalErrorException: Failed to create vnet 987529:
> inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet
> prefix is expected rather than "239.15.3857.137".Error
> It looks like the vxlan implementation doesn't scale correctly with vxlan's
> capabilities. The VNI is supposed to be up to 24 bits (16777216), it should
> be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do
> this:
> local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256
> )).$(( $vxlanId % 256 ))"
> $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256
> On a less important note, I should point out that the bridge naming
> convention will break in certain rare situations. The max size of a bridge
> device name is 15 characters. For bond devices, a VNI above 10 million will
> not fit, e.g. "brbond0-1600", or ethernet devices above 10
> "breth10-1600". However, these may be quite rare, and changing the
> naming convention as we found in 4.2 is a bit painful if it can't be done in
> a backward compatible way. My first thought was to have vxlan and vxlan only
> use hex for it's VNI, that might be ok since it's never been released yet.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4809) Can't execute Disk Offering to create a Volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski resolved CLOUDSTACK-4809. Resolution: Fixed Min Chen fixed this in this commit: 694ec684a372c95abf8d1a798714b6f074862816 > Can't execute Disk Offering to create a Volume > -- > > Key: CLOUDSTACK-4809 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4809 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski > Fix For: Future > > > I'm trying to create a volume from a Disk Offering that specifies a 10 GB > disk. > When attempting to create a volume from this Disk Offering, I'm told the > maximum size I can create for a volume is 0 GB. > In VolumeApiServiceImpl, I see a private instance variable called > _maxVolumeSizeInGb, which appears to be the problem. > It is read from, but never written to (its default value is 0 since it is a > 'long' member variable). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4809) Can't execute Disk Offering to create a Volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski closed CLOUDSTACK-4809. -- > Can't execute Disk Offering to create a Volume > -- > > Key: CLOUDSTACK-4809 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4809 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski > Fix For: Future > > > I'm trying to create a volume from a Disk Offering that specifies a 10 GB > disk. > When attempting to create a volume from this Disk Offering, I'm told the > maximum size I can create for a volume is 0 GB. > In VolumeApiServiceImpl, I see a private instance variable called > _maxVolumeSizeInGb, which appears to be the problem. > It is read from, but never written to (its default value is 0 since it is a > 'long' member variable). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4842) Can't create a VM based on an ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski closed CLOUDSTACK-4842. -- > Can't create a VM based on an ISO > - > > Key: CLOUDSTACK-4842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future > Environment: Mac OS X 10.8.3 >Reporter: Mike Tutkowski > Fix For: Future > > > I am unable to create a VM instance based on an ISO due to the following > error: > INFO [c.c.a.ApiServer] (804219803@qtp-426122736-3:ctx-1b07f7ab ctx-8d5a64da) > Unable to execute API command deployvirtualmachine due to invalid value. > Invalid parameter diskofferingid value=ff31ad62-309a-11e3-b2be-01818516e022 > due to incorrect long value format, or entity does not exist or due to > incorrect parameter annotation for the field in api cmd class. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4842) Can't create a VM based on an ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski resolved CLOUDSTACK-4842. Resolution: Fixed This issue is related to CLOUDSTACK-4801. If CLOUDSTACK-4801 gets fixed, this ticket shouldn't be a problem. What happened was I selected a Compute Offering instead of a Disk Offering, so the API correctly rejected the call. The problem is that a Compute Offering was an option to select, which is covered in CLOUDSTACK-4801. As such, closing this ticket. > Can't create a VM based on an ISO > - > > Key: CLOUDSTACK-4842 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4842 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future > Environment: Mac OS X 10.8.3 >Reporter: Mike Tutkowski > Fix For: Future > > > I am unable to create a VM instance based on an ISO due to the following > error: > INFO [c.c.a.ApiServer] (804219803@qtp-426122736-3:ctx-1b07f7ab ctx-8d5a64da) > Unable to execute API command deployvirtualmachine due to invalid value. > Invalid parameter diskofferingid value=ff31ad62-309a-11e3-b2be-01818516e022 > due to incorrect long value format, or entity does not exist or due to > incorrect parameter annotation for the field in api cmd class. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4981) Cannot log out of GUI
Mike Tutkowski created CLOUDSTACK-4981: -- Summary: Cannot log out of GUI Key: CLOUDSTACK-4981 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4981 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: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3 Reporter: Mike Tutkowski Fix For: 4.3.0 If I click on the drop down to log out of the GUI, the logout button shows up under the Default View combo box. If I move the mouse to click on it, the logout button disappears -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807245#comment-13807245
]
Yoshikazu Nojima commented on CLOUDSTACK-4967:
--
{quote}
The max size of a bridge device name is 15 characters.
{quote}
Thank you for let me know the length limitation.
If we use hex for vxlan, I think we need to append the prefix "0x" not to be
mistaken to decimal, because we keep using decimal for vlan, but it consumes 2
more length.
Moreover, user may use vlan interface like "eth0.1000" for underlay network,
and the bridge name will be "breth0.1000-". It's too long even if we use
hex.
I think raising error when the physical nic's name is longer than 6 is better
workaround.
How do you think, Marcus?
> vxlan doesn't scale
> ---
>
> Key: CLOUDSTACK-4967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 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: Marcus Sorensen
>Assignee: Yoshikazu Nojima
> Fix For: 4.3.0
>
>
> com.cloud.exception.InternalErrorException: Failed to create vnet 987529:
> inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet
> prefix is expected rather than "239.15.3857.137".Error
> It looks like the vxlan implementation doesn't scale correctly with vxlan's
> capabilities. The VNI is supposed to be up to 24 bits (16777216), it should
> be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do
> this:
> local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256
> )).$(( $vxlanId % 256 ))"
> $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256
> On a less important note, I should point out that the bridge naming
> convention will break in certain rare situations. The max size of a bridge
> device name is 15 characters. For bond devices, a VNI above 10 million will
> not fit, e.g. "brbond0-1600", or ethernet devices above 10
> "breth10-1600". However, these may be quite rare, and changing the
> naming convention as we found in 4.2 is a bit painful if it can't be done in
> a backward compatible way. My first thought was to have vxlan and vxlan only
> use hex for it's VNI, that might be ok since it's never been released yet.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-4980) Misaligned Columns
Mike Tutkowski created CLOUDSTACK-4980: -- Summary: Misaligned Columns Key: CLOUDSTACK-4980 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4980 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: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3 Reporter: Mike Tutkowski Priority: Minor Fix For: 4.3.0 Attachments: Misaligned Columns.png Please see the attached screen shot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4980) Misaligned Columns
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-4980: --- Attachment: Misaligned Columns.png > Misaligned Columns > -- > > Key: CLOUDSTACK-4980 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4980 > 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: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3 >Reporter: Mike Tutkowski >Priority: Minor > Fix For: 4.3.0 > > Attachments: Misaligned Columns.png > > > Please see the attached screen shot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoshikazu Nojima updated CLOUDSTACK-4967: - Comment: was deleted (was: Sorry, It's my misunderstanding...) > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807175#comment-13807175 ] Yoshikazu Nojima commented on CLOUDSTACK-4967: -- Sorry, It's my misunderstanding... > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Issue Comment Deleted] (CLOUDSTACK-4967) vxlan doesn't scale
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoshikazu Nojima updated CLOUDSTACK-4967:
-
Comment: was deleted
(was: {noformat}
local brif=`find ${sysfs_dir}*/brif/ -name $pif | sed -e "s,$sysfs_dir,," | sed
-e 's,/brif/.*$,,'`
{noformat}
I think you try to delete the bridge "br-", but it seems it
deletes the bridge associated with physical device ( ex. "cloudbr0").
I think you should change it to
{noformat}
local brif=`find ${sysfs_dir}*/brif/ -name $vxlanDev | sed -e "s,$sysfs_dir,,"
| sed -e 's,/brif/.*$,,'`
{noformat}
Is my understanding correct?
)
> vxlan doesn't scale
> ---
>
> Key: CLOUDSTACK-4967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 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: Marcus Sorensen
>Assignee: Yoshikazu Nojima
> Fix For: 4.3.0
>
>
> com.cloud.exception.InternalErrorException: Failed to create vnet 987529:
> inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet
> prefix is expected rather than "239.15.3857.137".Error
> It looks like the vxlan implementation doesn't scale correctly with vxlan's
> capabilities. The VNI is supposed to be up to 24 bits (16777216), it should
> be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do
> this:
> local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256
> )).$(( $vxlanId % 256 ))"
> $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256
> On a less important note, I should point out that the bridge naming
> convention will break in certain rare situations. The max size of a bridge
> device name is 15 characters. For bond devices, a VNI above 10 million will
> not fit, e.g. "brbond0-1600", or ethernet devices above 10
> "breth10-1600". However, these may be quite rare, and changing the
> naming convention as we found in 4.2 is a bit painful if it can't be done in
> a backward compatible way. My first thought was to have vxlan and vxlan only
> use hex for it's VNI, that might be ok since it's never been released yet.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13807168#comment-13807168
]
Yoshikazu Nojima commented on CLOUDSTACK-4967:
--
{noformat}
local brif=`find ${sysfs_dir}*/brif/ -name $pif | sed -e "s,$sysfs_dir,," | sed
-e 's,/brif/.*$,,'`
{noformat}
I think you try to delete the bridge "br-", but it seems it
deletes the bridge associated with physical device ( ex. "cloudbr0").
I think you should change it to
{noformat}
local brif=`find ${sysfs_dir}*/brif/ -name $vxlanDev | sed -e "s,$sysfs_dir,,"
| sed -e 's,/brif/.*$,,'`
{noformat}
Is my understanding correct?
> vxlan doesn't scale
> ---
>
> Key: CLOUDSTACK-4967
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967
> 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: Marcus Sorensen
>Assignee: Yoshikazu Nojima
> Fix For: 4.3.0
>
>
> com.cloud.exception.InternalErrorException: Failed to create vnet 987529:
> inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet
> prefix is expected rather than "239.15.3857.137".Error
> It looks like the vxlan implementation doesn't scale correctly with vxlan's
> capabilities. The VNI is supposed to be up to 24 bits (16777216), it should
> be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do
> this:
> local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256
> )).$(( $vxlanId % 256 ))"
> $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256
> On a less important note, I should point out that the bridge naming
> convention will break in certain rare situations. The max size of a bridge
> device name is 15 characters. For bond devices, a VNI above 10 million will
> not fit, e.g. "brbond0-1600", or ethernet devices above 10
> "breth10-1600". However, these may be quite rare, and changing the
> naming convention as we found in 4.2 is a bit painful if it can't be done in
> a backward compatible way. My first thought was to have vxlan and vxlan only
> use hex for it's VNI, that might be ok since it's never been released yet.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4971) Verifying proper Setup Issues EX:Server Down, other prerequisites for test setup to minimize test script failures.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-4971: Description: 1, Currently test scripts are running despite the test setup has issues. EX: In one of the test scenario, where ldap server was down, test suite or test cases depending upon them were still running. 2, Ideally, the setup( test module setup ) should check for these dependencies before running the test script and exit wherever possible with proper log and reporting. 3, We may not be able to cover all setup issues under setup class of test module or feature test class, but the purpose of setup is also to check for its existence and dependencies. Scripts depending upon particular server conditions, should have a proper setup verifying the server existence before proceeding further. 4, I believe running test cases when setup is down is also not idealistic. 5. Purpose is to reduce script errors vs failures due to product bugs. 6. Logging this bug to track the setup issue cases or script failures. was: 1, Currently test scripts are running despite the test setup has issues. EX: In one of the test scenario, where ldap server was down, test suite or test cases depending upon them was still running. 2, Ideally, the setup should check for these dependencies before running the test script and exit wherever possible with proper log and reporting . 3, We may not be able to cover all setup issues, but the purpose of setup is also to check for its existence and dependencies. Scripts depending upon particular server conditions, should have a proper setup verifying the server existence before proceeding further. 4, I believe running test cases when setup is down is also not idealistic. 5. Purpose is to reduce script errors vs failures due to product bugs. 6. Logging this bug to track the setup issue cases or script failures. > Verifying proper Setup Issues EX:Server Down, other prerequisites for test > setup to minimize test script failures. > -- > > Key: CLOUDSTACK-4971 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4971 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: Regression,Smoke tests etc. >Reporter: Santhosh Kumar Edukulla >Assignee: sadhu suresh > > 1, Currently test scripts are running despite the test setup has issues. EX: > In one of the test scenario, where ldap server was down, test suite or test > cases depending upon them were still running. > 2, Ideally, the setup( test module setup ) should check for these > dependencies before running the test script and exit wherever possible with > proper log and reporting. > 3, We may not be able to cover all setup issues under setup class of test > module or feature test class, but the purpose of setup is also to check for > its existence and dependencies. Scripts depending upon particular server > conditions, should have a proper setup verifying the server existence before > proceeding further. > 4, I believe running test cases when setup is down is also not idealistic. > 5. Purpose is to reduce script errors vs failures due to product bugs. > 6. Logging this bug to track the setup issue cases or script failures. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4977) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niasoff closed CLOUDSTACK-4977. -- Resolution: Duplicate > Provisioning VMs from templates fails on VMWare with error > ROOT-249/ROOT-249.vmdk was not found > --- > > Key: CLOUDSTACK-4977 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4977 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0, 4.2.1 >Reporter: Daniel Niasoff > > I am unable to provision VMs from templates. > Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. > I downloaded and built 4.2.1 but still getting same issue. > Tried creating new templates and it always fails on a move file task. > Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806985#comment-13806985 ] Toshiaki Hatano commented on CLOUDSTACK-4967: - Sorry Nojima-san, I haven't noticed you've started on this. My apology for the duplication. Would you mind if I ask you to review the change? > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806976#comment-13806976 ] ASF subversion and git services commented on CLOUDSTACK-4967: - Commit 3e70b145c45126593dd3b1116a82d3cd8bc18b87 in branch refs/heads/master from [~toshiaki.hatano] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3e70b14 ] CLOUDSTACK-4967: vxlan doesn't scale - Fix inproper multicast address creation (when VNI > 65535) - Fix missing bride name in delete oparation Signed-off-by : Toshiaki Hatano > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806970#comment-13806970 ] Yoshikazu Nojima commented on CLOUDSTACK-4967: -- Hi, Toshiaki, I've already start processing this ticket. > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806951#comment-13806951 ] Toshiaki Hatano commented on CLOUDSTACK-4967: - Thanks for pointing (and testing) it out! I obviously misunderstood the order of operation. I will also fix my silly mistake in delete operation. > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4750) bond.VLAN mapping in iptables FORWARD chain not created consistently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4750:
---
Assignee: Anthony Xu
> bond.VLAN mapping in iptables FORWARD chain not created consistently
>
>
> Key: CLOUDSTACK-4750
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4750
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
> Environment: CloudStack 4.2, Advanced Zone with Security Groups,
> XenServer 6.2
>Reporter: Gerard Lynch
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: Future, 4.2.1, 4.3.0
>
>
> Create an Advanced Zone with Security Groups.
> Setup multiple subnets using multiple VLANs (e.g.
> 1230,1231,1232,1233,1234,1235) on a physical network labelled GUEST.
> Run up VM's in each network
> *Issue:*
> bond.VLAN interface does not consistently get added to the FORWARD chain in
> iptables preventing connectivity to/from a VM
> e.g. if I run up a machine on VLAN 1233
> Looking through the management-server.log files I see it setting it up:
> [root@csm1 management]# zcat management-server.log.2013-09-26.gz | grep 1233
> -A 5 -B 5
> ...
> 2013-09-26 18:52:27,850 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Creating VIF for i-2-22-VM on nic
> [Nic:Guest-192.168.3.69-vlan://1233]
> 2013-09-26 18:52:27,852 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Looking for network named GUEST
> 2013-09-26 18:52:27,882 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Found a network called GUEST on host=10.1.2.3;
> Network=ceb6ea91-de34-cf95-5326-f865be6851a2;
> pif=5884f784-f9ce-58a6-517f-30caa04e67be
> 2013-09-26 18:52:27,883 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Creating VLAN 1233 on host 10.1.2.3 on device bond2
> 2013-09-26 18:52:28,482 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-8:null) Seq 9-390463667: Response Received:
> 2013-09-26 18:52:28,482 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 9-390463667: Received: { Ans: , MgmtId:
> 345052351047, via: 9, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2013-09-26 18:52:28,488 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-427:null) Seq 10-1220149422: Executing request
> 2013-09-26 18:52:28,637 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) VLAN is created for 1233. The uuid is
> 85d5ad86-40e6-8e6c-e1a6-254ea64df8cd
> 2013-09-26 18:52:28,646 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Created a vif b57fdf9e-7d90-7689-0eee-9ad550951189 on 0
> 2013-09-26 18:52:29,262 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-427:null) Seq 10-1220149422: Response Received:
> 2013-09-26 18:52:29,263 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 10-1220149422: Received: { Ans: , MgmtId:
> 345052351047, via: 10, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> …
> I inspect the host machine however and see
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>94 7460 BRIDGE-FIREWALL all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond2.1234 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond2.1230 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth2 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond0 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth3 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth6 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth4 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth7 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth10 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/0
[jira] [Updated] (CLOUDSTACK-4750) bond.VLAN mapping in iptables FORWARD chain not created consistently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4750:
---
Fix Version/s: (was: Future)
> bond.VLAN mapping in iptables FORWARD chain not created consistently
>
>
> Key: CLOUDSTACK-4750
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4750
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
> Environment: CloudStack 4.2, Advanced Zone with Security Groups,
> XenServer 6.2
>Reporter: Gerard Lynch
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.2.1, 4.3.0
>
>
> Create an Advanced Zone with Security Groups.
> Setup multiple subnets using multiple VLANs (e.g.
> 1230,1231,1232,1233,1234,1235) on a physical network labelled GUEST.
> Run up VM's in each network
> *Issue:*
> bond.VLAN interface does not consistently get added to the FORWARD chain in
> iptables preventing connectivity to/from a VM
> e.g. if I run up a machine on VLAN 1233
> Looking through the management-server.log files I see it setting it up:
> [root@csm1 management]# zcat management-server.log.2013-09-26.gz | grep 1233
> -A 5 -B 5
> ...
> 2013-09-26 18:52:27,850 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Creating VIF for i-2-22-VM on nic
> [Nic:Guest-192.168.3.69-vlan://1233]
> 2013-09-26 18:52:27,852 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Looking for network named GUEST
> 2013-09-26 18:52:27,882 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Found a network called GUEST on host=10.1.2.3;
> Network=ceb6ea91-de34-cf95-5326-f865be6851a2;
> pif=5884f784-f9ce-58a6-517f-30caa04e67be
> 2013-09-26 18:52:27,883 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Creating VLAN 1233 on host 10.1.2.3 on device bond2
> 2013-09-26 18:52:28,482 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-8:null) Seq 9-390463667: Response Received:
> 2013-09-26 18:52:28,482 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 9-390463667: Received: { Ans: , MgmtId:
> 345052351047, via: 9, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2013-09-26 18:52:28,488 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-427:null) Seq 10-1220149422: Executing request
> 2013-09-26 18:52:28,637 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) VLAN is created for 1233. The uuid is
> 85d5ad86-40e6-8e6c-e1a6-254ea64df8cd
> 2013-09-26 18:52:28,646 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-20:null) Created a vif b57fdf9e-7d90-7689-0eee-9ad550951189 on 0
> 2013-09-26 18:52:29,262 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-427:null) Seq 10-1220149422: Response Received:
> 2013-09-26 18:52:29,263 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 10-1220149422: Received: { Ans: , MgmtId:
> 345052351047, via: 10, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> …
> I inspect the host machine however and see
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>94 7460 BRIDGE-FIREWALL all -- * * 0.0.0.0/0
> 0.0.0.0/0 PHYSDEV match --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond2.1234 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond2.1230 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth2 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out bond0 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth3 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth6 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth4 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth7 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
> PHYSDEV match --physdev-out eth10 --physdev-is-bridged
> 0 0 ACCEPT all -- * * 0.0.0.0/0
[jira] [Updated] (CLOUDSTACK-4978) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niasoff updated CLOUDSTACK-4978: --- Attachment: apilog.log API Log > Provisioning VMs from templates fails on VMWare with error > ROOT-249/ROOT-249.vmdk was not found > --- > > Key: CLOUDSTACK-4978 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4978 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0, 4.2.1 >Reporter: Daniel Niasoff > Attachments: apilog.log, management-server.log > > > I am unable to provision VMs from templates. > Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. > I downloaded and built 4.2.1 but still getting same issue. > Tried creating new templates and it always fails on a move file task. > Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4978) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niasoff updated CLOUDSTACK-4978: --- Attachment: management-server.log management server logs > Provisioning VMs from templates fails on VMWare with error > ROOT-249/ROOT-249.vmdk was not found > --- > > Key: CLOUDSTACK-4978 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4978 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0, 4.2.1 >Reporter: Daniel Niasoff > Attachments: management-server.log > > > I am unable to provision VMs from templates. > Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. > I downloaded and built 4.2.1 but still getting same issue. > Tried creating new templates and it always fails on a move file task. > Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4979) DeployVM: automatically generated hostName is not RFC compliant
Alena Prokharchyk created CLOUDSTACK-4979:
-
Summary: DeployVM: automatically generated hostName is not RFC
compliant
Key: CLOUDSTACK-4979
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4979
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Alena Prokharchyk
Assignee: Kelven Yang
Fix For: Future
When no hostName is passed in to the deployVM call, we generate random UUID.
But this uuid is not compliant with RFC for the hostName as it always starts
with the digit. Here are all the rules for the hostName:
// must be between 1 and 63 characters long and may contain only the ASCII
letters 'a' through 'z' (in a
// case-insensitive manner),
// the digits '0' through '9', and the hyphen ('-').
// Can not start with a hyphen and digit, and must not end with a hyphen
// If it's a host name, don't allow to start with digit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-4977) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
Daniel Niasoff created CLOUDSTACK-4977: -- Summary: Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found Key: CLOUDSTACK-4977 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4977 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.2.1 Reporter: Daniel Niasoff I am unable to provision VMs from templates. Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. I downloaded and built 4.2.1 but still getting same issue. Tried creating new templates and it always fails on a move file task. Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4978) Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found
Daniel Niasoff created CLOUDSTACK-4978: -- Summary: Provisioning VMs from templates fails on VMWare with error ROOT-249/ROOT-249.vmdk was not found Key: CLOUDSTACK-4978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4978 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.2.1 Reporter: Daniel Niasoff I am unable to provision VMs from templates. Getting error "ROOT-249/ROOT-249.vmdk was not found" in VMWare console. I downloaded and built 4.2.1 but still getting same issue. Tried creating new templates and it always fails on a move file task. Any ideas? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-1819) AWS Regions - Issues seen when trying to move a zone from 1 region to another.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-1819: - Priority: Critical (was: Major) > AWS Regions - Issues seen when trying to move a zone from 1 region to another. > -- > > Key: CLOUDSTACK-1819 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1819 > Project: CloudStack > Issue Type: Bug > Components: Management Server >Affects Versions: 4.1.0, 4.2.0 > Environment: Build from 4.1 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.3.0 > > Attachments: Region.rar > > > Issues seen when trying to move a zone from 1 region to another. > Steps followed: > For Region1: > 1. Configured management server with 2 zones. > Registered few templates and deployed few Vms in both the zones. > 2. Disable all the zones in region 1 > 3. Dump region 1 DB ( mysqldump -u cloud -p -h cloud > > region1.sql) > 4. Stop management server. > For Region2: > 4. Install another management server for region 2. > 5. Set the region_id while installing the DB ( > cloud-setup-databases cloud:@localhost > --deploy-as=root: -e -m > -k -r ) > 6. Stop management server. > 7. Copy region 1 DB to to this region ( mysql -u cloud -p -h > cloud < region1.sql ) > 8. Start all management servers. At this point all the zones are disabled > 9. Enable zone1 in region1. > 10. Enable zone2 in region2. > Issues Found after following the above steps: > 1. UI for region1 and region2 shows details relating to all the Zones ( > including the disabled zones). This is very confusing to see VMs/Templates > from both the regions being listed in the region that does not service the > region anymore. > 2. Console Proxy view does not work for the newly deployed Vms in region2. > 3. Not able to register a new template in region2. > 4. Region_Id gets over-ridden when the the DB dump from region1 is copied > over to region2. > In case of KVM hosts , What is the suggested solution for these hosts to > migrate to another zone ? The cloud agent running in these hosts will still > be trying to contact management server from region1. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4594) [VMWARE] [Upgrade] Failed to revert VM Snapshot which were created before Live Storage Migrating the VM to other Cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806919#comment-13806919
]
Sudha Ponnaganti commented on CLOUDSTACK-4594:
--
Can this be tried with same version of ESXi - 5x taking out 4x in the env.
> [VMWARE] [Upgrade] Failed to revert VM Snapshot which were created before
> Live Storage Migrating the VM to other Cluster
>
>
> Key: CLOUDSTACK-4594
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4594
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar
>
>
> Upgraded setup :
> 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1
> host)
> 1.11 Vm’s deployed with 2 VM’s in stopped state
> 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes
> 3.Snapshots , Template / volumes from this snapshot
> 4.Detached volumes
> 5.Empty volumes which are not attached to any instance
> 6.Cluster with 2 primary storage's
> Upgraded to 4.2
> 1. Stop and Start the VM which is created prior to upgrade. Ensure that from
> Volume table disk (chian_info) got updated for all the volumes of this
> instance
> 2. Take 3 VM snapshots with some files in each snapshot
> 3. Perform Live Storage migration of this VM to a different cluster.
> 4. Tried to revert the VM to one of the old VM Snapshot which were created
> before Live Storage Migration .
> Observation:
> 1. Failed to revert VM Snapshot which were created before Live Storage
> Migrating the VM to other Cluster
> 2. Only VM can be reverted only to the VM Snapshots which are created after
> Live Storage Migration on Cluster2
> 2013-09-02 22:16:22,395 ERROR [vmware.manager.VmwareStorageManagerImpl]
> (DirectAgent-478:10.102.192.20) revert vm i-3-14-VM to snapshot
> i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing call information for method RevertToSnapshot_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method revert
> on object of type vim.vm.Snapshot
> at line 1, column 0
> 2013-09-02 22:16:22,395 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-478:null) Seq 1-693897047: Response Received:
> 2013-09-02 22:16:22,396 DEBUG [agent.transport.Request]
> (DirectAgent-478:null) Seq 1-693897047: Processing: { Ans: , MgmtId:
> 227594284004867, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.RevertToVMSnapshotAnswer":{"result":false,"details":"revert
> vm i-3-14-VM to snapshot i-3-14-VM_VS_20130902160037 failed due to \nGot
> tag when expecting <_this> tag\n\nwhile parsing call information for
> method RevertToSnapshot_Task\nat line 1, column 110\n\nwhile parsing SOAP
> body\nat line 1, column 102\n\nwhile parsing SOAP envelope\nat line 1, column
> 38\n\nwhile parsing HTTP request for method revert\non object of type
> vim.vm.Snapshot\nat line 1, column 0","wait":0}}] }
> 2013-09-02 22:16:22,396 DEBUG [agent.transport.Request]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ]) Seq
> 1-693897047: Received: { Ans: , MgmtId: 227594284004867, via: 1, Ver: v1,
> Flags: 10, { RevertToVMSnapshotAnswer } }
> 2013-09-02 22:16:22,396 ERROR [vm.snapshot.VMSnapshotManagerImpl]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ]) Revert
> VM: i-3-14-VM to snapshot: i-3-14-VM_VS_20130902160037 failed due to revert
> vm i-3-14-VM to snapshot i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing call information for method RevertToSnapshot_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method revert
> on object of type vim.vm.Snapshot
> at line 1, column 0
> 2013-09-02 22:16:22,416 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Revert VM: i-3-14-VM to
> snapshot: i-3-14-VM_VS_20130902160037 failed due to revert vm i-3-14-VM to
> snapshot i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing
[jira] [Updated] (CLOUDSTACK-4594) [VMWARE] [Upgrade] Failed to revert VM Snapshot which were created before Live Storage Migrating the VM to other Cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4594:
---
Assignee: (was: Kelven Yang)
> [VMWARE] [Upgrade] Failed to revert VM Snapshot which were created before
> Live Storage Migrating the VM to other Cluster
>
>
> Key: CLOUDSTACK-4594
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4594
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar
>
>
> Upgraded setup :
> 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1
> host)
> 1.11 Vm’s deployed with 2 VM’s in stopped state
> 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes
> 3.Snapshots , Template / volumes from this snapshot
> 4.Detached volumes
> 5.Empty volumes which are not attached to any instance
> 6.Cluster with 2 primary storage's
> Upgraded to 4.2
> 1. Stop and Start the VM which is created prior to upgrade. Ensure that from
> Volume table disk (chian_info) got updated for all the volumes of this
> instance
> 2. Take 3 VM snapshots with some files in each snapshot
> 3. Perform Live Storage migration of this VM to a different cluster.
> 4. Tried to revert the VM to one of the old VM Snapshot which were created
> before Live Storage Migration .
> Observation:
> 1. Failed to revert VM Snapshot which were created before Live Storage
> Migrating the VM to other Cluster
> 2. Only VM can be reverted only to the VM Snapshots which are created after
> Live Storage Migration on Cluster2
> 2013-09-02 22:16:22,395 ERROR [vmware.manager.VmwareStorageManagerImpl]
> (DirectAgent-478:10.102.192.20) revert vm i-3-14-VM to snapshot
> i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing call information for method RevertToSnapshot_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method revert
> on object of type vim.vm.Snapshot
> at line 1, column 0
> 2013-09-02 22:16:22,395 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-478:null) Seq 1-693897047: Response Received:
> 2013-09-02 22:16:22,396 DEBUG [agent.transport.Request]
> (DirectAgent-478:null) Seq 1-693897047: Processing: { Ans: , MgmtId:
> 227594284004867, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.RevertToVMSnapshotAnswer":{"result":false,"details":"revert
> vm i-3-14-VM to snapshot i-3-14-VM_VS_20130902160037 failed due to \nGot
> tag when expecting <_this> tag\n\nwhile parsing call information for
> method RevertToSnapshot_Task\nat line 1, column 110\n\nwhile parsing SOAP
> body\nat line 1, column 102\n\nwhile parsing SOAP envelope\nat line 1, column
> 38\n\nwhile parsing HTTP request for method revert\non object of type
> vim.vm.Snapshot\nat line 1, column 0","wait":0}}] }
> 2013-09-02 22:16:22,396 DEBUG [agent.transport.Request]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ]) Seq
> 1-693897047: Received: { Ans: , MgmtId: 227594284004867, via: 1, Ver: v1,
> Flags: 10, { RevertToVMSnapshotAnswer } }
> 2013-09-02 22:16:22,396 ERROR [vm.snapshot.VMSnapshotManagerImpl]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ]) Revert
> VM: i-3-14-VM to snapshot: i-3-14-VM_VS_20130902160037 failed due to revert
> vm i-3-14-VM to snapshot i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing call information for method RevertToSnapshot_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method revert
> on object of type vim.vm.Snapshot
> at line 1, column 0
> 2013-09-02 22:16:22,416 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-83:job-159 = [ 01c20b29-a7d4-4066-8329-0c15b8867b37 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.vmsnapshot.RevertToVMSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Revert VM: i-3-14-VM to
> snapshot: i-3-14-VM_VS_20130902160037 failed due to revert vm i-3-14-VM to
> snapshot i-3-14-VM_VS_20130902160037 failed due to
> Got tag when expecting <_this> tag
> while parsing call information for method RevertToSnapshot_Task
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> wh
[jira] [Assigned] (CLOUDSTACK-4967) vxlan doesn't scale
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoshikazu Nojima reassigned CLOUDSTACK-4967: Assignee: Yoshikazu Nojima (was: Toshiaki Hatano) > vxlan doesn't scale > --- > > Key: CLOUDSTACK-4967 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4967 > 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: Marcus Sorensen >Assignee: Yoshikazu Nojima > Fix For: 4.3.0 > > > com.cloud.exception.InternalErrorException: Failed to create vnet 987529: > inet 172.17.10.10/24 brd 172.17.10.255 scope global cloudbr0Error: an inet > prefix is expected rather than "239.15.3857.137".Error > It looks like the vxlan implementation doesn't scale correctly with vxlan's > capabilities. The VNI is supposed to be up to 24 bits (16777216), it should > be possible to use high VNI numbers. The script 'modifyvxlan.sh' seems to do > this: > local mcastGrp="239.$(( $vxlanId >> 16 % 256 )).$(( $vxlanId >> 8 % 256 > )).$(( $vxlanId % 256 ))" > $vlanid >> 8 %256 (and similar) may need to be ($vxlanId >> 8) % 256 > On a less important note, I should point out that the bridge naming > convention will break in certain rare situations. The max size of a bridge > device name is 15 characters. For bond devices, a VNI above 10 million will > not fit, e.g. "brbond0-1600", or ethernet devices above 10 > "breth10-1600". However, these may be quite rare, and changing the > naming convention as we found in 4.2 is a bit painful if it can't be done in > a backward compatible way. My first thought was to have vxlan and vxlan only > use hex for it's VNI, that might be ok since it's never been released yet. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4975) NPE while deleting the volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-4975:
---
Assignee: Likitha Shetty
> NPE while deleting the volume
> -
>
> Key: CLOUDSTACK-4975
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4975
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: newlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with VMWARE Hypervisor
> 2. Created shared network with ROOT domain as scope
> 3. Created a user account and deployed VM using this shared network
> 4. After VM is up and running , Destroy the VM
> Observation:
> Observed NPE while deleting the volume.
> 2013-10-28 14:24:07,209 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Executing resource DestroyCommand:
> {"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"739f096d-1b1d-4c20-895f-c416c95bace5","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"7e18404c-acd1-3b13-9c9c-bbaf2d28bccd","id":4,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/newdixonps3","port":2049}},"name":"ROOT-205","size":2147483648,"path":"ROOT-205","volumeId":217,"vmName":"i-6-205-userinstance","accountId":6,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[7e18404cacd13b139c9cbbaf2d28bccd]
>
> i-6-205-userinstance/ROOT-205.vmdk\"]}","format":"OVA","id":217,"hypervisorType":"VMware"}},"wait":0}
> 2013-10-28 14:24:07,343 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Destroy root volume and VM itself. vmName
> i-6-205-userinstance
> 2013-10-28 14:24:07,376 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:07,383 DEBUG [vmware.mo.VirtualMachineMO]
> (DirectAgent-442:10.102.192.23) Retrieved 1 networks with key : 2
> 2013-10-28 14:24:07,414 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:10,374 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:10,398 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:12,978 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Processing Seq 3-66860: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-10-28 14:24:12,984 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Sending Seq 3-66860: { Ans: ,
> MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-10-28 14:24:13,371 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-375:null) Ping from 5
> 2013-10-28 14:24:13,585 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:13,606 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:23,403 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (UserVm-Scavenger-1:null) Stopped called on VM[User|newuser1f5instance1] but
> the state is Expunging
> 2013-10-28 14:24:23,412 DEBUG [cloud.capacity.CapacityManagerImpl]
> (UserVm-Scavenger-1:null) VM state transitted from :Expunging to Expunging
> with event: ExpungeOperationvm's original host id: 1 new host id: null host
> id before state transition: null
> 2013-10-28 14:
[jira] [Commented] (CLOUDSTACK-4943) Can't create cluster in CS 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806828#comment-13806828 ] Ryan Lei commented on CLOUDSTACK-4943: -- Can you mark the Fix Versions to 4.2.1 and 4.3.0? Leaving it blank may let this issue go unnoticed. > Can't create cluster in CS 4.2 > -- > > Key: CLOUDSTACK-4943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4943 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: CloudStack 4.2 + Centos6.4 + vmware 5.1 >Reporter: Denis Finko >Priority: Critical > > I am tring to configure CloudStack 4.2 (installed from cloudstack repo > baseurl=http://cloudstack.apt-get.eu/rhel/4.2/) with VMware 5.1. During > adding new zone into user interface I have got following error: > "Unable to add the external cluster" > We have following networking configuration in vSphere Client: > Standard Switch: vSwitch0 > -Virtual Machine Port Group (VM Network) --vmnic0 > -VMkernel Port (Management Network) > Standard Switch: vSwitch1 > -VMkernel Port (Storage1) --vmnic2 > management-server.log: > 2013-10-23 05:36:03,534 DEBUG [cloud.api.ApiServlet] > (catalina-exec-22:null) ===START=== 193.142.124.9 -- GET > command=addCluster&zoneId=4f28654f-e767-4be2-b32f-39f634a01746&hypervisor=VMware&clustertype=ExternalManaged&podId=94e55d0c-3ea9-4dbc-800b-854262fd2674&username=Administrator&url=http%3A%2F%2F10.199.0.40%2Fcs4%2Fcs4it&clustername=10.199.0.40%2Fcs4%2Fcs4it&response=json&sessionkey=uAl68djojOPwUBfhwxw8OwodZuE%3D&_=1382520964075 > 2013-10-23 05:36:03,643 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Discover host. dc: 1, pod: 1, cluster: 1, uri > host: 10.199.0.40 > 2013-10-23 05:36:03,689 INFO [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Detected private network label : vSwitch0, > 2013-10-23 05:36:03,689 DEBUG [vmware.resource.VmwareContextFactory] > (catalina-exec-22:null) initialize VmwareContext. url: > https://10.199.0.40/sdk/vimService, username: Administrator, password: > r*** > 2013-10-23 05:36:03,817 INFO [vmware.util.VmwareContext] > (catalina-exec-22:null) New VmwareContext object, current outstanding > count: 1 > 2013-10-23 05:36:03,952 INFO [vmware.manager.VmwareManagerImpl] > (catalina-exec-22:null) Preparing network on host > com.cloud.hypervisor.vmware.util.VmwareContext@60e2e3d4 for vSwitch0, > 2013-10-23 05:36:03,999 ERROR [vmware.mo.HypervisorHostHelper] > (catalina-exec-22:null) Unable to find vSwitchvSwitch0, > 2013-10-23 05:36:03,999 WARN [hypervisor.vmware.VmwareServerDiscoverer] > (catalina-exec-22:null) Unable to connect to Vmware vSphere server. > service address: 10.199.0.40 > 2013-10-23 05:36:04,012 WARN [cloud.resource.ResourceManagerImpl] > (catalina-exec-22:null) Unable to find the server resources at > http://10.199.0.40/cs4/cs4it > 2013-10-23 05:36:04,014 INFO [utils.exception.CSExceptionErrorCode] > (catalina-exec-22:null) Could not find exception: > com.cloud.exception.DiscoveryException in error code list for exceptions > 2013-10-23 05:36:04,095 WARN [admin.cluster.AddClusterCmd] > (catalina-exec-22:null) Exception: > com.cloud.exception.DiscoveryException: Unable to add the external cluster > at > com.cloud.resource.ResourceManagerImpl.discoverCluster(ResourceManagerImpl.java:533) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.admin.cluster.AddClusterCmd.execute(AddClusterCmd.java:181) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(Er
[jira] [Commented] (CLOUDSTACK-4968) Support multiple subnets in shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806812#comment-13806812 ] Nux commented on CLOUDSTACK-4968: - OMG, wait, I found it. Clicked on "defaultGuestNetwork" then "IP ranges" and here I have this option.. Sorry for wasting your time! :) > Support multiple subnets in shared network > -- > > Key: CLOUDSTACK-4968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4968 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nux >Assignee: Bharat Kumar > Labels: features, ip, network > > Hello, > I'm testing CS for selling VPSes and would like to use the newly "shared > network with SG" feature, but there's one problem - it does not accept > multiple subnets or IP allocations. > Right now when the active subnet runs out that's it, one can no longer create > VMs, this is bad for business. :) > This problem is handled well in the "basic network zone" where one can simply > add more subnets as required. Can something similar be done to solve this > issue? > Thanks, > Lucian -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4968) Support multiple subnets in shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806803#comment-13806803 ] Nux commented on CLOUDSTACK-4968: - I went to Infrastructure -> Zones -> ZoneName -> Physical Network 1 -> defaultGuestNetwork (shared). Here what I need to do basically is to add another IPv4 CIDR, but I do not see any option for it. All I see is "Add guest network", which doesn't help me. Regards, Lucian > Support multiple subnets in shared network > -- > > Key: CLOUDSTACK-4968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4968 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nux >Assignee: Bharat Kumar > Labels: features, ip, network > > Hello, > I'm testing CS for selling VPSes and would like to use the newly "shared > network with SG" feature, but there's one problem - it does not accept > multiple subnets or IP allocations. > Right now when the active subnet runs out that's it, one can no longer create > VMs, this is bad for business. :) > This problem is handled well in the "basic network zone" where one can simply > add more subnets as required. Can something similar be done to solve this > issue? > Thanks, > Lucian -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806784#comment-13806784 ] Abhinandan Prateek edited comment on CLOUDSTACK-4976 at 10/28/13 2:10 PM: -- Does it happen with any other windows OS ? Looks like a Xenserver issue assigning to Anthony and decreasing criticality. was (Author: aprateek): Does it happen with any other windows OS ? > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806784#comment-13806784 ] Abhinandan Prateek commented on CLOUDSTACK-4976: Does it happen with any other windows OS ? > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4976: --- Assignee: Anthony Xu > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4976: --- Priority: Critical (was: Blocker) > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Priority: Critical > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4968) Support multiple subnets in shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806757#comment-13806757 ] Bharat Kumar commented on CLOUDSTACK-4968: -- We support this feature for shared network with sg service. please give some additional info like steps that were taken to add the additional subnet. > Support multiple subnets in shared network > -- > > Key: CLOUDSTACK-4968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4968 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nux > Labels: features, ip, network > > Hello, > I'm testing CS for selling VPSes and would like to use the newly "shared > network with SG" feature, but there's one problem - it does not accept > multiple subnets or IP allocations. > Right now when the active subnet runs out that's it, one can no longer create > VMs, this is bad for business. :) > This problem is handled well in the "basic network zone" where one can simply > add more subnets as required. Can something similar be done to solve this > issue? > Thanks, > Lucian -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4968) Support multiple subnets in shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-4968: - Assignee: Bharat Kumar > Support multiple subnets in shared network > -- > > Key: CLOUDSTACK-4968 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4968 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nux >Assignee: Bharat Kumar > Labels: features, ip, network > > Hello, > I'm testing CS for selling VPSes and would like to use the newly "shared > network with SG" feature, but there's one problem - it does not accept > multiple subnets or IP allocations. > Right now when the active subnet runs out that's it, one can no longer create > VMs, this is bad for business. :) > This problem is handled well in the "basic network zone" where one can simply > add more subnets as required. Can something similar be done to solve this > issue? > Thanks, > Lucian -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4750) bond.VLAN mapping in iptables FORWARD chain not created consistently
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerard Lynch updated CLOUDSTACK-4750:
-
Description:
Create an Advanced Zone with Security Groups.
Setup multiple subnets using multiple VLANs (e.g.
1230,1231,1232,1233,1234,1235) on a physical network labelled GUEST.
Run up VM's in each network
*Issue:*
bond.VLAN interface does not consistently get added to the FORWARD chain in
iptables preventing connectivity to/from a VM
e.g. if I run up a machine on VLAN 1233
Looking through the management-server.log files I see it setting it up:
[root@csm1 management]# zcat management-server.log.2013-09-26.gz | grep 1233 -A
5 -B 5
...
2013-09-26 18:52:27,850 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) Creating VIF for i-2-22-VM on nic
[Nic:Guest-192.168.3.69-vlan://1233]
2013-09-26 18:52:27,852 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) Looking for network named GUEST
2013-09-26 18:52:27,882 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) Found a network called GUEST on host=10.1.2.3;
Network=ceb6ea91-de34-cf95-5326-f865be6851a2;
pif=5884f784-f9ce-58a6-517f-30caa04e67be
2013-09-26 18:52:27,883 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) Creating VLAN 1233 on host 10.1.2.3 on device bond2
2013-09-26 18:52:28,482 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-8:null) Seq 9-390463667: Response Received:
2013-09-26 18:52:28,482 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 9-390463667: Received: { Ans: , MgmtId: 345052351047, via: 9, Ver: v1,
Flags: 10, { GetStorageStatsAnswer } }
2013-09-26 18:52:28,488 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-427:null) Seq 10-1220149422: Executing request
2013-09-26 18:52:28,637 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) VLAN is created for 1233. The uuid is
85d5ad86-40e6-8e6c-e1a6-254ea64df8cd
2013-09-26 18:52:28,646 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-20:null) Created a vif b57fdf9e-7d90-7689-0eee-9ad550951189 on 0
2013-09-26 18:52:29,262 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-427:null) Seq 10-1220149422: Response Received:
2013-09-26 18:52:29,263 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 10-1220149422: Received: { Ans: , MgmtId: 345052351047, via: 10, Ver: v1,
Flags: 10, { GetStorageStatsAnswer } }
…
I inspect the host machine however and see
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
94 7460 BRIDGE-FIREWALL all -- * * 0.0.0.0/0
0.0.0.0/0 PHYSDEV match --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out bond2.1234 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out bond2.1230 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth2 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out bond0 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth3 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth6 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth4 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth7 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth10 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out bond2 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth11 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth9 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth5 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth8 --physdev-is-bridged
0 0 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0
PHYSDEV match --physdev-out eth1 --physdev-is-bridged
0 0 ACCE
[jira] [Updated] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-4976: - Attachment: PVDriver_BSOD.jpg > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
Pavan Kumar Bandarupally created CLOUDSTACK-4976: Summary: BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 Key: CLOUDSTACK-4976 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Environment: Before Upgrade: CS: 3.0.7 Patch_B XS: 5.6 SP2 After Upgrade: CS: 4.2.1 XS: 6.2 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.2.1 Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to 6.2. A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers installed. After upgrade when we try to restart the VM, a BSOD occurs and the VM reverts to system recovery screen. Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4599) GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806732#comment-13806732 ] Murali Reddy commented on CLOUDSTACK-4599: -- I happened to hit exact error on XS6.2 as well. Investigation the cause of failure. > GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1 > > > Key: CLOUDSTACK-4599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Network Devices, XenServer >Affects Versions: 4.1.1 > Environment: Management server: CentOS 6.4 x86_64, CentOS Plus repo > enabled, also pri/sec storage NFS server > Hosts: XenServer 6.1, included OVS (1.4.2?) > All the above running on ESX 5.1 (but I don't think it's a factor), with > recommended CPU and RAM configurations. >Reporter: David Black >Assignee: Murali Reddy > Attachments: management-server.log, SMlog.cs-host1, SMlog.cs-host2 > > > Each hypervisor has two NICs, one on a public/management network, the other > dedicated to private/isolated traffic. Both NICs (as xenbrX) have IP > addresses and each host can reach the other over the respective bridge IP > addresses. The bridge networks are labeled Public (xenbr0) and Private > (xenbr1). The xenbr1 bridge IP subnet has no default gateway as it's there > only for the tunnel endpoints on each host. > Guest networking is configured to be on the Private label, isolation type > GRE. In addition, in Global Settings, > sdn.ovs.controller = true and sdn.ovs.controller.default.label = Private. I > tried VLAN (vNet) ranges of 1-4094 and 0-2147483647. In the below example > it was set to the latter and picked 10960. > BTW, it took quite a bit of scouring the net to find out how to config and > what hypervisor (XenServer only) GRE tunnels should work with, in 4.1.1. > Also, I'd prefer to use KVM but understand that support is also in the > process of being implemented. > I had initially tried using XCP 1.6 and received a different error, then > realized XCP support isn't yet finished. I thought XenServer 6.1 should work > though. The xapiX bridges are set up on the host and a vifX.Y appears to be > added for the tunnel endpoints, then the next step - I guess creating the > tunnel itself, fails. In this example, both the virtual router and single > isolated VM were on the same host... but I also could not migrate either one, > receiving a "VM requires network" error. I won't provide details of that > second error right now, but can if desired. Below is an excerpt of the > management log > Please let me know what other details to provide. If desired, I can arrange > access to the vCloud Director system on which it's running, preferably via > IPv6 and/or of course collect more logs, run tests, etc. > 2013-09-02 22:11:38,508 DEBUG [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) Xen Server network for tunnels found:OVSTunnel10960 > 2013-09-02 22:11:38,579 DEBUG [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) Create a vif on dom0 for tunnel network for account > 10960 > 2013-09-02 22:11:38,873 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) createandConfigureTunnelNetwork failed > The server failed to handle your request, due to an internal error. The > given message may give details useful for debugging the problem. > at com.xensource.xenapi.Types.checkResponse(Types.java:1694) > 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.VIF.plug(VIF.java:846) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:655) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.configureTunnelNetwork(CitrixResourceBase.java:745) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5135) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:541) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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:16
[jira] [Assigned] (CLOUDSTACK-4599) GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy reassigned CLOUDSTACK-4599: Assignee: Murali Reddy > GRE isolation - createandConfigureTunnelNetwork failing on XenServer 6.1 > > > Key: CLOUDSTACK-4599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4599 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Network Devices, XenServer >Affects Versions: 4.1.1 > Environment: Management server: CentOS 6.4 x86_64, CentOS Plus repo > enabled, also pri/sec storage NFS server > Hosts: XenServer 6.1, included OVS (1.4.2?) > All the above running on ESX 5.1 (but I don't think it's a factor), with > recommended CPU and RAM configurations. >Reporter: David Black >Assignee: Murali Reddy > Attachments: management-server.log, SMlog.cs-host1, SMlog.cs-host2 > > > Each hypervisor has two NICs, one on a public/management network, the other > dedicated to private/isolated traffic. Both NICs (as xenbrX) have IP > addresses and each host can reach the other over the respective bridge IP > addresses. The bridge networks are labeled Public (xenbr0) and Private > (xenbr1). The xenbr1 bridge IP subnet has no default gateway as it's there > only for the tunnel endpoints on each host. > Guest networking is configured to be on the Private label, isolation type > GRE. In addition, in Global Settings, > sdn.ovs.controller = true and sdn.ovs.controller.default.label = Private. I > tried VLAN (vNet) ranges of 1-4094 and 0-2147483647. In the below example > it was set to the latter and picked 10960. > BTW, it took quite a bit of scouring the net to find out how to config and > what hypervisor (XenServer only) GRE tunnels should work with, in 4.1.1. > Also, I'd prefer to use KVM but understand that support is also in the > process of being implemented. > I had initially tried using XCP 1.6 and received a different error, then > realized XCP support isn't yet finished. I thought XenServer 6.1 should work > though. The xapiX bridges are set up on the host and a vifX.Y appears to be > added for the tunnel endpoints, then the next step - I guess creating the > tunnel itself, fails. In this example, both the virtual router and single > isolated VM were on the same host... but I also could not migrate either one, > receiving a "VM requires network" error. I won't provide details of that > second error right now, but can if desired. Below is an excerpt of the > management log > Please let me know what other details to provide. If desired, I can arrange > access to the vCloud Director system on which it's running, preferably via > IPv6 and/or of course collect more logs, run tests, etc. > 2013-09-02 22:11:38,508 DEBUG [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) Xen Server network for tunnels found:OVSTunnel10960 > 2013-09-02 22:11:38,579 DEBUG [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) Create a vif on dom0 for tunnel network for account > 10960 > 2013-09-02 22:11:38,873 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-407:null) createandConfigureTunnelNetwork failed > The server failed to handle your request, due to an internal error. The > given message may give details useful for debugging the problem. > at com.xensource.xenapi.Types.checkResponse(Types.java:1694) > 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.VIF.plug(VIF.java:846) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.enableXenServerNetwork(CitrixResourceBase.java:655) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.configureTunnelNetwork(CitrixResourceBase.java:745) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5135) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:541) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > 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$101(ScheduledT
[jira] [Resolved] (CLOUDSTACK-4962) router VM failed to start on KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-4962.
---
Resolution: Fixed
ssh client is not installed on the KVM host. VR started successfully after
installing ssh client.
> router VM failed to start on KVM
> -
>
> Key: CLOUDSTACK-4962
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4962
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Virtual Router
>Affects Versions: 4.2.1
> Environment: have a advance zone with KVM
> KVM on centos6.4
> MS on centos6.4
> SystemVM templete seeded
> http://nfs1.lab.vmops.com/templates/campo_qa/systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2
> Build :
> CloudPlatform-4.2.1-22-rhel6.4.tar.gz
>Reporter: shweta agarwal
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: agent.log, management-server.log.tar.gz
>
>
> Repro steps:
> Setup an advance zone and try to create a VM
> Bug: Router VM failed to start
> MS shows :
> 2013-10-25 15:48:11,672 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 1-580780059: Processing: { Ans: , MgmtId:
> 233845177509810, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":4,"name":"r-4-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-4-VM
> eth2ip=10.147.51.12 eth2mask=255.255.255.0 gateway=10.147.51.1
> eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
> dhcprange=10.1.1.1 eth1ip=169.254.1.72 eth1mask=255.255.0.0 type=router
> disable_rp_filter=true
> dns1=10.103.128.16","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"942ed47654205cb4","vncAddr":"10.147.40.27","params":{},"uuid":"065375b6-d32d-4bfe-8b6e-e4dcc23f158e","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"cf634689-b1f5-45d6-807e-9b78689612b1","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96cdf130-10ea-3765-9017-315b02d94ec4","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/dixon.kvm.primary","port":2049}},"name":"ROOT-4","size":276162048,"path":"148d97cd-c173-4904-a7ff-e6dafc7420bd","volumeId":5,"vmName":"r-4-VM","accountId":2,"format":"QCOW2","id":5,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"}],"nics":[{"deviceId":2,"networkRateMbps":200,"defaultNic":true,"uuid":"223a9278-ba80-4271-81cd-55f0bffd6852","ip":"10.147.51.12","netmask":"255.255.255.0","gateway":"10.147.51.1","mac":"06:6c:be:00:00:0d","dns1":"10.103.128.16","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://51","isolationUri":"vlan://51","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":200,"defaultNic":false,"uuid":"f73b4717-680c-4c78-833e-f79c355d4229","ip":"10.1.1.1","netmask":"255.255.255.0","mac":"02:00:13:c1:00:02","dns1":"10.103.128.16","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://1049","isolationUri":"vlan://1049","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"0ceaa1a8-31ab-49bd-94a3-414603c5fca2","ip":"169.254.1.72","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:01:48","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"result":true,"wait":0}},{"com.cloud.agent.api.check.CheckSshAnswer":{"result":true,"wait":0}},{"com.cloud.agent.api.GetDomRVersionAnswer":{"result":false,"details":"GetDomRVersionCmd
>
> failed","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
> by previous
> failure","wait":0}},{"com.cloud.agent.api.Answer":{"result":false,"details":"Stopped
> by previous failure","wait":0}}] }
> 2013-10-25 15:48:11,673 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-1:null) Seq 1-580780059: No more commands found
> 2013-10-25 15:48:11,673 DEBUG [agent.transport.Request]
> (Job-Executor-1:job-13 = [ 2d4992a5-4bc1-4dc2-8640-dfb0ed16c4a4 ]) Seq
> 1-580780059: Received: { Ans: , MgmtId: 233845177509810, via: 1, Ver: v1,
> Flags: 110, { StartAnswer, CheckSshAnswer, GetDomRVersionAnswer, Answer,
> Answer } }
> 2013-10-25 15:48:11,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
> ===END=== 10.146.0.132 -- GET
> command=queryAsyncJobResult&jobId=2d4992a5-4bc1-4dc2-8640-dfb0ed16c4a4&response=json&sessionkey=C9YivQ93YtZ4O2Bi53wlAMx9E5Q%3D&_=1382696291074
> 2013-10-25 15:48:11,788 WARN
> [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-1:job-13 =
> [ 2d4992a5-4bc1-4dc2-864
[jira] [Updated] (CLOUDSTACK-4939) Failed to create snapshot (KVM, Multiple hosts, Sharedstorage)
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Kozlov updated CLOUDSTACK-4939:
Summary: Failed to create snapshot (KVM, Multiple hosts, Sharedstorage)
(was: Failed to create snaphot (KVM, GFS2))
> Failed to create snapshot (KVM, Multiple hosts, Sharedstorage)
> --
>
> Key: CLOUDSTACK-4939
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4939
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Snapshot
>Affects Versions: 4.2.0, 4.2.1
> Environment: CentOS 6.4, KVM, Shared mount point primary storage,
> GFS2, iSCSI
>Reporter: Ivan Kozlov
>Priority: Blocker
> Labels: kvm, sharedstorage, snapshot
> Fix For: 4.2.1
>
>
> With one host snapshots are created ok. After adding second host some
> snapshots fail (Failed to create snapshot due to an internal error creating
> snapshot for volume 14) stucking with state "CreatedOnPrimary". Even when all
> VMs are running on the same host.
> debug libvirt log shows:
> 2013-10-23 17:31:21.634+: 20007: debug :
> virStorageFileGetMetadataInternal:673 :
> path=/mnt/48a148f6-3373-3af2-8667-2f240988163d/snapshots, fd=31, format=2
> 2013-10-23 17:32:57.189+: 20015: debug : qemuSnapObjFromName:233 : Domain
> snapshot not found: no domain snapshot with matching name
> '909848a0-b3ec-4657-a53a-c449dc24365b'
> 2013-10-23 17:32:57.474+: 20009: debug :
> virStorageFileGetMetadataInternal:673 :
> path=/mnt/48a148f6-3373-3af2-8667-2f240988163d/snapshots, fd=31, format=2
> 2013-10-23 17:34:28.264+: 20008: debug : qemuSnapObjFromName:233 : Domain
> snapshot not found: no domain snapshot with matching name
> 'f4e51b11-ac79-4a6a-b887-8926ffbd5cca'
> management server log:
> 2013-10-23 20:29:50,561 INFO [user.snapshot.CreateSnapshotCmd]
> (Job-Executor-52:job-94 = [ 42f8d6e0-762e-4f01-a7d5-daff2e31be13 ]) VOLSS:
> createSnapshotCmd starts:1382549390561
> 2013-10-23 20:29:52,053 DEBUG [agent.transport.Request]
> (Job-Executor-52:job-94 = [ 42f8d6e0-762e-4f01-a7d5-daff2e31be13 ]) Seq
> 6-1170407437: Waiting for Seq 1170407434 Scheduling: { Cmd , MgmtId:
> 161342718518, via: 6, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/primary/d59c6574-8ff9-41e4-86e5-ce560f30d717/f4e51b11-ac79-4a6a-b887-8926ffbd5cca","volume":{"uuid":"02c07659-59d3-42f2-8928-1d899cef94e7","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2c8e7b93-2d02-4c47-99ce-7bcd8670554a","id":2,"poolType":"SharedMountPoint","host":"localhost","path":"/primary","port":0}},"name":"ROOT-14","size":8589934592,"path":"d59c6574-8ff9-41e4-86e5-ce560f30d717","volumeId":14,"vmName":"i-2-14-VM","accountId":2,"format":"QCOW2","id":14,"hypervisorType":"KVM"},"parentSnapshotPath":"/primary/d59c6574-8ff9-41e4-86e5-ce560f30d717/ab317705-7368-4a40-9d1c-da2c8a7b1824","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2c8e7b93-2d02-4c47-99ce-7bcd8670554a","id":2,"poolType":"SharedMountPoint","host":"localhost","path":"/primary","port":0}},"vmName":"i-2-14-VM","name":"t1_ROOT-14_20131023172950","hypervisorType":"KVM","id":33}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/14","volume":{"uuid":"02c07659-59d3-42f2-8928-1d899cef94e7","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"2c8e7b93-2d02-4c47-99ce-7bcd8670554a","id":2,"poolType":"SharedMountPoint","host":"localhost","path":"/primary","port":0}},"name":"ROOT-14","size":8589934592,"path":"d59c6574-8ff9-41e4-86e5-ce560f30d717","volumeId":14,"vmName":"i-2-14-VM","accountId":2,"format":"QCOW2","id":14,"hypervisorType":"KVM"},"parentSnapshotPath":"snapshots/2/14/ab317705-7368-4a40-9d1c-da2c8a7b1824","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://192.168.10.31/export/secondary","_role":"Image"}},"vmName":"i-2-14-VM","name":"t1_ROOT-14_20131023172950","hypervisorType":"KVM","id":33}},"executeInSequence":true,"wait":21600}}]
> }
> 2013-10-23 20:31:21,560 DEBUG [agent.transport.Request]
> (AgentManager-Handler-8:null) Seq 6-1170407434: Processing: { Ans: , MgmtId:
> 161342718518, via: 6, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
> Domain snapshot not found: no domain snapshot with matching name
> '65113136-dfb5-4cea-8e65-1065462ca2fe'","wait":0}}] }
> 2013-10-23 20:31:21,832 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-49:job-91 = [ e2bf2454-4273-4a89-bc38-35add8297eb1 ]) Failed to
[jira] [Commented] (CLOUDSTACK-4902) Fail to create snapshot with KVM when run multiple Hosts in Cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806686#comment-13806686
]
Ivan Kozlov commented on CLOUDSTACK-4902:
-
I think this bug may be related to
https://issues.apache.org/jira/browse/CLOUDSTACK-4939
My investigation shows that issue is caused by sending commands to random
hosts. so sometimes we send commands to host where vm is running and everything
is ok and sometimes command is sent not to host where vm is running so it fails.
Are you using sharedmountpoint or clvm as primary storage?
> Fail to create snapshot with KVM when run multiple Hosts in Cluster
> ---
>
> Key: CLOUDSTACK-4902
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4902
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Management Server
>Affects Versions: 4.2.0
> Environment: Managegemnet server: CentOS 6.3 64bit
> KVM Host: Ubuntu 12.04.1 64bit
>Reporter: le cong duan
>Priority: Critical
> Fix For: 4.2.0
>
>
> When only one Host in the Cluster, I always success to create snapshot for
> the volume by manual or automation.
> But when have multiple Host in Cluster. The creating is failed with status
> "CreatedOnPrimary", sometimes it is successfull.
> The following is error log on Management when occur error, there are three
> error situations.
> --> First Situation
> 2013-10-18 22:46:27,163 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-120 = [ d07688b0-
> bd86-4259-bdc2-441c36c4727d ]) Seq 11-714015661: Received: { Ans: , MgmtId:
> 113353561884, via: 11,
> Ver: v1, Flags: 110, { CopyCmdAnswer } }
> 2013-10-18 22:46:27,175 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-122:job-120 =
> [ d07688b0-bd86-4259-bdc2-441c36c4727d ]) Failed to create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: Domain snapshot not
> found: no snapshot with matching name '8a1d6db7-9ffe-43b5-a7df-df627329a168'
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot
> (SnapshotServiceImpl.java:280)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot
> (XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot
> (XenserverSnapshotStrategy.java:264)
> at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot
> (SnapshotManagerImpl.java:1013)
> at com.cloud.utils.component.ComponentInstantiationPostProcessor
> $InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot
> (VolumeServiceImpl.java:1307)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2719)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute
> (CreateSnapshotCmd.java:170)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-10-18 22:46:27,181 DEBUG [storage.volume.VolumeServiceImpl]
> (Job-Executor-122:job-120 = [
> d07688b0-bd86-4259-bdc2-441c36c4727d ]) Take snapshot: 12 failed
> com.cloud.utils.exception.CloudRuntimeException: Failed to create snapshot
> at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot
> (SnapshotManagerImpl.java:1040)
> at com.cloud.utils.component.ComponentInstantiationPostProcessor
> $InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot
> (VolumeServiceImpl.java:1307)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2719)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute
> (CreateSnapshotCmd.java:170)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Exec
[jira] [Assigned] (CLOUDSTACK-482) Installation Guide Doc Error Section 4.5.7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair reassigned CLOUDSTACK-482: --- Assignee: (was: Radhika Nair) > Installation Guide Doc Error Section 4.5.7 > -- > > Key: CLOUDSTACK-482 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-482 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 LTS >Reporter: Jim Leary > Fix For: Future > > > Section 4.5.7 of the Installation Guide: entries calling out > /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... > are incorrect. They should be: > /usr/lib/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4970) [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair closed CLOUDSTACK-4970. > [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command > --- > > Key: CLOUDSTACK-4970 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4970 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: sebastien goasguen > Fix For: 4.2.1 > > > At this link: > https://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/management-server-install-flow.html > The command for installing the management server for Ubuntu is spelt > incorrectly, make sure you spell management correctly if you are copying and > pasting from the guide. > If someone could spend the 20 seconds updating the guide, even better. > (Posted on behalf of Mark van der Meulen ) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4975) NPE while deleting the volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada updated CLOUDSTACK-4975:
-
Fix Version/s: 4.2.1
> NPE while deleting the volume
> -
>
> Key: CLOUDSTACK-4975
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4975
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Critical
> Fix For: 4.2.1
>
>
> Steps:
> 1. Configure Adv zone with VMWARE Hypervisor
> 2. Created shared network with ROOT domain as scope
> 3. Created a user account and deployed VM using this shared network
> 4. After VM is up and running , Destroy the VM
> Observation:
> Observed NPE while deleting the volume.
> 2013-10-28 14:24:07,209 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Executing resource DestroyCommand:
> {"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"739f096d-1b1d-4c20-895f-c416c95bace5","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"7e18404c-acd1-3b13-9c9c-bbaf2d28bccd","id":4,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/newdixonps3","port":2049}},"name":"ROOT-205","size":2147483648,"path":"ROOT-205","volumeId":217,"vmName":"i-6-205-userinstance","accountId":6,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[7e18404cacd13b139c9cbbaf2d28bccd]
>
> i-6-205-userinstance/ROOT-205.vmdk\"]}","format":"OVA","id":217,"hypervisorType":"VMware"}},"wait":0}
> 2013-10-28 14:24:07,343 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Destroy root volume and VM itself. vmName
> i-6-205-userinstance
> 2013-10-28 14:24:07,376 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:07,383 DEBUG [vmware.mo.VirtualMachineMO]
> (DirectAgent-442:10.102.192.23) Retrieved 1 networks with key : 2
> 2013-10-28 14:24:07,414 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:10,374 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:10,398 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:12,978 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Processing Seq 3-66860: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-10-28 14:24:12,984 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Sending Seq 3-66860: { Ans: ,
> MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-10-28 14:24:13,371 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-375:null) Ping from 5
> 2013-10-28 14:24:13,585 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:13,606 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:23,403 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (UserVm-Scavenger-1:null) Stopped called on VM[User|newuser1f5instance1] but
> the state is Expunging
> 2013-10-28 14:24:23,412 DEBUG [cloud.capacity.CapacityManagerImpl]
> (UserVm-Scavenger-1:null) VM state transitted from :Expunging to Expunging
> with event: ExpungeOperationvm's original host id: 1 new host id: null host
> id before state transition: null
> 2013-10-28 14:24:23,412 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (UserVm-Scavenger-1:null) Destroyin
[jira] [Updated] (CLOUDSTACK-4975) NPE while deleting the volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada updated CLOUDSTACK-4975:
-
Attachment: newlogs.rar
> NPE while deleting the volume
> -
>
> Key: CLOUDSTACK-4975
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4975
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: newlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with VMWARE Hypervisor
> 2. Created shared network with ROOT domain as scope
> 3. Created a user account and deployed VM using this shared network
> 4. After VM is up and running , Destroy the VM
> Observation:
> Observed NPE while deleting the volume.
> 2013-10-28 14:24:07,209 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Executing resource DestroyCommand:
> {"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"739f096d-1b1d-4c20-895f-c416c95bace5","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"7e18404c-acd1-3b13-9c9c-bbaf2d28bccd","id":4,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/newdixonps3","port":2049}},"name":"ROOT-205","size":2147483648,"path":"ROOT-205","volumeId":217,"vmName":"i-6-205-userinstance","accountId":6,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[7e18404cacd13b139c9cbbaf2d28bccd]
>
> i-6-205-userinstance/ROOT-205.vmdk\"]}","format":"OVA","id":217,"hypervisorType":"VMware"}},"wait":0}
> 2013-10-28 14:24:07,343 INFO [storage.resource.VmwareStorageProcessor]
> (DirectAgent-442:10.102.192.23) Destroy root volume and VM itself. vmName
> i-6-205-userinstance
> 2013-10-28 14:24:07,376 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:07,383 DEBUG [vmware.mo.VirtualMachineMO]
> (DirectAgent-442:10.102.192.23) Retrieved 1 networks with key : 2
> 2013-10-28 14:24:07,414 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
> 2013-10-28 14:24:10,374 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:10,398 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
> 2013-10-28 14:24:12,978 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Processing Seq 3-66860: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-10-28 14:24:12,984 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-8:null) SeqA 3-66860: Sending Seq 3-66860: { Ans: ,
> MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-10-28 14:24:13,371 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-375:null) Ping from 5
> 2013-10-28 14:24:13,585 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===START=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:13,606 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
> ===END=== 10.104.255.45 -- GET
> command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
> 2013-10-28 14:24:23,403 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (UserVm-Scavenger-1:null) Stopped called on VM[User|newuser1f5instance1] but
> the state is Expunging
> 2013-10-28 14:24:23,412 DEBUG [cloud.capacity.CapacityManagerImpl]
> (UserVm-Scavenger-1:null) VM state transitted from :Expunging to Expunging
> with event: ExpungeOperationvm's original host id: 1 new host id: null host
> id before state transition: null
> 2013-10-28 14:24:23,412 DEBUG [cloud.vm.VirtualMachineManagerImpl
[jira] [Created] (CLOUDSTACK-4975) NPE while deleting the volume
Sailaja Mada created CLOUDSTACK-4975:
Summary: NPE while deleting the volume
Key: CLOUDSTACK-4975
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4975
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Priority: Critical
Steps:
1. Configure Adv zone with VMWARE Hypervisor
2. Created shared network with ROOT domain as scope
3. Created a user account and deployed VM using this shared network
4. After VM is up and running , Destroy the VM
Observation:
Observed NPE while deleting the volume.
2013-10-28 14:24:07,209 INFO [storage.resource.VmwareStorageProcessor]
(DirectAgent-442:10.102.192.23) Executing resource DestroyCommand:
{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"739f096d-1b1d-4c20-895f-c416c95bace5","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"7e18404c-acd1-3b13-9c9c-bbaf2d28bccd","id":4,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/newdixonps3","port":2049}},"name":"ROOT-205","size":2147483648,"path":"ROOT-205","volumeId":217,"vmName":"i-6-205-userinstance","accountId":6,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[7e18404cacd13b139c9cbbaf2d28bccd]
i-6-205-userinstance/ROOT-205.vmdk\"]}","format":"OVA","id":217,"hypervisorType":"VMware"}},"wait":0}
2013-10-28 14:24:07,343 INFO [storage.resource.VmwareStorageProcessor]
(DirectAgent-442:10.102.192.23) Destroy root volume and VM itself. vmName
i-6-205-userinstance
2013-10-28 14:24:07,376 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
===START=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
2013-10-28 14:24:07,383 DEBUG [vmware.mo.VirtualMachineMO]
(DirectAgent-442:10.102.192.23) Retrieved 1 networks with key : 2
2013-10-28 14:24:07,414 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null)
===END=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950771190
2013-10-28 14:24:10,374 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===START=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
2013-10-28 14:24:10,398 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null)
===END=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950774191
2013-10-28 14:24:12,978 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 3-66860: Processing Seq 3-66860: { Cmd ,
MgmtId: -1, via: 3, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-10-28 14:24:12,984 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 3-66860: Sending Seq 3-66860: { Ans: ,
MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-10-28 14:24:13,371 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-375:null) Ping from 5
2013-10-28 14:24:13,585 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
===START=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
2013-10-28 14:24:13,606 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null)
===END=== 10.104.255.45 -- GET
command=queryAsyncJobResult&jobId=805d2fd9-ce54-49db-a2a0-3479c084&response=json&sessionkey=t%2FFTuAD%2Fvg3MVIIB7VszPAxZw40%3D&_=1382950777196
2013-10-28 14:24:23,403 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(UserVm-Scavenger-1:null) Stopped called on VM[User|newuser1f5instance1] but
the state is Expunging
2013-10-28 14:24:23,412 DEBUG [cloud.capacity.CapacityManagerImpl]
(UserVm-Scavenger-1:null) VM state transitted from :Expunging to Expunging with
event: ExpungeOperationvm's original host id: 1 new host id: null host id
before state transition: null
2013-10-28 14:24:23,412 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(UserVm-Scavenger-1:null) Destroying vm VM[User|newuser1f5instance1]
2013-10-28 14:24:23,412 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(UserVm-Scavenger-1:null) Cleaning up NICS
2013-10-28 14:24:23,414 DEBUG [cloud.network.NetworkManagerImpl]
(UserVm-Scavenger-1:null) Cleaning network for vm: 205
2013-10-28 14:24:23,417 DEBUG [cloud.storage.Volume
[jira] [Assigned] (CLOUDSTACK-4970) [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sebastien goasguen reassigned CLOUDSTACK-4970: -- Assignee: sebastien goasguen > [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command > --- > > Key: CLOUDSTACK-4970 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4970 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: sebastien goasguen > Fix For: 4.2.1 > > > At this link: > https://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/management-server-install-flow.html > The command for installing the management server for Ubuntu is spelt > incorrectly, make sure you spell management correctly if you are copying and > pasting from the guide. > If someone could spend the 20 seconds updating the guide, even better. > (Posted on behalf of Mark van der Meulen ) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4970) [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sebastien goasguen resolved CLOUDSTACK-4970. Resolution: Fixed Fix Version/s: 4.2.1 already fixed in master > [Doc] Installation Guide Error: Typo in the Ubuntu Installation Command > --- > > Key: CLOUDSTACK-4970 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4970 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: sebastien goasguen > Fix For: 4.2.1 > > > At this link: > https://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/management-server-install-flow.html > The command for installing the management server for Ubuntu is spelt > incorrectly, make sure you spell management correctly if you are copying and > pasting from the guide. > If someone could spend the 20 seconds updating the guide, even better. > (Posted on behalf of Mark van der Meulen ) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4946) Restore VM with template id feature doesnt work on VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806610#comment-13806610 ] ASF subversion and git services commented on CLOUDSTACK-4946: - Commit 7116268f33a5576f2eb80dffc921918021fd510f in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7116268 ] CLOUDSTACK-4946. VM Restore with template id/Volatile VM feature doesnt work on VMware When a ROOT volume is created from base template, if a folder already exists for the ROOT volume's VM then replace the old ROOT disk files with the new one. > Restore VM with template id feature doesnt work on VMware > - > > Key: CLOUDSTACK-4946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.1 > > > To restore a VM to a different/original template, user can use > restoreVirtualMachine API with templateId parameter or create the VM from a > service offering that has isVolatile set to true and then reboot the VM. > In 4.2 this functionality is not working as expected in a VMware environment. > When a VM restore is called the VM is not restored to the right template, > instead the VM continues to use the original template. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4946) Restore VM with template id feature doesnt work on VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-4946. Resolution: Fixed > Restore VM with template id feature doesnt work on VMware > - > > Key: CLOUDSTACK-4946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.1 > > > To restore a VM to a different/original template, user can use > restoreVirtualMachine API with templateId parameter or create the VM from a > service offering that has isVolatile set to true and then reboot the VM. > In 4.2 this functionality is not working as expected in a VMware environment. > When a VM restore is called the VM is not restored to the right template, > instead the VM continues to use the original template. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4946) Restore VM with template id feature doesnt work on VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806608#comment-13806608 ] ASF subversion and git services commented on CLOUDSTACK-4946: - Commit 1a3f394730e92bb80388a9f78aa83bbc513b451f in branch refs/heads/4.2 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1a3f394 ] CLOUDSTACK-4946. VM Restore with template id/Volatile VM feature doesnt work on VMware When a ROOT volume is created from base template, if a folder already exists for the ROOT volume's VM then replace the old ROOT disk files with the new one. > Restore VM with template id feature doesnt work on VMware > - > > Key: CLOUDSTACK-4946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.1 > > > To restore a VM to a different/original template, user can use > restoreVirtualMachine API with templateId parameter or create the VM from a > service offering that has isVolatile set to true and then reboot the VM. > In 4.2 this functionality is not working as expected in a VMware environment. > When a VM restore is called the VM is not restored to the right template, > instead the VM continues to use the original template. -- This message was sent by Atlassian JIRA (v6.1#6144)
