[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931505#comment-13931505 ] ASF subversion and git services commented on CLOUDSTACK-4787: - Commit 17a08a0236ed9710ca10024e1a52d634bb58b9c3 in cloudstack's branch refs/heads/ova-multiple-disks from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=17a08a0 ] CLOUDSTACK-4787 Support OVA with multiple volumes Creating OVF file to pack vmdk corresponding to data disk in OVA. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org Allow selection of scsi controller type in vSphere -- Key: CLOUDSTACK-4787 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI, VMware Affects Versions: 4.2.0, 4.3.0 Environment: vSphere 5.1 Reporter: Chris Sciarrino Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: Future When adding an OVA template for a vSphere environment allow the selection of the scsi controller type. Currently the instances are deployed with the the LSI Parallel controller type. This results in a blue screen on boot when attempting to deploy templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6181) Root resize
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931644#comment-13931644 ] Nux commented on CLOUDSTACK-6181: - Marcus, It worked great! All my tests succeeded on local, NFS, GlusterFS and CLVM. The only problem that I'm hitting now is the inability of shrinking qcow2 files, but this is a qemu-img/qcow2 limitation and not a Cloudstack bug. Thanks a lot for your work! Root resize --- Key: CLOUDSTACK-6181 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6181 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller, UI Affects Versions: 4.4.0 Environment: KVM/libvirt/CentOS, Xenserver Reporter: Nux Labels: disk, resize, template Fix For: 4.4.0 Rationale: Currently the root size of an instance is locked to that of the template. This creates unnecessary template duplicates, prevents the creation of a market place, wastes time and disk space and generally makes work more complicated. Real life example - a small VPS provider might want to offer the following sizes (in GB): 10,20,40,80,160,240,320,480,620 That's 9 offerings. The template selection could look like this, including real disk space used: Windows 2008 ~10GB Windows 2008+Plesk ~15GB Windows 2008+MSSQL ~15GB Windows 2012 ~10GB Windows 2012+Plesk ~15GB Windows 2012+MSSQL ~15GB CentOS ~1GB CentOS+CPanel ~3GB CentOS+Virtualmin ~3GB CentOS+Zimbra ~3GB CentOS+Docker ~2GB Debian ~1GB Ubuntu LTS ~1GB In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If your storage is expensive and limited SSD this can get painful! If the root resize feature is enabled we can reduce this to under 100 GB. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4757) [VMware] Support OVA files with multiple disks for templates and uploaded volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931711#comment-13931711 ] ASF subversion and git services commented on CLOUDSTACK-4757: - Commit 99eb63ed854eea722b02dee68bb9d0bf5a892dc2 in cloudstack's branch refs/heads/ova-multiple-disks from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=99eb63e ] CLOUDSTACK-4757 Support OVA with multiple volumes Get bootdevice from extra config option in ova template. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org [VMware] Support OVA files with multiple disks for templates and uploaded volumes - Key: CLOUDSTACK-4757 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.0 CloudStack volumes and templates are one single virtual disk in case of XenServer/XCP and KVM hypervisors since the files used for templates and volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates are in OVA format, which are archives that can contain a complete VM including multiple VMDKs and other files such as ISOs. And currently, Cloudstack only supports Template creation based on OVA files containing a single disk. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, only the first disk is attached to the new instance and other disks are ignored. Similarly with uploaded volumes, attaching an uploaded volume that contains multiple disks to a VM will result in only one VMDK to being attached to the VM. This behavior needs to be improved in VMWare to support OVA files with multiple disks for both uploaded volumes and templates. i.e. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, the first disk should be attached to the new instance as the ROOT disk and volumes should be created based on other VMDK disks in the OVA file and should be attached to the instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6231) Cloudstack createNetworkACL cuts cidrlist at 256 characters
Daan Hoogland created CLOUDSTACK-6231:
-
Summary: Cloudstack createNetworkACL cuts cidrlist at 256
characters
Key: CLOUDSTACK-6231
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6231
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Fix For: 4.4.0
[2014-03-11T11:18:54+01:00] INFO: Creating acl on network SBP_VPC_MGT1_APP1:
10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.10/32,10.75.14.214/32,10.75.15.86/32,10.75.16.101/32,10.75.16.105/32,10.75.16.114/32,10.75.16.124/32,10.75.16.67/32,10.75.16.80/32,10.75.16.88/32,10.75.16.93/32,10.75.16.97/32,10.75.17.113/32,10.75.17.124/32,10.75.17.73/32,10.75.17.84/32,10.75.17.87/32,10.75.17.92/32,10.75.18.168/32,10.75.18.20/32,10.75.2.11/32,10.75.2.112/32,10.75.2.114/32,10.75.2.116/32,10.75.2.123/32,10.75.2.14/32,10.75.2.35/32,10.75.2.61/32,10.75.2.79/32,10.75.2.83/32,10.75.21.12/32,10.75.22.187/32,10.75.23.4/32,10.75.24.29/32,10.75.25.114/32,10.75.25.9/32,10.75.26.20/32,10.75.26.27/32,10.75.26.28/32,10.75.27.11/32,10.75.27.17/32,10.75.27.23/32,10.75.28.159/32,10.75.29.109/32,10.75.3.32/32,10.75.30.71/32,10.75.31.3/32,10.75.32.57/32,10.75.33.15/32,10.75.34.46/32,10.75.35.113/32,10.75.35.33/32,10.75.35.80/32,10.75.36.70/32,10.75.38.4/32,10.75.39.6/32,10.75.4.118/32,10.75.4.23/32,10.75.40.49/32,10.75.40.72/32,10.75.41.57/32,10.75.41.75/32,10.75.42.102/32,10.75.42.2/32,10.75.43.126/32,10.75.43.28/32,10.75.44.2/32,10.75.45.9/32,10.75.47.111/32,10.75.47.29/32,10.75.47.35/32,10.75.6.6/32,192.168.0.208/32,192.168.0.30/32
tcp 514/514 Ingress [2014-03-11T11:18:54+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:55+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:56+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:57+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:58+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:59+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:19:00+01:00] INFO: Job e71b6c83-a482-4765-9024-2ee9d146baa1
done, result: {networkacl={id=5f226473-8798-4336-a68d-b38a3f7a41a0,
protocol=tcp, startport=514, endport=514,
traffictype=Ingress, state=Active,
cidrlist=10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.1,
tags=[], aclid=482f3740-7eda-11e3-aa74-005056b95463, number=93,
action=Allow}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4757) [VMware] Support OVA files with multiple disks for templates and uploaded volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931763#comment-13931763 ] ASF subversion and git services commented on CLOUDSTACK-4757: - Commit 7fb5641f48f63c72e41b11828b57e910e381c737 in cloudstack's branch refs/heads/ova-multiple-disks from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7fb5641 ] CLOUDSTACK-4757 Support OVA with multiple volumes If no user configured bootdisk available, choose 1st disk. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org [VMware] Support OVA files with multiple disks for templates and uploaded volumes - Key: CLOUDSTACK-4757 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.0 CloudStack volumes and templates are one single virtual disk in case of XenServer/XCP and KVM hypervisors since the files used for templates and volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates are in OVA format, which are archives that can contain a complete VM including multiple VMDKs and other files such as ISOs. And currently, Cloudstack only supports Template creation based on OVA files containing a single disk. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, only the first disk is attached to the new instance and other disks are ignored. Similarly with uploaded volumes, attaching an uploaded volume that contains multiple disks to a VM will result in only one VMDK to being attached to the VM. This behavior needs to be improved in VMWare to support OVA files with multiple disks for both uploaded volumes and templates. i.e. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, the first disk should be attached to the new instance as the ROOT disk and volumes should be created based on other VMDK disks in the OVA file and should be attached to the instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
Daan Hoogland created CLOUDSTACK-6232:
-
Summary: isolated network can no longer reserve ip range
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted in
4.2.1. It seems in line with the philosophy of cloudstack but is hurting our
operation. In 4.1.1 we could add a bridged network with the following network
offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter} ]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6231) Cloudstack createNetworkACL cuts cidrlist at 256 characters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931831#comment-13931831
]
ASF subversion and git services commented on CLOUDSTACK-6231:
-
Commit 1dc2bbdc37faa9cb007c3e0446efc078255f3f76 in cloudstack's branch
refs/heads/master from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1dc2bbd ]
CLOUDSTACK-6231 allow for cidr list entry of more than 256 chars
Cloudstack createNetworkACL cuts cidrlist at 256 characters
---
Key: CLOUDSTACK-6231
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6231
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Fix For: 4.4.0
[2014-03-11T11:18:54+01:00] INFO: Creating acl on network SBP_VPC_MGT1_APP1:
10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.10/32,10.75.14.214/32,10.75.15.86/32,10.75.16.101/32,10.75.16.105/32,10.75.16.114/32,10.75.16.124/32,10.75.16.67/32,10.75.16.80/32,10.75.16.88/32,10.75.16.93/32,10.75.16.97/32,10.75.17.113/32,10.75.17.124/32,10.75.17.73/32,10.75.17.84/32,10.75.17.87/32,10.75.17.92/32,10.75.18.168/32,10.75.18.20/32,10.75.2.11/32,10.75.2.112/32,10.75.2.114/32,10.75.2.116/32,10.75.2.123/32,10.75.2.14/32,10.75.2.35/32,10.75.2.61/32,10.75.2.79/32,10.75.2.83/32,10.75.21.12/32,10.75.22.187/32,10.75.23.4/32,10.75.24.29/32,10.75.25.114/32,10.75.25.9/32,10.75.26.20/32,10.75.26.27/32,10.75.26.28/32,10.75.27.11/32,10.75.27.17/32,10.75.27.23/32,10.75.28.159/32,10.75.29.109/32,10.75.3.32/32,10.75.30.71/32,10.75.31.3/32,10.75.32.57/32,10.75.33.15/32,10.75.34.46/32,10.75.35.113/32,10.75.35.33/32,10.75.35.80/32,10.75.36.70/32,10.75.38.4/32,10.75.39.6/32,10.75.4.118/32,10.75.4.23/32,10.75.40.49/32,10.75.40.72/32,10.75.41.57/32,10.75.41.75/32,10.75.42.102/32,10.75.42.2/32,10.75.43.126/32,10.75.43.28/32,10.75.44.2/32,10.75.45.9/32,10.75.47.111/32,10.75.47.29/32,10.75.47.35/32,10.75.6.6/32,192.168.0.208/32,192.168.0.30/32
tcp 514/514 Ingress [2014-03-11T11:18:54+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:55+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:56+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:57+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:58+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:59+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:19:00+01:00] INFO: Job e71b6c83-a482-4765-9024-2ee9d146baa1
done, result: {networkacl={id=5f226473-8798-4336-a68d-b38a3f7a41a0,
protocol=tcp, startport=514, endport=514,
traffictype=Ingress, state=Active,
cidrlist=10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.1,
tags=[], aclid=482f3740-7eda-11e3-aa74-005056b95463, number=93,
action=Allow}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6231) Cloudstack createNetworkACL cuts cidrlist at 256 characters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931905#comment-13931905
]
ASF subversion and git services commented on CLOUDSTACK-6231:
-
Commit 454cac448d83b973d8cd337cf214b17e31828b93 in cloudstack's branch
refs/heads/4.3-forward from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=454cac4 ]
CLOUDSTACK-6231 allow for cidr list entry of more than 256 chars
Cloudstack createNetworkACL cuts cidrlist at 256 characters
---
Key: CLOUDSTACK-6231
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6231
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Fix For: 4.4.0
[2014-03-11T11:18:54+01:00] INFO: Creating acl on network SBP_VPC_MGT1_APP1:
10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.10/32,10.75.14.214/32,10.75.15.86/32,10.75.16.101/32,10.75.16.105/32,10.75.16.114/32,10.75.16.124/32,10.75.16.67/32,10.75.16.80/32,10.75.16.88/32,10.75.16.93/32,10.75.16.97/32,10.75.17.113/32,10.75.17.124/32,10.75.17.73/32,10.75.17.84/32,10.75.17.87/32,10.75.17.92/32,10.75.18.168/32,10.75.18.20/32,10.75.2.11/32,10.75.2.112/32,10.75.2.114/32,10.75.2.116/32,10.75.2.123/32,10.75.2.14/32,10.75.2.35/32,10.75.2.61/32,10.75.2.79/32,10.75.2.83/32,10.75.21.12/32,10.75.22.187/32,10.75.23.4/32,10.75.24.29/32,10.75.25.114/32,10.75.25.9/32,10.75.26.20/32,10.75.26.27/32,10.75.26.28/32,10.75.27.11/32,10.75.27.17/32,10.75.27.23/32,10.75.28.159/32,10.75.29.109/32,10.75.3.32/32,10.75.30.71/32,10.75.31.3/32,10.75.32.57/32,10.75.33.15/32,10.75.34.46/32,10.75.35.113/32,10.75.35.33/32,10.75.35.80/32,10.75.36.70/32,10.75.38.4/32,10.75.39.6/32,10.75.4.118/32,10.75.4.23/32,10.75.40.49/32,10.75.40.72/32,10.75.41.57/32,10.75.41.75/32,10.75.42.102/32,10.75.42.2/32,10.75.43.126/32,10.75.43.28/32,10.75.44.2/32,10.75.45.9/32,10.75.47.111/32,10.75.47.29/32,10.75.47.35/32,10.75.6.6/32,192.168.0.208/32,192.168.0.30/32
tcp 514/514 Ingress [2014-03-11T11:18:54+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:55+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:56+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:57+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:58+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:59+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:19:00+01:00] INFO: Job e71b6c83-a482-4765-9024-2ee9d146baa1
done, result: {networkacl={id=5f226473-8798-4336-a68d-b38a3f7a41a0,
protocol=tcp, startport=514, endport=514,
traffictype=Ingress, state=Active,
cidrlist=10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.1,
tags=[], aclid=482f3740-7eda-11e3-aa74-005056b95463, number=93,
action=Allow}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6230) OpenStack Swift as Object Storage Service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-6230: - Attachment: Implements-OpenStack-Swift-as-an-Object-Storage-Service.patch Here is a patch file based on master on 2014/03/12... OpenStack Swift as Object Storage Service - Key: CLOUDSTACK-6230 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6230 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: Future Reporter: Will Stevens Assignee: Will Stevens Fix For: Future Attachments: Implements-OpenStack-Swift-as-an-Object-Storage-Service.patch Check the FS for details: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=39622892 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931973#comment-13931973
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit 5685d145373ea05c7ceb152c4553953599b7369a in cloudstack's branch
refs/heads/master from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5685d14 ]
[CLOUDSTACK-6232] bridging allowed in isolated networks
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931993#comment-13931993
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8 in cloudstack's branch
refs/heads/4.3-forward from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f78e7ae ]
[CLOUDSTACK-6232] bridging allowed in isolated networks
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932035#comment-13932035
]
Alena Prokharchyk commented on CLOUDSTACK-6232:
---
Daan, looks like we also has to change createVlanIpRange call in addition to
createNetwork, otherwise the fix would be partial. This call is executed when
the network is already created, and you want to extend its range.
Configuration ManagerImpl, public Vlan
createVlanAndPublicIpRange(CreateVlanIpRangeCmd cmd)
// If networkId is not specified, and vlan is Virtual or Direct
// Untagged, try to locate default networks
if (forVirtualNetwork) {
if (network == null) {
// find default public network in the zone
networkId =
_networkModel.getSystemNetworkByZoneAndTrafficType(zoneId,
TrafficType.Public).getId();
network = _networkModel.getNetwork(networkId);
} else if (network.getGuestType() != null ||
network.getTrafficType() != TrafficType.Public) {
throw new InvalidParameterValueException(Can't find Public
network by id= + networkId);
}
} else {
if (network == null) {
if (zone.getNetworkType() == DataCenter.NetworkType.Basic) {
networkId =
_networkModel.getExclusiveGuestNetwork(zoneId).getId();
network = _networkModel.getNetwork(networkId);
} else {
network =
_networkModel.getNetworkWithSecurityGroupEnabled(zoneId);
if (network == null) {
throw new InvalidParameterValueException(Nework id is
required for Direct vlan creation );
}
networkId = network.getId();
zoneId = network.getDataCenterId();
}
CHANGE THIS LINE BY ADDING :} else if (network.getGuestType() ==
null || network.getGuestType() == Network.GuestType.Isolated) {WITH
} else if (network.getGuestType() == null || (network.getGuestType() ==
Network.GuestType.Isolated
areServicesSupportedByNetworkOffering(ntwkOff.getId(), Service.SourceNat)))
throw new InvalidParameterValueException(Can't create direct
vlan for network id= + networkId + with type: + network.getGuestType());
}
}
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6233) Add new tab GPU in Host detailView for gpu enabled hosts
Sanjay Tripathi created CLOUDSTACK-6233: --- Summary: Add new tab GPU in Host detailView for gpu enabled hosts Key: CLOUDSTACK-6233 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6233 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Sanjay Tripathi Fix For: 4.4.0 For GPU/vGPU enabled Hosts, UI should display the supported vGPU types and remaining capacity of GPU card. The tab should only be visible for GPU enabled hosts. For GPU/vGPU enabled Hosts, listHosts API gives the following response: memorytotal15972703488/memorytotal memoryallocated1610612736/memoryallocated memoryused2600064/memoryused gpugroup gpugroupnameGroup of NVIDIA Corporation GK104GL [GRID K2] GPUs/gpugroupname vgpu vgputypeGRID K200/vgputype remainingcapacity16/remainingcapacity /vgpu vgpu vgputypepassthrough/vgputype remainingcapacity2/remainingcapacity /vgpu vgpu vgputypeGRID K260Q/vgputype remainingcapacity4/remainingcapacity /vgpu vgpu vgputypeGRID K240Q/vgputype remainingcapacity8/remainingcapacity /vgpu /gpugroup capabilities xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64 /capabilities This response tells about the no. of GPU cards and remaining capacity per vGPU types in the GPU cards. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932088#comment-13932088
]
Daan Hoogland commented on CLOUDSTACK-6232:
---
Ah, that is what you meant. Let me look at it
On Wed, Mar 12, 2014 at 6:21 PM, Alena Prokharchyk (JIRA)
--
Daan
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6233) Add new tab GPU in Host detailView for gpu enabled hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-6233: Attachment: screenshot-1.jpg In my view, right place for GPU tab is next to Statistics tab. Add new tab GPU in Host detailView for gpu enabled hosts -- Key: CLOUDSTACK-6233 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6233 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Sanjay Tripathi Fix For: 4.4.0 Attachments: screenshot-1.jpg For GPU/vGPU enabled Hosts, UI should display the supported vGPU types and remaining capacity of GPU card. The tab should only be visible for GPU enabled hosts. For GPU/vGPU enabled Hosts, listHosts API gives the following response: memorytotal15972703488/memorytotal memoryallocated1610612736/memoryallocated memoryused2600064/memoryused gpugroup gpugroupnameGroup of NVIDIA Corporation GK104GL [GRID K2] GPUs/gpugroupname vgpu vgputypeGRID K200/vgputype remainingcapacity16/remainingcapacity /vgpu vgpu vgputypepassthrough/vgputype remainingcapacity2/remainingcapacity /vgpu vgpu vgputypeGRID K260Q/vgputype remainingcapacity4/remainingcapacity /vgpu vgpu vgputypeGRID K240Q/vgputype remainingcapacity8/remainingcapacity /vgpu /gpugroup capabilities xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64 /capabilities This response tells about the no. of GPU cards and remaining capacity per vGPU types in the GPU cards. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932144#comment-13932144
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit b5c8a56eeaa62cb1295993b43b11f1fb916949af in cloudstack's branch
refs/heads/master from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b5c8a56 ]
CLOUDSTACK-6232 allow expansion of ip on isolated networks as well
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932153#comment-13932153
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit edf97ac86c94741ae8964b640bdfc0234929c1e4 in cloudstack's branch
refs/heads/4.3-forward from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=edf97ac ]
CLOUDSTACK-6232 allow expansion of ip on isolated networks as well
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6234) local storage shows up as 0 for disksizeallocated
Timothy Ehlers created CLOUDSTACK-6234: -- Summary: local storage shows up as 0 for disksizeallocated Key: CLOUDSTACK-6234 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6234 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0, 4.0.2, 4.0.1, 4.0.0 Reporter: Timothy Ehlers Priority: Critical clusterid: 10ea4d99-09ea-48cb-aca3-fe30c1c574ac, clustername: pod1c1, created: 2013-11-25T17:17:53-0600, disksizeallocated: 0, disksizetotal: 588371378176, disksizeused: 29782499328, id: 1d25d177-6d51-47ca-b03d-e3ec1f5adfc0, ipaddress: 10.228.231.45, name: server4 Local Storage, -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6235) listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response
Alena Prokharchyk created CLOUDSTACK-6235: - Summary: listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response Key: CLOUDSTACK-6235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6235 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 Steps to reproduce: == 1) Setup basic zone with EIP/ELB services 2) Wait for system vms to come up 3) execute listSystemVms call. Bug: gateway/netmask info is missing for the VM's public interface -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6235) listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-6235: -- Affects Version/s: (was: 4.3.0) 4.4.0 Fix Version/s: (was: 4.3.0) 4.4.0 listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response - Key: CLOUDSTACK-6235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6235 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.4.0 Steps to reproduce: == 1) Setup basic zone with EIP/ELB services 2) Wait for system vms to come up 3) execute listSystemVms call. Bug: gateway/netmask info is missing for the VM's public interface -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6231) Cloudstack createNetworkACL cuts cidrlist at 256 characters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932524#comment-13932524
]
ASF subversion and git services commented on CLOUDSTACK-6231:
-
Commit 34435173a789eb5a1385672fa10cda6332aa9ad8 in cloudstack's branch
refs/heads/4.3 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3443517 ]
CLOUDSTACK-6231 allow for cidr list entry of more than 256 chars
(cherry picked from commit 454cac448d83b973d8cd337cf214b17e31828b93)
Signed-off-by: Animesh Chaturvedi anim...@apache.org
Cloudstack createNetworkACL cuts cidrlist at 256 characters
---
Key: CLOUDSTACK-6231
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6231
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Fix For: 4.4.0
[2014-03-11T11:18:54+01:00] INFO: Creating acl on network SBP_VPC_MGT1_APP1:
10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.10/32,10.75.14.214/32,10.75.15.86/32,10.75.16.101/32,10.75.16.105/32,10.75.16.114/32,10.75.16.124/32,10.75.16.67/32,10.75.16.80/32,10.75.16.88/32,10.75.16.93/32,10.75.16.97/32,10.75.17.113/32,10.75.17.124/32,10.75.17.73/32,10.75.17.84/32,10.75.17.87/32,10.75.17.92/32,10.75.18.168/32,10.75.18.20/32,10.75.2.11/32,10.75.2.112/32,10.75.2.114/32,10.75.2.116/32,10.75.2.123/32,10.75.2.14/32,10.75.2.35/32,10.75.2.61/32,10.75.2.79/32,10.75.2.83/32,10.75.21.12/32,10.75.22.187/32,10.75.23.4/32,10.75.24.29/32,10.75.25.114/32,10.75.25.9/32,10.75.26.20/32,10.75.26.27/32,10.75.26.28/32,10.75.27.11/32,10.75.27.17/32,10.75.27.23/32,10.75.28.159/32,10.75.29.109/32,10.75.3.32/32,10.75.30.71/32,10.75.31.3/32,10.75.32.57/32,10.75.33.15/32,10.75.34.46/32,10.75.35.113/32,10.75.35.33/32,10.75.35.80/32,10.75.36.70/32,10.75.38.4/32,10.75.39.6/32,10.75.4.118/32,10.75.4.23/32,10.75.40.49/32,10.75.40.72/32,10.75.41.57/32,10.75.41.75/32,10.75.42.102/32,10.75.42.2/32,10.75.43.126/32,10.75.43.28/32,10.75.44.2/32,10.75.45.9/32,10.75.47.111/32,10.75.47.29/32,10.75.47.35/32,10.75.6.6/32,192.168.0.208/32,192.168.0.30/32
tcp 514/514 Ingress [2014-03-11T11:18:54+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:55+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:56+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:57+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:18:58+01:00] INFO: Status of job
e71b6c83-a482-4765-9024-2ee9d146baa1 is 0 [2014-03-11T11:18:59+01:00] INFO:
Status of job e71b6c83-a482-4765-9024-2ee9d146baa1 is 0
[2014-03-11T11:19:00+01:00] INFO: Job e71b6c83-a482-4765-9024-2ee9d146baa1
done, result: {networkacl={id=5f226473-8798-4336-a68d-b38a3f7a41a0,
protocol=tcp, startport=514, endport=514,
traffictype=Ingress, state=Active,
cidrlist=10.168.1.198/32,10.168.1.251/32,10.168.2.178/32,10.168.2.245/32,10.168.4.27/32,10.168.4.44/32,10.71.76.27/32,10.71.76.28/32,10.75.12.108/32,10.75.12.11/32,10.75.12.35/32,10.75.12.75/32,10.75.12.98/32,10.75.13.30/32,10.75.13.71/32,10.75.13.94/32,10.75.14.1,
tags=[], aclid=482f3740-7eda-11e3-aa74-005056b95463, number=93,
action=Allow}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932525#comment-13932525
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit 9af90e319d3efe38c86712e3206984670f3625d7 in cloudstack's branch
refs/heads/4.3 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9af90e3 ]
[CLOUDSTACK-6232] bridging allowed in isolated networks
(cherry picked from commit f78e7ae51f55da17ed5ba239f99457ee8bc7c4d8)
Signed-off-by: Animesh Chaturvedi anim...@apache.org
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5986) dnsmasq racy condition result in dnsmasq failed to handout IP address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932523#comment-13932523 ] ASF subversion and git services commented on CLOUDSTACK-5986: - Commit 92b9951df3050c8934b882b0b4c70828ac01f9af in cloudstack's branch refs/heads/4.3 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92b9951 ] CLOUDSTACK-5986: Fix dnsmasq lease for VPC (cherry picked from commit a253ff24682a7d405bfa8428a0833423bf19f9b9) Signed-off-by: Animesh Chaturvedi anim...@apache.org dnsmasq racy condition result in dnsmasq failed to handout IP address - Key: CLOUDSTACK-5986 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5986 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0, 4.2.1 Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.2.1, 4.3.0 In the past, dnsmasq.leases is managed by cloudstack, and would be updated after new entry is added(and the entry with same IP or host would be removed). In 4.2, we introduced dhcp_release try to speed up the dnsmasq reload process, thus result in this issue. So in this scenario: 1. VM1 would create entry: mac A, IP A, host A 2. VM2 would create entry: mac B, IP B, host B 3. VM1 destroyed and VM 2 destroyed, no change to lease file, two records still existed. 4. VM1 created with IP B: mac C, IP B, host A. At this time, lease file would only contain: mac C, IP B, host A, because the original entries would be removed by either IP match or host name match. In fact dnsmasq still holds lease of IP A with mac A in memory, but record is already removed from lease file by cloudstack. The lease file is out of sync now. 5. VM2 recreated with IP A, dhcp_release would be used to release the lease. But there is no mac A, IP A record in the lease file, so dhcp_release failed. So result in dnsmasq cannot handle out the IP A to new mac D, because dnsmasq was still holding lease for IP A with mac A and haven't been released yet. So it only happened when user create and destroy different VMs which share the same name but get different IPs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6232) isolated network can no longer reserve ip range
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932526#comment-13932526
]
ASF subversion and git services commented on CLOUDSTACK-6232:
-
Commit 6a6ec648099553a42f830dcd566eab2452428908 in cloudstack's branch
refs/heads/4.3 from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6a6ec64 ]
CLOUDSTACK-6232 allow expansion of ip on isolated networks as well
(cherry picked from commit edf97ac86c94741ae8964b640bdfc0234929c1e4)
Signed-off-by: Animesh Chaturvedi anim...@apache.org
isolated network can no longer reserve ip range
---
Key: CLOUDSTACK-6232
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6232
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.2.0, 4.3.0, 4.4.0
Reporter: Daan Hoogland
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.4.0
We found a functionality that we use once in a while no longer is permitted
in 4.2.1. It seems in line with the philosophy of cloudstack but is hurting
our operation. In 4.1.1 we could add a bridged network with the following
network offering:
cno.traffictype = GUEST
cno.guestiptype = Isolated
cno.specifyipranges = True
cno.specifyvlan = False
cno.serviceproviderlist = [ { service: Connectivity, provider:
NiciraNvp},
{ service: UserData, provider:
VirtualRouter},
{ service: Dhcp, provider: VirtualRouter}
]
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6235) listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6235. --- Resolution: Fixed listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response - Key: CLOUDSTACK-6235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6235 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.4.0 Steps to reproduce: == 1) Setup basic zone with EIP/ELB services 2) Wait for system vms to come up 3) execute listSystemVms call. Bug: gateway/netmask info is missing for the VM's public interface -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6235) listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932530#comment-13932530 ] ASF subversion and git services commented on CLOUDSTACK-6235: - Commit 40192cd8a1ee33ec784cfcbdb7c4c78483a8f1eb in cloudstack's branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40192cd ] CLOUDSTACK-6235 - return gateway/netmask of publicVlan, along with the EIP information, for system vms in EIP/ELB setup listSystemVms in EIP/ELB setup: gateway/netmask are missing from the response - Key: CLOUDSTACK-6235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6235 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.4.0 Steps to reproduce: == 1) Setup basic zone with EIP/ELB services 2) Wait for system vms to come up 3) execute listSystemVms call. Bug: gateway/netmask info is missing for the VM's public interface -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6236) Negative ref_cnt of template(snapshot/volume)_store_ref results in out-of-range error in Mysql
Min Chen created CLOUDSTACK-6236:
Summary: Negative ref_cnt of template(snapshot/volume)_store_ref
results in out-of-range error in Mysql
Key: CLOUDSTACK-6236
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6236
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.4.0
Steps:
1. Deploy CS with ESXi5.5 and NFS secondary storage.
2. Create a VM and take the snapshot of root volume.
3. Create a template from snapshot.
4. Migrate the secondary NFS to S3.
5. Download the template created from snapshot (step3). Now the template will
be in S3.
6. Tried to delete the template now.
Observation:
Template got deleted from S3 but observing an exception while deleting it from
ImageCache.
2014-03-04 16:19:58,227 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 2-9302: Sending Seq 2-9302: { Ans: ,
MgmtId: 6758231703598, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-03-04 16:19:58,255 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-51:Job-47) Unexpected exception while executing
org.apache.cloudstack.api.command.user.template.DeleteTemplateCmd
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@5cb563d: SELECT template_store_ref.id,
template_store_ref.store_id, template_store_ref.template_id,
template_store_ref.store_role, template_store_ref.created,
template_store_ref.last_updated, template_store_ref.download_pct,
template_store_ref.size, template_store_ref.physical_size,
template_store_ref.download_state, template_store_ref.local_path,
template_store_ref.error_str, template_store_ref.job_id,
template_store_ref.install_path, template_store_ref.url,
template_store_ref.is_copy, template_store_ref.destroyed,
template_store_ref.update_count, template_store_ref.updated,
template_store_ref.state, template_store_ref.ref_cnt FROM template_store_ref
WHERE template_store_ref.template_id = 202 AND template_store_ref.store_role =
'ImageCache'
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:340)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:1243)
at
org.apache.cloudstack.storage.image.db.TemplateDataStoreDaoImpl.listOnCache(TemplateDataStoreDaoImpl.java:365)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
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 $Proxy108.listOnCache(Unknown Source)
at
org.apache.cloudstack.storage.image.TemplateDataFactoryImpl.listTemplateOnCache(TemplateDataFactoryImpl.java:147)
at
com.cloud.template.HypervisorTemplateAdapter.delete(HypervisorTemplateAdapter.java:355)
at
com.cloud.template.TemplateManagerImpl.deleteTemplate(TemplateManagerImpl.java:1097)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
at
[jira] [Commented] (CLOUDSTACK-6236) Negative ref_cnt of template(snapshot/volume)_store_ref results in out-of-range error in Mysql
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932645#comment-13932645
]
ASF subversion and git services commented on CLOUDSTACK-6236:
-
Commit cd8af6a3e2a180ea4d2cfea8a273dbb0929e0a87 in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd8af6a ]
CLOUDSTACK-6236:Negative ref_cnt of template(snapshot/volume)_store_ref results
in out-of-range error in Mysql
Negative ref_cnt of template(snapshot/volume)_store_ref results in
out-of-range error in Mysql
--
Key: CLOUDSTACK-6236
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6236
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.4.0
Steps:
1. Deploy CS with ESXi5.5 and NFS secondary storage.
2. Create a VM and take the snapshot of root volume.
3. Create a template from snapshot.
4. Migrate the secondary NFS to S3.
5. Download the template created from snapshot (step3). Now the template will
be in S3.
6. Tried to delete the template now.
Observation:
Template got deleted from S3 but observing an exception while deleting it
from ImageCache.
2014-03-04 16:19:58,227 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 2-9302: Sending Seq 2-9302: { Ans: ,
MgmtId: 6758231703598, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-03-04 16:19:58,255 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-51:Job-47) Unexpected exception while executing
org.apache.cloudstack.api.command.user.template.DeleteTemplateCmd
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@5cb563d: SELECT template_store_ref.id,
template_store_ref.store_id, template_store_ref.template_id,
template_store_ref.store_role, template_store_ref.created,
template_store_ref.last_updated, template_store_ref.download_pct,
template_store_ref.size, template_store_ref.physical_size,
template_store_ref.download_state, template_store_ref.local_path,
template_store_ref.error_str, template_store_ref.job_id,
template_store_ref.install_path, template_store_ref.url,
template_store_ref.is_copy, template_store_ref.destroyed,
template_store_ref.update_count, template_store_ref.updated,
template_store_ref.state, template_store_ref.ref_cnt FROM template_store_ref
WHERE template_store_ref.template_id = 202 AND template_store_ref.store_role
= 'ImageCache'
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:340)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:1243)
at
org.apache.cloudstack.storage.image.db.TemplateDataStoreDaoImpl.listOnCache(TemplateDataStoreDaoImpl.java:365)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
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 $Proxy108.listOnCache(Unknown Source)
at
org.apache.cloudstack.storage.image.TemplateDataFactoryImpl.listTemplateOnCache(TemplateDataFactoryImpl.java:147)
at
com.cloud.template.HypervisorTemplateAdapter.delete(HypervisorTemplateAdapter.java:355)
at
com.cloud.template.TemplateManagerImpl.deleteTemplate(TemplateManagerImpl.java:1097)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
[jira] [Comment Edited] (CLOUDSTACK-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931120#comment-13931120 ] angeline shen edited comment on CLOUDSTACK-6214 at 3/12/14 11:28 PM: - Verifify with latest build internal build 4.3.0.0-0.402-rhel6.3.tar.gz MS: 10.223.130.160 host: 10.223.51.4 XS 6.2 nw offer isolated specify VLAN VPC LB type: public LB chk vpn dhcp dns lb userdata sourceNAT staticNAT PF nwACL account 1. Create VPC Configure NW ACL list - Add ACL list vpc4ACL4 vpc4ACL4 ACL list rules add rule 1: 0.0.0.0/0 allow ALL Ingress add rule 2: 0.0.0.0/0 allow ALL Egress 2. Create NW offering 6214: Guest type: isolated specify VLAN: check VPC : check LB type: public LB Supported services: VPN - VR Dhcp - VR DNS - VR Firewall - Uncheck Load balancer - VR User data - VR Source NAT - VR Static NAT - VR Port forwarding - VR networkACL - check supported source NAT type: per account 3. Vpc4 create NW tier vpc4G4with nw offering 6214 4. Vpc4G4 Deploy VM 5. Login host 10.223.51.4 - login to VR r-3-VM [ashen@localhost ~]$ ssh root@10.223.51.3 root@10.223.51.3's password: [root@Rack2Host19 ~]# ssh -i /root/.ssh/id_rsa.cloud 169.254.3.181 -p 3922 Linux r-3-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 6. r-3-VM: root@r-3-VM:~# ifconfig eth0 Link encap:Ethernet HWaddr 0e:00:a9:fe:03:b5 inet addr:169.254.3.181 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c00:a9ff:fefe:3b5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:416 errors:0 dropped:0 overruns:0 frame:0 TX packets:395 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:53884 (52.6 KiB) TX bytes:66554 (64.9 KiB) Interrupt:25 eth1 Link encap:Ethernet HWaddr 06:2b:70:00:00:13 inet addr:10.223.123.17 Bcast:10.223.123.63 Mask:255.255.255.192 inet6 addr: fe80::42b:70ff:fe00:13/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:31 errors:0 dropped:0 overruns:0 frame:0 TX packets:89 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2122 (2.0 KiB) TX bytes:7170 (7.0 KiB) Interrupt:24 eth2 Link encap:Ethernet HWaddr 02:00:7f:16:00:02 inet addr:10.4.1.1 Bcast:10.4.1.255 Mask:255.255.255.0 inet6 addr: fe80::7fff:fe16:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:23 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2314 (2.2 KiB) TX bytes:3238 (3.1 KiB) Interrupt:26 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1318 (1.2 KiB) TX bytes:1318 (1.2 KiB) 7. check iptables [root@Rack2Host19 ~]# iptables-save # Generated by iptables-save v1.4.14 on Tue Mar 11 22:13:02 2014 *mangle :PREROUTING ACCEPT [455:46866] :INPUT ACCEPT [455:46866] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [402:55390] :POSTROUTING ACCEPT [402:55390] :ACL_OUTBOUND_eth2 - [0:0] :VPN_STATS_eth1 - [0:0] -A PREROUTING -i eth1 -m state --state NEW -j CONNMARK --set-xmark 0x1/0x -A PREROUTING -i eth2 -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A PREROUTING -s 10.4.1.0/24 ! -d 10.4.1.1/32 -i eth2 -m state --state NEW -j ACL_OUTBOUND_eth2 -A FORWARD -j VPN_STATS_eth1 -A OUTPUT -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A ACL_OUTBOUND_eth2 -j ACCEPT -A ACL_OUTBOUND_eth2 -j DROP -A VPN_STATS_eth1 -o eth1 -m mark --mark 0x525 -A VPN_STATS_eth1 -i eth1 -m mark --mark 0x524 COMMIT # Completed on Tue Mar 11 22:13:02 2014 # Generated by iptables-save v1.4.14 on Tue Mar 11 22:13:02 2014 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [402:55390] :ACL_INBOUND_eth2 - [0:0] :NETWORK_STATS_eth1 - [0:0] -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 3922 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth2 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -d 10.4.1.1/32 -i eth2 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -d 10.4.1.1/32 -i eth2 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -d 10.4.1.1/32 -i eth2 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A INPUT
[jira] [Resolved] (CLOUDSTACK-6236) Negative ref_cnt of template(snapshot/volume)_store_ref results in out-of-range error in Mysql
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-6236.
--
Resolution: Fixed
Guard negative ref_cnt in decrRefCnt methods.
Negative ref_cnt of template(snapshot/volume)_store_ref results in
out-of-range error in Mysql
--
Key: CLOUDSTACK-6236
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6236
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.3.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.4.0
Steps:
1. Deploy CS with ESXi5.5 and NFS secondary storage.
2. Create a VM and take the snapshot of root volume.
3. Create a template from snapshot.
4. Migrate the secondary NFS to S3.
5. Download the template created from snapshot (step3). Now the template will
be in S3.
6. Tried to delete the template now.
Observation:
Template got deleted from S3 but observing an exception while deleting it
from ImageCache.
2014-03-04 16:19:58,227 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 2-9302: Sending Seq 2-9302: { Ans: ,
MgmtId: 6758231703598, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-03-04 16:19:58,255 ERROR [c.c.a.ApiAsyncJobDispatcher]
(Job-Executor-51:Job-47) Unexpected exception while executing
org.apache.cloudstack.api.command.user.template.DeleteTemplateCmd
com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
com.mysql.jdbc.JDBC4PreparedStatement@5cb563d: SELECT template_store_ref.id,
template_store_ref.store_id, template_store_ref.template_id,
template_store_ref.store_role, template_store_ref.created,
template_store_ref.last_updated, template_store_ref.download_pct,
template_store_ref.size, template_store_ref.physical_size,
template_store_ref.download_state, template_store_ref.local_path,
template_store_ref.error_str, template_store_ref.job_id,
template_store_ref.install_path, template_store_ref.url,
template_store_ref.is_copy, template_store_ref.destroyed,
template_store_ref.update_count, template_store_ref.updated,
template_store_ref.state, template_store_ref.ref_cnt FROM template_store_ref
WHERE template_store_ref.template_id = 202 AND template_store_ref.store_role
= 'ImageCache'
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:421)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:356)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:340)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:1243)
at
org.apache.cloudstack.storage.image.db.TemplateDataStoreDaoImpl.listOnCache(TemplateDataStoreDaoImpl.java:365)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
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 $Proxy108.listOnCache(Unknown Source)
at
org.apache.cloudstack.storage.image.TemplateDataFactoryImpl.listTemplateOnCache(TemplateDataFactoryImpl.java:147)
at
com.cloud.template.HypervisorTemplateAdapter.delete(HypervisorTemplateAdapter.java:355)
at
com.cloud.template.TemplateManagerImpl.deleteTemplate(TemplateManagerImpl.java:1097)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
[jira] [Comment Edited] (CLOUDSTACK-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13929819#comment-13929819 ] angeline shen edited comment on CLOUDSTACK-6214 at 3/12/14 11:27 PM: - Try to reproduce problem withinternal build 4.3-0.292-rhel6.3.tar.gz (few days old): MS: 10.223.130.59 host: 10.223.51.3 XS 6.2 nw offer isolated specify VLANVPC LB type: public LB chkvpn dhcp dns lb userdata sourceNAT staticNATPF nwACL account 1. Create VPC - Configure - NW ACL list -Add ACL list vpc2ACL1 - vpc2ACL1 ACL list rulesadd rule 1: 0.0.0.0/0 allow ALL Ingress add rule 2: 0.0.0.0/0 allow ALL Egress 2. Create NW offering 6214: Guest type:isolated specify VLAN: check VPC :check LB type: public LB Supported services: VPN -VR Dhcp - VR DNS - VR Firewall - Uncheck Load balancer -VR User data - VR Source NAT-VR Static NAT - VR Port forwarding - VR networkACL- check supported source NAT type:per account 3. Vpc2 create NW tiervpc2G2 with nw offering6214 4. Vpc2G2 Deploy VM 5. Login host10.223.51.3 -login to VR r-4-VM [ashen@localhost ~]$ ssh root@10.223.51.3 root@10.223.51.3's password: [root@Rack2Host18 ~]# ssh -i /root/.ssh/id_rsa.cloud 169.254.2.234 -p 3922 6. R-4-VM: root@r-4-VM:~# ifconfig eth0 Link encap:Ethernet HWaddr 0e:00:a9:fe:02:ea inet addr:169.254.2.234 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::c00:a9ff:fefe:2ea/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:695 errors:0 dropped:0 overruns:0 frame:0 TX packets:622 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:74492 (72.7 KiB) TX bytes:202424 (197.6 KiB) Interrupt:25 eth1 Link encap:Ethernet HWaddr 06:2c:ce:00:00:17 inet addr:10.223.123.33 Bcast:10.223.123.63 Mask:255.255.255.192 inet6 addr: fe80::42c:ceff:fe00:17/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:34 errors:0 dropped:0 overruns:0 frame:0 TX packets:104 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2180 (2.1 KiB) TX bytes:8376 (8.1 KiB) Interrupt:24 eth2 Link encap:Ethernet HWaddr 02:00:33:51:00:02 inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 inet6 addr: fe80::33ff:fe51:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1143 (1.1 KiB) TX bytes:1851 (1.8 KiB) Interrupt:26 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:10 errors:0 dropped:0 overruns:0 frame:0 TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1318 (1.2 KiB) TX bytes:1318 (1.2 KiB) 7. check iptables: What are we looking for? # Generated by iptables-save v1.4.14 on Mon Mar 10 23:50:17 2014 *mangle :PREROUTING ACCEPT [263:28463] :INPUT ACCEPT [263:28463] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [228:33139] :POSTROUTING ACCEPT [228:33139] :ACL_OUTBOUND_eth2 - [0:0] :VPN_STATS_eth1 - [0:0] -A PREROUTING -i eth1 -m state --state NEW -j CONNMARK --set-xmark 0x1/0x -A PREROUTING -i eth2 -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A PREROUTING -s 10.1.1.0/24 ! -d 10.1.1.1/32 -i eth2 -m state --state NEW -j ACL_OUTBOUND_eth2 -A FORWARD -j VPN_STATS_eth1 -A OUTPUT -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A ACL_OUTBOUND_eth2 -j ACCEPT -A VPN_STATS_eth1 -o eth1 -m mark --mark 0x525 -A VPN_STATS_eth1 -i eth1 -m mark --mark 0x524 COMMIT # Completed on Mon Mar 10 23:50:17 2014 # Generated by iptables-save v1.4.14 on Mon Mar 10 23:50:17 2014 *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [217:31431]
[jira] [Commented] (CLOUDSTACK-6217) CRUD APIs for guest os and guest os mappings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932680#comment-13932680 ] ASF subversion and git services commented on CLOUDSTACK-6217: - Commit 3ee1fc28deafc575dedd655bc6af37c274142275 in cloudstack's branch refs/heads/master from [~amogh.vasekar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3ee1fc2 ] CLOUDSTACK-6217: Add APIs for ability to add new guest OS types, and their hypervisor specific mappings. The table guest_os_hypervisor is currently maintained but not used, and the APIs reuse the same Signed off by: Nitin Mehta nitin.me...@citrix.com CRUD APIs for guest os and guest os mappings Key: CLOUDSTACK-6217 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6217 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.4.0 Add APIs to be able to add new guest OS types, and their hypervisor specific mappings -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5986) dnsmasq racy condition result in dnsmasq failed to handout IP address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932742#comment-13932742 ] ASF subversion and git services commented on CLOUDSTACK-5986: - Commit 6baa0538a852f59d17f9b2372ec6ae96381e4b3d in cloudstack's branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6baa053 ] CLOUDSTACK-5986: Fix dnsmasq lease judgement dnsmasq racy condition result in dnsmasq failed to handout IP address - Key: CLOUDSTACK-5986 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5986 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0, 4.2.1 Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.2.1, 4.3.0 In the past, dnsmasq.leases is managed by cloudstack, and would be updated after new entry is added(and the entry with same IP or host would be removed). In 4.2, we introduced dhcp_release try to speed up the dnsmasq reload process, thus result in this issue. So in this scenario: 1. VM1 would create entry: mac A, IP A, host A 2. VM2 would create entry: mac B, IP B, host B 3. VM1 destroyed and VM 2 destroyed, no change to lease file, two records still existed. 4. VM1 created with IP B: mac C, IP B, host A. At this time, lease file would only contain: mac C, IP B, host A, because the original entries would be removed by either IP match or host name match. In fact dnsmasq still holds lease of IP A with mac A in memory, but record is already removed from lease file by cloudstack. The lease file is out of sync now. 5. VM2 recreated with IP A, dhcp_release would be used to release the lease. But there is no mac A, IP A record in the lease file, so dhcp_release failed. So result in dnsmasq cannot handle out the IP A to new mac D, because dnsmasq was still holding lease for IP A with mac A and haven't been released yet. So it only happened when user create and destroy different VMs which share the same name but get different IPs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6114) Create config management recipes to install CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932863#comment-13932863 ] Ian Duffy commented on CLOUDSTACK-6114: --- I'm interested in looking into this. There are scripts already available in the source within /tools/devcloud/src. I have no idea what their current state is. From what I can tell they are outdated. They also required a modified version of vagrant to allow files to be transferred over SCP. This is not required, since vagrant 1.5 they have introduced rsync for exposing files to guest VMs. Preferred configuration management tool would be puppet. Preferred box building tool would be packer. Myself and Chris Snow made some progress on creating a 4.3 devcloud: https://github.com/imduffy15/devcloud At the moment it works, I have 50gb storage on root for base OS + secondary storage. I use SR type EXT for primary/localstorage on a separate partition. I modified the devcloud.cfg to use 192.168.56.10(the hypervisor) as the gateway for the guest VMs, this enables them to have internet access. Cloning the codebase and executing vagrant up will give you xcp-xapi 6.2 on debian. It is ready to be added as a host on 4.3. I haven't ran the management server on dom0, I didn't think it was realistic due to the RAM requirements required(2-4gb for xen, reserve 2gb on dom0 for management server). Chris has been running it fine with a few modifications. Suggested systems would be as follows: Simulator - All in one solution based of simstack using puppet. Most likely created for CentOS. Devcloud1: 1 VM running debian + xcp-xapi as done in my above github link with the host machine acting as the management server. Devcloud2: - VM1 debian + xcp-xapi (local storage enabled) - VM2 management server + mysql + secondary storage Devcloud3: All in one solution, xcp-xapi and management on one box. Testing with vagrant-fusion would be interesting to allow for vt-x to be used to expose HVM capabilities on devcloud, however this needs a license. Create config management recipes to install CloudStack -- Key: CLOUDSTACK-6114 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6114 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: sebastien goasguen Labels: gsoc2014 To ease deployment of CloudStack we need to develop a set of recipes for all the configuration management systems. A few already exists using Chef, Puppet and Ansible. This project will do an inventory of existing recipes available on-line, coalesce them into a coherent set and write missing recipes. The student will need to learn configuration management with at least one tool (chef, puppet, ansible, salt..etc) and will develop recipes using Vagrant. The outcome will be a fully functional devcloud (cloudstack sandbox) with mutiple recipes. CloudStack will be deployable in a sanbox or in a multi-machine environment. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6045) [GSoC] Create GUI to add primary storage based on plug-ins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Duffy updated CLOUDSTACK-6045: -- Labels: gsoc gsoc2014 (was: gsoc) [GSoC] Create GUI to add primary storage based on plug-ins -- Key: CLOUDSTACK-6045 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6045 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: All browsers that CloudStack supports Reporter: Mike Tutkowski Labels: gsoc, gsoc2014 Fix For: 4.4.0 At the time being, if an admin wants to add primary storage to CloudStack that is NOT based on the default storage plug-in, the admin must invoke the addStoragePool API outside of the CloudStack GUI. It would be beneficial to CloudStack admins if they could add this kind of primary storage to CloudStack via its standard GUI. This project will require a degree of usability work in that the designer must analyze CloudStack's GUI sufficiently to come up with a plan for where the necessary information can be input. Once a GUI prototype has been developed (one could use a tool like PowerPoint for this purpose), then the developer must analyze the necessary HTML and JavaScript logic to add the proposed support. This project could take the form of an optional GUI plug-in. It is possible this project may add one or more parameters to the addStoragePool API. If so, then this will require Java changes on the backend. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4322) Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932868#comment-13932868 ] Namita Chaudhari commented on CLOUDSTACK-4322: -- When a domain is deleted with force option, failed is returned as response incase if there are accounts under that domain that needs cleanup. I have attached the logs(DomainDeleteFailed_logs.txt) and screenshot (del_domain_fail.jpg) for the same. Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup. --- Key: CLOUDSTACK-4322 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4322 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Fix For: Future deleteDomain with cleanup = true, CS is not allowing deletion of domain if there is any account under that domain needs clean up; though these accounts are removed and admin can't see them in the listaccounts call. From the end user perspective, CS should return success in case of force delete domain and handle the cleanup of sub-domains/accounts internally. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4322) Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932869#comment-13932869 ] Namita Chaudhari commented on CLOUDSTACK-4322: -- I tried to delete a domain with force option: 1) The domain gets deleted successfully when the accounts under that domain does not need cleanup. 2) The domain does not get deleted, when the accounts under that domain needs cleanup. It throws an exception saying Failed to clean up domain resources and sub domains, delete failed on domain. I traversed through the code and the flow of the code is such that when a request is sent to delete a domain it first changes the state of domain to Inactive, cleanup the accounts under those domain and then delete the domain. But if the resources of those accounts are referenced elsewhere, then the accounts and domain are not deleted and the domain is reverted back to Active state. Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup. --- Key: CLOUDSTACK-4322 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4322 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Fix For: Future deleteDomain with cleanup = true, CS is not allowing deletion of domain if there is any account under that domain needs clean up; though these accounts are removed and admin can't see them in the listaccounts call. From the end user perspective, CS should return success in case of force delete domain and handle the cleanup of sub-domains/accounts internally. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4322) Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namita Chaudhari updated CLOUDSTACK-4322: - Attachment: DomainDeleteFailed_logs.txt del_domain_fail.JPG Delete domain with force option is not returning failed as response incase of accounts under that domain needs cleanup. --- Key: CLOUDSTACK-4322 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4322 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Fix For: Future Attachments: DomainDeleteFailed_logs.txt, del_domain_fail.JPG deleteDomain with cleanup = true, CS is not allowing deletion of domain if there is any account under that domain needs clean up; though these accounts are removed and admin can't see them in the listaccounts call. From the end user perspective, CS should return success in case of force delete domain and handle the cleanup of sub-domains/accounts internally. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6211) Xenserver - HA - SSVM fails to start due to running out of management Ip ranges when testing host down scenarios.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932892#comment-13932892 ] ASF subversion and git services commented on CLOUDSTACK-6211: - Commit 15bf144f1a89ee024f087427a3c72cf233e49356 in cloudstack's branch refs/heads/4.3-forward from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=15bf144 ] CLOUDSTACK-6211: Xenserver - HA - SSVM fails to start due to running out of management Ip ranges when testing host down scenarios Signed-off-by: Koushik Das kous...@apache.org Xenserver - HA - SSVM fails to start due to running out of management Ip ranges when testing host down scenarios. - Key: CLOUDSTACK-6211 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6211 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.3.0 Xenserver - HA - SSVM fails to start due to running out of management Ip ranges when testing host down scenarios. Set up: Advanced zone set up with 2 hosts in 1 cluster and 1 more host in another cluster. I have been performing test cases that involves host going down and up , so that HA of user Vms and System Vms happen. Currently SSVM is not able to start because of not having any free management Ip. DB shows that there are many ip addresses from the pod range that has been assigned to the SSVM( older SSVMs that are currently in Destroyed state). Database changed mysql select * from nics where id in ( 7,22,23,3,4); -- - iduuidinstance_id mac_address ip4_address netmask gateway ip_type broadcast_uri network_id modestate strategyreserver_name reservation_id device_id update_time isolation_uri ip6_address default_nic vm_type c reated removed ip6_gateway ip6_cidrsecondary_ip display_nic -- - 3 c3ac0565-e881-4900-8b52-f323935f1a1b18 NULLNULLNULL NULLNULLNULL201 Static DeallocatingStart PodBasedNetworkGuru c8e4d764-f6ca-40b5 -8d25-c46170f5f7bd 1 2014-02-19 19:37:24 NULLNULL0 SecondaryStorageVm 2 014-02-19 00:29:352014-02-20 00:37:24 NULLNULL0 1 4 7cb4375a-241d-4ed5-9024-761607f3862e18 NULLNULLNULL NULLNULLNULL203 Static DeallocatingStart StorageNetworkGuru c8e4d764-f6ca-40b5 -8d25-c46170f5f7bd 3 2014-02-19 19:37:24 NULLNULL0 SecondaryStorageVm 2 014-02-19 00:29:352014-02-20 00:37:24 NULLNULL0 1 7 93ed755c-8f47-4e52-8116-08af431535e819 06:84:0c:00:00:07 10.223.59.76255.255.255.192 10.223.5 9.65 Ip4 NULL201 Static ReservedStart PodBasedNetworkGuru dc82d127-074a-470b -bee8-9bb9393e7cda 1 2014-02-24 18:02:55 NULLNULL0 ConsoleProxy2 014-02-19 00:31:35NULLNULLNULL0 1 2267684964-1a8d-4b8f-b645-5e19eeaf86a928 NULLNULLNULL NULLNULLNULL201 Static DeallocatingStart PodBasedNetworkGuru dd6f0afb-97c5-44c1 -829f-3d209c95e53c 1 2014-02-24 18:03:20 NULLNULL0 SecondaryStorageVm 2 014-02-20 00:37:252014-02-24 23:03:20 NULLNULL0 1 2317ad1565-4aeb-4de7-8e94-c82aedc6d25528 NULLNULLNULL NULLNULLNULL203 Static DeallocatingStart StorageNetworkGuru ff80bf7b-918b-4bba -9068-8d78c9ed3915 3 2014-02-24 18:03:20 NULLNULL0 SecondaryStorageVm 2 014-02-20
