date:20140310


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925629#comment-13925629
 ] 

Nux commented on CLOUDSTACK-6181:
-

Marcus,

Thanks for the tip, it worked great and the root was resized to my specified 
value. This is with NFS, but will try also local, CLVM and gluster.

One thing though, my test template size is 1.9G and the api happily accepted 
details[0].rootdisksize=1; given that 1  1.9 shouldn't it have errored out 
or something?
The VM ended up with the template size, 1.9.

 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] [Resolved] (CLOUDSTACK-6183) Unplug the nic when all the ips of public subnet is released

2014-03-10 Thread Jayapal Reddy (JIRA)


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

Jayapal Reddy resolved CLOUDSTACK-6183.
---

Resolution: Fixed

 Unplug the nic when all the ips of public subnet is released
 

 Key: CLOUDSTACK-6183
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6183
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.3.0, 4.4.0


 1. Add one public subnet
 2. Aquire ips from the two subnets and configure the rules so that the nics 
 get plugged in VR.
 3. Release all the ips from the subnet
 Expected:
 4. After all ips release the nic on the VR specific to this subnet get 
 removed.
 Bug: The nic is not unplugged and it can't be reused for other subnets if we 
 add.
  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6187) Migrate router from UI is showing error

2014-03-10 Thread Jayapal Reddy (JIRA)


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

Jayapal Reddy resolved CLOUDSTACK-6187.
---

Resolution: Fixed

 Migrate router from UI is showing error
 ---

 Key: CLOUDSTACK-6187
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6187
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.3.0, 4.4.0


 1. Migrate router from the UI is showing error.
 Migration of router happened successfully but the listRouters api is showing 
 error.
 2. This issue is because MigrateSystemVMCmd api  response systemvm property 
 is empty.
 2014-02-03 10:36:05,363 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-32:ctx-6d049390) Done executing com.cloud.vm.VmWorkMigrate for 
 job-53
 2014-02-03 10:36:05,400 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] 
 (Job-Executor-32:ctx-6d049390) Sync queue (3) is currently empty
 2014-02-03 10:36:05,401 INFO [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-32:ctx-6d049390) Remove job-53 from job monitoring
 2014-02-03 10:36:07,950 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-4c128982) ===START=== 10.252.192.25 – GET 
 command=queryAsyncJobResultjobId=f939d9f6-7ba0-47fe-ov8%3D_=1391422430324
 2014-02-03 10:36:07,987 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-4:ctx-4c128982 ctx-a4265f7b) ===END=== 10.252.192.25 – GET 
 command=queryAsyncJobResultjobId=f939d9f6vFwGfRH%2Brov8%3D_=1391422430324
 2014-02-03 10:36:08,157 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-19:ctx-7627cfac) ===START=== 10.252.192.25 – GET 
 command=listRoutersid=undefinedresponse=jsonsessi
 2014-02-03 10:36:08,172 DEBUG [c.c.a.ApiDispatcher] 
 (catalina-exec-19:ctx-7627cfac ctx-28964964) Object entity uuid = undefined 
 does not exist in the database.
 2014-02-03 10:36:08,172 INFO [c.c.a.ApiServer] (catalina-exec-19:ctx-7627cfac 
 ctx-28964964) Unable to execute API command listrouters due to invalid value. 
 Invalid party does not exist or due to incorrect parameter annotation for the 
 field in api cmd class.
 2014-02-03 10:36:08,174 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-19:ctx-7627cfac ctx-28964964) ===END=== 10.252.192.25 – GET 
 command=listRoutersid=undefinedresponse



--
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=13925734#comment-13925734
 ] 

Nux commented on CLOUDSTACK-6181:
-

Ok,

So my tests have been almost ok, details[0].rootdisksize works great for all 
storage I tried, NFS, local, Gluster and CLVM. What did not work is resizing 
the root volume of a stopped VM. For example:

 resize volume id=ebc4c8ee-9524-4841-88fd-a559fddd194b size=20
