[jira] [Resolved] (CLOUDSTACK-8791) VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: unsupported flags (0x8)

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma resolved CLOUDSTACK-8791.
--
Resolution: Won't Fix
  Assignee: Remi Bergsma

No response so closing. Use recent RHEL / CentOS version as this is a known 
issue in RHEL / CentOS 6.3.

> VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: 
> unsupported flags (0x8)
> ---
>
> Key: CLOUDSTACK-8791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8791
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: KVM Hypervisor
>Reporter: Deepthi Machiraju
>Assignee: Remi Bergsma
>Priority: Critical
> Attachments: management-server.zip, mysqlcloud.dmp
>
>
> - Deploy a network , with RVR offering id and ensure both master and back up 
> are UP and Running
> - Migrate 'Master' to the available suitable Host.
> Expected result :
> Migrate should be successful.
> Observation :
> Migrate is failing with the below exception : 
> .utils.exception.CloudRuntimeException: invalid argument: 
> virDomainDefFormatInternal: unsupported flags (0x8)
> 2015-08-31 12:12:54,074 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Done with run of VM work 
> job: com.cloud.vm.VmWorkMigrate for VM 39, job origin: 187
> 2015-08-31 12:12:54,074 ERROR [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Unable to complete 
> AsyncJobVO {id:188, userId: 2, accountId: 2, instanceType: null, instanceId: 
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo: 
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAJ3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 55769813040052, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: Mon Aug 31 12:12:53 UTC 2015}, job origin:187
> com.cloud.utils.exception.CloudRuntimeException: invalid argument: 
> virDomainDefFormatInternal: unsupported flags (0x8)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1979)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1876)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4598)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4730)
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> 

[jira] [Commented] (CLOUDSTACK-8804) configure routes only in case of public networks when using vpc network.

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909165#comment-14909165
 ] 

Remi Bergsma commented on CLOUDSTACK-8804:
--

Probably fixed by https://github.com/apache/cloudstack/pull/887 please test 
once merged.

> configure routes only in case of public networks when using vpc network.
> 
>
> Key: CLOUDSTACK-8804
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8804
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0
>Reporter: Bharat Kumar
>Assignee: Bharat Kumar
>Priority: Critical
>
> In CsAddress.py the process() method adds routes to all the network types 
> which are not of type control, This should be fixed to add routes only in 
> case of public networks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-8791) VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: unsupported flags (0x8)

[Remi Bergsma (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma closed CLOUDSTACK-8791.


> VR Migrate fails with Error : invalid argument: virDomainDefFormatInternal: 
> unsupported flags (0x8)
> ---
>
> Key: CLOUDSTACK-8791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8791
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: KVM Hypervisor
>Reporter: Deepthi Machiraju
>Assignee: Remi Bergsma
>Priority: Critical
> Attachments: management-server.zip, mysqlcloud.dmp
>
>
> - Deploy a network , with RVR offering id and ensure both master and back up 
> are UP and Running
> - Migrate 'Master' to the available suitable Host.
> Expected result :
> Migrate should be successful.
> Observation :
> Migrate is failing with the below exception : 
> .utils.exception.CloudRuntimeException: invalid argument: 
> virDomainDefFormatInternal: unsupported flags (0x8)
> 2015-08-31 12:12:54,074 DEBUG [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Done with run of VM work 
> job: com.cloud.vm.VmWorkMigrate for VM 39, job origin: 187
> 2015-08-31 12:12:54,074 ERROR [c.c.v.VmWorkJobDispatcher] 
> (Work-Job-Executor-114:ctx-32f05da2 job-187/job-188) Unable to complete 
> AsyncJobVO {id:188, userId: 2, accountId: 2, instanceType: null, instanceId: 
> null, cmd: com.cloud.vm.VmWorkMigrate, cmdInfo: 
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAJ3QAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAnNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXEAfgAJcQB-AAlwcQB-AAk,
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 55769813040052, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: Mon Aug 31 12:12:53 UTC 2015}, job origin:187
> com.cloud.utils.exception.CloudRuntimeException: invalid argument: 
> virDomainDefFormatInternal: unsupported flags (0x8)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1979)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:1876)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4598)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4730)
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2015-08-31 12:12:54,077 DEBUG 

[jira] [Commented] (CLOUDSTACK-8878) No route to host on VPC router after stop/start/reboot

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909160#comment-14909160
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8878:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/887#issuecomment-143409187
  
