[jira] [Commented] (CLOUDSTACK-9104) VM naming convention in case vmware is used

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Josip Valic (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Kiran Ranganath (JIRA)]

 [ 
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

[Kiran Ranganath (JIRA)]

 [ 
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 (JIRA)]

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

[Kiran Ranganath (JIRA)]

 [ 
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 (JIRA)]

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)

[jira] [Updated] (CLOUDSTACK-9424) Documentation Error: Incorrect OpenLDAP configuration parameter default value

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi updated CLOUDSTACK-9424:

Summary: Documentation Error: Incorrect OpenLDAP configuration parameter 
default value  (was: Documentation Error: Incorrect OpenLDAP configuration 
parameter name)

> Documentation Error: Incorrect OpenLDAP configuration parameter default value
> -
>
> Key: CLOUDSTACK-9424
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9424
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Affects Versions: 4.8.0
> Environment: NA
>Reporter: Ganesh Satpute
>Priority: Minor
>  Labels: doc, docstrings
>
> At this document: 
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/accounts.html#using-an-ldap-server-for-user-authentication
>  
> There is a section where information on how to configure LDAP is written. 
> The value for the object {{ldap.user.object}} for openldap is incorrectly 
> written as {{interorgperson}} rather it should be {{inetorgperson}}



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

[jira] [Updated] (CLOUDSTACK-9424) Documentation Error: Incorrect OpenLDAP configuration parameter default value

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi updated CLOUDSTACK-9424:

Description: 
At this document: 
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/accounts.html#using-an-ldap-server-for-user-authentication
 

There is a section where information on how to configure LDAP is written. 

The default value for the object {{ldap.user.object}} for openldap is 
incorrectly written as {{interorgperson}} rather it should be {{inetorgperson}}

  was:
At this document: 
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/accounts.html#using-an-ldap-server-for-user-authentication
 

There is a section where information on how to configure LDAP is written. 

The value for the object {{ldap.user.object}} for openldap is incorrectly 
written as {{interorgperson}} rather it should be {{inetorgperson}}


> Documentation Error: Incorrect OpenLDAP configuration parameter default value
> -
>
> Key: CLOUDSTACK-9424
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9424
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Affects Versions: 4.8.0
> Environment: NA
>Reporter: Ganesh Satpute
>Priority: Minor
>  Labels: doc, docstrings
>
> At this document: 
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/accounts.html#using-an-ldap-server-for-user-authentication
>  
> There is a section where information on how to configure LDAP is written. 
> The default value for the object {{ldap.user.object}} for openldap is 
> incorrectly written as {{interorgperson}} rather it should be 
> {{inetorgperson}}



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

[jira] [Commented] (CLOUDSTACK-9424) Documentation Error: Incorrect OpenLDAP configuration parameter name

[Rajani Karuturi (JIRA)]

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

Rajani Karuturi commented on CLOUDSTACK-9424:
-

https://github.com/apache/cloudstack-docs-admin/pull/39

> Documentation Error: Incorrect OpenLDAP configuration parameter name
> 
>
> Key: CLOUDSTACK-9424
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9424
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Affects Versions: 4.8.0
> Environment: NA
>Reporter: Ganesh Satpute
>Priority: Minor
>  Labels: doc, docstrings
>
> At this document: 
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/accounts.html#using-an-ldap-server-for-user-authentication
>  
> There is a section where information on how to configure LDAP is written. 
> The value for the object {{ldap.user.object}} for openldap is incorrectly 
> written as {{interorgperson}} rather it should be {{inetorgperson}}



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