.Async job 9abdfe20-8b5b-44a7-bab3-843df01d4929 failed
Error 530, Volume should be in ready or allocated state before attempting a 
resize
accountid = 90a4e9a8-a783-11e3-816a-9660573836d5
cmd = org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd
created = 2014-03-10T13:11:25+
jobid = 9abdfe20-8b5b-44a7-bab3-843df01d4929
jobprocstatus = 0
jobresult:
errorcode = 530
errortext = Volume should be in ready or allocated state before attempting a 
resize
jobresultcode = 530
jobresulttype = object
jobstatus = 2
userid = 90a4f0b0-a783-11e3-816a-9660573836d5

The volume IS in Ready state! http://fpaste.org/83939/45885313/raw/

The management log doesn't offer much more info 
http://fpaste.org/83938/13944587/raw/

 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-6181) Root resize


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925824#comment-13925824
 ] 

Marcus Sorensen commented on CLOUDSTACK-6181:
-

I'll take a look. Since the code is existing, I suspect that may be an issue 
with resizing DATA disks on a stopped vm, as well.

 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-6181) Root resize


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925839#comment-13925839
 ] 

Marcus Sorensen commented on CLOUDSTACK-6181:
-

I've added some debugging for both. I'll try to replicate them if I can find 
time, but the debugging is checked in if you have time to test. I currently 
don't see a way you'd get that error if your volume is in ready state or 
allocated state, so the error prints the actual state now.

The code that checks requested rootdisksize vs template size also prints what 
sizes its comparing now.

 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] [Resolved] (CLOUDSTACK-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied

2014-03-10 Thread Animesh Chaturvedi (JIRA)


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

Animesh Chaturvedi resolved CLOUDSTACK-6214.


Resolution: Fixed

 VPC: when guest network is in Setup state, on its initial nicPlug to the VR, 
 corresponding network rules are not getting applied
 

 Key: CLOUDSTACK-6214
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6214
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.3.0


 Steps to reproduce:
 ==
 1) Create VPC
 2) Add networkACLList and a rule to it
 3) In VPC, create a network from NetworkOffering with specifyVlan=true. 
 Network is created in Setup state.
 4) Start user vm in the network. 
 Bug: network ACLs are not applied although the guest nic is plugged to the VR.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6181) Root resize

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925917#comment-13925917
 ] 

Marcus Sorensen commented on CLOUDSTACK-6181:
-

I can't replicate the volume must be in ready or allocated state resize 
issue, a stopped vm resizes for me just fine.

I also am not currently able to replicate passing a rootdisksize smaller than 
templatesize and having it work. Here's a 2G template and I'm passing 
rootdisksize=1

 deploy virtualmachine zoneid=8d209071-ed46-46a9-82a6-a5874ee5be6d 
 templateid=31f52a4d-5681-43f7-8651-ad4aaf823618 
 serviceofferingid=62179906-ad2c-4c76-b160-063e294ee960 
 networkids=6ebe3113-f95d-418b-9742-26a42fe5ccc3 name=customroo 
 details[0].rootdisksize=1 hypervisor=KVM
unsupported: rootdisksize override is smaller than template size 2147483648

So hopefully the debugging I put in will help us determine why these pop up in 
your environment.

 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-6170) Support managed storage for root disks


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925938#comment-13925938
 ] 

ASF subversion and git services commented on CLOUDSTACK-6170:
-

Commit 1d74daf6fe7c87931b6308d4e2e0e39f109a85ac in cloudstack's branch 
refs/heads/master from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d74daf ]

CLOUDSTACK-6170


 Support managed storage for root disks
 --

 Key: CLOUDSTACK-6170
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: I expect to support managed storage for root disks on 
 XenServer and ESX (KVM is targeted for 4.5).
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.4.0


 Cloud environments have a need for guaranteed storage performance. By this I 
 mean having the ability to specify a minimum and maximum number of IOPS on a 
 volume-by-volume basis.
 I added support for this for XenServer and ESX in 4.2 for data disks.
 I added support for this for KVM in 4.3 for data disks.
 It is my intent to add support for this for XenServer and ESX in 4.4 for root 
 disks (with subsequent support for root disks on KVM expected in 4.5).
 The main changes are expected to occur in CloudStack logic that controls 
 hypervisors and additions to the way root-volume orchestration happens.
 This will also require minor changes in the SolidFire (storage) plug-in.