This PR also fixes CLOUDSTACK-8878 
(https://issues.apache.org/jira/browse/CLOUDSTACK-8878): No route to host on 
VPC router after stop/start/reboot


> No route to host on VPC router after stop/start/reboot
> --
>
> Key: CLOUDSTACK-8878
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8878
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> The VPC router was broken after the fix applied for PR #765 resulting in 2 
> exceptions in the test_vpc_routers.py:
> === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | 
> Status : EXCEPTION ===
> === TestName: test_02_reboot_router_after_addition_of_one_guest_network | 
> Status : EXCEPTION ===
> It has also been reproduced manually:
> 1. Create a VPC
> 2. Add tiers/VMs/Public IPs/PF rules
> 3. Stop the router
> 4. Start the router
> Router won't start due to "no route to host error"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8913) Search box in Templates tab out of alignment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909197#comment-14909197
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8913:


Github user nitin-maharana commented on the pull request:

https://github.com/apache/cloudstack/pull/891#issuecomment-143419034
  
Sorry Its Decreased not increased. 


> Search box in Templates tab out of alignment
> 
>
> Key: CLOUDSTACK-8913
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8913
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.1
>Reporter: Nitin Kumar Maharana
>
> CURRENT BEHAVIOUR
> 
> Search box in Templates tab is not aligned with other buttons in Firefox, 
> Chrome, and Safari.
> EXPECTED BEHAVIOUR
> 
> Search box in Templates tab should be aligned with other buttons in all 
> browser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8913) Search box in Templates tab out of alignment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909195#comment-14909195
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8913:


GitHub user nitin-maharana opened a pull request:

https://github.com/apache/cloudstack/pull/891

CLOUDSTACK-8913: Search box in Templates tab out of alignment

Increased the margin and padding to accomodate all the boxes inside toolbar.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nitin-maharana/cloudstack CloudStack-Nitin9

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/891.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #891


commit 6f0d5bc52e50678e2ebca1441d71e47b052f27f7
Author: Nitin Kumar Maharana 
Date:   2015-09-26T11:03:28Z

CLOUDSTACK-8913: Search box in Templates tab out of alignment

Increased the margin and padding to accomodate all the boxes inside toolbar.




> Search box in Templates tab out of alignment
> 
>
> Key: CLOUDSTACK-8913
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8913
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.1
>Reporter: Nitin Kumar Maharana
>
> CURRENT BEHAVIOUR
> 
> Search box in Templates tab is not aligned with other buttons in Firefox, 
> Chrome, and Safari.
> EXPECTED BEHAVIOUR
> 
> Search box in Templates tab should be aligned with other buttons in all 
> browser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8913) Search box in Templates tab out of alignment

[Nitin Kumar Maharana (JIRA)]

Nitin Kumar Maharana created CLOUDSTACK-8913:


 Summary: Search box in Templates tab out of alignment
 Key: CLOUDSTACK-8913
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8913
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.5.1
Reporter: Nitin Kumar Maharana


CURRENT BEHAVIOUR

Search box in Templates tab is not aligned with other buttons in Firefox, 
Chrome, and Safari.

EXPECTED BEHAVIOUR

Search box in Templates tab should be aligned with other buttons in all browser.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8808) Successfully registered VHD template is downloaded again due to missing virtualsize property in template.properties

[Rajani Karuturi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909248#comment-14909248
 ] 

Rajani Karuturi commented on CLOUDSTACK-8808:
-

[~remibergsma]
from the code, I can see that vritualSize can be empty if 
VhdProcessor.getVirtualSize() throws an IOException. That might mean vhd file 
is not generated properly and doesnt have the correct header and footer offset. 
Did you face any issues with vms running on this template? for example usage 
calculation or template sync issues?

I think we should not allow template registration if the vhd file processing is 
not successful. This means there wont be any templates with missing 
virtualsize. I will make a PR for this.

Is it possible to share the template vhd file which didnt have virtualsize? It 
would help me in testing. 

