CLOUDSTACK-6485 regression

[Jayapal Reddy Uradi]

Hi Daan,

CLOUDSTACK-6485 is fixed by you and caused the regression for CLOUDSTACK-6084 
and CLOUDSTACK-6548.

vpcId param changed to null causing the issue. After reverting this private 
gateway is working fine.

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/vpc/VpcManagerImpl.java;h=5263d56f531178f3362a50c25b2e66b8ab6f91fc;hp=0c33fc606bc04c253dc6d58c6ca56f0522e8b171;hb=3bd594c;hpb=881792991ecbce5538939e2917cbf6582257ad43

Can you please looking to it.

Thanks,
Jayapal

Re: Review Request 21161: Fixed few cases failing, added proper port for creating client

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/21161/#review42494
---

Ship it!


Ship It!

- Jayapal Reddy


On May 7, 2014, 2:57 p.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21161/
> ---
> 
> (Updated May 7, 2014, 2:57 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1. Fied few cases failing earlier because of wrong zone,domain retrieval
> 2. Added proper port usage while creating client
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vm.py c07e663 
>   tools/marvin/marvin/cloudstackTestClient.py 0e3d3d0 
>   tools/marvin/marvin/marvinPlugin.py 74b64ef 
> 
> Diff: https://reviews.apache.org/r/21161/diff/
> 
> 
> Testing
> ---
> 
> yes, done the changes and tested on simulator
> 
> Test Deploy Virtual Machine ... === TestName: test_deploy_vm | Status : 
> SUCCESS ===
> ok
> Test Multiple Deploy Virtual Machine ... === TestName: 
> test_deploy_vm_multiple | Status : SUCCESS ===
> ok
> Test Deploy Virtual Machine - start operation failure and retry ... === 
> TestName: test_deploy_vm_start_failure | Status : SUCCESS ===
> ok
> Test Deploy Virtual Machine - volume creation failure and retry ... === 
> TestName: test_deploy_vm_volume_creation_failure | Status : SUCCESS ===
> ok
> 
> --
> Ran 4 tests in 138.006s
> 
> OK
> ~ 
>   
> ~   
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Re: secondary ip

[Jayapal Reddy Uradi]

Hi Alena,

listPortForwardingRules response shows vm ip addr, primary/secondary ip address.
We are not showing primary/secondary ip info separately in the response.

Thanks,
Jayapal

On 13-May-2014, at 4:18 AM, Alena Prokharchyk 
 wrote:

> Murali,
> 
> I have a question about the secondary vm ip address. By looking at the 
> listPortForwardingRules response, how do I know if the ip address presented 
> there, is secondary or primary ip address for the vm? I remember you told me 
> before that if vmGuestIp is present in the response, then its a secondary ip; 
> if only vmId is present, then its a primary one. In the latest 4.4 build I 
> see this parameter being populated when the PF rule is created for the 
> Primary ip.
> 
> Thank you,
> Alena.

Re: [ACS44] 4.4.0 blokker issues

[Jayapal Reddy Uradi]

Hi Daan,

While working on 
CLOUDSTACK-6084<https://issues.apache.org/jira/browse/CLOUDSTACK-6084> fixed 
few issues for CLOUDSTACK-6582 and uploaded the patch in the bug.
There are still few issues in network acl cidr changes.

CLOUDSTACK-6582 and CLOUDSTACK-6485 fixes created regression for vpc create 
private gateway CLOUDSTACK-6084.

Thanks,
Jayapal


On 06-May-2014, at 7:25 PM, Rajesh Battala 
mailto:rajesh.batt...@citrix.com>>
 wrote:

CLOUDSTACK-6295,  I have commented on it and closed it.

Thanks
Rajesh Battala

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com<http://gmail.com>]
Sent: Tuesday, May 6, 2014 6:24 PM
To: dev
Subject: [ACS44] 4.4.0 blokker issues

At the moment we have 14 blokker issues in jira. Can all reporters and 
assignees please have a look to see if these are really blokkers and if they 
can be resolved before long?

Key:Summary:Reporter:Assignee
CLOUDSTACK-6130
[Automation] listPublicAdress is failing Srikanteswararao Talluri Hugo Trippaers

CLOUDSTACK-6245
Security group rules on hypervisor host are lagging behind rules in DB edison 
su edison su

CLOUDSTACK-6295
Management server cannot start because Java 7 missing Paul Angus Unassigned

CLOUDSTACK-6444
[Automation] test_01_primary_storage_iscsi failed on "test_primary_storage.py" 
- Wrong iscsi path format - it should be /targetIQN/LUN Chandan Purushothama 
Chandan Purushothama

CLOUDSTACK-6453
[GPU] Windows 2012 Server instance created with vGPU offering is not coming up 
after installing PV drivers Sailaja Mada Sanjay Tripathi

CLOUDSTACK-6544
[Automation] Failed to create template for ROOT volume in Xen, with
Exception: callHostPlugin failed
Rayees Namathponnan Harikrishna Patnala

CLOUDSTACK-6547
[Automation] Failed to download volume in Xen with error "Failed to copy the 
volume from pri stor pool to sec stor pool"
Rayees Namathponnan Nitin Mehta

CLOUDSTACK-6548
[Automation] createPrivateNetwork API failed with NullPointer exception Rayees 
Namathponnan Santhosh Kumar Edukulla

CLOUDSTACK-6551
[Automation] Failed to revert vm snapshot in xen Rayees Namathponnan 
Harikrishna Patnala

CLOUDSTACK-6553
[Automation] Resize volume test case failing with error "value=invalid id due 
to incorrect long value format"
Rayees Namathponnan Rajani Karuturi

CLOUDSTACK-6570
API breakage of the UpdateUser API call
Ove Ewerlid Unassigned

CLOUDSTACK-6572
[Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic Sowmya 
Krishnan Unassigned

CLOUDSTACK-6573
Multiple exceptions after upgrading from 4.3 to 4.4 manasaveloori Unassigned

CLOUDSTACK-6582
Listing acl list rules are failed with exception Unknown column 
'network_acl_item.cidr'
Jayapal Reddy Unassigned

I am taking the last one.
--
Daan

[ACS44] cherry pick

[Jayapal Reddy Uradi]

Hi Daan,

Can you please cherry-pick the following commits  from 4.4-forward.

commit a708d5c4982595666cfe8fe03510517cfefe1326
Author: Jayapal 
Date:   Mon May 5 13:45:51 2014 +0530

CLOUDSTACK-6577: Disable service monitoring in RVR

commit 758f7f2f16d361c40bf61db1e7fd799efe9827db
Author: Jayapal 
Date:   Mon May 5 13:56:59 2014 +0530

CLOUDSTACK-6578: Fixed issue in delete remote access vpn command

commit 645516ee78a8117dfa221caa0fc8d4dfe521af2b
Author: Rajani Karuturi 
Date:   Mon May 5 15:31:35 2014 +0530

CLOUDSTACK-6531: stopping the router in case of command failures. Also 
added alerts for failures.

Signed-off-by: Jayapal 

Thanks,
Jayapal

Re: Is this a bug when creating VPN failed because UDP ports conflicts

[Jayapal Reddy Uradi]

HI Yitao,

If you want to enable vpn on the ip, omit the udp 500,1701 and 4500 ports on 
public ip firewall rule and configure
the vpn.

You can file bug this, for the vpn enable ip cloudstack should ignore vpn ports 
for firewall rule ports conflict.

Thanks,
Jayapal

On 21-Apr-2014, at 3:25 PM, Yitao Jiang  wrote:

> Hi, stackers
> 
>I just found that if the the firewall of sourced nat ip of Isolated
> network has opened UDP port such as 1-65535 range , the create vpn command
> will faile, because the system will
> 
> reopen the udp port of 500, 1701, 4500 which are conflicts with origin port
> range.Response as below
> 
> [{"createremoteaccessvpnresponse":{"errortext":"The range specified,
> 500-500, conflicts with rule 84 which has
> 1-65535","cserrorcode":,"errorcode":537,"uuidList":[]}}]
> 
> So is this a bug ?Or we should ommit the conflict of UDP ports and continue
> to creating VPN , Is that right
> 
> Any thoughts?
> 
> ​BYW, i am working on cloudstack 4.2.1 build from source​
> 
> Thanks,
> 
> Yitao

Re: [ANNOUNCE] New PMC Menber: Alena Prokharchyk

[Jayapal Reddy Uradi]

Congratulations Alena !

On 23-Apr-2014, at 1:20 AM, Daan Hoogland  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked
> Alena Prokharchyk to join the PMC and we are pleased to announce that
> he has accepted.
> 
> Join me in congratulating Alena!
> 
> 
> -The CloudStack PMC

Re: Security Group bug impeding system VMs functionality

[Jayapal Reddy Uradi]

Hi Nux,

Can you please upload the logs.
Please add steps to try for reproducing.

Thanks,
Jayapal

On 16-Apr-2014, at 9:26 AM, Jayapal Reddy Uradi  
wrote:

> Hi Nux,
> 
> The paste links are does not exist.
> Can you please upload the logs again. Also upload rules/logs specific to 
> system rules are not set.
> 
> 
> Thanks,
> Jayapal
> 
> On 11-Apr-2014, at 9:10 PM, Nux!  wrote:
> 
>> Hello,
>> 
>> I'm on 4.3 right now, CentOS6.5 + KVM and SG ADV zone.
>> What happens is that after a reboot or after disabling a zone, when the 
>> system VMs come back the iptables rules required for their proper 
>> functioning do not get set.
>> It seems to be happening randomly and it may not be affecting both VMs (S 
>> and V) at the same time.
>> 
>> More info:
>> http://paste.fedoraproject.org/93567/72307041/
>> sg log: http://paste.fedoraproject.org/93564/23056713/
>> 
>> The problem always goes away if I stop/start the system VMs; the required 
>> iptables rules get created, eg:
>> -A s-105-VM -m physdev --physdev-in vnet3 --physdev-is-bridged -j RETURN
>> -A s-105-VM -m physdev --physdev-in vnet2 --physdev-is-bridged -j RETURN
>> -A s-105-VM -m physdev --physdev-in vnet1 --physdev-is-bridged -j RETURN
>> -A s-105-VM -j ACCEPT
>> -A v-106-VM -m physdev --physdev-in vnet6 --physdev-is-bridged -j RETURN
>> -A v-106-VM -m physdev --physdev-in vnet5 --physdev-is-bridged -j RETURN
>> -A v-106-VM -j ACCEPT
>> 
>> 
>> If someone could have a look at this it'd be great. Let me know if more info 
>> is needed.
>> 
>> Lucian
>> 
>> -- 
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
> 

Re: Security Group bug impeding system VMs functionality

[Jayapal Reddy Uradi]

Hi Nux,

The paste links are does not exist.
Can you please upload the logs again. Also upload rules/logs specific to system 
rules are not set.


Thanks,
Jayapal

On 11-Apr-2014, at 9:10 PM, Nux!  wrote:

> Hello,
> 
> I'm on 4.3 right now, CentOS6.5 + KVM and SG ADV zone.
> What happens is that after a reboot or after disabling a zone, when the 
> system VMs come back the iptables rules required for their proper functioning 
> do not get set.
> It seems to be happening randomly and it may not be affecting both VMs (S and 
> V) at the same time.
> 
> More info:
> http://paste.fedoraproject.org/93567/72307041/
> sg log: http://paste.fedoraproject.org/93564/23056713/
> 
> The problem always goes away if I stop/start the system VMs; the required 
> iptables rules get created, eg:
> -A s-105-VM -m physdev --physdev-in vnet3 --physdev-is-bridged -j RETURN
> -A s-105-VM -m physdev --physdev-in vnet2 --physdev-is-bridged -j RETURN
> -A s-105-VM -m physdev --physdev-in vnet1 --physdev-is-bridged -j RETURN
> -A s-105-VM -j ACCEPT
> -A v-106-VM -m physdev --physdev-in vnet6 --physdev-is-bridged -j RETURN
> -A v-106-VM -m physdev --physdev-in vnet5 --physdev-is-bridged -j RETURN
> -A v-106-VM -j ACCEPT
> 
> 
> If someone could have a look at this it'd be great. Let me know if more info 
> is needed.
> 
> Lucian
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: [ACS4.4][TestPlanReview]Configuring load balancing rules for VM nic secondary ips

[Jayapal Reddy Uradi]

Hi Manasa,

Here are few comments.

1. In API for vmidipmap pass the values as below.
 vmidipmap[0].vmid= , vmidipmap[0].vmip=

2. when you pass the virtualmachineids and vmidipmap then vm primary ip and 
secondary
assigned to lb rule.
3.Add test cases to check the existing behaviour is not disturbed by this 
feature.
4.In verification please add steps to verify the functionality using traffic.
5.Add test case to check impact on internal load balancing, auto scale load 
balancer etc.

Thanks,
Jayapal

On 08-Apr-2014, at 2:33 PM, "Manasa Veloori (3P)" 
mailto:manasa.velo...@citrix.com>>
 wrote:

Hi ,

I have written test cases for the feature “Configuring LB rules for VM NIC 
secondary IPs”
Please review it and provide the comments.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/TestPlan+:Configuring+load+balancing+rules+for+VM+nic+secondary+ips

Thanks,
Manasa

Re: security_group.py closed unexpectedly

[Jayapal Reddy Uradi]

The error is specific to running with sudo. 
But this error is not related to security_group.py failure.

Thanks,
Jayapal
On 07-Apr-2014, at 4:06 PM, Giri Prasad 
 wrote:

> Hi,
> 
> Thanks for your reply.
> 
> /usr/bin/python 
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
> default_network_rules_systemvm --vmname s-5-VM --localbrname cloud
> > runs fine, without any problem.
> 
>  However, I notice the following errors, in the management log, when I stop 
> and start the management server and the cloudstack agent.
> 
>  Please let know of any clues towards this.
> 
> Thanks in advance.
> 
> Regards,
> Giri
> 
> 2014-04-07 15:43:25,145 DEBUG [c.c.u.s.Script] (main:null) Executing: sudo 
> keytool -genkey -keystore 
> /etc/cloudstack/management/cloudmanagementserver.keystore -storepass 
> vmops.com -keypass vmops.com -keyalg RSA -validity 3650 -dname cn="Cloudstack 
> User",ou="giriubuntu.cruzesoft.com",o="giriubuntu.cruzesoft.com",c="Unknown" 
> 2014-04-07 15:43:25,181 DEBUG [c.c.u.s.Script] (main:null) Exit value is 1
> 2014-04-07 15:43:25,181 DEBUG [c.c.u.s.Script] (main:null) sudo: no tty 
> present and no askpass program specifiedSorry, try again.sudo: no tty present 
> and no askpass program specifiedSorry, try again.sudo: no tty present and no 
> askpass program specifiedSorry, try again.sudo: 3 incorrect password attempts
> 2014-04-07 15:43:25,182 WARN  [c.c.s.ConfigurationServerImpl] (main:null) 
> Would use fail-safe keystore to continue.
> java.io.IOException: Fail to generate certificate!: sudo: no tty present and 
> no askpass program specifiedSorry, try again.sudo: no tty present and no 
> askpass program specifiedSorry, try again.sudo: no tty present and no askpass 
> program specifiedSorry, try again.sudo: 3 incorrect password attempts
>   at 
> com.cloud.server.ConfigurationServerImpl.generateDefaultKeystore(ConfigurationServerImpl.java:576)
>  
> 
> 
> 014-04-07 15:43:25,222 INFO  [c.c.s.ConfigurationServerImpl] (main:null) 
> Going to update systemvm iso with generated keypairs if needed
> 2014-04-07 15:43:25,223 DEBUG [c.c.u.s.Script] (main:null) Looking for 
> scripts/vm/systemvm/injectkeys.sh in the classpath
> 2014-04-07 15:43:25,223 DEBUG [c.c.u.s.Script] (main:null) System resource: 
> null
> 2014-04-07 15:43:25,224 DEBUG [c.c.u.s.Script] (main:null) Classpath 
> resource: 
> file:/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh
> 2014-04-07 15:43:25,224 DEBUG [c.c.u.s.Script] (main:null) Absolute path =  
> /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/vm/systemvm/injectkeys.sh
> 2014-04-07 15:43:25,224 DEBUG [c.c.u.s.Script] (main:null) Looking for 
> vms/systemvm.iso in the classpath
> 2014-04-07 15:43:25,224 DEBUG [c.c.u.s.Script] (main:null) System resource: 
> null
> 2014-04-07 15:43:25,994 DEBUG [c.c.u.s.Script] (main:null) Classpath 
> resource: 
> file:/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/vms/systemvm.iso
> 2014-04-07 15:43:25,994 DEBUG [c.c.u.s.Script] (main:null) Absolute path =  
> /usr/share/cloudstack-management/webapps/client/WEB-INF/classes/vms/systemvm.iso
> 
> 
> 2014-04-07 15:43:26,199 INFO  [c.c.c.ClusterManagerImpl] (main:null) Start 
> configuring cluster manager : ClusterManagerImpl
> 2014-04-07 15:43:26,200 INFO  [c.c.c.ClusterManagerImpl] (main:null) Cluster 
> node IP : 192.168.1.5
> 2014-04-07 15:43:26,218 INFO  [c.c.c.ClusterManagerImpl] (main:null) Trying 
> to connect to 192.168.1.5
> 2014-04-07 15:43:26,221 ERROR [c.c.c.ClusterManagerImpl] (main:null) Unable 
> to ping management server at 192.168.1.5:9090 due to ConnectException
> java.net.ConnectException: Connection refused
>   at sun.nio.ch.Net.connect(Native Method)
>   at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:534)
>   at 
> com.cloud.cluster.ClusterManagerImpl.pingManagementNode(ClusterManagerImpl.java:1122)
>  
> 
> 
> 
> 2014-04-07 15:43:37,511 INFO  [o.a.c.s.d.p.DefaultHostListener] 
> (AgentConnectTaskPool-1:ctx-d531d35b) Connection established between 
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@1fd79af9 host + 1
> 2014-04-07 15:43:37,520 DEBUG [c.c.s.StorageManagerImpl] 
> (AgentConnectTaskPool-1:ctx-d531d35b) Successfully set Capacity - 
> 447226052608 for capacity type - 3 , DataCenterId - 1, HostOrPoolId - 1, 
> PodId 1
> 2014-04-07 15:43:37,520 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-1:ctx-d531d35b) Sending Connect to listener: 
> SecondaryStorageListener
> 2014-04-07 15:43:37,520 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-1:ctx-d531d35b) Sending Connect to listener: 
> DeploymentPlanningManagerImpl
> 2014-04-07 15:43:37,522 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentConnectTaskPool-1:ctx-d531d35b) Sending Connect to listener: 
> ClusteredVirtualMachineManagerImpl
> 2014-04-07 15:43:37,522 DEBUG [c.c.v.VirtualMachineManagerImpl] 
> (AgentConnectTaskPool-1:ctx-d

Re: security_group.py closed unexpectedly

[Jayapal Reddy Uradi]

Hi,

Can you please run the below script on the host and check for errors.
> /usr/bin/pyton 
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
> default_network_rules_systemvm --vmname s-5-VM --localbrname cloud

iptables chain create should not cause issues.

Thanks,
Jayapal

On 07-Apr-2014, at 3:22 PM, Giri Prasad 
 wrote:

> Hello All,
> 
>  I installed Ubuntu 12.04 LTS on a i3, 8gb ram machine. And installed 
> cloudstack 4.3. Upon starting the the management server and agent of 
> cloudstack, the following errors are reported by the system. Any insights? 
> Thanks in advance.
> 
> Regards,
> Giri
> 
> security_group.py has closed unexpectedly
> 
> Executable Path
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py
> 
> Package
>   cloudstack-common-4.3.0 [origin cloudstack.org]
> 
> Problem Type
>Crash
> 
> Title:
> security_group.py crashed with CalledProcessError in __call__(): Command 
> '['/bin/bash', '-c', u'iptables -N BF-cloudbr9']' returned non-zero exit 
> status 1
> 
> ProcCmdLine
> /usr/bin/pyton 
> /usr/share/cloudstack-common/scripts/vm/network/security_group.py 
> default_network_rules_systemvm --vmname s-5-VM --localbrname cloud
> 
> PytonArgs
> ['/usr/share/cloudstack-common/scripts/vm/network/security_group.py','default_network_rules_systemvm','--vmname','s-5-VM','--localbrname','cloud0']
> 
> Source Package
>   cloudstack
> 
> Uname
>   Linux 3.11.0-19-generic
> 
> management-server.log 
> *
> 2014-04-07 14:09:31,246 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-132e0e49) Found 0 routers to update status. 
> 2014-04-07 14:09:31,248 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-132e0e49) Found 0 networks to update RvR status. 
> 2014-04-07 14:09:46,714 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentManager-Handler-3:null) Ping from 1
> 2014-04-07 14:10:01,247 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-6b66bd10) Found 0 routers to update status. 
> 2014-04-07 14:10:01,249 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-6b66bd10) Found 0 networks to update RvR status. 
> 2014-04-07 14:10:06,141 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Resetting hosts suitable for reconnect
> 2014-04-07 14:10:06,143 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Completed resetting hosts suitable for reconnect
> 2014-04-07 14:10:06,143 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Acquiring hosts for clusters already owned by this 
> management server
> 2014-04-07 14:10:06,144 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Completed acquiring hosts for clusters already owned by 
> this management server
> 2014-04-07 14:10:06,144 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Acquiring hosts for clusters not owned by any management 
> server
> 2014-04-07 14:10:06,145 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager 
> Timer:ctx-2f093bdb) Completed acquiring hosts for clusters not owned by any 
> management server
> 2014-04-07 14:10:16,204 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-566129ef) VmStatsCollector is running...
> 2014-04-07 14:10:16,321 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-6a332b1b) StorageCollector is running...
> 2014-04-07 14:10:16,328 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-6a332b1b) There is no secondary storage VM for 
> secondary storage host nfs://192.168.1.5/export/secondary
> 2014-04-07 14:10:16,397 DEBUG [c.c.a.t.Request] 
> (StatsCollector-1:ctx-6a332b1b) Seq 1-1822556174: Received:  { Ans: , MgmtId: 
> 108689543298440, via: 1, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2014-04-07 14:10:17,509 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-054ac5cc) HostStatsCollector is running...
> 2014-04-07 14:10:18,133 DEBUG [c.c.a.t.Request] 
> (StatsCollector-3:ctx-054ac5cc) Seq 1-1822556175: Received:  { Ans: , MgmtId: 
> 108689543298440, via: 1, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2014-04-07 14:10:31,246 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-bf9adfc5) Found 0 routers to update status. 
> 2014-04-07 14:10:31,248 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-bf9adfc5) Found 0 networks to update RvR status. 
> 2014-04-07 14:10:46,715 DEBUG [c.c.a.m.AgentManagerImpl] 
> (AgentManager-Handler-6:null) Ping from 1
> 2014-04-07 14:11:01,245 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-6b62a466) Found 0 routers to update status. 
> 2014-04-07 14:11:01,247 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:ctx-6b62a466) Found 0 networks to update RvR status. 

