[jira] [Comment Edited] (CLOUDSTACK-8444) [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358464#comment-15358464 ] Anshul Gangwar edited comment on CLOUDSTACK-8444 at 7/1/16 6:51 AM: To build cloudstack refer http://docs.cloudstack.apache.org/en/latest/developer_guide.html. After cloning git repo you have to apply patch from my PR. You need to build the Hyper-V agent using steps mentioned at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer. You just need to generate the AgentShell.exe. no need to build full installer. Generated AgentShell.exe with all dependencies can be copied to all the hosts which you are planning to add in Failover cluster. If you are facing issues in generating then I can see whether I can provide you already generated one. After installing agent you can setup the failover cluster of hyper-v as you normally would. After setting failover cluster you can add all the hosts of failover cluster(hyperv) in cloudstack in single cluster(cloudstack). To add CSV you need to use PreSetup option. For more details you can refer https://cwiki.apache.org/confluence/display/CLOUDSTACK/iSCSI+and+HA+support+in+Hyper-V was (Author: anshulg): You need to build the Hyper-V agent using steps mentioned at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer. You just need to generate the AgentShell.exe. no need to build full installer. Generated AgentShell.exe with all dependencies can be copied to all the hosts which you are planning to add in Failover cluster. If you are facing issues in generating then I can see whether I can provide you already generated one. After installing agent you can setup the failover cluster of hyper-v as you normally would. After setting failover cluster you can add all the hosts of failover cluster(hyperv) in cloudstack in single cluster(cloudstack). To add CSV you need to use PreSetup option. For more details you can refer https://cwiki.apache.org/confluence/display/CLOUDSTACK/iSCSI+and+HA+support+in+Hyper-V > [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack > > > Key: CLOUDSTACK-8444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8444 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > This will enable us to add support for HA and cluster shared volume in Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-8444) [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358464#comment-15358464 ] Anshul Gangwar edited comment on CLOUDSTACK-8444 at 7/1/16 6:07 AM: You need to build the Hyper-V agent using steps mentioned at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer. You just need to generate the AgentShell.exe. no need to build full installer. Generated AgentShell.exe with all dependencies can be copied to all the hosts which you are planning to add in Failover cluster. If you are facing issues in generating then I can see whether I can provide you already generated one. After installing agent you can setup the failover cluster of hyper-v as you normally would. After setting failover cluster you can add all the hosts of failover cluster(hyperv) in cloudstack in single cluster(cloudstack). To add CSV you need to use PreSetup option. For more details you can refer https://cwiki.apache.org/confluence/display/CLOUDSTACK/iSCSI+and+HA+support+in+Hyper-V was (Author: anshulg): You need to build the Hyper-V agent using steps mentioned at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer. You just need to generate the AgentShell.exe. no need to build full installer. Generated AgentShell.exe with all dependencies can be copied to all the hosts which you are planning to add in Failover cluster. After installing agent you can setup the failover cluster of hyper-v as you normally would. After setting failover cluster you can add all the hosts of failover cluster(hyperv) in cloudstack in single cluster(cloudstack). To add CSV you need to use PreSetup option. For more details you can refer https://cwiki.apache.org/confluence/display/CLOUDSTACK/iSCSI+and+HA+support+in+Hyper-V > [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack > > > Key: CLOUDSTACK-8444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8444 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > This will enable us to add support for HA and cluster shared volume in Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8444) [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358464#comment-15358464 ] Anshul Gangwar commented on CLOUDSTACK-8444: You need to build the Hyper-V agent using steps mentioned at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer. You just need to generate the AgentShell.exe. no need to build full installer. Generated AgentShell.exe with all dependencies can be copied to all the hosts which you are planning to add in Failover cluster. After installing agent you can setup the failover cluster of hyper-v as you normally would. After setting failover cluster you can add all the hosts of failover cluster(hyperv) in cloudstack in single cluster(cloudstack). To add CSV you need to use PreSetup option. For more details you can refer https://cwiki.apache.org/confluence/display/CLOUDSTACK/iSCSI+and+HA+support+in+Hyper-V > [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack > > > Key: CLOUDSTACK-8444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8444 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > This will enable us to add support for HA and cluster shared volume in Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9104) VM naming convention in case vmware is used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15358371#comment-15358371 ] ASF GitHub Bot commented on CLOUDSTACK-9104: Github user priyankparihar commented on the issue: https://github.com/apache/cloudstack/pull/1302 Hi @rhtyd and @sateesh-chodapuneedi, I have made modification, according to your suggestion. Please take a look. > VM naming convention in case vmware is used > --- > > Key: CLOUDSTACK-9104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar > > ISSUE > == > VM naming convention in case vmware is used. > Description > == > User with different account cannot create VMs with the same name, which was > possible earlier (I am not sure in which CCP version). That time naming > convention used was like this “I--” > Currently if vm.instancename.flag is set to true the VM name will be exactly > as display name given. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8444) [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357890#comment-15357890 ] Josip Valic commented on CLOUDSTACK-8444: - We can test this feature, we have one SOFS in production with Hyper-V failover cluster and we can setup another SOFS just for CloudStack. What we need to do? > [Hyper-V] Add a Failover Clustering of Hyper-V support in CloudStack > > > Key: CLOUDSTACK-8444 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8444 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > This will enable us to add support for HA and cluster shared volume in Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9423) Object storage should get the correct size for compressed templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357551#comment-15357551 ] ASF GitHub Bot commented on CLOUDSTACK-9423: Github user syed closed the pull request at: https://github.com/apache/cloudstack/pull/1598 > Object storage should get the correct size for compressed templates > --- > > Key: CLOUDSTACK-9423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9423 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: syed ahmed > Labels: secondary_storage, swift, template > > When uploading templates to an object store like Swift, if the template is > compressed, we get an invalid size (negative). This fix tries to see if the > template is compressed, if so, gets the correct size by partially > decompressing the VHD header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9423) Object storage should get the correct size for compressed templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357552#comment-15357552 ] ASF GitHub Bot commented on CLOUDSTACK-9423: GitHub user syed reopened a pull request: https://github.com/apache/cloudstack/pull/1598 [CLOUDSTACK-9423] Add ability to get virtual size of compressed VHDs With object store like Swift as secondary storage, if a compressed VHD is uploaded as a template, the `VHDProcessor` incorrectly calculates the virutal size leading to the template being useless. This fix tries to guess the virtual size by partially decompressing it and falls back to a sensible default which is the size of the file. Before the fix: template.properties on Swift ``` uniquename=routing-1 filename=routing-1.vhd size=263417314 virtualsize=2894447637315205059 ``` After the fix ``` uniquename=routing-1 filename=routing-1.vhd size=263417314 virtualsize=3145728000 ``` Look at the `virutalsize` in both cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/syed/cloudstack vhd-compressed-size Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1598.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 #1598 > Object storage should get the correct size for compressed templates > --- > > Key: CLOUDSTACK-9423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9423 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: syed ahmed > Labels: secondary_storage, swift, template > > When uploading templates to an object store like Swift, if the template is > compressed, we get an invalid size (negative). This fix tries to see if the > template is compressed, if so, gets the correct size by partially > decompressing the VHD header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9423) Object storage should get the correct size for compressed templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357529#comment-15357529 ] ASF GitHub Bot commented on CLOUDSTACK-9423: Github user syed closed the pull request at: https://github.com/apache/cloudstack/pull/1598 > Object storage should get the correct size for compressed templates > --- > > Key: CLOUDSTACK-9423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9423 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: syed ahmed > Labels: secondary_storage, swift, template > > When uploading templates to an object store like Swift, if the template is > compressed, we get an invalid size (negative). This fix tries to see if the > template is compressed, if so, gets the correct size by partially > decompressing the VHD header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9423) Object storage should get the correct size for compressed templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357530#comment-15357530 ] ASF GitHub Bot commented on CLOUDSTACK-9423: GitHub user syed reopened a pull request: https://github.com/apache/cloudstack/pull/1598 [CLOUDSTACK-9423] Add ability to get virtual size of compressed VHDs With object store like Swift as secondary storage, if a compressed VHD is uploaded as a template, the `VHDProcessor` incorrectly calculates the virutal size leading to the template being useless. This fix tries to guess the virtual size by partially decompressing it and falls back to a sensible default which is the size of the file. Before the fix: template.properties on Swift ``` uniquename=routing-1 filename=routing-1.vhd size=263417314 virtualsize=2894447637315205059 ``` After the fix ``` uniquename=routing-1 filename=routing-1.vhd size=263417314 virtualsize=3145728000 ``` Look at the `virutalsize` in both cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/syed/cloudstack vhd-compressed-size Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1598.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 #1598 commit b0247b53f99ff97fd05d4d8528115ed6e7d497c0 Author: Syed Date: 2016-06-27T20:11:14Z [CLOUDSTACK-9423] Add ability to get virtual size of compressed VHDs > Object storage should get the correct size for compressed templates > --- > > Key: CLOUDSTACK-9423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9423 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: syed ahmed > Labels: secondary_storage, swift, template > > When uploading templates to an object store like Swift, if the template is > compressed, we get an invalid size (negative). This fix tries to see if the > template is compressed, if so, gets the correct size by partially > decompressing the VHD header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9425) Storage statistics shown on CloudStack Primary storage is different from the statistics on Xen SR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Ranganath updated CLOUDSTACK-9425: Attachment: CS statistics mismatch.PNG > Storage statistics shown on CloudStack Primary storage is different from the > statistics on Xen SR > - > > Key: CLOUDSTACK-9425 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9425 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Xen >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > Xenserver 6.2.0 >Reporter: Kiran Ranganath > Attachments: CS statistics mismatch.PNG > > > 1) Add Xen hosts > 2) Create Primary storage in the cluster. This should create Storage > respository for the Xenserver > 3) Create compute offering to create root disk on the created primary storage > 4) Create an instance. > 5) Once the VM is UP. > 6) Check storage statistics on CloudStack (primary storage) and on Xenserver > (storage repository) > There is a variance in the allocated size shown on CloudStack Primary storage > and associated Xen Storage repository. > I used Debian based system VM template to create the VM. > CloudStack: > Disk Total 10 GB > Disk Allocated 5.87 GB > Xen: > 4.2 GB used of 10 GB (2.9 GB allocated) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9425) Storage statistics shown on CloudStack Primary storage is different from the statistics on Xen SR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Ranganath updated CLOUDSTACK-9425: Attachment: (was: CS statistics mismatch.PNG) > Storage statistics shown on CloudStack Primary storage is different from the > statistics on Xen SR > - > > Key: CLOUDSTACK-9425 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9425 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Xen >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > Xenserver 6.2.0 >Reporter: Kiran Ranganath > > 1) Add Xen hosts > 2) Create Primary storage in the cluster. This should create Storage > respository for the Xenserver > 3) Create compute offering to create root disk on the created primary storage > 4) Create an instance. > 5) Once the VM is UP. > 6) Check storage statistics on CloudStack (primary storage) and on Xenserver > (storage repository) > There is a variance in the allocated size shown on CloudStack Primary storage > and associated Xen Storage repository. > I used Debian based system VM template to create the VM. > CloudStack: > Disk Total 10 GB > Disk Allocated 5.87 GB > Xen: > 4.2 GB used of 10 GB (2.9 GB allocated) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9426) CloudStack does not re-scan for new LUNs for an iSCSI based storage on KVM host
Kiran Ranganath created CLOUDSTACK-9426: --- Summary: CloudStack does not re-scan for new LUNs for an iSCSI based storage on KVM host Key: CLOUDSTACK-9426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9426 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, Storage Controller Affects Versions: 4.5.2 Environment: QEMU emulator version 2.0.0 Reporter: Kiran Ranganath When we create the first Volume on an iSCSI Primary Storage, CS requests all hosts to scan for new LUNs. But when the second volume creation is attempted, it does not scan for newly available LUNs. Thus creation of the second volume fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9425) Storage statistics shown on CloudStack Primary storage is different from the statistics on Xen SR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Ranganath updated CLOUDSTACK-9425: Attachment: CS statistics mismatch.PNG > Storage statistics shown on CloudStack Primary storage is different from the > statistics on Xen SR > - > > Key: CLOUDSTACK-9425 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9425 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Xen >Affects Versions: 4.5.2 > Environment: CloudStack 4.5.2 > Xenserver 6.2.0 >Reporter: Kiran Ranganath > Attachments: CS statistics mismatch.PNG > > > 1) Add Xen hosts > 2) Create Primary storage in the cluster. This should create Storage > respository for the Xenserver > 3) Create compute offering to create root disk on the created primary storage > 4) Create an instance. > 5) Once the VM is UP. > 6) Check storage statistics on CloudStack (primary storage) and on Xenserver > (storage repository) > There is a variance in the allocated size shown on CloudStack Primary storage > and associated Xen Storage repository. > I used Debian based system VM template to create the VM. > CloudStack: > Disk Total 10 GB > Disk Allocated 5.87 GB > Xen: > 4.2 GB used of 10 GB (2.9 GB allocated) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9425) Storage statistics shown on CloudStack Primary storage is different from the statistics on Xen SR
Kiran Ranganath created CLOUDSTACK-9425: --- Summary: Storage statistics shown on CloudStack Primary storage is different from the statistics on Xen SR Key: CLOUDSTACK-9425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9425 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller, Xen Affects Versions: 4.5.2 Environment: CloudStack 4.5.2 Xenserver 6.2.0 Reporter: Kiran Ranganath 1) Add Xen hosts 2) Create Primary storage in the cluster. This should create Storage respository for the Xenserver 3) Create compute offering to create root disk on the created primary storage 4) Create an instance. 5) Once the VM is UP. 6) Check storage statistics on CloudStack (primary storage) and on Xenserver (storage repository) There is a variance in the allocated size shown on CloudStack Primary storage and associated Xen Storage repository. I used Debian based system VM template to create the VM. CloudStack: Disk Total 10 GB Disk Allocated 5.87 GB Xen: 4.2 GB used of 10 GB (2.9 GB allocated) -- This message was sent by Atlassian JIRA (v6.3.4#6332)