> Successfully registered VHD template is downloaded again due to missing 
> virtualsize property in template.properties
> ---
>
> Key: CLOUDSTACK-8808
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8808
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.4.4, 4.6.0
> Environment: Seen on NFS as sec storage
>Reporter: Remi Bergsma
>Assignee: Rajani Karuturi
>Priority: Blocker
>
> We noticed all of our templates are downloaded again as soon as we restart 
> SSVM, its Cloud service or the management server it connects to.
> A scan done by the SSVM (listvmtmplt.sh) returns the template, but it is 
> rejected later (Post download installation was not completed) because (Format 
> is invalid) due to missing virtualSize property in template.properties.
> The initial registration did succeed however. I'd either want the 
> registration to fail, or it to succeed. Not first succeed (and spin VMs 
> without a problem) then fail unexpectedly later.
> This is the script processing the download:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>  759 private List listTemplates(String rootdir) { 
> 
>  760 List result = new ArrayList();   
> 
>  761  
> 
>  762 Script script = new Script(listTmpltScr, s_logger);  
> 
>  763 script.add("-r", rootdir);   
> For example this becomes:
> ==> /usr/local/cloud/systemvm/scripts/storage/secondary/listvmtmplt.sh -r 
> /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0
> In this log file, it processes the output:
> less /var/log/cloud/cloud.out
> 2015-09-04 08:39:54,622 WARN  [storage.template.DownloadManagerImpl] 
> (agentRequest-Handler-1:null) Post download installation was not completed 
> for /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0/template/tmpl/2/1607
> This error message is generated here:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>  
> 780 List publicTmplts = listTemplates(templateDir);   
>
>  781 for (String tmplt : publicTmplts) {  
> 
>  782 String path = tmplt.substring(0, 
> tmplt.lastIndexOf(File.separator)); 
>  783 TemplateLocation loc = new TemplateLocation(_storage, path); 
> 
>  784 try {
> 
>  785 if (!loc.load()) {   
> 
>  786 s_logger.warn("Post download installation was not 
> completed for " + path);
>  787 // loc.purge();  
> 
>  788 _storage.cleanup(path, templateDir); 
> 
>  789 continue;
> 
>  790 }
> 
>  791 } catch (IOException e) {
> 
>  792 s_logger.warn("Unable to load template location " + 
> path, e);
>  793 continue;
> 
>  794 } 
> In the logs this message is also seen:
> MCCP-ADMIN-1|s-32436-VM CLOUDSTACK: 10:09:17,333  WARN TemplateLocation:196 - 
> Format is invalid 
> It is generated here:
> .//core/src/com/cloud/storage/template/TemplateLocation.java
> 192public boolean addFormat(FormatInfo newInfo) { 
> 

[jira] [Commented] (CLOUDSTACK-8906) /var/log/cloud/ doesn't get logrotated on xenserver

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909380#comment-14909380
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8906:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/883#issuecomment-143475690
  
@SudharmaJain The title and the content of your PR do not match. You seem 
to re-implement the XenServer 6.0.2 resource? If that is what you want, make a 
PR just for that. Also I'd like to know if the logrotate you make works on 6.2 
and 6.5 as well.

Did you also see PR #861 on this subject? 


> /var/log/cloud/ doesn't get logrotated on xenserver 
> 
>
> Key: CLOUDSTACK-8906
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8906
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8906) /var/log/cloud/ doesn't get logrotated on xenserver

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909403#comment-14909403
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8906:


Github user SudharmaJain commented on the pull request:

https://github.com/apache/cloudstack/pull/883#issuecomment-143478261
  
@remibergsma I didn't checked the PR #861. I was looking to fix the issue 
with xenserver 6.0.2 and higher. For this I have added a logrotate script and a 
Patch file for 6.0.2 which is the same as for xenserver 6.0 with an extra entry 
for logrotate script. same entry is added in patch file for 6.2 and 6.5. In 
earlier version, you can find logrotate in /etc/cron.hourly. In later versions 
it was not available which broke the log rotate functionality.


> /var/log/cloud/ doesn't get logrotated on xenserver 
> 
>
> Key: CLOUDSTACK-8906
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8906
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8914) cannot delete pod, NPE

[Noel D. Kendall (JIRA)]

Noel D. Kendall created CLOUDSTACK-8914:
---

 Summary: cannot delete pod, NPE
 Key: CLOUDSTACK-8914
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8914
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.2
 Environment: Simple test setup with one zone, one pod, one cluster, 
one host
Reporter: Noel D. Kendall
Priority: Critical


Tried a cloudmonkey script to clean up an environment, deleting host, cluster, 
pod and zone in order to recreate.

Failed through cloudmonkey.

Tried manually deleting pod, same error, same debug stack. NPE.

Log snippet below:
2015-09-26 11:36:42,153 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-23:ctx-a265f355) ===START===  172.16.1.14 -- GET  
command=deletePod=a0be72da-4681-42dc-8d3a-324879d778b0=json&_=1443281802111
2015-09-26 11:36:42,216 DEBUG [c.c.u.d.T.Transaction] 
(catalina-exec-23:ctx-a265f355 ctx-7a0bf087) Rolling back the transaction: Time 
= 52 Name =  catalina-exec-23; called by 
-TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-Transaction.execute:49-Transaction.execute:54-ConfigurationManagerImpl.deletePod:1023-NativeMethodAccessorImpl.invoke0:-2-NativeMethodAccessorImpl.invoke:57-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183
2015-09-26 11:36:42,291 ERROR [c.c.a.ApiServer] (catalina-exec-23:ctx-a265f355 
ctx-7a0bf087) unhandled exception executing api command: 
[Ljava.lang.String;@4a47022e
java.lang.NullPointerException
at 
com.cloud.dc.dao.VlanDaoImpl.listVlansForPodByType(VlanDaoImpl.java:161)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy98.listVlansForPodByType(Unknown Source)
at 
com.cloud.network.NetworkModelImpl.listPodVlans(NetworkModelImpl.java:796)
at 
com.cloud.configuration.ConfigurationManagerImpl$1.doInTransactionWithoutResult(ConfigurationManagerImpl.java:1043)
at 
com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57)
at com.cloud.utils.db.Transaction.execute(Transaction.java:45)
at com.cloud.utils.db.Transaction.execute(Transaction.java:54)
at 
com.cloud.configuration.ConfigurationManagerImpl.deletePod(ConfigurationManagerImpl.java:1023)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy105.deletePod(Unknown Source)
at 

[jira] [Commented] (CLOUDSTACK-8808) Successfully registered VHD template is downloaded again due to missing virtualsize property in template.properties

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909390#comment-14909390
 ] 