Re: Script executed when an instance is just deployed

[Jayapal Reddy Uradi]

Hi,

You want to execute a script in VM after the vm is booted ?
Can you please elaborate more


Thanks,
Jayapal
On 04-Apr-2014, at 5:28 PM, mathieu herbert 
 wrote:

> Hi,
> In my company, we would like to execute a script at the end of the
> deployment process (Jar).
> 
> How can we include this script in the deployment process?
> 
> Do you have any documentation about this subject?
> 
> Thank you.
> 
> -- 
> 
> Mathieu Herbert

Re: Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

> On March 18, 2014, 6:35 p.m., Alena Prokharchyk wrote:
> > Even for the Basic zone, we should send the ipSet command on nicplug only 
> > when the SG is supported by the Basic zone network. Because we also support 
> > a model when Basic zone is deployed with SG disabled.

When vm is created vm primary ip is set in ipset. For nic secondary ip there is 
no nicplug command send to hypervisor. 


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/#review37596
---


On March 19, 2014, 11:59 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19351/
> ---
> 
> (Updated March 19, 2014, 11:59 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and edison su.
> 
> 
> Bugs: CLOUDSTACK-6240
> https://issues.apache.org/jira/browse/CLOUDSTACK-6240
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Updated adding SG rules for nic secondary ips in Advacned SG.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> b5e2239 
>   api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java 
> 199cf2e 
>   server/src/com/cloud/network/security/SecurityGroupManagerImpl.java 51c93b7 
> 
> Diff: https://reviews.apache.org/r/19351/diff/
> 
> 
> Testing
> ---
> 
> Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

> On March 18, 2014, 6:25 p.m., Alena Prokharchyk wrote:
> > Jayapal, you shoudldn't rely on SG attribute of the zone. You should check 
> > if the SG service is supported by the network you are adding your rule to.

Updated patch to check network for SG enabled.


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/#review37589
---


On March 19, 2014, 11:59 a.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19351/
> ---
> 
> (Updated March 19, 2014, 11:59 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and edison su.
> 
> 
> Bugs: CLOUDSTACK-6240
> https://issues.apache.org/jira/browse/CLOUDSTACK-6240
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Updated adding SG rules for nic secondary ips in Advacned SG.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> b5e2239 
>   api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java 
> 199cf2e 
>   server/src/com/cloud/network/security/SecurityGroupManagerImpl.java 51c93b7 
> 
> Diff: https://reviews.apache.org/r/19351/diff/
> 
> 
> Testing
> ---
> 
> Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Review Request 19916: Updated listLoadBalancerRuleInstances, removeFromLoadBalancerRule APIs for VM secondary ip addresses

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19916/
---

Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, and Murali 
Reddy.


Bugs: CLOUDSTACK-6327
https://issues.apache.org/jira/browse/CLOUDSTACK-6327


Repository: cloudstack-git


Description
---

Configuring load balancing rules for VM secondary ip address feature is in 4.4.

In this patch updated 'listLoadBalancerRuleInstances' API response to display 
the VM ip address.

Also updated the removeFromLoadBalancerRule to remove the specific vm and ip 
entry which assigned to LB rule.


Diffs
-

  api/src/com/cloud/network/lb/LoadBalancingRulesService.java 6643de6 
  api/src/org/apache/cloudstack/api/ApiConstants.java 1146cea 
  
api/src/org/apache/cloudstack/api/command/admin/loadbalancer/ListLoadBalancerRuleInstancesCmdByAdmin.java
 26202b9 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java
 2d458a7 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveFromLoadBalancerRuleCmd.java
 8714d34 
  api/src/org/apache/cloudstack/api/response/LoadBalancerRuleVmMapResponse.java 
PRE-CREATION 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 51f45c2 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java bb24e04 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java 8fafcc9 
  server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 4e6d6fd 

Diff: https://reviews.apache.org/r/19916/diff/


Testing
---

Tested listLoadBalancerRuleInstances API to display vm and vm ip address 
details.
Tested removing only specific ip of the VM from the LB rule.


Thanks,

Jayapal Reddy

Re: Review Request 19916: Updated listLoadBalancerRuleInstances, removeFromLoadBalancerRule APIs for VM secondary ip addresses

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19916/
---

(Updated April 2, 2014, 1:06 p.m.)


Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, and Murali 
Reddy.


Bugs: CLOUDSTACK-6327
https://issues.apache.org/jira/browse/CLOUDSTACK-6327


Repository: cloudstack-git


Description
---

Configuring load balancing rules for VM secondary ip address feature is in 4.4.

In this patch updated 'listLoadBalancerRuleInstances' API response to display 
the VM ip address.

Also updated the removeFromLoadBalancerRule to remove the specific vm and ip 
entry which assigned to LB rule.


Diffs
-

  api/src/com/cloud/network/lb/LoadBalancingRulesService.java 6643de6 
  api/src/org/apache/cloudstack/api/ApiConstants.java 1146cea 
  
api/src/org/apache/cloudstack/api/command/admin/loadbalancer/ListLoadBalancerRuleInstancesCmdByAdmin.java
 26202b9 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/ListLoadBalancerRuleInstancesCmd.java
 2d458a7 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/RemoveFromLoadBalancerRuleCmd.java
 8714d34 
  api/src/org/apache/cloudstack/api/response/LoadBalancerRuleVmMapResponse.java 
PRE-CREATION 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 51f45c2 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java bb24e04 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java 8fafcc9 
  server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 4e6d6fd 

Diff: https://reviews.apache.org/r/19916/diff/


Testing
---

Tested listLoadBalancerRuleInstances API to display vm and vm ip address 
details.
Tested removing only specific ip of the VM from the LB rule.


Thanks,

Jayapal Reddy

Re: Review Request 19034: Assigning LB rule to vm nic secondary ip

[Jayapal Reddy]

> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java, line 984
> > <https://reviews.apache.org/r/19034/diff/1/?file=516177#file516177line984>
> >
> > where is the test for this?

Added test


- Jayapal


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19034/#review37257
---


On March 11, 2014, 12:04 p.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19034/
> ---
> 
> (Updated March 11, 2014, 12:04 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, Kishan 
> Kavala, and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-2692
> https://issues.apache.org/jira/browse/CLOUDSTACK-2692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> With this feature load balancing rules assigned/associated to any ip of the 
> vm nic. The vm nic ip can be primary ip or nic secondary ip.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 4c87d34 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 0a3fafd 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java
>  6bd7537 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 79eaf8e 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java 
> b0b14fc 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapVO.java 0a67106 
>   server/src/com/cloud/network/NetworkServiceImpl.java ebeb31a 
>   server/src/com/cloud/network/as/AutoScaleManagerImpl.java 2fa3821 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6f0c1e9 
>   setup/db/db/schema-430to440.sql ee4cf21 
> 
> Diff: https://reviews.apache.org/r/19034/diff/
> 
> 
> Testing
> ---
> 
> Tested configuring the LB rules to vm primary ip and vm secondary ip.
> The haproxy config is created correctly for the selected ip.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request 19034: Assigning LB rule to vm nic secondary ip

[Jayapal Reddy]

> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > api/src/com/cloud/network/lb/LoadBalancingRulesService.java, line 97
> > <https://reviews.apache.org/r/19034/diff/1/?file=516169#file516169line97>
> >
> > HoW ABOUT DESCRIBING THE ADDITIONAL PARAMETER IN THE COMMENTS

updated the comment


> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java,
> >  line 123
> > <https://reviews.apache.org/r/19034/diff/1/?file=516171#file516171line123>
> >
> > Prefer returning empty map instead of null

updated to return empty map


> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > server/src/com/cloud/network/NetworkServiceImpl.java, line 811
> > <https://reviews.apache.org/r/19034/diff/1/?file=516175#file516175line811>
> >
> > Why not put this code in the LB manager.

Moved to LB manager


> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > server/src/com/cloud/network/as/AutoScaleManagerImpl.java, line 1410
> > <https://reviews.apache.org/r/19034/diff/1/?file=516176#file516176line1410>
> >
> > prefer passing empty maps

done


> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java, line 939
> > <https://reviews.apache.org/r/19034/diff/1/?file=516177#file516177line939>
> >
> > You should have a test written for this condition

done


> On March 14, 2014, 7:38 p.m., Chiradeep Vittal wrote:
> > server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java, line 945
> > <https://reviews.apache.org/r/19034/diff/1/?file=516177#file516177line945>
> >
> > if you had passed in an EMPTY map from the API level you wouldn't have 
> > to check for nullness

updated to pass empty map and removed null check


- Jayapal


-------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19034/#review37257
---


On March 11, 2014, 12:04 p.m., Jayapal Reddy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19034/
> ---
> 
> (Updated March 11, 2014, 12:04 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, Kishan 
> Kavala, and Murali Reddy.
> 
> 
> Bugs: CLOUDSTACK-2692
> https://issues.apache.org/jira/browse/CLOUDSTACK-2692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> With this feature load balancing rules assigned/associated to any ip of the 
> vm nic. The vm nic ip can be primary ip or nic secondary ip.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/lb/LoadBalancingRulesService.java 4c87d34 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 0a3fafd 
>   
> api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java
>  6bd7537 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 79eaf8e 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java 
> b0b14fc 
>   engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapVO.java 0a67106 
>   server/src/com/cloud/network/NetworkServiceImpl.java ebeb31a 
>   server/src/com/cloud/network/as/AutoScaleManagerImpl.java 2fa3821 
>   server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6f0c1e9 
>   setup/db/db/schema-430to440.sql ee4cf21 
> 
> Diff: https://reviews.apache.org/r/19034/diff/
> 
> 
> Testing
> ---
> 
> Tested configuring the LB rules to vm primary ip and vm secondary ip.
> The haproxy config is created correctly for the selected ip.
> 
> 
> Thanks,
> 
> Jayapal Reddy
> 
>

Re: Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/
---

(Updated March 19, 2014, 11:59 a.m.)


Review request for cloudstack, Abhinandan Prateek and edison su.


Changes
---

Updated patch to check network for SG support and send SG rules.


Bugs: CLOUDSTACK-6240
https://issues.apache.org/jira/browse/CLOUDSTACK-6240


Repository: cloudstack-git


Description
---

Updated adding SG rules for nic secondary ips in Advacned SG.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
b5e2239 
  api/src/org/apache/cloudstack/api/command/user/vm/RemoveIpFromVmNicCmd.java 
199cf2e 
  server/src/com/cloud/network/security/SecurityGroupManagerImpl.java 51c93b7 

Diff: https://reviews.apache.org/r/19351/diff/


Testing
---

Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic


Thanks,

Jayapal Reddy

CLOUDSTACK-6240 patch

[Jayapal Reddy Uradi]

Hi Animesh,

Uploaded the patch for CLOUDSTACK-6240 -ipset requires VM stop/start to get 
updated
https://reviews.apache.org/r/19351/

Also updated the bug with the patch.

Thanks,
Jayapal

Review Request 19351: Fixed updating ipset on acquiring vm nic secondary ip for advanced SG zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19351/
---

Review request for cloudstack, Abhinandan Prateek and edison su.


Bugs: CLOUDSTACK-6240
https://issues.apache.org/jira/browse/CLOUDSTACK-6240


Repository: cloudstack-git


Description
---

Updated adding SG rules for nic secondary ips in Advacned SG.


Diffs
-

  api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
b5e2239 

Diff: https://reviews.apache.org/r/19351/diff/


Testing
---

Tested 'ipset -L' output on xenserver after acquiring secondary ip for vm nic


Thanks,

Jayapal Reddy

Review Request 19034: Assigning LB rule to vm nic secondary ip

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19034/
---

Review request for cloudstack, Abhinandan Prateek, Chiradeep Vittal, Kishan 
Kavala, and Murali Reddy.


Bugs: CLOUDSTACK-2692
https://issues.apache.org/jira/browse/CLOUDSTACK-2692


Repository: cloudstack-git


Description
---

With this feature load balancing rules assigned/associated to any ip of the vm 
nic. The vm nic ip can be primary ip or nic secondary ip.


Diffs
-

  api/src/com/cloud/network/lb/LoadBalancingRulesService.java 4c87d34 
  api/src/org/apache/cloudstack/api/ApiConstants.java 0a3fafd 
  
api/src/org/apache/cloudstack/api/command/user/loadbalancer/AssignToLoadBalancerRuleCmd.java
 6bd7537 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDao.java 79eaf8e 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapDaoImpl.java b0b14fc 
  engine/schema/src/com/cloud/network/dao/LoadBalancerVMMapVO.java 0a67106 
  server/src/com/cloud/network/NetworkServiceImpl.java ebeb31a 
  server/src/com/cloud/network/as/AutoScaleManagerImpl.java 2fa3821 
  server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 6f0c1e9 
  setup/db/db/schema-430to440.sql ee4cf21 

Diff: https://reviews.apache.org/r/19034/diff/


Testing
---

Tested configuring the LB rules to vm primary ip and vm secondary ip.
The haproxy config is created correctly for the selected ip.


Thanks,

Jayapal Reddy

Re: [PROPOSAL][QUESTION] Map parameters in API Commands

[Jayapal Reddy Uradi]

Hi Antonio,


I am working on the below feature for 4.4 as part it adding an extra MAP param 
vmidipmap to assignToLoadBalancerRule API.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuring+load+balancing+rules+for+VM+nic+secondary+ips

I am following the existing way for map access and in my case vm can have two 
ips, one is primay and other secondary
vmidipmap[0].vmid=10 vmidipmap[0].vmip=10.1.1.17 also we can have 
vmidipmap[1].vmid=10 vmidipmap[0].vmip=10.1.1.18

Will your changes effect for my changes ?

My opinion is wait 4.4 code freeze to commit patch. This way the patch can 
handle newly coming changes.

Thanks,
Jayapal



On 10-Mar-2014, at 1:13 PM, Bharat Kumar 
 wrote:

> Hi All,
> the roodiskresize is no longer valid. as there is no code which is using 
> rootdiskresize currently.
> 
> As a part of the custom service offering we had to enable specifying custom 
> values to parameters cpu, memory and cpuCores. 
> instead of adding a parameter for each of these values we changed it use a 
> details map.  This will also not require any further 
> changes in the API if we need to add some more custom values in future.
> 
> On 08-Mar-2014, at 1:42 am, Marcus  wrote:
> 
>> Any suggestion? Do we go forward assuming that the correct parameter
>> for resize on deploy is:
>> 
>> deployVirtualMachine&details[0].rootdisksize=3
>> 
>> or do we change it to
>> 
>> deployVirtualMachine&rootdisksize=3
>> 
>> On Tue, Mar 4, 2014 at 4:14 PM, Marcus  wrote:
>>> Ok, sounds like there needs to be some work done to make these more
>>> consistent, perhaps. Can you comment on why rootdisksize was made from
>>> a parameter into a part of the details map?
>>> 
>>> On Tue, Mar 4, 2014 at 3:12 AM, Bharat Kumar  
>>> wrote:
 Hi ALL,
 There are many other APIs that use Map like createNetworkOffering,
 updateZone, createTemplate, in most of the cases we do not
 say how to use maps, one way would be to write this in the description or 
 to
 use the same way to access maps of all APIs.
 
 BTW the way to use details in deploy vm API is
 details[0].foo=bar&details[1].baz=12 where foo and baz are keys.
 
 Also  if we want to use the regix protected static final String
 MAP_KEY_PATTERN_EXPRESSION = "^([^\\[^\\]]+)\\[(\\d+)\\]\\.key$";
  protected static final
 String MAP_VALUE_PATTERN_EXPRESSION = "^[^\\[^\\]]+\\[\\d+\\]\\.value$";
 
 wil this work in the following case. I believe service is the key here 
 which
 repeats.
 http://10.147.59.119:8080/client/api?command=createNetworkOffering&response=json&sessionkey=/kGFJDXFmMQU8JZnnC7QFfj3tV8=&name=bharat&displayText=bharat&guestIpType=Isolated&lbType=publicLb&;
 servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&
 servicecapabilitylist[0].capabilityvalue=peraccount&
 servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&
 servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Vpn,Dhcp,Dns,Firewall,Lb,UserData,SourceNat,StaticNat,PortForwarding&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Vpn&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dhcp&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Dns&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Firewall&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=Lb&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=UserData&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=SourceNat&serviceProviderList[6].provider=JuniperSRX&serviceProviderList[7].service=StaticNat&serviceProviderList[7].provider=JuniperSRX&serviceProviderList[8].service=PortForwarding&serviceProviderList[8].provider=JuniperSRX&egressdefaultpolicy=true&traffictype=GUEST&_=1393925230248
 
 
 
 On 04-Mar-2014, at 2:30 am, Marcus  wrote:
 
 Along these lines, the details parameter in deployVirtualMachine seems
 broken. If I call "details[0].key=foo,details[0].value=bar", it stores
 entries in the database like this:
 
 id | vmid | name | value | display
 
 12 | 25   |  value | bar   | 1
 13 | 25   |  key   | foo   | 1
 
 It seems as though this might be correct per Alena's email, but I
 don't understand how this can be reconstructed into foo=bar when
 there's no binding between the two rows. Perhaps details are supposed
 to be passed differently than the resource tags, because if I do
 "details[0].foo=bar&details[1].baz=12", I get:
 
 id | vmid | name | value | display
 

Re: Windows Guest vm takes diff. IP

[Jayapal Reddy Uradi]

Hi Tejas,

Is there any dhcp server running in your setup other than VR ?
Is the  ip really served by VR ?

Thanks,
Jayapal
On 06-Mar-2014, at 9:35 AM, Tejas Gadaria  wrote:

> Hi,
> 
> I have configured CS 4.0.2 with vmware in advance networking mode.
> I am facing this problem with only Windows guest vm. Linux gueust as
> working fine.
> 
> While deploying Windows 7 guest vm cloudstsck assigning ip from guest ip
> range.but guest vm actually takes different ip than what is shown under
> 'NICs' tab.
> 
> need your help on this.
> 
> Regards,
> Tejas

Re: 4.4 Feature Freeze

[Jayapal Reddy Uradi]

Hi,

The below feature is proposed in dev list but somehow the fix version is not 
set correctly, update it now.
CLOUDSTACK-2692 Add load 
balancing support for multiple ips to nic

Thanks,
Jayapal

On 04-Mar-2014, at 9:37 PM, Giles Sirett 
mailto:giles.sir...@shapeblue.com>>
 wrote:

I'm coming in late to this debate, but have been watching closely.

I am -1 on moving the freeze date
To put it more generally: I am -1 on ANYTHING that will have a potential impact 
on quality right now.
Whatever anybody says, I can bet that a shorter code freeze (even temporary) 
will have an impact on quality

I am not a developer, but I see the downstream fallout of features being rushed 
in with the users of this software

>From my experience in the field: customers (users)  do not rush to upgrade ACS 
>anyway.  Most of the orgs I know would accept a 3 month delay if they knew the 
>quality was going to be, on average, higher (obviously, we all have that one 
>feature that *we* want and think is low risk - but I'm generalising here)

We've already got a pretty frequent release cycle . This will be frustrating 
for some of you guys I know (understand many people working like crazy to build 
new features) , but we all know the release cycle, we all know the code freeze 
window.

I fully understand that 4.3 has been a pain to get out of the door and is the 
root cause of this situation. If we have less time to test 4.4, we run the risk 
of having the same happen again.

If that means that 4.4 needs to ship with fewer features. So be it



Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: 02 March 2014 18:08
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze


On Feb 26, 2014, at 10:44 PM, Sudha Ponnaganti  
wrote:

+1 to move feature freeze date in this case as 4.3 closure has impact on the 
next release cycle.  There are 14 features targeted  for 4.4 and all of them 
are in open state as of now.  There are only 2 weeks left to close on coding 
and developers would rush to check in the code.   This only results in poor 
quality code.

Why the rush ? if it's not done, it's not done and will get in later. Why rush 
to merge code that you know will have bugs ?


Thanks
/sudha

-Original Message-
From: John Kinsella [mailto:j...@stratosec.co]
Sent: Wednesday, February 26, 2014 7:22 PM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

I don't see not moving the freeze date as a penalty.  If a feature doesn't make 
the current deadline, it moves to the next release, which is still a few months 
away. For significant issues, it's not uncommon for us to allow them in late.

What we have a stronger need for than shifting a date, by several orders of 
magnitude, is understanding why the RC process took so long and what we can do 
in the future to make that not so painful.

For the record I'm +0 on moving the feature freeze date.

John

On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:

I share it too. Many developers in the community went out of their
way to get a cleaner RC and thereby impacting their feature
development efforts. We shouldn't be penalizing them with this 2
week's feature freeze schedule

Thanks,
RamG

-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
Sent: 27 February 2014 03:00
To: dev@cloudstack.apache.org
Subject: RE: 4.4 Feature Freeze

Mike I share your opinion most of us have been pretty much on 4.3
until now, and pushing out the release seems reasonable. As I called
out in earlier mail the feature proposal date was not called out for
4.4 and as such giving little extra room seems reasonable.

Animesh

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Wednesday, February 26, 2014 7:29 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.4 Feature Freeze

I think we're having this discussion after every release because
we're beginning to realize that a four-month release cycle has not
been very realistic for us yet.

The main issue I encounter is our month-long RC cycle where I spend
a bunch of time validating the RC and (during that timeframe) less
time developing for the next release as I had initially planned.

Perhaps instead of extending the cycle we could consider ways to
actually meet the schedule on a consistent basis. That would be
fine, as
well.


On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
wrote:

-1 on postponing the feature freeze. We are having this discussion
after every release, however we agreed to do a 4 month cycle so
let's stick
to it.

If there are important features that are currently being developed
but might not make this cut-off date we should discuss that
separately, but as a point of principle lets stick to the release
schedule as
proposed.


Cheers,

Hugo


On

commit cherrypick to 4.3

[Jayapal Reddy Uradi]

Hi Animesh,

Please cherry the pick the below commits from 4.3-forward to 4.3

37ce4e52c28081a0c718ca87fdbff79935074b75
7700a1b71622c1d45b2b54aa7444be5adc4fb8ab

Thanks,
Jayapal

Re: Not able to ping to outside network from system VMs

[Jayapal Reddy Uradi]

Which zone are you setting basic or advanced ?
My suggestion for you is first make a setup with simple config to get it work.

If you are trying for Advanced zone isolated network,
Try the separate ip range for management and public.
1. Management subnet: ex: 10.147.28.100-120 , gw 10.147.28.1 vlan:28 
2. Public subnet subnet: ex: 10.147.52.100-120, gw 10.147.52.1 vlan:52
3. Dns: use your corporate DNS server, do not use MS.

Thanks,
Jayapal

On 28-Feb-2014, at 1:21 PM, Jitendra Shelar  
wrote:

> 
> Hi Jaypal,
> We have configured for a single node setup.
> 
> Host/Management Server :  10.44.65.143
> IP range :   10.44.64.21 - 10.44.64.30
> 10.44.64.31 - 10.44.64.40
> Gateway : 10.44.64.1
> 
> During configuration of zone and pod, have taken the Management server IP as 
> DNS and gateway IP.
> 
> We are not able to ping from system VMs to 
> a) Gateway
> b) Google DNS
> c) Corporate DNS
> d) Management or Host Server
> 
> Following logs are repeating.
> 
> 2014-02-28 13:16:57,887 DEBUG [agent.manager.AgentManagerImpl] 
> (StatsCollector-1:null) Details from executing class 
> com.cloud.agent.api.GetHostStatsCommand: empty String
> 2014-02-28 13:16:57,887 WARN  [cloud.resource.ResourceManagerImpl] 
> (StatsCollector-1:null) Unable to obtain host 10 statistics.
> 2014-02-28 13:16:57,888 WARN  [cloud.server.StatsCollector] 
> (StatsCollector-1:null) Received invalid host stats for host: 10
> 2014-02-28 13:16:59,095 DEBUG [cloud.server.StatsCollector] 
> (StatsCollector-3:null) StorageCollector is running...
> 2014-02-28 13:16:59,098 DEBUG [cloud.server.StatsCollector] 
> (StatsCollector-3:null) There is no secondary storage VM for secondary 
> storage host nfs://10.44.65.143/export/secondary
> 2014-02-28 13:16:59,125 DEBUG [agent.transport.Request] 
> (StatsCollector-3:null) Seq 10-96469044: Received:  { Ans: , MgmtId: 
> 279278805451128, via: 10, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2014-02-28 13:17:02,067 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
> ===START===  10.43.3.110 -- GET  
> command=listTemplates&response=json&sessionkey=Q%2FWjHAwdSQdR8O771SQ4koi5PFA%3D&templatefilter=all&_=1393573622806
> 2014-02-28 13:17:02,157 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
> ===END===  10.43.3.110 -- GET  
> command=listTemplates&response=json&sessionkey=Q%2FWjHAwdSQdR8O771SQ4koi5PFA%3D&templatefilter=all&_=1393573622806
> 2014-02-28 13:17:16,065 DEBUG [storage.secondary.SecondaryStorageManagerImpl] 
> (secstorage-1:null) Zone 5 is ready to launch secondary storage VM
> 2014-02-28 13:17:16,187 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] 
> (consoleproxy-1:null) Zone 5 is ready to launch console proxy
> 2014-02-28 13:17:16,634 DEBUG 
> [cloud.network.ExternalLoadBalancerUsageManagerImpl] 
> (ExternalNetworkMonitor-1:null) External load balancer devices stats 
> collector is running...
> 2014-02-28 13:17:16,643 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2014-02-28 
> 07:47:16 GMT
> 2014-02-28 13:17:16,644 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Got 0 snapshots to be executed at 2014-02-28 07:47:16 
> GMT
> 2014-02-28 13:17:16,655 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null) 
> Found 0 running routers.
> 2014-02-28 13:17:16,657 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] 
> (RouterStatusMonitor-1:null) Found 0 routers.
> 2014-02-28 13:17:17,063 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) 
> ===START===  10.43.3.110 -- GET  
> command=listTemplates&response=json&sessionkey=Q%2FWjHAwdSQdR8O771SQ
> 
> Still, we are facing same issue.
> 
> Regards,
> Jitendra
> 
> 
> 
> 
> -Original Message-
> From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] 
> Sent: Friday, February 28, 2014 11:49 AM
> To: 
> Cc: us...@cloudstack.apache.org; Ajay Singh
> Subject: Re: Not able to ping to outside network from system VMs
> 
> Hi,
> 
> Change the name server to your internal DNS server in systemvm 
> (/etc/resolve.conf).
> I also observed that the google DNS server is pinging but not serving the dns 
> requests.
> 
> Thanks,
> Jayapal
> 
> 
> On 28-Feb-2014, at 11:02 AM, Jitendra Shelar 
> 
> wrote:
> 
>> Hi Tejas,
>> 
>> Thanks for your response.
>> 
>> We tried with Google DNS for the "Internal DNS"  of Zone. 
>> We are not able to resolve Google DNS  from the system VMs. 
>> We are able to ping to Google DNS from management server and host server.
>> 
>> We tried with single node setup.
>> We are fac