--
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=13925945#comment-13925945
 ] 

Nux commented on CLOUDSTACK-6181:
-

Marcus,

Thanks. What should I use for this testing? Latest master?

 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-6181) Root resize


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925952#comment-13925952
 ] 

Marcus Sorensen commented on CLOUDSTACK-6181:
-

resize-root branch still.



 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-6151) Local data disk with tag goes to the wrong local storage pool

2014-03-10 Thread edison su (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925957#comment-13925957
 ] 

edison su commented on CLOUDSTACK-6151:
---

Wondering, in which case, there are multiple local storage in one hypervisor 
host? Usually, there should be only one local storage per host.

 Local data disk with tag goes to the wrong local storage pool
 -

 Key: CLOUDSTACK-6151
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6151
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.4.0


 In case of attaching Volume we are not honoring the tags of the volume and 
 the storage pool.
 Often the disk goes to the wrong local storage pool in case of multiple local 
 storages on a single host.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6181) Root resize

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925990#comment-13925990
 ] 

Nux commented on CLOUDSTACK-6181:
-

Ah, okay. Will build new RPMs and test.

 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-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=13926030#comment-13926030
 ] 

ASF subversion and git services commented on CLOUDSTACK-6214:
-

Commit bf9375b8b9c437bf314d0459233f17860d85d3f3 in cloudstack's branch 
refs/heads/master from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf9375b ]

CLOUDSTACK-6214: apply network rules when plug new guest nic to router for the 
network in Setup state
Conflicts:

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManager.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java

Conflicts:
api/src/com/cloud/network/VpcVirtualNetworkApplianceService.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManager.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
server/test/com/cloud/vpc/MockVpcVirtualNetworkApplianceManager.java


 VPC: when guest network is in Setup state, on its initial nicPlug to the VR, 
 corresponding network rules are not getting applied
 

 Key: CLOUDSTACK-6214
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6214
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.3.0


 Steps to reproduce:
 ==
 1) Create VPC
 2) Add networkACLList and a rule to it
 3) In VPC, create a network from NetworkOffering with specifyVlan=true. 
 Network is created in Setup state.
 4) Start user vm in the network. 
 Bug: network ACLs are not applied although the guest nic is plugged to the VR.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6217) CRUD APIs for guest os and guest os mappings

2014-03-10 Thread Amogh Vasekar (JIRA)

Amogh Vasekar created CLOUDSTACK-6217:
-

 Summary: 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] [Created] (CLOUDSTACK-6218) VR commands need to be serialized in VR resource

2014-03-10 Thread Sheng Yang (JIRA)

Sheng Yang created CLOUDSTACK-6218:
--

 Summary: VR commands need to be serialized in VR resource
 Key: CLOUDSTACK-6218
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6218
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.4.0
Reporter: Sheng Yang
Assignee: Sheng Yang
 Fix For: 4.4.0


In very large scale parallel deployment, multiple commands executed at VR would 
result in VR itself's lock time out, since the later commands would need to 
wait longer and longer for execution.

This fix would put a lock in VR resource part, and make sure every commands to 
VR would be queued before executed in VR, prevent timeout in the VR. However, 
the timeout would still possible with agent manager level, if VR resource has 
too many commands to deal with and cannot give back answer in time. But this 
timeout can be adjusted from mgmt server side, so the problem is mitigated. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6194) Failed to increase Shared network IP Range

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926186#comment-13926186
 ] 

ASF subversion and git services commented on CLOUDSTACK-6194:
-

Commit 859a78e1d321a936efd18dc6f0a55ab336cd3b70 in cloudstack's branch 
refs/heads/4.3 from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=859a78e ]