Remi Bergsma commented on CLOUDSTACK-8808:
--

[~rajanik] Thanks, will see if I can find such a template. It'd be best to 
reject it at register time indeed.

> Successfully registered VHD template is downloaded again due to missing 
> virtualsize property in template.properties
> ---
>
> Key: CLOUDSTACK-8808
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8808
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.4.4, 4.6.0
> Environment: Seen on NFS as sec storage
>Reporter: Remi Bergsma
>Assignee: Rajani Karuturi
>Priority: Blocker
>
> We noticed all of our templates are downloaded again as soon as we restart 
> SSVM, its Cloud service or the management server it connects to.
> A scan done by the SSVM (listvmtmplt.sh) returns the template, but it is 
> rejected later (Post download installation was not completed) because (Format 
> is invalid) due to missing virtualSize property in template.properties.
> The initial registration did succeed however. I'd either want the 
> registration to fail, or it to succeed. Not first succeed (and spin VMs 
> without a problem) then fail unexpectedly later.
> This is the script processing the download:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>  759 private List listTemplates(String rootdir) { 
> 
>  760 List result = new ArrayList();   
> 
>  761  
> 
>  762 Script script = new Script(listTmpltScr, s_logger);  
> 
>  763 script.add("-r", rootdir);   
> For example this becomes:
> ==> /usr/local/cloud/systemvm/scripts/storage/secondary/listvmtmplt.sh -r 
> /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0
> In this log file, it processes the output:
> less /var/log/cloud/cloud.out
> 2015-09-04 08:39:54,622 WARN  [storage.template.DownloadManagerImpl] 
> (agentRequest-Handler-1:null) Post download installation was not completed 
> for /mnt/SecStorage/ee8633dd-5dbd-39a3-b3ea-801ca0a20da0/template/tmpl/2/1607
> This error message is generated here:
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
>  
> 780 List publicTmplts = listTemplates(templateDir);   
>
>  781 for (String tmplt : publicTmplts) {  
> 
>  782 String path = tmplt.substring(0, 
> tmplt.lastIndexOf(File.separator)); 
>  783 TemplateLocation loc = new TemplateLocation(_storage, path); 
> 
>  784 try {
> 
>  785 if (!loc.load()) {   
> 
>  786 s_logger.warn("Post download installation was not 
> completed for " + path);
>  787 // loc.purge();  
> 
>  788 _storage.cleanup(path, templateDir); 
> 
>  789 continue;
> 
>  790 }
> 
>  791 } catch (IOException e) {
> 
>  792 s_logger.warn("Unable to load template location " + 
> path, e);
>  793 continue;
> 
>  794 } 
> In the logs this message is also seen:
> MCCP-ADMIN-1|s-32436-VM CLOUDSTACK: 10:09:17,333  WARN TemplateLocation:196 - 
> Format is invalid 
> It is generated here:
> .//core/src/com/cloud/storage/template/TemplateLocation.java
> 192public boolean addFormat(FormatInfo newInfo) { 
>   
> 193 deleteFormat(newInfo.format); 
>
> 194   
>
> 195 if (!checkFormatValidity(newInfo)) {  
>
> 196 s_logger.warn("Format is invalid ");  
>
> 197 return false; 
>
> 198 } 
>   

[jira] [Commented] (CLOUDSTACK-8878) No route to host on VPC router after stop/start/reboot

[Remi Bergsma (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909158#comment-14909158
 ] 

Remi Bergsma commented on CLOUDSTACK-8878:
--

This will be addressed here: https://github.com/apache/cloudstack/pull/887

> No route to host on VPC router after stop/start/reboot
> --
>
> Key: CLOUDSTACK-8878
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8878
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Wilder Rodrigues
>Assignee: Wilder Rodrigues
>Priority: Blocker
>
> The VPC router was broken after the fix applied for PR #765 resulting in 2 
> exceptions in the test_vpc_routers.py:
> === TestName: test_01_start_stop_router_after_addition_of_one_guest_network | 
> Status : EXCEPTION ===
> === TestName: test_02_reboot_router_after_addition_of_one_guest_network | 
> Status : EXCEPTION ===
> It has also been reproduced manually:
> 1. Create a VPC
> 2. Add tiers/VMs/Public IPs/PF rules
> 3. Stop the router
> 4. Start the router
> Router won't start due to "no route to host error"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8848) Unexpected VR reboot after out-of-band migration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909286#comment-14909286
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8848:


Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/885#issuecomment-143442228
  
We don't need new method isPowerStateUpToDate(long instanceId) as we are 
already performing the same operations in 
_instanceDao.updatePowerState(entry.getKey(), hostId, entry.getValue())) in 
start of method processReport.

So here we only need one line change 
Date vmStateUpdateTime = instance.getPowerStateUpdateTime();
instead of 
Date vmStateUpdateTime = instance.updateTime();
Did you check how update_time is getting updated?
I think one place it is getting updated during state transitions of VM.


> Unexpected VR reboot after out-of-band migration
> 
>
> Key: CLOUDSTACK-8848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.5.2, 4.6.0
>Reporter: René Moser
>Priority: Blocker
> Fix For: 4.5.3, 4.6.0
>
>
> In some conditions (race condition), VR gets rebooted after a out of band 
> migration was done on vCenter. 
> {panel:bgColor=#CE}
> Note, new global setting in 4.5.2 "VR reboot after out of band migration" is 
> set to *false* and this looks more like a bug.
> {panel}
> After a VR migration to a host _and_ when the VM power state report gathering 
> is running, the VR (and also any user VM as well) will get into the 
> "PowerReportMissing".
> If the VM is a VR. it will be powered off and started again on vCenter. That 
> is what we see. In can not be reproduced every time a migration was done, but 
> it seems the problem is related to "powerReportMissing".
> I grep-ed the source and found this line related
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java#L3616
> and also it seems that the graceful period might be also related, 
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
> In case it is a user VM, we see in the logs that the state will be set to 
> powered-off, but the VM keeps running. After a while a new VM power state 
> report is running and the state for the user VM gets updated to Running 
> again. Below the logs 
> h2. VR  r-342-VM reboot log
> {code:none}
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) Run missing VM report. current time: 
> 1442302626508
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) Detected missing VM. host: 19, vm id: 
> 342, power state: PowerReportMissing, last state update: 1442302506000
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) vm id: 342 - time since last state 
> update(120508ms) has passed graceful period
> 2015-09-15 09:37:06,517 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) VM state report is updated. host: 19, 
> vm id: 342, power state: PowerReportMissing 
> 2015-09-15 09:37:06,525 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) VM r-342-VM is at Running and we 
> received a power-off report while there is no pending jobs on it
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request] 
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Sending  { 
> Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int), 
> Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
>  }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request] 
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Executing:  
> { Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int), 
> Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
>  }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-136:ctx-9bc0a401) Seq 19-4511199451741686482: Executing request
> 2015-09-15 09:37:06,532 INFO  [c.c.h.v.r.VmwareResource] 
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd: 
> StopCommand) Executing resource StopCommand: 
> 

[jira] [Commented] (CLOUDSTACK-8879) Depend on rados-java 0.2.0

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909432#comment-14909432
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8879:


Github user K0zka commented on the pull request:

https://github.com/apache/cloudstack/pull/889#issuecomment-143480210
  
LGTM :+1: 


> Depend on rados-java 0.2.0
> --
>
> Key: CLOUDSTACK-8879
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8879
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Affects Versions: 4.5.2
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>Priority: Critical
> Fix For: 4.5.3, 4.6.0
>
>
> Need to depend on rados-java 0.2.0 due to a couple of crashes which have 
> occured.
> Will need some new imports in LibvirtComputingResource, but no major code 
> changes.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)