Re: Not able to ping to outside network from system VMs

[Jayapal Reddy Uradi]

Hi,

Change the name server to your internal DNS server in systemvm 
(/etc/resolve.conf).
I also observed that the google DNS server is pinging but not serving the dns 
requests.

Thanks,
Jayapal


On 28-Feb-2014, at 11:02 AM, Jitendra Shelar 
 wrote:

> Hi Tejas,
> 
> Thanks for your response.
> 
> We tried with Google DNS for the "Internal DNS"  of Zone. 
> We are not able to resolve Google DNS  from the system VMs. 
> We are able to ping to Google DNS from management server and host server.
> 
> We tried with single node setup.
> We are facing same issue. Not able to ping gateway from system VMs.
> 
> Regards,
> Jitendra
> 
> 
> 
> -Original Message-
> From: Tejas Gadaria [mailto:refond.g...@gmail.com] 
> Sent: Friday, February 28, 2014 9:20 AM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Not able to ping to outside network from system VMs
> 
> Is your "Internal DNS 1" of Zone able to resolve Google DNS?
> 
> Regards,
> Tejas
> 
> 
> On Thu, Feb 27, 2014 at 12:48 PM, Jitendra Shelar < 
> jitendra_she...@persistent.co.in> wrote:
> 
>> Hi All,
>> 
>> I am setting up a 2-node cloudstack environment.
>> 
>> Management Server :10.44.189.125
>> Host Server :  10.44.65.143
>> 
>> I am able to see the system VMs in running state.
>> But not able ping to outside network from system VMs.
>> 
>> I am not able to ping to corporate DNS or Google DNS from system VMs.
>> Also not able to ping gateway from system VMs.
>> 
>> Health Check :
>> root@s-20-VM:/usr/local/cloud/systemvm# ./ssvm-check.sh 
>> 
>> First DNS server is  8.8.8.8
>> PING 8.8.8.8 (8.8.8.8): 56 data bytes
>> 64 bytes from 10.44.188.14: Destination Host Unreachable
>> Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst Data
>> 4  5  00 5400    0 0040  40  01 5f64 10.44.188.14  8.8.8.8
>> 64 bytes from 10.44.188.14: Destination Host Unreachable
>> Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst Data
>> 4  5  00 5400    0 0040  40  01 5f64 10.44.188.14  8.8.8.8
>> --- 8.8.8.8 ping statistics ---
>> 2 packets transmitted, 0 packets received, 100% packet loss
>> WARNING: cannot ping DNS server
>> route follows
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric RefUse
>> Iface
>> 8.8.8.8 10.44.188.3 255.255.255.255 UGH   0  00
>> eth1
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth1
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth2
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth3
>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00
>> eth0
>> 0.0.0.0 10.44.188.3 0.0.0.0 UG0  00
>> eth2
>> 
>> ERROR: DNS not resolving download.cloud.com resolv.conf follows 
>> nameserver 8.8.8.8 nameserver 8.8.8.8 
>> root@s-20-VM:/usr/local/cloud/systemvm#
>> 
>> 
>> Route information on system VM :
>> 
>> root@s-20-VM:/usr/local/cloud/systemvm# route -n Kernel IP routing 
>> table
>> Destination Gateway Genmask Flags Metric RefUse
>> Iface
>> 8.8.8.8 10.44.188.3 255.255.255.255 UGH   0  00
>> eth1
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth1
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth2
>> 10.44.188.0 0.0.0.0 255.255.254.0   U 0  00
>> eth3
>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0  00
>> eth0
>> 0.0.0.0 10.44.188.3 0.0.0.0 UG0  00
>> eth2
>> root@s-20-VM:/usr/local/cloud/systemvm#
>> 
>> 
>> Please help me in getting out of this issue.
>> 
>> Thanks,
>> Jitendra
>> 
>> 
>> 
>> 
>> 
>> 
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which 
>> is the property of Persistent Systems Ltd. It is intended only for the 
>> use of the individual or entity to which it is addressed. If you are 
>> not the intended recipient, you are not authorized to read, retain, 
>> copy, print, distribute or use this message. If you have received this 
>> communication in error, please notify the sender and delete all copies of 
>> this message.
>> Persistent Systems Ltd. does not accept any liability for virus 
>> infected mails.
>> 
>> 
> 
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the 
> property of Persistent Systems Ltd. It is intended only for the use of the 
> individual or entity to which it is addressed. If you are not the intended 
> recipient, you are not authorized to read, retain, copy, print, distribute or 
> use this message. If you have received this communication in error, please 
> notify the sender and delete all copies of this message. Persistent Systems 
> Ltd. do

cherry pick commit to 4.3

[Jayapal Reddy Uradi]

Hi Animesh,

Please cherry pick the below commit to 4.3 from 4.3-forward.

e8f93f28fc424c73156723d9b65b13c05dafc5a8

Bug-id: CLOUDSTACK-6083

Thanks,
Jayapal

Re: [VOTE] Apache CloudStack 4.3.0 (fourth round) UPDATE

[Jayapal Reddy Uradi]

Hi Animesh,

I am able to reproduce the cidr issue.
I will commit the fix it in an hour.

Thanks,
Jayapal

On 13-Feb-2014, at 10:58 AM, Animesh Chaturvedi 
 wrote:

> 
> While the official 72 hours or rather 3 weekdays for this VOTE has passed and 
> we have required +1 (binding) votes following issues have been called out:
> 
> 1. CLOUDSTACK-6083 : Missing CIDRs in firewall rules after upgrade
> => Waiting on Jayapal to confirm and update the list with findings
> 2. CLOUDSTACK-6069: VPC with private gateway not working called out by Daan
> => No change was expected in this area, I am following up with some folks 
> (Murali, Kishan, Daan, Sudha) on if this is a setup specific issue or not. 
> Daan has a put a -1 but has indicated will continue to use 4.3 if VOTE passes
> 3. CLOUDSTACK-6065: KVM HA not working for shutdown VMs
> => While an issue but my understanding is it is a corner scenario only 
> affecting KVM and can be released  as a known issue
> 4. API compatibility broken
> => As per the discussion thread [4] and response from Devdeep and Min the 
> compatibility is not broken. So not an issue 
> 
> 
> 
> I would wait to  hear on 1) and 2)  before deciding moving on to release or 
> respin, folks associated with 1,2 please provide your inputs.
> 
> Counting the votes so far:
> +1: Marcus*, Animesh*, Edison*, Santhosh, Talluri, Amogh
> -1: Paul Angus, Nux, Alex Hitchins, Daan*
> 
> * indicated binding votes.
> 
> 
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-6083
> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-6069
> [3] https://issues.apache.org/jira/browse/CLOUDSTACK-6065 
> [4] http://markmail.org/message/xy3pwve7u52wgzmr  

Re: Missing cidrlist in 4.3 adv zone firewall

[Jayapal Reddy Uradi]

Hi Nux,

I found this issue in upgraded setup with external firewall srx.
I looking into this issue.

Thanks,
Jayapal

On 10/02/14 7:28 PM, "Nux!"  wrote:

>On 10.02.2014 13:28, Jayapal Reddy Uradi wrote:
>> Hi,
>> 
>> Cidr showing correctly in our setup.
>> Is cidr stored in   db table firewall_rules_cidrs ?
>
>Jayapal,
>
>I can see the CIDRs in that table.
>I also checked inside the VR and while iptables does have rules for the
>ports I mentioned, the CIDRs are missing, too.
>
>Do note this is an upgrade from 4.2.1.
>
>-- 
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro

Re: Missing cidrlist in 4.3 adv zone firewall

[Jayapal Reddy Uradi]

Hi,

Cidr showing correctly in our setup.
Is cidr stored in   db table firewall_rules_cidrs ?

Thanks,
Jayapal


On 10-Feb-2014, at 6:27 PM, Nux!  wrote:

> Hi,
> 
> It's the first time I'm testing firewall in 4.3 Advanced zone (without SG)  
> so please let me know if I'm missing something obvious; I notice the cidrlist 
> is missing from the rules, both in UI and in cloudmonkey.
> If I create the rule from cloudmoneky it also doesn't register a cidrlist, so 
> it doesn't seem to be UI's fault.
> This is what I see in the logs http://fpaste.org/75819/39203643/ when I 
> create a rule. Anyone else experiencing this?
> 
> 
> See http://img.nux.ro/3Kk-Selection_050.png
> 
> 
> mycloudmonkey > list firewallrules id=835dfc08-beab-458a-9c30-6b0b2b11f201
> count = 1
> firewallrule:
> id = 835dfc08-beab-458a-9c30-6b0b2b11f201
> cidrlist =
> endport = 65535
> ipaddress = 172.16.72.212
> ipaddressid = f481629a-deb6-4413-b253-e8e98d8a303a
> networkid = c615df7c-3ea3-4138-a83c-d848e20fe1f6
> protocol = tcp
> startport = 1
> state = Active
> tags:
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

[PROPOSAL] load balancing configuration for VM nic secondary ips

[Jayapal Reddy Uradi]

Hi,

Multiple ips per nic feature allows user to acquire more ip address on vm nic. 
On these ip addresses user able to configure PF and static NAT.

With this feature user can also configure the load balancing rules for vm 
secondary ips also.

Please review the below and give your comments.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuring+load+balancing+rules+for+VM+nic+secondary+ips

Ticket id:
CLOUDSTACK-2692


Thanks,
Jayapal

cherry pick commit to 4.3

[Jayapal Reddy Uradi]

Hi Animesh,

Please cherry pick the below commit from 4.3-forward to 4.3 branch.

commit 7a71cf33ce103392914ac51cd4689a6f5a340d0a
CLOUDSTACK-6040: Updated the ip addr validation in create port forwarding

Thanks,
Jayapal

Re: Port forwarding rule for secondary IP in Shared Network fails

[Jayapal Reddy Uradi]

Hi Gaurav,

This issue is showing in share networks ip ranges like 192.168.x.x.
To unblock with the issue try with ip range in 10.x.x.x.

This is bug.

Thanks,
Jayapal

On 06-Feb-2014, at 3:30 PM, Gaurav Aradhye 
 wrote:

> Hi all,
> 
> I have a VM deployed in shared network and I have added a secondary IP for
> the VM.
> Now when I acquire a public IP and try to create a NAT rule for the
> secondary IP of the VM using this public IP, the operation simply fails
> with error "Invalid vm ip address".
> 
> Management server log does not have any additional information than this
> single line [INFO\ message.
> 
> I have observed this on Vmware with CS - 4.3.0. The issue is reproducible
> through UI and through API also.
> 
> Please let me know if anyone has observed this issue before/ is it known? I
> will log a bug for this if not logged before.
> 
> Regards,
> Gaurav

Re: 4.3 commit cherry pick

[Jayapal Reddy Uradi]

Hi Animesh,

Please cherry pick the following commits from 4.3-forward to 4.3 branch.

7255e50f2051aff1cb5e1991e2dde4ef48f57454
888b90677623da745a01db0a5087272f0dabe42c

Thanks,
Jayapal
On 30-Jan-2014, at 2:36 PM, Jayapal Reddy  wrote:

> Hi Animesh,
> 
> Can you please cherry pick commit to 7255e50f2051aff1cb5e1991e2dde4ef48f57454 
> 4.3 branch 
> from 4.3-forward.
> 
> Thanks,
> Jayapal

4.3 commit cherry pick

[Jayapal Reddy Uradi]

Hi Animesh,

Can you please cherry pick commit to 7255e50f2051aff1cb5e1991e2dde4ef48f57454 
4.3 branch 
from 4.3-forward.

Thanks,
Jayapal

Re: [Doc] [4.3] Service Monitoring Tool for Virtual Router for Review [CLOUDSTACK-5292]

[Jayapal Reddy Uradi]

Hi Radhika,

The configuration is from the global settings.

Thanks,
Jayapal
On 29-Jan-2014, at 9:56 AM, Radhika Puthiyetath 
 wrote:

> We have the UI item coming up for this feature: 
> https://issues.apache.org/jira/browse/CLOUDSTACK-5966
> 
> 
> 
> -Original Message-
> From: Sanjeev Neelarapu [mailto:sanjeev.neelar...@citrix.com] 
> Sent: Tuesday, January 14, 2014 11:05 AM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: RE: [Doc] [4.3] Service Monitoring Tool for Virtual Router for 
> Review [CLOUDSTACK-5292]
> 
> Hi David,
> 
> As you said the tool runs in the background and is not exposed to the 
> administrator at-least in 4.3.
> 
> -Sanjeev
> 
> -Original Message-
> From: David Nalley [mailto:da...@gnsa.us] 
> Sent: Monday, January 13, 2014 7:59 PM
> To: us...@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [Doc] [4.3] Service Monitoring Tool for Virtual Router for 
> Review [CLOUDSTACK-5292]
> 
> Hi Radhika:
> 
> So I read this section and while the documentation is clear on what it does; 
> it's not clear on how I use it. If it isn't intended to be exposed to the 
> administrator and just runs in the background like so many things in 
> CloudStack does already, why document it at all in the admin guide? Why I 
> read that there is a monitoring tool it instantly makes me want to go check 
> status, so that I know that I can verify status if something goes awry.
> 
> --David
> 
> On Mon, Jan 13, 2014 at 1:02 AM, Radhika Puthiyetath 
>  wrote:
>> Hi,
>> 
>> 4.3 Documentation is getting ready to be reviewed. I have prepared the first 
>> draft for the feature, Enhanced Upgrade for Virtual Router.
>> 
>> Please see section 16.5.4. Service Monitoring Tool for Virtual Router, and 
>> let me know your feedback.
>> 
>> 1.The documentation is uploaded at 
>> https://issues.apache.org/jira/browse/ 
>> CLOUDSTACK-5292
>> 2.
>> 
>> Regards
>> -Radhika

Re: Useless egress in SG zone?

[Jayapal Reddy Uradi]

Hi Nux,


1. By default we are allowing egress in SG.
2. But when you configure any rule in egress, it allows ONLY configured rule 
traffic and other traffic will be BLOCKED.

If admin wants allow to only specific ports/addresses this can be done by 
configuring SG egress rules.

In my firewalls, the default egress is allow for trusted networks.

Thanks,
Jayapal

On 25-Jan-2014, at 6:58 AM, Nux!  wrote:

> On 25.01.2014 01:12, Marcus Sorensen wrote:
>> Are you talking about the rules that ensure an instance can't bring up and
>> use IP addresses that are not assigned to it?
> 
> I'm not sure. Here's a pic:
> http://img.nux.ro/jC4b-Selection_015.png
> 
> The anti-spoofing is working ok, supposedly, but I was expecting that either:
> 1 - egress is blocked by default, just like ingress, so just ports/addresses 
> specified there can be accessed
> 2 - less orthodox, but since we allow all outgoing by default for a VM then 
> make this is a blacklist instead of a whitelist, ie ports/addresses specified 
> here cannot be accessed
> 
> Do I make any sense?
> 
> Lucian
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: Review Request 14124: CLOUDSTACK-4622 : If a VM from guest network is added to network tier of VPC then IP reservation allows the CIDR to be a superset of Network CIDR for that VPC tier

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14124/#review32472
---


Can you please run marvin test cases of VPC with this patch and update the 
testing done section

- Jayapal Reddy


On Jan. 7, 2014, 11:58 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14124/
> ---
> 
> (Updated Jan. 7, 2014, 11:58 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-4622
> https://issues.apache.org/jira/browse/CLOUDSTACK-4622
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Add a new utility method for comparing 2 CIDRs.
> The method takes in 2 cidrs, cidrA and cidrB and returns true if cidrA's IP 
> range is equal or a subset of cidrB's IP range.
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/net/NetUtils.java 266a5d1 
>   utils/test/com/cloud/utils/net/NetUtilsTest.java b049516 
> 
> Diff: https://reviews.apache.org/r/14124/diff/
> 
> 
> Testing
> ---
> 
> Added unit test for the utility.
> Tested locally.
> Build is successful.
> Patch applies cleanly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re:[SOLVED] Weird IP address allocation in 4.3

[Jayapal Reddy Uradi]

+users

On 24-Jan-2014, at 2:38 AM, Ahmad Emneina  wrote:

> blasted vlans and the trunks they rhode in on! :) glad all is well.
> 
> 
> On Thu, Jan 23, 2014 at 10:45 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> I asked one of our IT guys to look into this. He determined a port was in
>> the wrong VLAN and that's how my VM got an IP address from a different DHCP
>> server.
>> 
>> No CloudStack issue here. :)
>> 
>> Thanks
>> 
>> 
>> On Wed, Jan 22, 2014 at 11:05 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>> 
>>> That is an interesting possibility. Thanks, guys
>>> 
>>> 
>>> On Wed, Jan 22, 2014 at 10:59 PM, Ahmad Emneina wrote:
>>> 
>>>> Mike, you might have another machine serving up DHCP on that network. If
>>>> thats the case get it to ignore cloudstack assigned mac addresses (06
>>>> prefix).
>>>> 
>>>> 
>>>> On Wed, Jan 22, 2014 at 9:53 PM, Mike Tutkowski <
>>>> mike.tutkow...@solidfire.com> wrote:
>>>> 
>>>>> Hi Jayapal,
>>>>> 
>>>>> That table has 8 rows and includes IP addresses from 192.168.128.23 to
>>>>> 192.168.128.30 (which should be correct).
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> 
>>>>> On Wed, Jan 22, 2014 at 10:49 PM, Jayapal Reddy Uradi <
>>>>> jayapalreddy.ur...@citrix.com> wrote:
>>>>> 
>>>>>> Hi Mike,
>>>>>> 
>>>>>> Can you please check the db table user_ip_address to see what are
>>>> the ips
>>>>>> addresses are there.
>>>>>> IP will be picked from this table.
>>>>>> 
>>>>>> Thanks,
>>>>>> Jayapal
>>>>>> 
>>>>>> On 23-Jan-2014, at 10:35 AM, Mike Tutkowski <
>>>>> mike.tutkow...@solidfire.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Slight correction (this may have been obvious from one of my screen
>>>>>> shots):
>>>>>>> The VM with the address outside of the range I gave to CloudStack
>>>> is
>>>>> in a
>>>>>>> XenServer cluster.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Jan 22, 2014 at 10:03 PM, Mike Tutkowski <
>>>>>>> mike.tutkow...@solidfire.com> wrote:
>>>>>>> 
>>>>>>>> The IP address that CloudStack says is assigned to VM i-2-11-VM
>>>>>>>> (192.168.128.28) does not appear to be assigned to any VM in the
>>>>> system
>>>>>>>> (user or system VM).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Jan 22, 2014 at 9:59 PM, Mike Tutkowski <
>>>>>>>> mike.tutkow...@solidfire.com> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> I was wondering if someone who deals with networking in
>>>> CloudStack
>>>>>> might
>>>>>>>>> know something about this.
>>>>>>>>> 
>>>>>>>>> I have a development setup with one zone, one pod, and three
>>>> clusters
>>>>>>>>> (one VMware, one XenServer, and one KVM).
>>>>>>>>> 
>>>>>>>>> The IP addresses I've given to CloudStack span from
>>>> 192.168.128.20 to
>>>>>>>>> 192.168.128.30 (just 11 addresses).
>>>>>>>>> 
>>>>>>>>> http://i.imgur.com/3SAn98W.png
>>>>>>>>> 
>>>>>>>>> http://i.imgur.com/cZ1pLun.png
>>>>>>>>> Somehow one of my VMs was assigned the IP address 192.168.128.118
>>>>>>>>> (outside of the range above).
>>>>>>>>> 
>>>>>>>>> http://imgur.com/TeRMEf9
>>>>>>>>> The zone is using basic networking.
>>>>>>>>> 
>>>>>>>>> The issue is in my VMware cluster (two hosts in this cluster).
>>>>>>>>> 
>>>>>>>>> Thanks!
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> *Mike Tutkowski*
>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>>>> e: mike.tutkow...@solidfire.com
>>>>>>>>> o: 303.746.7302
>>>>>>>>> Advancing the way the world uses the cloud<
>>>>>> http://solidfire.com/solution/overview/?video=play>
>>>>>>>>> *™*
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> *Mike Tutkowski*
>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>>> e: mike.tutkow...@solidfire.com
>>>>>>>> o: 303.746.7302
>>>>>>>> Advancing the way the world uses the cloud<
>>>>>> http://solidfire.com/solution/overview/?video=play>
>>>>>>>> *™*
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> *Mike Tutkowski*
>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>> e: mike.tutkow...@solidfire.com
>>>>>>> o: 303.746.7302
>>>>>>> Advancing the way the world uses the
>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>>> *™*
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> *Mike Tutkowski*
>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>> e: mike.tutkow...@solidfire.com
>>>>> o: 303.746.7302
>>>>> Advancing the way the world uses the
>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>> *™*
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the 
>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>> *™*
>>> 
>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the 
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *™*
>> 

Re: Review Request 17231: review request for master of defect CLOUDSTACJ-2031

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17231/#review32615
---

Ship it!


Ship It!

- Jayapal Reddy


On Jan. 23, 2014, 12:10 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17231/
> ---
> 
> (Updated Jan. 23, 2014, 12:10 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is for master branch of the review request 
> https://reviews.apache.org/r/16780/
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> c0e8d3e 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDao.java 9fbfa27 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDaoImpl.java 2f3cc29 
>   server/src/com/cloud/configuration/Config.java 9117bc4 
>   server/src/com/cloud/network/NetworkServiceImpl.java 056190f 
>   setup/db/db/schema-430to440.sql 1b6a9ab 
> 
> Diff: https://reviews.apache.org/r/17231/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 17231: review request for master of defect CLOUDSTACJ-2031

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/17231/#review32603
---



setup/db/db/schema-421to430.sql
<https://reviews.apache.org/r/17231/#comment61513>

Please move this changes to schema-43to44.sql


- Jayapal Reddy


On Jan. 23, 2014, 7:18 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17231/
> ---
> 
> (Updated Jan. 23, 2014, 7:18 a.m.)
> 
> 
> Review request for cloudstack and Jayapal Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is for master branch of the review request 
> https://reviews.apache.org/r/16780/
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> c0e8d3e 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDao.java 9fbfa27 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDaoImpl.java 2f3cc29 
>   server/src/com/cloud/configuration/Config.java 9117bc4 
>   server/src/com/cloud/network/NetworkServiceImpl.java 056190f 
>   setup/db/db/schema-421to430.sql ccff7c1 
> 
> Diff: https://reviews.apache.org/r/17231/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: SSH to VM via default network failing

[Jayapal Reddy Uradi]

Hi Ashutosh,

1. Check the router public interface is configured with the acquired public ip
2. Check the rules specific to FW/PF are configured correctly on VR.
3. If 1,2 are correct try to debug the traffic by capturing the packets on 
router and vm
4. If the packets reached to router and then VM, there could be issue in return 
traffic path.
5. If the packets reached router but not VM, issue with the router iptables 
rules


Thanks,
Jayapal

On 23-Jan-2014, at 2:38 PM, Ashutosh Kelkar  wrote:

> Hi,
> 
> I have a VM deployed in two isolated networks. I am doing following things
> with each network.
> 
> 1) Acquire public IP
> 2) Open firewall for this IP
> 3) Create port forwarding rule using this IP for the above mentioned VM
> 
> Now when I try to SSH to VM using these 2 IPs, SSH via IP belonging to
> non-default network succeeds but through the IP belonging to default
> network fails.
> 
> Can someone throw some light on why would this be happening? Shouldn't it
> work for both the IPs?
> 
> -- 
> Regards,
> Ashutosh

Re: Weird IP address allocation in 4.3

[Jayapal Reddy Uradi]

Hi Mike,

Can you please check the db table user_ip_address to see what are the ips 
addresses are there.
IP will be picked from this table.

Thanks,
Jayapal

On 23-Jan-2014, at 10:35 AM, Mike Tutkowski  
wrote:

> Slight correction (this may have been obvious from one of my screen shots):
> The VM with the address outside of the range I gave to CloudStack is in a
> XenServer cluster.
> 
> 
> On Wed, Jan 22, 2014 at 10:03 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> The IP address that CloudStack says is assigned to VM i-2-11-VM
>> (192.168.128.28) does not appear to be assigned to any VM in the system
>> (user or system VM).
>> 
>> 
>> On Wed, Jan 22, 2014 at 9:59 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>> 
>>> Hi,
>>> 
>>> I was wondering if someone who deals with networking in CloudStack might
>>> know something about this.
>>> 
>>> I have a development setup with one zone, one pod, and three clusters
>>> (one VMware, one XenServer, and one KVM).
>>> 
>>> The IP addresses I've given to CloudStack span from 192.168.128.20 to
>>> 192.168.128.30 (just 11 addresses).
>>> 
>>> http://i.imgur.com/3SAn98W.png
>>> 
>>> http://i.imgur.com/cZ1pLun.png
>>> Somehow one of my VMs was assigned the IP address 192.168.128.118
>>> (outside of the range above).
>>> 
>>> http://imgur.com/TeRMEf9
>>> The zone is using basic networking.
>>> 
>>> The issue is in my VMware cluster (two hosts in this cluster).
>>> 
>>> Thanks!
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the 
>>> cloud
>>> *™*
>>> 
>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the 
>> cloud
>> *™*
>> 
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: DHCP entry fails to apply on the latest master

[Jayapal Reddy Uradi]

+users

When ever we see the error 'Unable to contact resource', I suggest to check the 
host agent logs (for xen /var/log/SMlog).
It will give you idea of what is going wrong from the router. Most of times 
there could be script execution failures.

Adding command to clean up tags on xenserver
xe host-param-clear param-name=tags uuid=[uuid]

-Jayapal

On 22-Jan-2014, at 12:49 AM, Alena Prokharchyk  
wrote:

> To fix it, you should cleanup the tags on your xen host, so the MS will
> copy the newest ISO there.
> 
> Sheng, thank you for helping to debug it.
> 
> -Alena.
> 
> On 1/21/14, 11:09 AM, "Nitin Mehta"  wrote:
> 
>> I also face this issue. Here is the snippet of logs. Please let me know if
>> you need any other info.
>> 
>> 2014-01-21 10:52:46,909 INFO  [c.c.v.VirtualMachineManagerImpl]
>> (Job-Executor-1:ctx-57a7ba8c ctx-933fbba1) Unable to contact resource.
>> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1]
>> is unreachable: Unable to apply dhcp entry on router
>>   at 
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(Vir
>> t
>> ualNetworkApplianceManagerImpl.java:3826)
>>   at 
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry
>> (
>> VirtualNetworkApplianceManagerImpl.java:2956)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
>> 3
>> 9)
>>   at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
>> p
>> l.java:25)
>>   at java.lang.reflect.Method.invoke(Method.java:597)
>> 
>> 
>> 
>> 
>> 
>> 
>> On 21/01/14 11:01 AM, "Alena Prokharchyk" 
>> wrote:
>> 
>>> I¹ve deployed the latest master code, re-deployed the DB and uploaded new
>>> system templates with 4.3 version. After that, UserVm fails to start
>>> because DHCP entry fails to apply on the VR.
>>> Its a xen host deployment, and I¹ve tested that ssh to the VR works just
>>> fine. Sheng, can you please take a look? It happened on a couple of
>>> setups.
>>> 
>>> -Alena.
>> 
> 

Re: SSH issue in SG enabled advanced zone

[Jayapal Reddy Uradi]

It is ebtables in previous mail, ebtables  is auto corrected by my mail client 
:)

On 21-Jan-2014, at 11:37 AM, Jayapal Reddy Uradi 
 wrote:

> Hi Gaurav,
> 
> Network mode should be bridge for SG rules work.
> 
> Some of security group rules (iptables rules) are configured match the 
> traffic in/out from the bridge.
> Also eatables rules needs bridge.
> 
> Cloudstack Basic and Advanced needs bridge mode for SG networks.
> 
> Thanks,
> Jayapal
> 
> 1.
> On 20-Jan-2014, at 3:55 PM, Gaurav Aradhye  wrote:
> 
>> Hi Jayapal,
>> 
>> CSP is installed but the network mode is set to openvswitch. Should it be
>> "bridge"?
>> 
>> Here are few doubts.
>> 
>> 1) Does Security Group feature always requires network mode set to bridge
>> irrespective of basic or advanced zone setup?
>> 
>> 2) In what scenarios we will need it to be openvswitch / bridge? And why
>> exactly? I reckon openvswitch has more features than the basic bridge
>> networking mode.
>> 
>> 
>> Regards,
>> Gaurav
>> 
>> 
>> On Mon, Jan 20, 2014 at 2:18 PM, Jayapal Reddy Uradi <
>> jayapalreddy.ur...@citrix.com> wrote:
>> 
>>> Hi Gaurav,
>>> 
>>> Did you install CSP in xenserver ?
>>> Is host network mode set to bridge ?
>>> check file /etc/xensource/network.conf for 'bridge'
>>> 
>>> From the host iptables, there are no SG rules got configured.
>>> 
>>> Thanks,
>>> Jayapal
>>> 
>>> 
>>> 
>>> 
>>> On 20-Jan-2014, at 12:27 PM, Gaurav Aradhye 
>>> wrote:
>>> 
>>>> Hello all,
>>>> 
>>>> I am facing issue while SSHing to VM in security groups enabled advanced
>>>> zone (XenServer host) even after applying the ingress rule for the
>>> security
>>>> group in which VM is deployed.
>>>> 
>>>> Also, even if I can see the ingress rule being applied through API
>>> listing
>>>> and on UI, I can't see the iptables on host being updated after
>>>> adding/removing ingress rule.
>>>> 
>>>> Is there any existing problem with XenServer regarding this? I read on
>>> few
>>>> blogs about some people encountering similar issue with Xenserver. I have
>>>> not yet tried on KVM.
>>>> 
>>>> The output of command "iptables -L -v -n" on host is as following.
>>>> 
>>>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>>>> pkts bytes target prot opt in out source
>>>> destination
>>>>  0 0 ACCEPT 47   --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>> 109M  110G RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>> 
>>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>>> pkts bytes target prot opt in out source
>>>> destination
>>>>  0 0 RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>> 
>>>> Chain OUTPUT (policy ACCEPT 91M packets, 149G bytes)
>>>> pkts bytes target prot opt in out source
>>>> destination
>>>> 
>>>> Chain RH-Firewall-1-INPUT (2 references)
>>>> pkts bytes target prot opt in out source
>>>> destination
>>>> 54M   76G ACCEPT all  --  lo *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>> 8430  520K ACCEPT icmp --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   icmp type 255
>>>>  0 0 ACCEPT esp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>>  0 0 ACCEPT ah   --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0
>>>>  0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>>> 224.0.0.251 udp dpt:5353
>>>>  0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   udp dpt:631
>>>>  0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   tcp dpt:631
>>>>  0 0 ACCEPT udp  --  xenapi *   0.0.0.0/0
>>>> 0.0.0.0/0   udp dpt:67
>>>> 47M   32G ACCEPT all  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   state RELATED,ESTABLISHED
>>>>  0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   state NEW udp dpt:694
>>>> 19  1132 ACCEPT tcp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   state NEW tcp dpt:22
>>>> 3919  204K ACCEPT tcp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   state NEW tcp dpt:80
>>>> 346K   21M ACCEPT tcp  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   state NEW tcp dpt:443
>>>> 7721K 1583M REJECT all  --  *  *   0.0.0.0/0
>>>> 0.0.0.0/0   reject-with icmp-host-prohibited
>>>> 
>>>> 
>>>> Any directions?
>>>> 
>>>> Regards,
>>>> Gaurav
>>> 
>>> 
> 

Re: SSH issue in SG enabled advanced zone