CLOUDSTACK-6194: Failed to increase Shared network IP Range

Submitted-by:Saksham Srivastava saksham.srivast...@citrix.com
(cherry picked from commit 135247afd114c1dfc6dde22184430237e79aafc5)

Signed-off-by: Animesh Chaturvedi anim...@apache.org


 Failed to increase Shared network IP Range
 --

 Key: CLOUDSTACK-6194
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6194
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Management Server
Affects Versions: 4.3.0
 Environment: Xenserver, CloudStack 4.3-forward
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
 Fix For: 4.3.0


 Steps from UI:
 1. Newly installed setup with Adv zone configuration
 2. Created shared network
 3. Tried to Add IP range to the same shared network.
 Observation:
 It failed saying there is already one vlan 110 on network :212, only one 
 vlan is allowed on guest network .



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6204) HTTP support for CPVM, as part of realhostip changes

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926187#comment-13926187
 ] 

ASF subversion and git services commented on CLOUDSTACK-6204:
-

Commit ec4db7bbff60f0be96e39f51c0f17b12e0de440c in cloudstack's branch 
refs/heads/4.3 from [~jlkinsel]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec4db7b ]

CLOUDSTACK-6204: Removing realhostip.com dependency

For more info, see 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes

Author: Amogh Vasekar amogh.vase...@citrix.com
Signed-off-by: John Kinsella j...@stratosec.co 1394399081 -0700
(cherry picked from commit 2fe7aeea23ddef25224e3e248f0a91513a14811f)

Signed-off-by: Animesh Chaturvedi anim...@apache.org


 HTTP support for CPVM, as part of realhostip changes
 

 Key: CLOUDSTACK-6204
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6204
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Reporter: Amogh Vasekar
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: Future


 Details can be found here 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926185#comment-13926185
 ] 

ASF subversion and git services commented on CLOUDSTACK-6214:
-

Commit 3b92031de99bf59b14d03e3fcf13defcfddb75b8 in cloudstack's branch 
refs/heads/4.3 from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b92031 ]

CLOUDSTACK-6214: apply network rules when plug new guest nic to router for the 
network in Setup state
Conflicts:

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManager.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
(cherry picked from commit 164ea3e84f6f282006e66725f22cd2246f0be8f8)

Signed-off-by: Animesh Chaturvedi anim...@apache.org


 VPC: when guest network is in Setup state, on its initial nicPlug to the VR, 
 corresponding network rules are not getting applied
 

 Key: CLOUDSTACK-6214
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6214
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.3.0


 Steps to reproduce:
 ==
 1) Create VPC
 2) Add networkACLList and a rule to it
 3) In VPC, create a network from NetworkOffering with specifyVlan=true. 
 Network is created in Setup state.
 4) Start user vm in the network. 
 Bug: network ACLs are not applied although the guest nic is plugged to the VR.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6219) 3.0.7 Patch E to Felton: fk_external_dhcp_devices_pod_id` foreign key constraint is remanant on `baremetal_dhcp_devices` table on the Upgraded Setup. It is not prese

2014-03-10 Thread frank zhang (JIRA)

frank zhang created CLOUDSTACK-6219:
---

 Summary: 3.0.7 Patch E to Felton: fk_external_dhcp_devices_pod_id` 
foreign key constraint is remanant on `baremetal_dhcp_devices` table on the 
Upgraded Setup. It is not present on the Fresh Setup
 Key: CLOUDSTACK-6219
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6219
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Baremetal
Affects Versions: 4.3.0
Reporter: frank zhang
Assignee: frank zhang
 Fix For: 4.3.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-6219) 3.0.7 Patch E to Felton: fk_external_dhcp_devices_pod_id` foreign key constraint is remanant on `baremetal_dhcp_devices` table on the Upgraded Setup. It is not presen

2014-03-10 Thread frank zhang (JIRA)


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

frank zhang closed CLOUDSTACK-6219.
---

Resolution: Fixed

wrong bug report

 3.0.7 Patch E to Felton: fk_external_dhcp_devices_pod_id` foreign key 
 constraint is remanant on `baremetal_dhcp_devices` table on the Upgraded 
 Setup. It is not present on the Fresh Setup
 --

 Key: CLOUDSTACK-6219
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6219
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Baremetal
Affects Versions: 4.3.0
Reporter: frank zhang
Assignee: frank zhang
 Fix For: 4.3.0






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script