[Jayapal Reddy Uradi]

Hi Gaurav,

Network mode should be bridge for SG rules work.

Some of security group rules (iptables rules) are configured match the traffic 
in/out from the bridge.
Also eatables rules needs bridge.

Cloudstack Basic and Advanced needs bridge mode for SG networks.

Thanks,
Jayapal

1.
On 20-Jan-2014, at 3:55 PM, Gaurav Aradhye  wrote:

> Hi Jayapal,
> 
> CSP is installed but the network mode is set to openvswitch. Should it be
> "bridge"?
> 
> Here are few doubts.
> 
> 1) Does Security Group feature always requires network mode set to bridge
> irrespective of basic or advanced zone setup?
> 
> 2) In what scenarios we will need it to be openvswitch / bridge? And why
> exactly? I reckon openvswitch has more features than the basic bridge
> networking mode.
> 
> 
> Regards,
> Gaurav
> 
> 
> On Mon, Jan 20, 2014 at 2:18 PM, Jayapal Reddy Uradi <
> jayapalreddy.ur...@citrix.com> wrote:
> 
>> Hi Gaurav,
>> 
>> Did you install CSP in xenserver ?
>> Is host network mode set to bridge ?
>> check file /etc/xensource/network.conf for 'bridge'
>> 
>> From the host iptables, there are no SG rules got configured.
>> 
>> Thanks,
>> Jayapal
>> 
>> 
>> 
>> 
>> On 20-Jan-2014, at 12:27 PM, Gaurav Aradhye 
>> wrote:
>> 
>>> Hello all,
>>> 
>>> I am facing issue while SSHing to VM in security groups enabled advanced
>>> zone (XenServer host) even after applying the ingress rule for the
>> security
>>> group in which VM is deployed.
>>> 
>>> Also, even if I can see the ingress rule being applied through API
>> listing
>>> and on UI, I can't see the iptables on host being updated after
>>> adding/removing ingress rule.
>>> 
>>> Is there any existing problem with XenServer regarding this? I read on
>> few
>>> blogs about some people encountering similar issue with Xenserver. I have
>>> not yet tried on KVM.
>>> 
>>> The output of command "iptables -L -v -n" on host is as following.
>>> 
>>> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>>>   0 0 ACCEPT 47   --  *  *   0.0.0.0/0
>>> 0.0.0.0/0
>>> 109M  110G RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>>>  0.0.0.0/0
>>> 
>>> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>>>   0 0 RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>>>  0.0.0.0/0
>>> 
>>> Chain OUTPUT (policy ACCEPT 91M packets, 149G bytes)
>>> pkts bytes target prot opt in out source
>>> destination
>>> 
>>> Chain RH-Firewall-1-INPUT (2 references)
>>> pkts bytes target prot opt in out source
>>> destination
>>> 54M   76G ACCEPT all  --  lo *   0.0.0.0/0
>>> 0.0.0.0/0
>>> 8430  520K ACCEPT icmp --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   icmp type 255
>>>   0 0 ACCEPT esp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0
>>>   0 0 ACCEPT ah   --  *  *   0.0.0.0/0
>>> 0.0.0.0/0
>>>   0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>> 224.0.0.251 udp dpt:5353
>>>   0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   udp dpt:631
>>>   0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   tcp dpt:631
>>>   0 0 ACCEPT udp  --  xenapi *   0.0.0.0/0
>>> 0.0.0.0/0   udp dpt:67
>>> 47M   32G ACCEPT all  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state RELATED,ESTABLISHED
>>>   0 0 ACCEPT udp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state NEW udp dpt:694
>>>  19  1132 ACCEPT tcp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state NEW tcp dpt:22
>>> 3919  204K ACCEPT tcp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state NEW tcp dpt:80
>>> 346K   21M ACCEPT tcp  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   state NEW tcp dpt:443
>>> 7721K 1583M REJECT all  --  *  *   0.0.0.0/0
>>> 0.0.0.0/0   reject-with icmp-host-prohibited
>>> 
>>> 
>>> Any directions?
>>> 
>>> Regards,
>>> Gaurav
>> 
>> 

Re: SSH issue in SG enabled advanced zone

[Jayapal Reddy Uradi]

Hi Gaurav,

Did you install CSP in xenserver ?
Is host network mode set to bridge ?
check file /etc/xensource/network.conf for 'bridge'

>From the host iptables, there are no SG rules got configured.

Thanks,
Jayapal




On 20-Jan-2014, at 12:27 PM, Gaurav Aradhye  wrote:

> Hello all,
> 
> I am facing issue while SSHing to VM in security groups enabled advanced
> zone (XenServer host) even after applying the ingress rule for the security
> group in which VM is deployed.
> 
> Also, even if I can see the ingress rule being applied through API listing
> and on UI, I can't see the iptables on host being updated after
> adding/removing ingress rule.
> 
> Is there any existing problem with XenServer regarding this? I read on few
> blogs about some people encountering similar issue with Xenserver. I have
> not yet tried on KVM.
> 
> The output of command "iptables -L -v -n" on host is as following.
> 
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>0 0 ACCEPT 47   --  *  *   0.0.0.0/0
> 0.0.0.0/0
> 109M  110G RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>   0.0.0.0/0
> 
> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target prot opt in out source
> destination
>0 0 RH-Firewall-1-INPUT  all  --  *  *   0.0.0.0/0
>   0.0.0.0/0
> 
> Chain OUTPUT (policy ACCEPT 91M packets, 149G bytes)
> pkts bytes target prot opt in out source
> destination
> 
> Chain RH-Firewall-1-INPUT (2 references)
> pkts bytes target prot opt in out source
> destination
>  54M   76G ACCEPT all  --  lo *   0.0.0.0/0
> 0.0.0.0/0
> 8430  520K ACCEPT icmp --  *  *   0.0.0.0/0
> 0.0.0.0/0   icmp type 255
>0 0 ACCEPT esp  --  *  *   0.0.0.0/0
> 0.0.0.0/0
>0 0 ACCEPT ah   --  *  *   0.0.0.0/0
> 0.0.0.0/0
>0 0 ACCEPT udp  --  *  *   0.0.0.0/0
> 224.0.0.251 udp dpt:5353
>0 0 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   udp dpt:631
>0 0 ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   tcp dpt:631
>0 0 ACCEPT udp  --  xenapi *   0.0.0.0/0
> 0.0.0.0/0   udp dpt:67
>  47M   32G ACCEPT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state RELATED,ESTABLISHED
>0 0 ACCEPT udp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state NEW udp dpt:694
>   19  1132 ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state NEW tcp dpt:22
> 3919  204K ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state NEW tcp dpt:80
> 346K   21M ACCEPT tcp  --  *  *   0.0.0.0/0
> 0.0.0.0/0   state NEW tcp dpt:443
> 7721K 1583M REJECT all  --  *  *   0.0.0.0/0
> 0.0.0.0/0   reject-with icmp-host-prohibited
> 
> 
> Any directions?
> 
> Regards,
> Gaurav

Re: Review Request 16780: Added new Configuration parameter to configuration table and checked for max value reached or not before acquiring an IP in a nic

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16780/#review32280
---



engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDaoImpl.java
<https://reviews.apache.org/r/16780/#comment61011>

please remove white space here



server/src/com/cloud/network/NetworkServiceImpl.java
<https://reviews.apache.org/r/16780/#comment61012>

Remove white space here


- Jayapal Reddy


On Jan. 10, 2014, 12:31 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16780/
> ---
> 
> (Updated Jan. 10, 2014, 12:31 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-2031
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> support for number of ips per nic limit needs to be added for the multiple ip 
> address per nic
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/user/vm/AddIpToVmNicCmd.java 
> b5e2239 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDao.java da96df4 
>   engine/schema/src/com/cloud/vm/dao/NicSecondaryIpDaoImpl.java 3befaf7 
>   server/src/com/cloud/configuration/Config.java d2713c0 
>   server/src/com/cloud/network/NetworkServiceImpl.java 11313d5 
>   setup/db/db/schema-421to430.sql c1f9780 
> 
> Diff: https://reviews.apache.org/r/16780/diff/
> 
> 
> Testing
> ---
> 
> Tested the same by changing default value from 256 to 2.
> Also tested the new acquire of ip if number if IPs are less than in that nic 
> than the max limit
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: [ANNOUNCE] New Committer: Sanjay Tripathi

[Jayapal Reddy Uradi]

Congrats Sanjay!

On 10-Jan-2014, at 4:23 AM, David Nalley  wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked
> Sanjay Tripathi to become a committer and we are pleased to announce
> that they have
> accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Sanjay!
> 
> --David,
> on behalf of the Apache CloudStack PMC

Re: Review Request 14124: CLOUDSTACK-4622 : If a VM from guest network is added to network tier of VPC then IP reservation allows the CIDR to be a superset of Network CIDR for that VPC tier

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14124/#review30865
---

Ship it!


Ship It!

- Jayapal Reddy


On Dec. 24, 2013, 9:20 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14124/
> ---
> 
> (Updated Dec. 24, 2013, 9:20 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy and Sateesh Chodapuneedi.
> 
> 
> Bugs: CLOUDSTACK-4622
> https://issues.apache.org/jira/browse/CLOUDSTACK-4622
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Add a new utility method for comparing 2 CIDRs.
> The method takes in 2 cidrs, cidrA and cidrB and returns true if cidrA's IP 
> range is equal or a subset of cidrB's IP range.
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/net/NetUtils.java f6f6285 
>   utils/test/com/cloud/utils/net/NetUtilsTest.java c7407bf 
> 
> Diff: https://reviews.apache.org/r/14124/diff/
> 
> 
> Testing
> ---
> 
> Added unit test for the utility.
> Tested locally.
> Build is successful.
> Patch applies cleanly.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Faulty method isNetworkAWithinNetworkB ?

[Jayapal Reddy Uradi]

Hi Saksham,

Always the higher suffix cidr will be in lower suffix cidr.
10.1.1.0/24 will have 256 addresses and 10.1.1.0/25 will have 128 addresses[1].

/25 will be completely in /24 but not wise versa. 

The below are incorrect.
> isNetworkAWithinNetworkB("10.1.1.0/24", "10.1.1.0/25") returns true
> isNetworkAWithinNetworkB("10.1.1.0/22", "10.1.1.0/23") returns true

I think you can change isNetworkAWithinNetworkB method to compare respective ip 
ranges for cidrs.

What about changing method name isNetworkACompletelyWithinNetworkB() ?

[1]https://www.dan.me.uk/ipsubnets?ip=10.1.1.0


Thanks,
Jayapal

On 13-Dec-2013, at 4:49 PM, Saksham Srivastava  
wrote:

> Hi,
> 
> I encountered a method isNetworkAWithinNetworkB(cidrA, cidrB) in 
> NetUtils.java which should return true if cidrA is a subset of cidrB.
> The method returns flawed output in many scenarios. After unittesting it I 
> found :
> 
> isNetworkAWithinNetworkB("10.1.1.0/24", "10.1.1.0/25") returns true
> isNetworkAWithinNetworkB("10.1.1.0/25", "10.1.1.0/24") returns true
> isNetworkAWithinNetworkB("10.1.1.0/23", "10.1.1.0/22") returns true
> isNetworkAWithinNetworkB("10.1.1.0/22", "10.1.1.0/23") returns true
> 
> Due to this I am able to create VPC tiers with cidr 10.1.0.0/24 even when the 
> VPC super cidr has been defined as 10.1.1.0/25
> IMO the simpler/cleaner way to compare cidrs should be to compare the 
> respective IP ranges. I have an old patch [1] in RB which uses the IP ranges 
> to compare 2 cidrs.
> We could leverage that to replace isNetworkAWithinNetworkB() or in case of 
> any other suggestions please share.
> 
> Thanks,
> Saksham
> 
> [1] https://reviews.apache.org/r/14124/diff/#index_header
> 

Re:{SOLVED} Problem with vhd-util?

[Jayapal Reddy Uradi]

Added users list and solved tag.

On 19-Dec-2013, at 12:43 AM, Mike Tutkowski  
wrote:

> That was the problem.
> 
> Thanks for the reminder! :)
> 
> 
> On Wed, Dec 18, 2013 at 12:05 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
> 
>> Hi Nitin,
>> 
>> Yes, on my normal build machine I do keep it in that location.
>> 
>> I just noticed, however, that I do not have it there on my lab machine
>> that's running the management server.
>> 
>> I think that's the problem.
>> 
>> Thanks! :)
>> 
>> 
>> On Wed, Dec 18, 2013 at 11:57 AM, Nitin Mehta wrote:
>> 
>>> Vhd-util location has recently changed on XS from /opt/xensource/bin to
>>> /opt/cloud/bin.
>>> Do you keep it to this location in the source tree:
>>> scripts/vm/hypervisor/xenserver/vhd-util ?
>>> 
>>> Thanks,
>>> -Nitin
>>> 
>>> On 18/12/13 10:51 AM, "Mike Tutkowski" 
>>> wrote:
>>> 
 Hi,
 
 I am working with a new XenServer host in my CS environment (testing 4.3)
 this morning and having trouble getting system VMs to start up.
 
 The Xen agent says it, "can not create vdi in sr ."
 
 The stack trace indicates the
 XenServerStorageProcessor.copy_vhd_from_secondarystorage method is where
 the problem is happening.
 
 Any thoughts on this? Could this be a vhd-util problem?
 
 Thanks!
 
 --
 *Mike Tutkowski*
 *Senior CloudStack Developer, SolidFire Inc.*
 e: mike.tutkow...@solidfire.com
 o: 303.746.7302
 Advancing the way the world uses the
 cloud
 * *
>>> 
>>> 
>> 
>> 
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the 
>> cloud
>> *™*
>> 
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Re: Review Request 16319: CLOUDSTACK-5507: Unable to add XenServer 5.6 host to cloudstack

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16319/#review30605
---

Ship it!


Ship It!

- Jayapal Reddy


On Dec. 17, 2013, 9:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16319/
> ---
> 
> (Updated Dec. 17, 2013, 9:19 a.m.)
> 
> 
> Review request for cloudstack and Jayapal Reddy.
> 
> 
> Bugs: CLOUDSTACK-5507
> https://issues.apache.org/jira/browse/CLOUDSTACK-5507
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5507: Unable to add XenServer 5.6 host to cloudstack
> 
> Fixed "ImportError: No module named cloudstack_pluginlib" on Xenserver 5.6
> 
> 
> Diffs
> -
> 
>   scripts/vm/hypervisor/xenserver/xenserver56/patch 4180b6e 
>   scripts/vm/hypervisor/xenserver/xenserver56fp1/patch 4a95048 
> 
> Diff: https://reviews.apache.org/r/16319/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: test failures

[Jayapal Reddy Uradi]

Hi,

I have the similar issue.
It got fixed for me after creating /etc/cloudstack/management/key with content 
password.

Thanks,
Jayapal

On 05-Dec-2013, at 3:15 AM, Alena Prokharchyk  
wrote:

> Laszlo, here is the error:
> 
> Tests run: 28, Failures: 0, Errors: 26, Skipped: 2, Time elapsed: 0.825 sec 
> <<< FAILURE!
> getColumnName(com.cloud.utils.DbUtilTest)  Time elapsed: 0.293 sec  <<< ERROR!
> java.lang.ExceptionInInitializerError
>at sun.misc.Unsafe.ensureClassInitialized(Native Method)
>at 
> sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
> ………..
> 
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
>at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: com.cloud.utils.exception.CloudRuntimeException: File containing 
> secret key not found: /etc/cloudstack/management/key
>at 
> com.cloud.utils.crypt.EncryptionSecretKeyChecker.check(EncryptionSecretKeyChecker.java:88)
>at 
> com.cloud.utils.db.DbProperties.getDbProperties(DbProperties.java:79)
>at 
> com.cloud.utils.db.TransactionLegacy.(TransactionLegacy.java:1024)
>... 39 more
> Caused by: java.io.FileNotFoundException: /etc/cloudstack/management/key (No 
> such file or directory)
>at java.io.FileInputStream.open(Native Method)
>at java.io.FileInputStream.(FileInputStream.java:120)
>at java.io.FileReader.(FileReader.java:55)
>at 
> com.cloud.utils.crypt.EncryptionSecretKeyChecker.check(EncryptionSecretKeyChecker.java:84)
>... 41 more
> getColumnName(com.cloud.utils.DbUtilTest)  Time elapsed: 0.294 sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class 
> com.cloud.utils.db.TransactionLegacy
>at sun.misc.Unsafe.ensureClassInitialized(Native Method)
> 
> From: Laszlo Hornyak 
> mailto:laszlo.horn...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Date: Wednesday, December 4, 2013 1:34 PM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: Re: test failures
> 
> Hi,
> 
> I wrote those tests a few weeks ago, it may be my mistake. It works for me
> after git rebase. Could you send me a full log from the build + testcase
> output txt/xml file?
> 
> Thank you,
> Laszlo
> 
> 
> On Wed, Dec 4, 2013 at 2:07 AM, Min Chen 
> mailto:min.c...@citrix.com>> wrote:
> 
> I am encountering the same.
> 
> Thanks
> -min
> 
> On 12/3/13 4:41 PM, "Alena Prokharchyk" 
> mailto:alena.prokharc...@citrix.com>>
> wrote:
> 
>> Does anybody experience this test failure on the latest master?
>> 
>> Results :
>> 
>> Tests in error:
>> getColumnName(com.cloud.utils.DbUtilTest)
>> getColumnName(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> isPersistable(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> isPersistable(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> getTableName(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> getTableName(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> getGlobalLock(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> getGlobalLockTimeout(com.cloud.utils.DbUtilTest): Could not initialize
>> class com.cloud.utils.db.TransactionLegacy
>> getGlobalLockTimeout(com.cloud.utils.DbUtilTest): Could not initialize
>> class com.cloud.utils.db.TransactionLegacy
>> closeNull(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> closeNull(com.cloud.utils.DbUtilTest): Could not initialize class
>> com.cloud.utils.db.TransactionLegacy
>> 
> 
> 
> 
> 
> --
> 
> EOF
> 

Re: Review Request 16122: CLOUDSTACK-4498 cherry picked from 4.2

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16122/#review30183
---

Ship it!


Ship It!

- Jayapal Reddy


On Dec. 11, 2013, 5:45 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16122/
> ---
> 
> (Updated Dec. 11, 2013, 5:45 a.m.)
> 
> 
> Review request for cloudstack and Jayapal Reddy.
> 
> 
> Bugs: CLOUDSTACK-4498
> https://issues.apache.org/jira/browse/CLOUDSTACK-4498
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
>  CLOUDSTACK-4498 we should not reserve memory and cpu for vmware VMs if the 
> vmware.reserve.cpu and vmware.reserve.mem are set to false.
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
> 081c651 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
>  066a395 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  e34d5e1 
> 
> Diff: https://reviews.apache.org/r/16122/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: New Committer: Sanjeev Neelarapu

[Jayapal Reddy Uradi]

Congrats Sanjeev!

On 14-Nov-2013, at 11:42 AM, Bharat Kumar 
 wrote:

> Congratulations Sanjeev.
> 
> On 14-Nov-2013, at 11:38 am, Sailaja Mada  wrote:
> 
>> Congratulations Sanjeev.
>> 
>> Regards,
>> Sailaja.M
>> 
>> -Original Message-
>> From: Prasanna Santhanam [mailto:t...@apache.org] 
>> Sent: 14 November 2013 11:30
>> To: CloudStack Dev
>> Subject: New Committer: Sanjeev Neelarapu
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked 
>> Sanjeev Neelarapu to become a committer and we are pleased to announce that 
>> they have accepted.
>> 
>> Being a committer allows many contributors to contribute more autonomously. 
>> For developers, it makes it easier to submit changes and eliminates the need 
>> to have contributions reviewed via the patch submission process. Whether 
>> contributions are development-related or otherwise, it is a recognition of a 
>> contributor's participation in the project and commitment to the project and 
>> the Apache Way.
>> 
>> Please join me in congratulating Sanjeev!
>> 
>> --
>> Prasanna.,
>> on behalf of the Apache CloudStack PMC
>> 
>> 
>> Powered by BigRock.com
>> 
> 

Re: [PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

 mgmt server responds with a URL 
> for an install script - VR runs that to download/setup appropriate monitoring 
> agent
> 3) VR has standardized scripts for agent to call to find out what should be 
> running, and then agent can go check for itself.
> 
> With a setup like this, you can support SNMP, Opsview/Nagios, Monit, NSA, 
> Zenoss, HPOV, Tivoli, etc etc etc. I'll happily write the Opsview/Nagios 
> module (I'm thinking module is hosted outside ACS, but I guess it could be a 
> plugin - see earlier licensing points).
> 
> Thoughts?
> 
> Just my 2c. Happy to tweak wiki if folks lean towards this.
> 
> John
> 1: Aside - this applies to SSVM creation currently - that hamster[2] keeps 
> trying to spin that create SSVM wheel..
> 2: Apache CloudHamster, CloudMonkey's furry monitoring friend?
> 
> On Nov 6, 2013, at 7:58 AM, Jayapal Reddy Uradi 
>  wrote:
> 
>> Please find below update FS
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Monitoring+VR+s
>> ervices
>> 
>> Thanks,
>> Jayapal
>> 
>> On 05-Oct-2013, at 6:54 PM, Santhosh Edukulla  
>> wrote:
>> 
>>> A shell script can be used. Few thoughts below:
>>> 
>>> 1. Collect the process id of all daemons you wanted to monitor using 
>>> "pidof" of command and then use "kill" command to check if the pid you got 
>>> is valid. Using kill we can send a signal 0, then check the status using 
>>> echo $? . For sending a notification use linux syslog call ( man 3 syslogd) 
>>> or "logger" command to send to syslog. If wanted to send email then you may 
>>> also have to look for firewall not allowing outbound smtp port 
>>> communiation. Even for snmp this holds same( i mean if any blocking through 
>>> firewall rules ).  Using syslog may be good as it by default exposes 
>>> various debug log levels through its api call.
>>> 
>>> Now, to keep the monitor script up always up and runninig. Keep the monitor 
>>> script run continuosly through cron or at at regular\scheduled intervals. 
>>> This way even if monitor script goes down, the next xth interval, it is up 
>>> again. 
>>> 
>>> With this there is a catch though, we may got multiple pids for a given 
>>> daemon provided if there are multiple daemons spawned by same\multiple 
>>> applications, if this scenario is not common then its ok, otherwise we may 
>>> have to track it differently maintaining state of each spawned daemon and 
>>> see if it exists. If multiple applications launch the same daemon, you may 
>>> also wanted to say its application which got killed. EX: A launched httpd, 
>>> and during its exit logic, it is killing all daemons it launched, then you 
>>> may wanted to add  A is not available, rather than just http is not 
>>> available. 
>>> 
>>> 
>>> 2.  Using  netstat command : Check for available, listening and active 
>>> ports on local host, provided all the daemons you wanted to monitor are 
>>> running on "standard" ports or if we know the listening ports of those 
>>> deamons to be monitored. Again, this script can be added through cron\at to 
>>> be scheduled to run x units, if it gets killed the next x units after the 
>>> monitor script is up again. 
>>> 
>>> Also, there could be many other approaches as well.
>>> 
>>> 
>>> Thanks!
>>> Santhosh
>>> 
>>> From: Jayapal Reddy Uradi [jayapalreddy.ur...@citrix.com]
>>> Sent: Saturday, October 05, 2013 5:17 AM
>>> To: 
>>> Cc: 
>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>> 
>>> Hi,
>>> 
>>> +users list
>>> If any one is already using any tools for monitoring then please share your 
>>> ideas.
>>> Also share the cases where you experienced service crashes.
>>> 
>>> Thanks,
>>> Jayapal
>>> 
>>> On 05-Oct-2013, at 4:12 AM, Chiradeep Vittal  
>>> wrote:
>>> 
>>>> Well just make sure that your script is resilient to its own crashes 
>>>> as well.
>>>> 
>>>> On 10/4/13 1:59 AM, "Jayapal Reddy Uradi" 
>>>> 
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am planning to write script utility to monitor processes and 
>>>>> restart on the event of failure. It will also logs the events.
>>>>> 
>>>&

Re: [PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

Please find below update FS
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Monitoring+VR+services

Thanks,
Jayapal

On 05-Oct-2013, at 6:54 PM, Santhosh Edukulla  
wrote:

> A shell script can be used. Few thoughts below:
> 
> 1. Collect the process id of all daemons you wanted to monitor using "pidof" 
> of command and then use "kill" command to check if the pid you got is valid. 
> Using kill we can send a signal 0, then check the status using echo $? . For 
> sending a notification use linux syslog call ( man 3 syslogd) or "logger" 
> command to send to syslog. If wanted to send email then you may also have to 
> look for firewall not allowing outbound smtp port communiation. Even for snmp 
> this holds same( i mean if any blocking through firewall rules ).  Using 
> syslog may be good as it by default exposes various debug log levels through 
> its api call.
> 
> Now, to keep the monitor script up always up and runninig. Keep the monitor 
> script run continuosly through cron or at at regular\scheduled intervals. 
> This way even if monitor script goes down, the next xth interval, it is up 
> again. 
> 
> With this there is a catch though, we may got multiple pids for a given 
> daemon provided if there are multiple daemons spawned by same\multiple 
> applications, if this scenario is not common then its ok, otherwise we may 
> have to track it differently maintaining state of each spawned daemon and see 
> if it exists. If multiple applications launch the same daemon, you may also 
> wanted to say its application which got killed. EX: A launched httpd, and 
> during its exit logic, it is killing all daemons it launched, then you may 
> wanted to add  A is not available, rather than just http is not available. 
> 
> 
> 2.  Using  netstat command : Check for available, listening and active ports 
> on local host, provided all the daemons you wanted to monitor are running on 
> "standard" ports or if we know the listening ports of those deamons to be 
> monitored. Again, this script can be added through cron\at to be scheduled to 
> run x units, if it gets killed the next x units after the monitor script is 
> up again. 
> 
> Also, there could be many other approaches as well.
> 
> 
> Thanks!
> Santhosh 
> 
> From: Jayapal Reddy Uradi [jayapalreddy.ur...@citrix.com]
> Sent: Saturday, October 05, 2013 5:17 AM
> To: 
> Cc: 
> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
> 
> Hi,
> 
> +users list
> If any one is already using any tools for monitoring then please share your 
> ideas.
> Also share the cases where you experienced service crashes.
> 
> Thanks,
> Jayapal
> 
> On 05-Oct-2013, at 4:12 AM, Chiradeep Vittal  
> wrote:
> 
>> Well just make sure that your script is resilient to its own crashes as
>> well.
>> 
>> On 10/4/13 1:59 AM, "Jayapal Reddy Uradi" 
>> wrote:
>> 
>>> Hi,
>>> 
>>> I am planning to write script utility to monitor processes and restart on
>>> the event of failure. It will also logs the events.
>>> 
>>> Thanks,
>>> Jayapal
>>> 
>>> On 02-Oct-2013, at 3:25 AM, Simon Weller  wrote:
>>> 
>>>> supervisord maybe?
>>>> 
>>>> - Original Message -
>>>> 
>>>> From: "Chiradeep Vittal" 
>>>> To: dev@cloudstack.apache.org
>>>> Sent: Tuesday, October 1, 2013 4:45:56 PM
>>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>>> 
>>>> Got it. Any other OSS tool out there similar to monit?
>>>> 
>>>> On 10/1/13 8:24 AM, "David Nalley"  wrote:
>>>> 
>>>>> On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal
>>>>>  wrote:
>>>>>> SNMP wouldn't restart a failed process nor would it generate alerts.
>>>>>> It
>>>>>> is
>>>>>> simply too generic for the requirements outlined here. The proposal
>>>>>> does
>>>>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>>>> the
>>>>>> AGPL.
>>>>> 
>>>>> Let me restate my objection to anything AGPL.
>>>>> People are largely comfortable with GPLv2 software - Linux is
>>>>> ubiquitous. Many legal departments routinely prohibit GPLv3 software
>>>>> (we actually saw this when CS was GPLv3 licensed.) But the Affero GPL
>>>>> license is anathema in many corporate environments, and by forcing it
>>>>> on folks in the default System VM I fear it will hurt adoption of
>>>>> CloudStack.
>>>>> 
>>>>> --David
>>>> 
>>>> 
>>> 
>> 
> 

Re: Exception Occurred adding host

[Jayapal Reddy Uradi]

Hi,

>From the logs vmops, setIptables call failed.
for cmd: setIptables with args  due to There was a failure

Can you check the xenserver agent log (SMlog) to know more info
 
Thanks,
Jayapal


On 06-Nov-2013, at 9:56 AM, Aakash Kumar 
 wrote:

> Hello ,
> Following exception occurred on running deployDatacenter.py using
> devcloud.cfg
> 
> INFO  [c.c.r.ResourceManagerImpl]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Trying to add a new host at http://192.168.56.10/ in data center 1
> INFO  [c.c.h.x.d.XcpServerDiscoverer]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Found host devcloud ip=192.168.56.10 product version=1.6.0
> INFO  [c.c.h.x.r.CitrixResourceBase]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Private Network is Pool-wide network associated with eth0 for host
> 192.168.56.10
> INFO  [c.c.h.x.r.CitrixResourceBase]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Guest Network is Pool-wide network associated with eth0 for host
> 192.168.56.10
> INFO  [c.c.h.x.r.CitrixResourceBase]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Public Network is Pool-wide network associated with eth0 for host
> 192.168.56.10
> INFO  [c.c.h.x.d.XcpServerDiscoverer]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> Host: devcloud connected with hypervisor type: XenServer. Checking
> CIDR...
> INFO  [c.c.a.m.DirectAgentAttache]
> (1456585835@qtp-2122825114-0:ctx-2dc342a1 ctx-d1559de5 ctx-fae00876)
> StartupAnswer received 1 Interval = 60
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\ovsgre
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\..\..\..\network\domr\\ipassoc.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\..\..\..\network\domr\\getDomRVersion.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\..\..\..\network\domr\\getRouterStatus.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\..\..\..\network\domr\\networkUsage.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\..\..\..\network\domr\\l2tp_vpn.sh
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e) We
> cannot locate 
> E:\cloudstack\cloudstackworkspace\cloudstack_4.2\client\target\generated-webapp\WEB-INF\classes\scripts\vm\hypervisor\xenserver\xcposs\..\vhd-util
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e)
> callHostPlugin failed for cmd: setIptables with args  due to There was
> a failure communicating with the plugin.
> WARN  [c.c.h.x.r.CitrixResourceBase] (DirectAgent-1:ctx-24b06a5e)
> Unable to setup
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed
> for cmd: setIptables with args  due to There was a failure
> communicating with the plugin.
>   at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:4293)
>   at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.setIptables(CitrixResourceBase.java:4305)
>   at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5098)
>   at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:547)
>   at 
> com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:140)
>   at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:187)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>   at 
> org.apa

Re: [ANNOUNCE] New Committer: Nguyen Anh Tu

[Jayapal Reddy Uradi]

Congrats Nguyen!

On 04-Nov-2013, at 5:42 PM, Hugo Trippaers 
mailto:h...@trippaers.nl>>
 wrote:

Congrats Tuna :-)


Cheers,

Hugo

On 4 nov. 2013, at 11:12, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:

welcome Nguyen.

On Mon, Nov 4, 2013 at 10:02 AM, Sebastien Goasguen 
mailto:run...@gmail.com>> wrote:
Well done Nguyen !

-Sebastien

On 4 Nov 2013, at 09:33, Prasanna Santhanam 
mailto:t...@apache.org>> wrote:

The Project Management Committee (PMC) for Apache CloudStack has asked Nguyen
Anh Tu to become a committer and we are pleased to announce that they have
accepted.

Being a committer allows many contributors to contribute more autonomously. For
developers, it makes it easier to submit changes and eliminates the need to
have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a recognition of a
contributor's participation in the project and commitment to the project and
the Apache Way.

Please join me in congratulating Nguyen!

--
Prasanna.,
on behalf of the Apache CloudStack PMC


Powered by BigRock.com

Re: [ANNOUNCE] New Committer: Shilamkar, Girish

[Jayapal Reddy Uradi]

Congrats Girish!

On 24-Oct-2013, at 12:45 AM, Rayees Namathponnan 
 wrote:

> Congrats Girsih 
> 
> -Original Message-
> From: Ahmad Emneina [mailto:aemne...@gmail.com] 
> Sent: Wednesday, October 23, 2013 10:34 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [ANNOUNCE] New Committer: Shilamkar, Girish
> 
> Nice work Girish!
> 
> 
> On Wed, Oct 23, 2013 at 9:59 AM, Sangeetha Hariharan < 
> sangeetha.hariha...@citrix.com> wrote:
> 
>> Congrats Girish!!
>> 
>> -Original Message-
>> From: Radhika Puthiyetath [mailto:radhika.puthiyet...@citrix.com]
>> Sent: Wednesday, October 23, 2013 3:59 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [ANNOUNCE] New Committer: Shilamkar, Girish
>> 
>> Congratz, Girish
>> 
>> -Original Message-
>> From: Prasanna Santhanam [mailto:t...@apache.org]
>> Sent: Wednesday, October 23, 2013 4:08 PM
>> To: CloudStack Dev
>> Subject: [ANNOUNCE] New Committer: Shilamkar, Girish
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked 
>> Girish Shilamkar to become a committer and we are pleased to announce 
>> that they have accepted.
>> 
>> Being a committer allows many contributors to contribute more 
>> autonomously. For developers, it makes it easier to submit changes and 
>> eliminates the need to have contributions reviewed via the patch 
>> submission process. Whether contributions are development-related or 
>> otherwise, it is a recognition of a contributor's participation in the 
>> project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Girish!
>> 
>> --
>> Prasanna.,
>> on behalf of the Apache CloudStack PMC
>> 
>> 
>> Powered by BigRock.com
>> 
>> 

Re: [ANNOUNCE] New PMC member: Animesh Chaturvedi

[Jayapal Reddy Uradi]

Congrats, Animesh!

On 22-Oct-2013, at 8:55 AM, Go Chiba  wrote:

> Congrats, Animesh!
> 
> 
> On Tue, Oct 22, 2013 at 4:01 AM, Chip Childers wrote:
> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Animesh Chaturvedi to join the PMC and we are pleased to announce that they
>> have accepted.
>> 
>> Join me in congratulating Animesh!
>> 
>> -The CloudStack PMC
>> 
> 
> 
> 
> -- 
> 千葉 豪  Go Chiba
> E-mail:go.ch...@gmail.com

Re: Review Request 14591: Fixng the issue of wrong netmask value is allowed in public traffic wizard while creating a zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14591/#review27182
---

Ship it!


Ship It!

- Jayapal Reddy


On Oct. 18, 2013, 9:49 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14591/
> ---
> 
> (Updated Oct. 18, 2013, 9:49 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Jayapal Reddy, and Murali 
> Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-4811
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-4811
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The UI Wizard was allowing Invalid CIDR in public traffic page while creating 
> a zone and back end was also not checking the correctness of the CIDR before 
> creating a zone.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fda3b1 
>   utils/pom.xml 35012b2 
>   utils/src/com/cloud/utils/net/NetUtils.java e64af4c 
> 
> Diff: https://reviews.apache.org/r/14591/diff/
> 
> 
> Testing
> ---
> 
> Testing is done through UI
> For Example : Given wrong NetMask value 255.255.25.0 which is wrong net mask 
> value
>   Given Gateway as 10.147.30.1 and  NetMask as 255.255.255.192 
> and public IP Range as 10.147.30.150-10.147.30.159..which is a wrong ip range 
> for the given gateway and net mask values.
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 14591: Fixng the issue of wrong netmask value is allowed in public traffic wizard while creating a zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14591/#review27122
---



utils/src/com/cloud/utils/net/NetUtils.java
<https://reviews.apache.org/r/14591/#comment52770>

This patch is failed to apply on master.



utils/src/com/cloud/utils/net/NetUtils.java
<https://reviews.apache.org/r/14591/#comment52771>

Please remove the tabs here


- Jayapal Reddy


On Oct. 11, 2013, 10:53 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14591/
> ---
> 
> (Updated Oct. 11, 2013, 10:53 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Jayapal Reddy, and Murali 
> Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-4811
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-4811
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The UI Wizard was allowing Invalid CIDR in public traffic page while creating 
> a zone and back end was also not checking the correctness of the CIDR before 
> creating a zone.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java b09b8ca 
>   utils/pom.xml f4ac12b 
>   utils/src/com/cloud/utils/net/NetUtils.java 05b485b 
> 
> Diff: https://reviews.apache.org/r/14591/diff/
> 
> 
> Testing
> ---
> 
> Testing is done through UI
> For Example : Given wrong NetMask value 255.255.25.0 which is wrong net mask 
> value
>   Given Gateway as 10.147.30.1 and  NetMask as 255.255.255.192 
> and public IP Range as 10.147.30.150-10.147.30.159..which is a wrong ip range 
> for the given gateway and net mask values.
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 14591: Fixng the issue of wrong netmask value is allowed in public traffic wizard while creating a zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14591/#review26926
---



server/src/com/cloud/configuration/ConfigurationManagerImpl.java
<https://reviews.apache.org/r/14591/#comment52441>

Please remove white spaces



utils/src/com/cloud/utils/net/NetUtils.java
<https://reviews.apache.org/r/14591/#comment52442>

Please remove white spaces


- Jayapal Reddy


On Oct. 11, 2013, 10:07 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14591/
> ---
> 
> (Updated Oct. 11, 2013, 10:07 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Jayapal Reddy, and Murali 
> Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-4811
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The UI Wizard was allowing Invalid CIDR in public traffic page while creating 
> a zone and back end was also not checking the correctness of the CIDR before 
> creating a zone.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java b09b8ca 
>   utils/pom.xml f4ac12b 
>   utils/src/com/cloud/utils/net/NetUtils.java 05b485b 
> 
> Diff: https://reviews.apache.org/r/14591/diff/
> 
> 
> Testing
> ---
> 
> Testing is done through UI
> For Example : Given wrong NetMask value 255.255.25.0 which is wrong net mask 
> value
>   Given Gateway as 10.147.30.1 and  NetMask as 255.255.255.192 
> and public IP Range as 10.147.30.150-10.147.30.159..which is a wrong ip range 
> for the given gateway and net mask values.
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: [PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

Hi,

+users list
If any one is already using any tools for monitoring then please share your 
ideas.
Also share the cases where you experienced service crashes.

Thanks,
Jayapal

On 05-Oct-2013, at 4:12 AM, Chiradeep Vittal  
wrote:

> Well just make sure that your script is resilient to its own crashes as
> well.
> 
> On 10/4/13 1:59 AM, "Jayapal Reddy Uradi" 
> wrote:
> 
>> Hi,
>> 
>> I am planning to write script utility to monitor processes and restart on
>> the event of failure. It will also logs the events.
>> 
>> Thanks,
>> Jayapal
>> 
>> On 02-Oct-2013, at 3:25 AM, Simon Weller  wrote:
>> 
>>> supervisord maybe?
>>> 
>>> - Original Message -
>>> 
>>> From: "Chiradeep Vittal" 
>>> To: dev@cloudstack.apache.org
>>> Sent: Tuesday, October 1, 2013 4:45:56 PM
>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>> 
>>> Got it. Any other OSS tool out there similar to monit?
>>> 
>>> On 10/1/13 8:24 AM, "David Nalley"  wrote:
>>> 
>>>> On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal
>>>>  wrote:
>>>>> SNMP wouldn't restart a failed process nor would it generate alerts.
>>>>> It 
>>>>> is 
>>>>> simply too generic for the requirements outlined here. The proposal
>>>>> does 
>>>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>>> the 
>>>>> AGPL. 
>>>> 
>>>> Let me restate my objection to anything AGPL.
>>>> People are largely comfortable with GPLv2 software - Linux is
>>>> ubiquitous. Many legal departments routinely prohibit GPLv3 software
>>>> (we actually saw this when CS was GPLv3 licensed.) But the Affero GPL
>>>> license is anathema in many corporate environments, and by forcing it
>>>> on folks in the default System VM I fear it will hurt adoption of
>>>> CloudStack. 
>>>> 
>>>> --David 
>>> 
>>> 
>> 
> 

Re: [PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

Hi,

I am planning to write script utility to monitor processes and restart on 
the event of failure. It will also logs the events.

Thanks,
Jayapal

On 02-Oct-2013, at 3:25 AM, Simon Weller  wrote:

> supervisord maybe? 
> 
> - Original Message -
> 
> From: "Chiradeep Vittal"  
> To: dev@cloudstack.apache.org 
> Sent: Tuesday, October 1, 2013 4:45:56 PM 
> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router 
> 
> Got it. Any other OSS tool out there similar to monit? 
> 
> On 10/1/13 8:24 AM, "David Nalley"  wrote: 
> 
>> On Thu, Sep 26, 2013 at 1:27 AM, Chiradeep Vittal 
>>  wrote: 
>>> SNMP wouldn't restart a failed process nor would it generate alerts. It 
>>> is 
>>> simply too generic for the requirements outlined here. The proposal does 
>>> not talk about modifying monit, just using it. That wouldn't trigger the 
>>> AGPL. 
>> 
>> Let me restate my objection to anything AGPL. 
>> People are largely comfortable with GPLv2 software - Linux is 
>> ubiquitous. Many legal departments routinely prohibit GPLv3 software 
>> (we actually saw this when CS was GPLv3 licensed.) But the Affero GPL 
>> license is anathema in many corporate environments, and by forcing it 
>> on folks in the default System VM I fear it will hurt adoption of 
>> CloudStack. 
>> 
>> --David 
> 
> 

Re: [PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

The current scope is limited to VR.
If a service fails to restart after certain cycles then monit will timeout, log 
the event. In this case admin has to interfere, solve the issue in the service 
and add it to monit again.

Thanks,
Jayapal

On 01-Oct-2013, at 11:16 AM, Koushik Das 
 wrote:

> This is a very useful feature. Can this be extended to the other system VMs? 
> SSVM and CPVM
> 
> Based on the discussion I see that there is an assumption that restarting 
> services/rebooting should fix the issues. Is that always true? What if the 
> service fails to restart after repeated attempts? What is the fallback?
> 
> -Koushik
> 
> 
> On 01-Oct-2013, at 3:15 AM, Chiradeep Vittal  
> wrote:
> 
>> Good idea. If x and y and z are borked, initiate shutdown?
>> 
>> More generically, it seems we need some form of in-VM automation that can
>> co-ordinate with top-level orchestration
>> 
>> On 9/28/13 4:14 AM, "Daan Hoogland"  wrote:
>> 
>>> Even when always restarting on every glitch we need to monitor the inside
>>> of the vr to know when to restart/respin a new vr. There is much
>>> functionality present on the vr an for us it is not possible to say for
>>> sure what is important to a customer installation so the admin should be
>>> able to define the minimal reqs that will stop us from spinning up a new
>>> vr. And there must be tools present for monitoring these reqs.
>>> 
>>> makes sense?
>>> 
>>> 
>>> On Thu, Sep 26, 2013 at 10:01 PM, David Nalley  wrote:
>>> 
>>>> For what it's worth we created an ACS-specific MIB (beneath the
>>>> org.apache MIB) so really this is just a matter of defining and
>>>> publishing it.
>>>> 
>>>> But lets think about monit being used to restart services - with HA,
>>>> Redundant VR, are we sure that we want to inject yet another point of
>>>> control into things? Is it better to just respawn an instance since
>>>> they are essentially stateless? I don't know, but management server,
>>>> local daemons, and other SysVMs making decisions seems like we are
>>>> increasing complexity.
>>>> 
>>>> --David
>>>> 
>>>> On Thu, Sep 26, 2013 at 10:31 AM, Chiradeep Vittal
>>>>  wrote:
>>>>> In this case you would have to invent another enterprise MIB. Not too
>>>>> hard, but I'd argue that it needs to be proxied through some other
>>>> service
>>>>> anyway and it represents a different integration point with ACS.
>>>> Depends
>>>>> on whether you consider the system vm part of the ACS deployment, or
>>>> an
>>>>> entity like a host.
>>>>> 
>>>>> On 9/26/13 10:27 AM, "Alex Huang"  wrote:
>>>>> 
>>>>>> Using SNMP for alert notification is not a bad idea though.  I don't
>>>> see
>>>>>> why we can't do that instead of posting to the management server.
>>>> This
>>>>>> is specifically referring to the second part of the proposal.  Why
>>>>>> reinvent that part of it?
>>>>>> 
>>>>>> --Alex
>>>>>> 
>>>>>>> -Original Message-
>>>>>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>>>>>> Sent: Wednesday, September 25, 2013 10:28 PM
>>>>>>> To: dev@cloudstack.apache.org
>>>>>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>>>>>> 
>>>>>>> SNMP wouldn't restart a failed process nor would it generate
>>>> alerts. It
>>>>>>> is
>>>>>>> simply too generic for the requirements outlined here. The proposal
>>>> does
>>>>>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>>>>> the AGPL.
>>>>>>> I think the idea is to have a tight monitoring loop that scales: so
>>>>>>> executing the
>>>>>>> monitoring loop in-situ makes sense.
>>>>>>> 
>>>>>>> 
>>>>>>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>>>>>>> 
>>>>>>>> On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>>>>>>>>  wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>&

Re: Virtual Router reachability

[Jayapal Reddy Uradi]

Hi Girish,

While selecting the delay I suggest the following.

In general check the time taken for the router boot up. 
Take the max interval as 10 times of boot up time. 
Repeat the ssh for each boot up interval.

Thanks,
Jayapal
 
On 30-Sep-2013, at 1:38 PM, Girish Shilamkar 
 wrote:

> Marcus,
> 
> I guess it no longer applies to even KVM . I have seen the router in running 
> state and yet fails to accept 
> ssh connection.
> 
> Santhosh,
> 
> Adding random delay is what I am trying to avoid or at least minimise. Thanks 
> for the suggestions.
> 
> Regards,
> Girish
> 
> On 30-Sep-2013, at 12:18 PM, Marcus Sorensen  wrote:
> 
>> In the past, with KVM, the agent doesn't show the router as running until
>> it can ssh to it. You can watch the agent poll if it is debug logging. Does
>> this issue not apply to KVM, or is it a regression?
>> On Sep 29, 2013 11:38 PM, "Girish Shilamkar"  wrote:
>> 
>>> Hello,
>>> 
>>> Egress rules tests rely on accessing virtual router VR after creating a
>>> network. I have often seen that VR is not immediately accessible.
>>> A ssh to VR fails, I think it takes a while for the network to come up and
>>> VR can be ssh'd. This happens even though the VR is in "Running"
>>> state.
>>> So I added a delay before trying to ssh VR. I was wondering what is the
>>> right amount of delay here. I did not find a param in global settings
>>> which can be used as wait time.
>>> 
>>> Please advise.
>>> 
>>> Regards,
>>> Girish
>>> 
>>> 
> 

Re: Virtual Router reachability

[Jayapal Reddy Uradi]

Girish,

cloudstack shows router status as 'running' before the router booting 
completed. The router is accessible when the cloud-early-config starts the sshd 
in booting.

+1 on santosh suggestion.

Thanks,
Jayapal
 

On 30-Sep-2013, at 11:25 AM, Santhosh Edukulla 
 wrote:

> Girish,
> 
> 1. Using timeout will make it to wait for that many units always and again it 
> may not be fool proof, we may succeed to find ssh daemon on remote machine is 
> up and running  and with this, we again run it few more times to check again 
> if it is not running, so its not much predictable. 
> 
> Instead of  waiting for specified time always. 
> 
> a) poll check  to see if ping to ip is working and then verify ssh port is 
> open for connections on the target, if yes, we are good to go.  This way, we 
> are not waiting for specific time always.
> b)  There is a telnet lib of which you can use either read_until or expect 
> calls with specific max timeout ( worst ) with strings like "connected" etc 
> to check ssh port is available for connections, If we are getting the desired 
> string in the output, then we are ok, or otherwise you may take a call. This 
> way, we wait for max time only during worst cases.  Check the link below link 
> for specific examples: 
> 
> http://docs.python.org/2/library/telnetlib.html
> 
> Regards,
> Santhosh
> 
> From: Girish Shilamkar [gir...@clogeny.com]
> Sent: Monday, September 30, 2013 1:38 AM
> To: dev@cloudstack.apache.org
> Subject: Virtual Router reachability
> 
> Hello,
> 
> Egress rules tests rely on accessing virtual router VR after creating a 
> network. I have often seen that VR is not immediately accessible.
> A ssh to VR fails, I think it takes a while for the network to come up and VR 
> can be ssh'd. This happens even though the VR is in "Running"
> state.
> So I added a delay before trying to ssh VR. I was wondering what is the right 
> amount of delay here. I did not find a param in global settings
> which can be used as wait time.
> 
> Please advise.
> 
> Regards,
> Girish

Re: [ANNOUNCE] New Committer: Darren Shepherd

[Jayapal Reddy Uradi]

Congrats Darren!

-Jayapal

On 29-Sep-2013, at 10:12 AM, Alena Prokharchyk  
wrote:

> Congrats, Darren!
> 
> -Alena
> 
> From: Chip Childers 
> mailto:chip.child...@sungard.com>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Date: Saturday, September 28, 2013 5:24 AM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: [ANNOUNCE] New Committer: Darren Shepherd
> 
> The Project Management Committee (PMC) for Apache CloudStack
> has asked Darren Shepherd to become a committer and we are pleased to
> announce that he has accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the
> project and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Darren!
> 
> -chip
> on behalf of the CloudStack PMC
> 

[PROPOSAL] Service monitoring tool in virtual router

[Jayapal Reddy Uradi]

Hi,

Currently in virtual router there is no way to recover and notify if some 
service goes down unexpectedly.

This feature is about monitoring all the services rendered by the virtual 
router, ensure that the services are running through the life time of the VR.

On service failure:
1. Generate an alert and event indicating failure
2. Restart the service

Services to be monitored:
DHCP, DNS, haproxy, password server etc.

As part of monitoring there are two activities

1. One is monitoring the services in VR and log the events. Using monit for 
monitoring services
2. Second part is pushing alerts from router to  MS server. Thinking on POST 
the logs to web server in MS.

I will be updating more details and FS in this thread.

I created enhancement bug for this.
https://issues.apache.org/jira/browse/CLOUDSTACK-4736

Thanks,
Jayapal

Re: [ANNOUNCE] New committer: Rajesh Battala

[Jayapal Reddy Uradi]

Congrats Rajesh!


On 25-Sep-2013, at 10:36 AM, Harikrishna Patnala 
 wrote:

> Congratulations Rajesh :)
> 
> On 25-Sep-2013, at 10:26 AM, Venkata SwamyBabu Budumuru 
> 
> wrote:
> 
>> Congrats Rajesh!
>> 
>> On 25/09/13 10:00 AM, "Abhinav Roy"  wrote:
>> 
>>> Congrats Rajesh :)
>>> 
>>> 
>>> -Original Message-
>>> From: Sanjay Tripathi [mailto:sanjay.tripa...@citrix.com]
>>> Sent: Wednesday, September 25, 2013 9:58 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: [ANNOUNCE] New committer: Rajesh Battala
>>> 
>>> Congrats Rajesh!!
>>> 
>>> --Sanjay
>>> 
 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Tuesday, September 24, 2013 9:00 PM
 To: dev@cloudstack.apache.org
 Subject: [ANNOUNCE] New committer: Rajesh Battala
 
 The Project Management Committee (PMC) for Apache CloudStack has asked
 Rajesh Battala to become a committer and we are pleased to announce
 that they have accepted.
 
 Being a committer allows many contributors to contribute more
 autonomously. For developers, it makes it easier to submit changes and
 eliminates the need to have contributions reviewed via the patch
 submission process. Whether contributions are development-related or
 otherwise, it is a recognition of a contributor's participation in the
 project and commitment to the project and the Apache Way.
 
 Please join me in congratulating Rajesh!
 
 -chip
 on behalf of the CloudStack PMC
>> 
> 

[PROPOSAL] adding [SOLVED] tag in mailing list subject

[Jayapal Reddy Uradi]

Hi,

When the issues raised in dev/users mailing lists are solved by using 
suggestions/solutions as replies 
send by community members then the one who raised the issue please reply to the 
thread by adding [SOLVED] tag.


Also please add the accumulated steps performed to solve it, this will helpful 
to other members when they gets the similar issues.

Thanks,
Jayapal

Re: Iptables Configuration

[Jayapal Reddy Uradi]

Hi,

Did you install CSP in cloudstack properly ?
please refer the below link to install CSP in xenserver.
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/citrix-xenserver-installation.html#xenserver-support-pkg-installation

Please refer the example working iptables rules configured on the xenserver 
host.

https://www.dropbox.com/sh/4zhgdpj7q0rc2d8/-79saHSIbC/Xenserver-sg-rules/iptables.txt


Thanks,
Jayapal

On 21-Sep-2013, at 5:53 AM, Michael Phillips  wrote:

> So I've been having a few issues with my test system which all seem to boil 
> down to iptables not being configured correctly on my XEN host. Problems I've 
> been having are
> 1. Template's not able to download - *can be fixed by stopping iptables on 
> XEN host
> 2. System VM's don't deploy and start running - *can be fixed by stopping 
> iptables on XEN host
> 3. Security groups not worling - *been posting in the user list and it seems 
> like my XEN host does not have the necessary iptable entries for security 
> groups to work properly.
> With all these iptables issues, is there a iptables guide posted somewhere 
> that outlines the changes needed to make XEN 6.02 + CSP work correctly?
> 

Re: Security Groups

[Jayapal Reddy Uradi]

Hi,

Can you please share your security group rules 'iptables -L -nv' output in 
pastebin
So that see why it is happening.

Thanks,
Jayapal
On 13-Sep-2013, at 9:25 AM, Jijun 
 wrote:

> hi , i encounter the same problem,
> 
> as i know, XenServer 6.2 need not  the CSP.
> 
> but the ingress not be blocked by default. i can ping all the Vms in that 
> security group.
> 
> i don't know why?
> 
> Thanks.
> 
> On 09/13/2013 02:02 AM, Michael Phillips wrote:
>> So that is definitely going to be the issue. I missed that in the 8.2.7 
>> section of the install guide.
>> 
>>> From: sangeetha.hariha...@citrix.com
>>> To: dev@cloudstack.apache.org
>>> Subject: RE: Security Groups
>>> Date: Thu, 12 Sep 2013 17:19:16 +
>>> 
>>> If you are using Xenserver hosts , can you make sure you have the CSP 
>>> packages installed?
>>> 
>>> -Thanks
>>> Sangeetha
>>> 
>>> -Original Message-
>>> From: Michael Phillips [mailto:mphilli7...@hotmail.com]
>>> Sent: Thursday, September 12, 2013 9:33 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Security Groups
>>> 
>>> I posed this question in the user list, but I figured I would throw it out 
>>> here as well...So If I have created a zone with the 
>>> "DefaultSharedNetworkOfferingWithSGService" network offering, then created 
>>> a VM using the default security group, which has 0 ingress rules, I should 
>>> NOT be able to do things like PING that VM correct? The answer to the above 
>>> question was answered "correct"...My next question is, in that case what 
>>> are some things I could look at to see why it's not behaving as expected.
>>> 
>>  
> 
> 
> -- 
> Thanks,
> Jijun
> 

Re: [ANNOUNCE] New PMC member: Ilya Musayev

[Jayapal Reddy Uradi]

Congratulations!

On 05-Sep-2013, at 12:21 PM, sebgoa 
 wrote:

> The Project Management Committee (PMC) for Apache CloudStack has asked Ilya 
> Musayev to join the PMC and we are pleased to announce that they have 
> accepted.
> 
> Join me in congratulating Ilya,
> 
> -The CloudStack PMC

Re: [Questions]: Basic Zone Securiy Group problem?

[Jayapal Reddy Uradi]

Hi,

The rules are looking as expected.
The ingress traffic to vm should block.

Can you run 'iptables -L -nv' and see which rules are accepting the ingress 
traffic.

Thanks,
Jayapal
On 30-Aug-2013, at 7:41 AM, Jijun  wrote:

> i clone branch 4.2 code, package and do a  fresh installation.
> 
> hypervisor : xenserver 6.2 change  openvswitch to bridge.
> 
> add basic zone ,security group enabeld.
> 
> create a new vm , default security group
> 
> the previous version  document   said the ingress will be blocked by default. 
>  but in my test, the network in and out are all allowed.
> so strange.
> 
> is it a bug ?
> 
> iptable rule in hypervisor :
> 
> [root@xenserver-dlghbuxq ~]# iptables -nL
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> BRIDGE-FIREWALL  all  --  0.0.0.0/00.0.0.0/0 PHYSDEV match 
> --physdev-is-bridged
> ACCEPT all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out eth1 --physdev-is-bridged
> ACCEPT all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out eth0 --physdev-is-bridged
> DROP   all  --  0.0.0.0/00.0.0.0/0
> 
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> 
> Chain BRIDGE-DEFAULT-FIREWALL (1 references)
> target prot opt source   destination
> ACCEPT all  --  0.0.0.0/00.0.0.0/0   state 
> RELATED,ESTABLISHED
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-is-bridged udp spt:68 dpt:67
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-is-bridged udp spt:67 dpt:68
> 
> Chain BRIDGE-FIREWALL (1 references)
> target prot opt source   destination
> BRIDGE-DEFAULT-FIREWALL  all  --  0.0.0.0/0 0.0.0.0/0
> i-2-7-def  all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif21.0 --physdev-is-bridged
> i-3-8-def  all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif20.0 --physdev-is-bridged
> r-4-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif19.0 --physdev-is-bridged
> r-4-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif19.1 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif18.2 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif18.0 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif18.1 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif18.3 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif17.2 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif17.0 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-in vif17.1 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif17.1 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif17.0 --physdev-is-bridged
> v-2-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif17.2 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif18.3 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif18.1 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif18.0 --physdev-is-bridged
> s-6-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif18.2 --physdev-is-bridged
> r-4-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif19.1 --physdev-is-bridged
> r-4-VM all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif19.0 --physdev-is-bridged
> i-3-8-def  all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif20.0 --physdev-is-bridged
> i-2-7-def  all  --  0.0.0.0/00.0.0.0/0   PHYSDEV match 
> --physdev-out vif21.0 --physdev-is-bridged
> 
> Chain L (0 references)
> target prot opt source   destination
> 
> Chain RH-Firewall-1-INPUT (0 references)
> target prot opt source   destination
> 
> Chain i-2-7-VM (1 references)
> target prot opt source   destination
> DROP   all  --  0.0.0.0/00.0.0.0/0
> 
> Chain i-2-7-VM-eg (1 refere

Re: New Committer: Daan Hoogland

[Jayapal Reddy Uradi]

Congrats Daan!

On 29-Aug-2013, at 10:46 AM, Koushik Das 
 wrote:

> Congrats Daan!
> 
> On 28-Aug-2013, at 7:28 PM, Chip Childers  wrote:
> 
>> The Project Management Committee (PMC) for Apache CloudStack
>> has asked Daan Hoogland to become a committer and we are pleased to
>> announce that he has accepted!
>> 
>> Daan's been quite active on the dev list, working on not just the code
>> but also helping us keep tabs on our responsiveness to questions (something 
>> that we always need to be mindful of).
>> 
>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the
>> project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Daan!
>> 
>> -chip
>> on behalf of the CloudStack PMC
> 

Re: IPTables Issues

[Jayapal Reddy Uradi]

Hi,

Please send 'iptables -L -nv' output when you are sending the DNS/console 
traffic.
So that we can find which rules are actually blocking the traffic.

Thanks,
Jayapal

On 29-Aug-2013, at 12:28 AM, Maurice Lawler  wrote:

> Hello folks,
> 
> I have a couple issues with the iptables showed below.
> 
> 1) When enabled, I find that I cannot resolve DNS (ie: ping google.com) or 
> even yum update etc.
> 
> 2) When enabled, I am also unable to view the console. 
> 
> When I disable both issues go away.
> 
> Please assist.
> 
> -Maurice
> 
> 3
> 
> [root@cloud ~]# cat /etc/sysconfig/iptables
> # Generated by iptables-save v1.4.7 on Fri Aug 16 15:30:37 2013
> *mangle
> :PREROUTING ACCEPT [0:0]
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill 
> -A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill 
> COMMIT
> *nat
> :PREROUTING ACCEPT [0:0]
> :POSTROUTING ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> COMMIT
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :BF-cloudbr0 - [0:0]
> :BF-cloudbr0-IN - [0:0]
> :BF-cloudbr0-OUT - [0:0]
> :s-1-VM - [0:0]
> :v-2-VM - [0:0]
> -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
> -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
> -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT 
> -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT 
> -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
> -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 9090 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 8250 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 7080 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT 
> -A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT 
> -A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT 
> -A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT 
> -A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 16509 -j ACCEPT 
> -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
> -A FORWARD -o cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 
> -A FORWARD -i cloudbr0 -m physdev --physdev-is-bridged -j BF-cloudbr0 
> -A FORWARD -o cloudbr0 -j DROP 
> -A FORWARD -i cloudbr0 -j DROP 
> -A FORWARD -i virbr0 -o virbr0 -j ACCEPT 
> -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable 
> -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable 
> -A FORWARD -i virbr0 -o virbr0 -j ACCEPT 
> -A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable 
> -A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable 
> -A BF-cloudbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
> -A BF-cloudbr0 -m physdev --physdev-is-in --physdev-is-bridged -j 
> BF-cloudbr0-IN 
> -A BF-cloudbr0 -m physdev --physdev-is-out --physdev-is-bridged -j 
> BF-cloudbr0-OUT 
> -A BF-cloudbr0 -m physdev --physdev-out eth0 --physdev-is-bridged -j ACCEPT 
> -A BF-cloudbr0-IN -m physdev --physdev-in vnet1 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-IN -m physdev --physdev-in vnet2 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-IN -m physdev --physdev-in vnet3 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-IN -m physdev --physdev-in vnet5 --physdev-is-bridged -j 
> v-2-VM 
> -A BF-cloudbr0-IN -m physdev --physdev-in vnet6 --physdev-is-bridged -j 
> v-2-VM 
> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet1 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet2 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet3 --physdev-is-bridged -j 
> s-1-VM 
> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet5 --physdev-is-bridged -j 
> v-2-VM 
> -A BF-cloudbr0-OUT -m physdev --physdev-out vnet6 --physdev-is-bridged -j 
> v-2-VM 
> -A s-1-VM -m physdev --physdev-in vnet1 --physdev-is-bridged -j RETURN 
> -A s-1-VM -m physdev --physdev-in vnet2 --physdev-is-bridged -j RETURN 
> -A s-1-VM -m physdev --physdev-in vnet3 --physdev-is-bridged -j RETURN 
> -A s-1-VM -j ACCEPT 
> -A v-2-VM -m physdev --physdev-in vnet5 --physdev-is-bridged -j RETURN 
> -A v-2-VM -m physdev --physdev-in vnet6 --physdev-is-bridged -j RETURN 
> -A v-2-VM -j ACCEPT 
> COMMIT
> # Completed on Fri Aug 16 15:30:37 2013
> [root@cloud ~]# 
> 