Nux created CLOUDSTACK-6220:
---

 Summary: Cloudstack agent fails to start due to broken init script
 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux


Hello,

On 4.4 `service cloudstack-agent start` fails with:
# service cloudstack-agent start
Starting Cloud Agent: 
touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
file or directory

/etc/init.d/cloudstack-agent used to have this which worked fine:
whatami=cloudstack-agent
SHORTNAME=$whatami

Now it has been replaced with this which fails:
SHORTNAME=$0

A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926238#comment-13926238
 ] 

Marcus Sorensen commented on CLOUDSTACK-6220:
-

commit 9dd57c22b02afcddb1d6c8ddc3e1b578961454e3
Author: John Kinsella j...@stratosec.co
Date:   Mon Feb 17 10:00:36 2014 -0800

CLOUDSTACK-6129: removing hard-coded script names

Replacing whatami with $0 which is how UNIX shell scripts should get the
script's name.

BUG-ID: CLOUDSTACK-6129
Bugfix-for:
Reviewed-by:
Reported-by:
Signed-off-by: John Kinsella j...@stratosec.co 1392660036 -0800


 Cloudstack agent fails to start due to broken init script
 -

 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux
  Labels: agent

 Hello,
 On 4.4 `service cloudstack-agent start` fails with:
 # service cloudstack-agent start
 Starting Cloud Agent: 
 touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
 file or directory
 /etc/init.d/cloudstack-agent used to have this which worked fine:
 whatami=cloudstack-agent
 SHORTNAME=$whatami
 Now it has been replaced with this which fails:
 SHORTNAME=$0
 A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926240#comment-13926240
 ] 

Marcus Sorensen commented on CLOUDSTACK-6129:
-

changing to 'basename $0' per CLOUDSTACK-6181...

 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926240#comment-13926240
 ] 

Marcus Sorensen edited comment on CLOUDSTACK-6129 at 3/10/14 9:25 PM:
--

changing to 'basename $0' per CLOUDSTACK-6220...


was (Author: mlsorensen):
changing to 'basename $0' per CLOUDSTACK-6181...

 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6129) Script names are hard-coded into some init scripts

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926251#comment-13926251
 ] 

Nux commented on CLOUDSTACK-6129:
-

Marcus,

Should be `basename $0` (note back-tick vs single quote). Thanks!

 Script names are hard-coded into some init scripts
 --

 Key: CLOUDSTACK-6129
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6129
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Reporter: John Kinsella
Assignee: John Kinsella
 Fix For: 4.4.0


 Some of the init scripts which ACS installs have the script name hard-coded 
 into it. An example from 
 python/distro/sles/SYSCONFDIR/init.d/cloud-ipallocator.in:
 whatami=cloud-external-ipallocator
 ...
 echo $Usage: $whatami {start|stop|restart|status|help}
 This is bad practice, $0 should be used to get a script's name, otherwise - 
 as shown in this example - things will fail or folks will be confused.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926258#comment-13926258
 ] 

ASF subversion and git services commented on CLOUDSTACK-6220:
-

Commit d033ca486bf9bc22a2afe314d00150ec6019c809 in cloudstack's branch 
refs/heads/master from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d033ca4 ]

CLOUDSTACK-6220: Fix cloudstack init scripts so that they
don't use fully qualified path as script name. Fix for
commit 9dd57c22b02afcddb1d6c8ddc3e1b578961454e3


 Cloudstack agent fails to start due to broken init script
 -

 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux
  Labels: agent

 Hello,
 On 4.4 `service cloudstack-agent start` fails with:
 # service cloudstack-agent start
 Starting Cloud Agent: 
 touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
 file or directory
 /etc/init.d/cloudstack-agent used to have this which worked fine:
 whatami=cloudstack-agent
 SHORTNAME=$whatami
 Now it has been replaced with this which fails:
 SHORTNAME=$0
 A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926261#comment-13926261
 ] 

ASF subversion and git services commented on CLOUDSTACK-6170:
-

Commit 1d74daf6fe7c87931b6308d4e2e0e39f109a85ac in cloudstack's branch 
refs/heads/resize-root from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d74daf ]

CLOUDSTACK-6170


 Support managed storage for root disks
 --

 Key: CLOUDSTACK-6170
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: I expect to support managed storage for root disks on 
 XenServer and ESX (KVM is targeted for 4.5).
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.4.0


 Cloud environments have a need for guaranteed storage performance. By this I 
 mean having the ability to specify a minimum and maximum number of IOPS on a 
 volume-by-volume basis.
 I added support for this for XenServer and ESX in 4.2 for data disks.
 I added support for this for KVM in 4.3 for data disks.
 It is my intent to add support for this for XenServer and ESX in 4.4 for root 
 disks (with subsequent support for root disks on KVM expected in 4.5).
 The main changes are expected to occur in CloudStack logic that controls 
 hypervisors and additions to the way root-volume orchestration happens.
 This will also require minor changes in the SolidFire (storage) plug-in.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926264#comment-13926264
 ] 

ASF subversion and git services commented on CLOUDSTACK-6220:
-

Commit d033ca486bf9bc22a2afe314d00150ec6019c809 in cloudstack's branch 
refs/heads/resize-root from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d033ca4 ]

CLOUDSTACK-6220: Fix cloudstack init scripts so that they
don't use fully qualified path as script name. Fix for
commit 9dd57c22b02afcddb1d6c8ddc3e1b578961454e3


 Cloudstack agent fails to start due to broken init script
 -

 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux
  Labels: agent

 Hello,
 On 4.4 `service cloudstack-agent start` fails with:
 # service cloudstack-agent start
 Starting Cloud Agent: 
 touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
 file or directory
 /etc/init.d/cloudstack-agent used to have this which worked fine:
 whatami=cloudstack-agent
 SHORTNAME=$whatami
 Now it has been replaced with this which fails:
 SHORTNAME=$0
 A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926263#comment-13926263
 ] 

ASF subversion and git services commented on CLOUDSTACK-6214:
-

Commit bf9375b8b9c437bf314d0459233f17860d85d3f3 in cloudstack's branch 
refs/heads/resize-root from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf9375b ]

CLOUDSTACK-6214: apply network rules when plug new guest nic to router for the 
network in Setup state
Conflicts:

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManager.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java

Conflicts:
api/src/com/cloud/network/VpcVirtualNetworkApplianceService.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManager.java

server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
server/test/com/cloud/vpc/MockVpcVirtualNetworkApplianceManager.java


 VPC: when guest network is in Setup state, on its initial nicPlug to the VR, 
 corresponding network rules are not getting applied
 

 Key: CLOUDSTACK-6214
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6214
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.3.0


 Steps to reproduce:
 ==
 1) Create VPC
 2) Add networkACLList and a rule to it
 3) In VPC, create a network from NetworkOffering with specifyVlan=true. 
 Network is created in Setup state.
 4) Start user vm in the network. 
 Bug: network ACLs are not applied although the guest nic is plugged to the VR.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-5583) vmopsSnapshot plug-in (XenServer) does not return an error when it should

2014-03-10 Thread Mike Tutkowski (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926294#comment-13926294
 ] 

Mike Tutkowski commented on CLOUDSTACK-5583:


Hi,

Here is how I reproduced it:

I created an iSCSI volume on my SAN that is only 2 GB.

I created a XenServer SR based on this SAN volume.