Re: Review Request 13856: CLOUDSTACK-4303: Add missing base.py changes

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13856/#review25606
---

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 27, 2013, 10:23 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13856/
> ---
> 
> (Updated Aug. 27, 2013, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna 
> Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4303
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> egressdefaultpolicy parameter was not set in base.py. Therefore
> egress test failed. Added this missing change.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/integration/lib/base.py b5d086b 
> 
> Diff: https://reviews.apache.org/r/13856/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Secondary IP (4.1.1)

[Jayapal Reddy Uradi]

you can add the below rules on the host.
Also you need to update the iptables filter rules.

You need to add rules on host in vm reboot, on VM reboot the old rules get 
added on host.

Thanks,
Jayapal

On 21-Aug-2013, at 6:49 AM, Maurice Lawler  wrote:

> It would seem to be perhaps I can add something via this segment in the 
> security policy.
> 
> try:
>193 # -s ! 52:54:0:56:44:32 -j DROP
>194 execute("ebtables -t nat -A PREROUTING -i " + vif + " -j " +  
> vmchain_in)
>195 execute("ebtables -t nat -A POSTROUTING -o " + vif + " -j " + 
> vmchain_out)
>196 except:
>197 logging.debug("Failed to program default rules")
>198 return 'false'
>199
>200 try:
>201 execute("ebtables -t nat -A " +  vmchain_in + " -s ! " +  
> vm_mac + " -j DROP")
>202 execute("ebtables -t nat -A " +  vmchain_in  + " -p ARP -s ! " 
> + vm_mac + " -j DROP")
>203 execute("ebtables -t nat -A " +  vmchain_in  + " -p ARP 
> --arp-mac-src ! " + vm_mac + " -j DROP")
>204 if vm_ip is not None:
>205 execute("ebtables -t nat -A " + vmchain_in  +  " -p ARP 
> --arp-ip-src ! " + vm_ip + " -j DROP")
>206 execute("ebtables -t nat -A " + vmchain_in  + " -p ARP 
> --arp-op Request -j ACCEPT")
>207 execute("ebtables -t nat -A " + vmchain_in  + " -p ARP 
> --arp-op Reply -j ACCEPT")
>208 execute("ebtables -t nat -A " + vmchain_in  + " -p ARP  -j 
> DROP")
>209 except:
>210 logging.exception("Failed to program default ebtables IN 
> rules")
>211 return 'false'
> 
> Am I wrong in my thinking?
> 
> 
> On Aug 19, 2013, at 11:43 PM, Marcus Sorensen  wrote:
> 
>> Well, it depends on how you edit the security_group.py script, it
>> certainly wouldn't have to open up everything. You could add a
>> one-liner in there that would pass the instance name to a separate
>> script that looked up the vm in a table or database and applied extra
>> rules (in post_default_network_rules), maybe adding something like:
>> 
>> "ebtables -t nat -I " + vmchain_in  +  "  -p ARP --arp-ip-src " +
>> secondary_vm_ip + " -j ACCEPT"
>> 
>> etc.
>> 
>> Although, that might not be fun to maintain.  It would probably be
>> easier to use the libvirt hooks: http://www.libvirt.org/hooks.html  To
>> call your script whenever a vm starts or stops.  You would accept the
>> guest name as an argument to your script, and then that script could
>> look up secondary IPs in a table, from a database or file, adding them
>> to the ebtables chain of the same guest name.
>> 
>> On Mon, Aug 19, 2013 at 8:03 PM, Maurice Lawler  
>> wrote:
>>> Greetings,
>>> 
>>> Does anyone have experience in adding a secondary IP address (by way of 
>>> altering the ebtables / security script) in basic networking mode (KVM)
>>> 
>>> I have reviewed the script that is called to setup the ebtables, but if I 
>>> alter that, I would believe that would open all ports on all my instances. 
>>> I just simply want the easy ability to add a secondary IP address.
>>> 
>>> I understand this is a feature coming in 4.2, but I also understand this 
>>> version is a ways out.
>>> 
>>> Any assistance would be GREATLY appreciated!
>>> 
>>> - Maurice
> 

Re: [ANNOUNCE] New Committer: Toshiaki Hatano

[Jayapal Reddy Uradi]

Congratulations!

On 20-Aug-2013, at 1:06 PM, Hugo Trippaers 
 wrote:

> Congratulations :-)
> 
> Sent from my iPhone
> 
> On 20 aug. 2013, at 02:55, Go Chiba  wrote:
> 
>> Congrats Hatano-san!
>> 
>> 
>> On Tue, Aug 20, 2013 at 7:56 AM, Marcus Sorensen wrote:
>> 
>>> The Project Management Committee (PMC) for Apache CloudStack
>>> has asked Toshiaki Hatano to become a committer and we are pleased
>>> to announce that he has accepted.
>>> 
>>> Being a committer enables easier contribution to the
>>> project since there is no need to go via the patch
>>> submission process. This should enable better productivity.
>>> 
>>> Please join us in congratulating Toshiaki!
>> 
>> 
>> 
>> -- 
>> 千葉 豪  Go Chiba
>> E-mail:go.ch...@gmail.com

Review Request 13643: Unplug the nic when there are no ips set on the interface

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13643/
---

Review request for cloudstack, anthony xu, Abhinandan Prateek, and Murali Reddy.


Repository: cloudstack-git


Description
---

Unplugging the public nic on the VR when there are no ips set on the interface.
This issue of not reusing the public nic is present in the xen and mvm.

For vmware the nic got reused.


Diffs
-

  core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
1fb86e0 
  patches/systemvm/debian/config/opt/cloud/bin/ipassoc.sh ae2d7e4 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 9104504 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 338e741 

Diff: https://reviews.apache.org/r/13643/diff/


Testing
---

Tested in xen and kvm.


Thanks,

Jayapal Reddy

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13626/#review25270
---

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 17, 2013, 11:35 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13626/
> ---
> 
> (Updated Aug. 17, 2013, 11:35 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4321
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
> machines(clients) to update its hostnames with a  DNS server
> Introducing the option dhcp-client-update fails if the version dnsmasq is 
> not above 2.6 (like in burbak template).
> Added a check for the version. will add this option in the config file 
> only if the version is 2.6 and above.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 
> 
> Diff: https://reviews.apache.org/r/13626/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.2.
> with the burbank template by running updated cloud-early-config manually.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 13626: CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual machines(clients) to update its hostnames with a DNS server Introducing the option dhcp-client-update fail

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13626/#review25269
---



patches/systemvm/debian/config/etc/init.d/cloud-early-config
<https://reviews.apache.org/r/13626/#comment49562>

grep for 'version 2.6'.
Split the 2.6 and compare 2 and 6

In router currently it is showing 2.62

Dnsmasq version 2.62  Copyright (c) 2000-2012 Simon Kelley


- Jayapal Reddy


On Aug. 17, 2013, 8:06 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13626/
> ---
> 
> (Updated Aug. 17, 2013, 8:06 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4321
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-4132 current dnsmasq config does not allow guest virtual 
> machines(clients) to update its hostnames with a  DNS server
> Introducing the option dhcp-client-update fails if the version dnsmasq is 
> not above 2.6 (like in burbak template).
> Added a check for the version. will add this option in the config file 
> only if the version is 2.6 and above.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config 736234c 
> 
> Diff: https://reviews.apache.org/r/13626/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.2.
> with the burbank template by running updated cloud-early-config manually.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Review Request 13496: changes for guest vm password script for parallel vm deployment

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13496/
---

Review request for cloudstack, anthony xu, Abhinandan Prateek, Chiradeep 
Vittal, and Sheng Yang.


Bugs: CLOUDSTACK-4184


Repository: cloudstack-git


Description
---

For parallel vm deployment guest vm password script is fixed by retrying after 
random sleep on failure.

Please review the changes and provide your comments so that I can commit this.

For windows guest VM script, changes for parallel vm deployment is not added.


Diffs
-

  setup/bindir/cloud-set-guest-password.in 3215894 

Diff: https://reviews.apache.org/r/13496/diff/


Testing
---

Tested by deploying 30 vms. All vms set its password successfully.


Thanks,

Jayapal Reddy

Re: Review Request 13472: make apache server listen on all the ipaliases to provide access to meta-data.

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13472/#review25001
---

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 12, 2013, 10:42 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13472/
> ---
> 
> (Updated Aug. 12, 2013, 10:42 a.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, Jayapal Reddy, Murali Reddy, 
> and Sheng Yang.
> 
> 
> Bugs: Cloudstack-4231
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4231
> make apache server listen on all the ipaliases to provide access to meta-data.
> 
> Earlier we were using the name data-server to access the meta-data in case of 
> multiple subnets. 
> This requires updating the guest templates. 
> 
> Now we make apache server listen on all the ipaliases. So no need to update 
> the template.
> we create separate file for each ipAlias 
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/etc/init.d/cloud-early-config a552d44 
>   patches/systemvm/debian/config/root/createIpAlias.sh 5498195 
>   patches/systemvm/debian/config/root/deleteIpAlias.sh fa228fb 
> 
> Diff: https://reviews.apache.org/r/13472/diff/
> 
> 
> Testing
> ---
> 
> Tested on 4.2
> deployed vms in different subnets.
> used the script cloud-set-guest-sshkey.in to fetch the public keys form the 
> router.
> was able to get the keys without using the name data-server.
> 
> deleted the subnet and checked if the apache config was removed.
> 
> ran a failure case, all the config files generated during this operation were 
> moved to failure_directory.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: anyone please: firewall rules application

[Jayapal Reddy Uradi]

Check the host logs (in xen /var/log/SMlog) to see which script is causing the 
failure.

Thanks,
jayapal

On 08-Aug-2013, at 4:43 PM, Daan Hoogland 
 wrote:

> I feel I am on a ghost hunt.
> 
> On Thu, Aug 8, 2013 at 10:32 AM, Daan Hoogland  
> wrote:
>> H,
>> 
>> I noted that in some of the 4.1 versions I have been testing setting a
>> firewall rule fails. This seems to be when a router is not fully
>> initialized, is it?
>> 
>> the stack trace seems to reflect this, but the error message just says
>> "Failed to create firewall rule" or "Failed to delete firewall rule"
>> 
>> com.cloud.exception.ResourceUnavailableException: Resource
>> [DataCenter:1] is unreachable: Unable to apply ip association, virtual
>> router is not in the right state
>> at 
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3445)
>> at 
>> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.associatePublicIP(VirtualNetworkApplianceManagerImpl.java:3272)
>> at 
>> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.associatePublicIP(VpcVirtualNetworkApplianceManagerImpl.java:554)
>> at 
>> com.cloud.network.element.VirtualRouterElement.applyIps(VirtualRouterElement.java:438)
>> at 
>> com.cloud.network.NetworkManagerImpl.applyIpAssociations(NetworkManagerImpl.java:625)
>> at 
>> com.cloud.network.NetworkManagerImpl.applyRules(NetworkManagerImpl.java:2380)
>> at 
>> com.cloud.network.firewall.FirewallManagerImpl.applyRules(FirewallManagerImpl.java:500)
>> at 
>> com.cloud.network.firewall.FirewallManagerImpl.applyFirewallRules(FirewallManagerImpl.java:630)
>> at 
>> com.cloud.network.firewall.FirewallManagerImpl.applyIngressFirewallRules(FirewallManagerImpl.java:603)
>> at 
>> org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.execute(CreateFirewallRuleCmd.java:124)
>> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
>> at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
>> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>> at java.util.concurrent.FutureTask.run(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>> at java.lang.Thread.run(Unknown Source)
>> 
>> Can someone confirm my suspicion?
>> 
>> thanks,
>> Daan

Re: Review Request 13320: In case when all the vnets are deleted we are not logging a error message if there are vnets allocated.

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13320/#review24775
---

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 6, 2013, 11:18 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13320/
> ---
> 
> (Updated Aug. 6, 2013, 11:18 a.m.)
> 
> 
> Review request for cloudstack and Jayapal Reddy.
> 
> 
> Bugs: Cloudstack-4105
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4105
> In case when all the vnets are deleted we are not logging a error message if 
> there are vnets allocated.
> Also not updating the physicalnetwork table in this case.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/dc/dao/DataCenterVnetDao.java de68e1e 
>   engine/schema/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java 3ac2729 
>   server/src/com/cloud/network/NetworkServiceImpl.java 304cefa 
> 
> Diff: https://reviews.apache.org/r/13320/diff/
> 
> 
> Testing
> ---
> 
> Tested on 4.2
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 12934: Tests for egress firewall rules for advance zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12934/#review24701
---

Ship it!


Ship It!

- Jayapal Reddy


On Aug. 6, 2013, 4:38 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12934/
> ---
> 
> (Updated Aug. 6, 2013, 4:38 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna 
> Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests for egress firewall rules for advance zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/12934/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 12934: Tests for egress firewall rules for advance zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12934/#review24640
---



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48746>

remove the white space (red colour).
Please apply the patch in your local and make sure there is no warning.
# git apply patchName.patch



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48747>

do we need specify vlan here ?



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48748>

Hard coding vlan may not work for others setups.
If specify vlan is set then query the free vlan id


- Jayapal Reddy


On Aug. 1, 2013, 6:19 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12934/
> ---
> 
> (Updated Aug. 1, 2013, 6:19 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna 
> Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests for egress firewall rules for advance zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/12934/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: is jira down. ?

[Jayapal Reddy Uradi]

Jira is down again.

Thanks,
Jayapal



On 05-Aug-2013, at 12:25 PM, Rajesh Battala 
mailto:rajesh.batt...@citrix.com>>
 wrote:

Jira is up now.
Looks like there was an issue with plugin and somebody Fixed it.

Thanks
Rajesh Battala

-Original Message-
From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
Sent: Monday, August 5, 2013 12:19 PM
To: dev@cloudstack.apache.org
Subject: is jira down. ?

Re: Review Request 12934: Tests for egress firewall rules for advance zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12934/#review24517
---



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48526>

I appreciate your effort in correcting the test cases.
There are few comments from my side. Please fix those.
Also the script is failed to run.Also look into this. The below exception 
is thrown


integration.component.test_egress_fw_rules.log_test_exceptions ... ERROR

==
ERROR: integration.component.test_egress_fw_rules.log_test_exceptions
--
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/nose/case.py", line 197, in 
runTest
self.test(*self.arg)
TypeError: log_test_exceptions() takes exactly 1 argument (0 given)




test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48519>

change the comment.
Egress policy is true



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48520>

fix the comment.
access to public network for tcp port 80 is blocked.



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48521>

Egress policy is not set to false, but comment says false. The above test 
case is already set to true



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48522>

Fix the comment, invalid cidr is passed to create the rule



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48523>

Invalid cidr is not passed to rule. fix the comment



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48524>

Fix the comment



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment48525>

Fix the comment


- Jayapal Reddy


On Aug. 1, 2013, 6:19 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12934/
> ---
> 
> (Updated Aug. 1, 2013, 6:19 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna 
> Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests for egress firewall rules for advance zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/12934/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: How to create Port Forwarding rule for VM through UI?

[Jayapal Reddy Uradi]

Hi Gaurav,

Port forwarding to work you need to create firewall rule also.

Thanks,
Jayapal

On 01-Aug-2013, at 5:38 PM, Daan Hoogland  wrote:

> network ->  -> IP Adresses ->  ->
> configuration -> Port Forwarding
> 
> On Mon, Jul 22, 2013 at 12:09 PM, Gaurav Aradhye
>  wrote:
>> Hi all,
>> 
>> Can anybody tell me how to create port forwarding rule for a specific vm
>> through Cloudstack UI?
>> You can just mention the navigational steps.
>> 
>> Regards,
>> Gaurav

Re: Review Request 12934: Tests for egress firewall rules for advance zone

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12934/#review24101
---



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47940>

I think you are not clear with the default egress policy. 

 - egress policy true
   All the guest network traffic to public n/w is allowed by default. 
Adding egress rule blocks only the rule specific traffic.
   
-egress policy false
By default guest network traffic to public n/w is block. if you add 
egress rule  then only egress rule specific traffic is allowed.

When egress policy is true, by default the guest network traffic is allow.

public network should be reachable



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47942>

here ping google.com should success.



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47941>

Please update all the comments in this file, network offering with egress 
policy .
# deploy vm with network offering egress policy true 



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47944>

Please understand the basics and update the test cases.

ping should be blocked. 100% packet loss



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47945>

mention the network offering with egress policy=false



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47946>

Here ping is success. 
I did not get why 100% packet loss ?



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47948>

In egress CIDR is not destination/public CIDR.
CIDR is guest network/source CIDR.

Please change the comments



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47949>

if 10.2.2.2 exists then ping will be success. 

You test case should be like.
give CIDR 10.1.1.120/32 and try to access wget from the vm 10.1.1.100. Then 
ping should fail from the 10.1.1.100 and pass from the vm with ip 10.1.1.120



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47950>

The purpose of the test is not correct.

The CIDR is source cidr, so testing public network is not needed.



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47951>


wget will be success.Why we get failed here ?



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47953>

here egress default policy is true. 
created egress rule for icmp , the icmp traffic is BLOCKED and other 
traffic is allowed.





test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47954>

connection to public should be allowed



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47952>

do we need second vm here ?



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47955>

here ping should fail here



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47956>

ping should success here



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47957>

Here you are passing valid CIDR.
The comment should be updated to 
'create egress rule with other than guest cidr'



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47958>

remove this comment



test/integration/component/test_egress_fw_rules.py
<https://reviews.apache.org/r/12934/#comment47959>

Remove this comment


- Jayapal Reddy


On July 29, 2013, 4:57 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12934/
> -------
> 
> (Updated July 29, 2013, 4:57 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna 
> Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests for egress firewall rules for advance zone.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/12934/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 12809: Fix for CLOUDSTACK-3703: change service offering of stopped vm on kvm is failing

[Jayapal Reddy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12809/#review24022
---


Patch failed to apply on 4.2.
Please update the patch

- Jayapal Reddy


On July 26, 2013, 10:05 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12809/
> ---
> 
> (Updated July 26, 2013, 10:05 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-3703
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3703: change service offering of stopped vm on kvm is failing
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java adcf475 
>   server/test/com/cloud/vm/UserVmManagerTest.java 0eb9a08 
> 
> Diff: https://reviews.apache.org/r/12809/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>