I created Primary Storage in CloudStack based on this XenServer SR.

I created a Disk Offering that was storage tagged to use this Primary Storage. 
It will lead to the creation of a 1 GB volume when executed and attached to a 
VM for the first time.

I executed the Disk Offering to create a CloudStack volume and attached this 
volume to a VM.

I took two hypervisor snapshots of the VM, then reverted to the first 
hypervisor snapshot.

I looked at the SR that should contain my CloudStack volume and its hypervisor 
snapshots. I saw two snapshots, but no active VDI. I should see two hypervisor 
snapshots and an active VDI.

Thanks!

 vmopsSnapshot plug-in (XenServer) does not return an error when it should
 -

 Key: CLOUDSTACK-5583
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5583
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Xen
Affects Versions: 4.3.0
 Environment: XenServer 6.1
Reporter: Mike Tutkowski
 Fix For: 4.3.0


 I tried to revert a VM snapshot and one of my storage repositories had an 
 insufficient amount of space. The plug-in did not return an error message (it 
 returned 0).
 From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot method:
 [root@XenServer-6 ~]# xe snapshot-revert 
 snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8
 Error code: SR_BACKEND_FAILURE_44
 Error parameters: , There is insufficient space, 
 An error should be returned from the plug-in instead of 0.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926316#comment-13926316
 ] 

ASF subversion and git services commented on CLOUDSTACK-6220:
-

Commit a4d3ec476fce815ef32e8273c7311850b5617f06 in cloudstack's branch 
refs/heads/master from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4d3ec4 ]

CLOUDSTACK-6220: Take 2, Fix cloudstack init scripts so that they
don't use fully qualified path as script name. Fix for
commit 9dd57c22b02afcddb1d6c8ddc3e1b578961454e3


 Cloudstack agent fails to start due to broken init script
 -

 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux
  Labels: agent

 Hello,
 On 4.4 `service cloudstack-agent start` fails with:
 # service cloudstack-agent start
 Starting Cloud Agent: 
 touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
 file or directory
 /etc/init.d/cloudstack-agent used to have this which worked fine:
 whatami=cloudstack-agent
 SHORTNAME=$whatami
 Now it has been replaced with this which fails:
 SHORTNAME=$0
 A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script

2014-03-10 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926315#comment-13926315
 ] 

ASF subversion and git services commented on CLOUDSTACK-6220:
-

Commit f0a7a7f23e0ac334fab3a3e58de10f0bd07da819 in cloudstack's branch 
refs/heads/resize-root from [~mlsorensen]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f0a7a7f ]

CLOUDSTACK-6220: Take 2, Fix cloudstack init scripts so that they
don't use fully qualified path as script name. Fix for
commit 9dd57c22b02afcddb1d6c8ddc3e1b578961454e3


 Cloudstack agent fails to start due to broken init script
 -

 Key: CLOUDSTACK-6220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.4.0
 Environment: CentOS 6.5 KVM/libvirt
Reporter: Nux
  Labels: agent

 Hello,
 On 4.4 `service cloudstack-agent start` fails with:
 # service cloudstack-agent start
 Starting Cloud Agent: 
 touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such 
 file or directory
 /etc/init.d/cloudstack-agent used to have this which worked fine:
 whatami=cloudstack-agent
 SHORTNAME=$whatami
 Now it has been replaced with this which fails:
 SHORTNAME=$0
 A possible solution is to replace $0 with `basename $0`



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6221) Publish vm uuid on the event bus when an operations is done on the vm

2014-03-10 Thread ASF subversion and git services (JIRA)

Nitin Mehta created CLOUDSTACK-6221:
---

 Summary: Publish vm uuid on the event bus when an operations is 
done on the vm
 Key: CLOUDSTACK-6221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Mehta


Publish vm uuid on the event bus when an operations is done on the vm



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6221) Publish vm uuid on the event bus when an operations is done on the vm


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13926429#comment-13926429
 ] 

ASF subversion and git services commented on CLOUDSTACK-6221:
-

Commit 33a0dec965c96483c8cd55e309250662fca5e2da in cloudstack's branch 
refs/heads/master from [~nitinme]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=33a0dec ]

CLOUDSTACK-6221:
Publish first class objects involved in an operation (for now vm uuid) on the 
event bus . Example -  during attach/detachIso along with iso id, vm id should 
be available as well.


 Publish vm uuid on the event bus when an operations is done on the vm
 -

 Key: CLOUDSTACK-6221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta

 Publish vm uuid on the event bus when an operations is done on the vm



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6221) Publish vm uuid on the event bus when an operations is done on the vm


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

Nitin Mehta updated CLOUDSTACK-6221:


Fix Version/s: 4.4.0

 Publish vm uuid on the event bus when an operations is done on the vm
 -

 Key: CLOUDSTACK-6221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Nitin Mehta
 Fix For: 4.4.0


 Publish vm uuid on the event bus when an operations is done on the vm



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6221) Publish vm uuid on the event bus when an operations is done on the vm


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

Nitin Mehta updated CLOUDSTACK-6221:


Affects Version/s: 4.4.0

 Publish vm uuid on the event bus when an operations is done on the vm
 -

 Key: CLOUDSTACK-6221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Nitin Mehta
 Fix For: 4.4.0


 Publish vm uuid on the event bus when an operations is done on the vm



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6221) Publish vm uuid on the event bus when an operations is done on the vm


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

Nitin Mehta resolved CLOUDSTACK-6221.
-

Resolution: Fixed

 Publish vm uuid on the event bus when an operations is done on the vm
 -

 Key: CLOUDSTACK-6221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6221
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.4.0
Reporter: Nitin Mehta

 Publish vm uuid on the event bus when an operations is done on the vm



--
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=13929775#comment-13929775
]

Marcus Sorensen commented on CLOUDSTACK-6181:
-

I've added some integration tests, so I think we're fairly close to requesting
merge. Let me know your findings.

1. Nux testing ...IN PROGRESS
2. tests ...DONE (could add a few more tests but the basic ones are there)
3. tests ...DONE
4. Wido buyoff ...DONE
5. Mike buyoff ...DONE
6. Other hypervisor support ... queried but seemingly no response. This isn't
necessary to move forward because the parameter is rejected if hypervisor !=
KVM. They can support it in the future if they like. ...DONE
7. Still discussing parameter format ... IN PROGRESS
8. Finally, get UI support added in (not necessary, but would be nice). Have
not heard on this. Generally UI support comes after features, though, so it's
not a big deal.

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-6181) Root resize


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13929793#comment-13929793
 ] 

Nux commented on CLOUDSTACK-6181:
-

Marcus,

You're awesome. At least one is having success.
I keep getting into all sorts of problems, like the init thing, that keep me 
from testing the actual thing, this is very frustrating. Now I can't even 
deploy a VM:
http://fpaste.org/84145/49768013/raw/

I'll try some more tomorrow from 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-6214) VPC: when guest network is in Setup state, on its initial nicPlug to the VR, corresponding network rules are not getting applied

2014-03-10 Thread angeline shen (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13929819#comment-13929819
 ] 

angeline shen commented on CLOUDSTACK-6214:
---

Try to reproduce problem withCloudPlatform-QA-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]
:ACL_INBOUND_eth2 - [0:0]
:NETWORK_STATS_eth1 - [0:0]
-A INPUT -d

[jira] [Updated] (CLOUDSTACK-669) Better VM Sync

2014-03-10 Thread Animesh Chaturvedi (JIRA)


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

Animesh Chaturvedi updated CLOUDSTACK-669:
--

Fix Version/s: (was: 4.3.0)
   4.4.0

 Better VM Sync
 --

 Key: CLOUDSTACK-669
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-669
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Reporter: Hari Kannan
Assignee: Kelven Yang
 Fix For: 4.4.0


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/VMWare+Enhancements+-+Support+for+DRS+and+VM+HA



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6181) Root resize