Advanced Networking with CloudStack

2013-11-09 Thread Joshua
Hello guys,

I have a special client request that I'm not quite certain the most secure
way to fulfil.

Client wants to host a virtual office environment of Windows VMs on the
cloud but needs the VMs to be connected to an onsite print/scan/fax. Access
to all VMs must be available at this same onsite office via thinclients but
some VMs must also be able to be RDPed in from a remote location.

My first instinct would be to install a virtual router with a single static
IP (maybe 2) but I'm not sure if there will be any negative implications of
such a setup. Onsite, there would be a VPN compatible router that would
talk to the virtual router to establish the VPN so that the onsite
thinclients can connect to the VMs via RDP to their internal IPs. Since the
printer is plugged to the same VPN router, this would allow all VMs connect
to the printer directly.

Regarding the issue about external RDP, the virtual router would forward
specific ports to specific computers. Targets will be identified via the
port being connected to - i.e. x.x.x.x:1 redirects to VM1:3389, 2
to VM2:3389 etc. I understand that I can modify the listen port on RDP but
these VMs will be created from template so a common port would be the least
troublesome.

Alternatively, the virtual router could authenticate the redirections via
MAC address but I think this would be an administrative nightmare.

So after reading my wall of text, my questions would be:

1. Any VPN routers that work well with CloudStack?

2. Can someone point me to some links on how to setup the virtual router
based on the above requirements?

3. Do advise if not having a particular static IP for the VPN router (means
the virtual router would have to listen to traffic from all global traffic)
would be opening a can of worms.

Thank you in advance.

Regards,
Joshua


Re: the plea to openstack

2013-11-09 Thread Daan Hoogland
H, I finally got around reading it. Good read indeed. I wonder how
(if) we can organize ourselves and our communication so as to
circumvent the traps described. I think the apache model takes some of
it for us but doesn't keep us completely save. Not to worry to much
though. Let us trust in the ways of human nature, a little ;)


On Wed, Nov 6, 2013 at 10:05 PM, Donal Lafferty
 wrote:
> The Conway Law reference is a good to keep in mind as we enter the next 
> collab conference.  (http://en.wikipedia.org/wiki/Conway's_law)
>
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> Sent: 06 November 2013 20:02
>> To: dev@cloudstack.apache.org
>> Subject: Re: the plea to openstack
>>
>> Agreed it's a very good read.
>>
>> -Sebastien
>>
>> On 6 Nov 2013, at 17:34, Marcus Sorensen  wrote:
>>
>> > http://stochasticresonance.wordpress.com/2013/11/04/openstack-a-plea/
>> >
>> > I thought this was an interesting read. There might be some things
>> > CloudStack could learn or issues it could avoid by keeping some of his
>> > points in mind.


Re: write access on cwiki

2013-11-09 Thread Daan Hoogland
On Thu, Nov 7, 2013 at 1:22 PM, Sanjeev Neelarapu
 wrote:
> sanjeevn


you're added


Re: Review Request 12192: set the field 'state' rather than the unread parameter 'state', if the parameter is null

2013-11-09 Thread daan Hoogland

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

Ship it!


3fd95fe231bdde6045b81fae0f6ff1bd4c2c0918

- daan Hoogland


On June 29, 2013, 9:08 p.m., Dave Brosius wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12192/
> ---
> 
> (Updated June 29, 2013, 9:08 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> code checks the parameter 'state' and if null, set it to Allocated, even 
> though that parameter is never accessed. Meant to set the field 'state'.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/network/dao/NetworkVO.java 6580ea0 
> 
> Diff: https://reviews.apache.org/r/12192/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dave Brosius
> 
>



Re: [PROPOSAL] Liaison with ETSI NFV ISG

2013-11-09 Thread Daan Hoogland
I don't mind being involved if needed.

On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers  wrote:
> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
>> 2013/11/7 Chiradeep Vittal 
>>
>> > While I appreciate the confidence, there are weekly calls to attend.
>> > The particularly interesting one (MANO WG) happens on Wednesdays at 6am
>> > PST.
>> > I've tried but there's very little chance that I can attend these
>> > meetings.
>> > Anybody in a more agreeable timezone?
>> >
>>
>> Not sure if I have permitted to join, I'm in agreeable timezone (9pm at
>> local time). It's great and I'm willing to join to liaison team.
>
> I'd say you are...  you're a committer on the project.  Perhaps you and
> Chiradeep can discuss how to get involved?


Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

2013-11-09 Thread Daan Hoogland
H Guys,

Can you shoot at my claims below, please?

syncing being optional does not conflict with the code being in the
core server. It seems that making a plugin for this is misuse of the
plugin mechanism. To me it is more of an option to switch on or of
with a global setting, having some extra configuration.

Also, cloudstack being a slave to the real user db is a separate issue
from cloudstack syncing its copy.

As for answerring the cap; this is a security answer as well as an
operational answer.

thanks,
Daan

On Sat, Nov 9, 2013 at 1:53 AM, Chip Childers  wrote:
> We are already (generally) AP for most infra changes really. I'd use that 
> model. Eventual consistency is better in this scenario.
>
>> On Nov 8, 2013, at 6:49 PM, Chiradeep Vittal  
>> wrote:
>>
>> I'd also like to highlight that it isn't a trivial problem.
>> Let's say there's 3 regions: this means there are 3 copies of the user
>> database that are geographically separated by network links that fail
>> quite often (orders of magnitude more than intra-DC networks).
>>
>> Here we run into the consequences of the CAP theorem [1].
>> We can either have a CP or AP system: either approach makes some tradeoffs:
>> 1. If we run a AP system, then the challenge is to resolve conflicting
>> updates
>> 2. If we run a CP system, then the challenge is to detect partitions
>> reliably and disallow updates during partitions.
>>
>> [1] http://en.wikipedia.org/wiki/CAP_theorem
>>
>>> On 11/7/13 11:58 AM, "Chip Childers"  wrote:
>>>
>>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
>>>  wrote:
 It may be an admin burden, but it has to be optional. There are other
 ways
 to achieve global sync (e.g., LDAP/AD/Oauth).
 A lot of service providers who run cloudstack have their own user
 database
 / portal. In their implementations the CloudStack database is not the
 master source of user records, but a slave.
>>>
>>> +1 to it being optional.
>>


Re: Ask for help with the "snapshot of volume" feature

2013-11-09 Thread Daan Hoogland
H Sunsbin,

It seems your question is about kvm and not about CloudStack, is it?
Can you give some context to your question?

Your English is good and your question is otherwise clear,
Daan

On Thu, Nov 7, 2013 at 6:58 AM, Sunsbin  wrote:
> Hello,everyone,
>   I'm a coder from Beijing in China,and it is the first time that I ask 
> for help here.
>   I'm learning cs4.0.2,and I found the "snapshot of volume" feature has 2 
> parts:creating snapshot and backupping snapshot.In backupping snapshot 
> parts,I'm confused of the "-s $snapshotName" parameter in the command " 
> $qemu_img convert -f qcow2 -O qcow2 -s $snapshotname $disk 
> $destPath/$destName".
>   my testing steps as follows:("test-vm is always running")
>1、Create a_snapshot on test-vm with the libvirt api 
> "domain.snapshotCreateXML().
>2、Write /a.txt on the test-vm
>3、“ qemu-img convert -f qcow2 -O qcow2 -s a_snapshot test-vm.disk 
> /tmp/testvm_a_ss”
>(test-vm.disk is the source disk of test-vm on the primary storage)
>4、define a "test-vm-ss" xml in /etc/libvirt/qemu with /tmp/testvm_a_ss 
> as its source.
>5、“virsh define test-vm-ss;virsh start test-vm-ss”
>As my results,and confused, I found the a.txt on the "test-vm-ss" vm. 
> Does the "-s a_snapshot" parameter work?
>   Thank you very much!I'm sorry for my English ability,but I'm looking 
> forward to your help very much.


RE: 4.2.1 BVT automation results

2013-11-09 Thread Rayees Namathponnan
Hi David,

Failures are due to test case issues, details are updated below

https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automation+Result 

Regards,
Rayees 

-Original Message-
From: David Nalley [mailto:da...@gnsa.us] 
Sent: Friday, November 08, 2013 11:27 AM
To: dev@cloudstack.apache.org
Subject: Re: 4.2.1 BVT automation results

Thats less than ideal, but better than no testing.
Did bugs get filed for the failing tests in 4.2.1?

--David

On Fri, Nov 8, 2013 at 10:43 AM, Rayees Namathponnan 
 wrote:
> 4.2.1 automation not executed from jenkins.buildacloud.org,
>
> Automation executed in side my company including vmware,
>
> Regards,
> Rayees
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Friday, November 08, 2013 12:20 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.2.1 BVT automation results
>
>
> On Nov 7, 2013, at 9:54 AM, Rayees Namathponnan 
>  wrote:
>
>> Hi Sebastian,
>>
>> I don't think so we are running automation  4.2.1 branch in 
>> jenkins.buildacloud.org,  below result is from master branch;
>>
>
> So how did you come up with the results for the 4.2.1 branch ?
>
>> http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matr
>> ix/
>>
>> Also I reported master failures in ASF jira
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5050
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5049
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5047
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5046
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5045
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4835
>>
>>
>> NOTE : I ran automation with RHEL 6.3
>>
>> Regards,
>> Rayees
>>
>> -Original Message-
>>
>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> Sent: Thursday, November 07, 2013 12:29 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.2.1 BVT automation results
>>
>>
>> On Nov 6, 2013, at 6:07 PM, Rayees Namathponnan 
>>  wrote:
>>
>>> Hi All,
>>>
>>> 4.2.1 BVT automation results published to cwiki; you can see the 
>>> results below
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automat
>>> ion+Result
>>>
>>> Regards,
>>> Rayees
>>>
>>
>> Where are those results coming from ?
>>
>> The qa and simulator jobs on 
>> http://jenkins.buildacloud.org/view/simulator/ seem to have been 
>> failing for a while
>>
>> Also it would be great if the results table could have the OS version. 
>> Technically we need to have each set run on ubuntu 12.04 and Centos6.4.
>>
>> -sebastien
>>
>>
>>>
>>
>


RE: [ACS43] Schedule reminder : feature freeze today 11/08

2013-11-09 Thread Animesh Chaturvedi
I have created the branch and kicked off jenkins build job

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, November 08, 2013 4:16 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [ACS43] Schedule reminder : feature freeze today 11/08
> 
> Folks one final reminder I will cut the 4.3 branch tomorrow morning.
> 
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Monday, November 04, 2013 9:58 PM
> > To: dev@cloudstack.apache.org
> > Subject: [ACS43] Schedule reminder : feature freeze this Friday 11/08
> >
> > Folks
> >
> > Friday 11/8 is the feature freeze date for ACS 4.3. If your
> > contribution is unlikely to make it to 4.3 feature freeze on 11/8
> > please move them out of 4.3 release to 'Future'.
> >
> > Do remember that we have a 72 hour notice period to solicit feedback
> > for MERGE requests. So the absolute last day for merge requests for
> > 4.3 features/ improvements is tomorrow 11/05. Contributors if you have
> > patches in reviewboard that you had planned for 4.3 make sure to
> > follow up with reviewers. The contribution has to be in master after
> > satisfying any merge concerns / review comments  by 11/08 to be
> > included  in 4.3.0 release.
> >
> >
> > For detailed branch merge requirement check [1]
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Ex
> > pe
> > ctations
> >
> >
> > Thanks
> > Animesh
> >



lxc about cloudstack4.2

2013-11-09 Thread Du Jun
Hi,all
Does cloudstack4.2 really support lxc?I feel confused that the lxc
template for system vm as installation guide shows actually is a
*.qcow2 format image for kvm!!!
Besides,I try to build a heterogeneous hypervisor cloudstack,I
work as follwing steps:
Create zone
Add a KVM cluster -> add a KVM host -> wait for systemvms to start
Add a LXC cluster -> add a LXC host

It seems to be work for creating systemvm and uer-vm in KVM cluster.

But I am now failed to create user-vm in LXC cluster.

Would you please give me some advice?


Best regards,
Frank


Fwd: F5: Failed to create VLAN

2013-11-09 Thread BJO ERN
Guys, I hope that there is someone who can help me.
After investing days now to get F5 loadbalancer and Cloudstack (4.2.1 build
from sources) I'm pretty much stuck, mostly due to lack of information and
documentation.

I got to a point now where Cloudstack wants to provision a VLAN to spin up
the first VR but it just bails out, what ever I do. Even worse it makes no
sense, the VLAN is created on the F5 so I guess there is just a bug going
on :

*Error Message cloudstack :*

2013-11-09 22:03:49,041 DEBUG [agent.transport.Request]
(Job-Executor-25:job-71 = [ 081a9bd4-6d4d-40d2-9868-48f6aca0116e ]) Seq
7-671875076: Sending  { Cmd , MgmtId: 110493122496, via: 7, Ver: v1, Flags:
100011, [{"com.cloud.agent.api.ro
uting.IpAssocCommand":{"ipAddresses":[{"accountId":1,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"vlanId":"651","vlanGateway":"10.161.2.168","vlanNetmask":"255.255.254.0","networkRate":200}],"accessDetails":{},"wait":
0}}] }
2013-11-09 22:03:49,041 DEBUG [agent.transport.Request]
(Job-Executor-25:job-71 = [ 081a9bd4-6d4d-40d2-9868-48f6aca0116e ]) Seq
7-671875076: Executing:  { Cmd , MgmtId: 110493122496, via: 7, Ver: v1,
Flags: 100011, [{"com.cloud.agent.api
.routing.IpAssocCommand":{"ipAddresses":[{"accountId":1,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"vlanId":"651","vlanGateway":"10.161.2.168","vlanNetmask":"255.255.254.0","networkRate":200}],"accessDetails":{},"wai
t":0}}] }
2013-11-09 22:03:49,042 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-220:null) Seq 7-671875076: Executing request
2013-11-09 22:03:49,316 DEBUG [network.resource.F5BigIpResource]
(DirectAgent-220:null) Creating a guest VLAN with tag 651
2013-11-09 22:03:49,398 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) *Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Failed to create vlan with
tag 651*
2013-11-09 22:03:49,467 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Retrying IpAssocCommand. Number of retries
remaining: 1
2013-11-09 22:03:49,662 DEBUG [network.resource.F5BigIpResource]
(DirectAgent-220:null) Creating a guest VLAN with tag 651
2013-11-09 22:03:49,685 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Exception caught in
Networking::urn:iControl:Networking/VLAN::create()
Exception: Common::OperationFailed
primary_error_code   : 16908390 (0x01020066)
secondary_error_code : 0
error_string : 01020066:3: The requested VLAN
(/Common/vlan-651) already exists in partition Common.
2013-11-09 22:03:49,685 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Exception caught in
Networking::urn:iControl:Networking/VLAN::c
reate()
Exception: Common::OperationFailed
primary_error_code   : 16908390 (0x01020066)
secondary_error_code : 0
error_string : 01020066:3: The requested VLAN
(/Common/vlan-651) already exists in partition Common.
2013-11-09 22:03:49,701 DEBUG
[storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) Zone 1
is ready to launch secondary storage VM
2013-11-09 22:03:49,765 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Retrying IpAssocCommand. Number of retries
remaining: 0
2013-11-09 22:03:49,910 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
(consoleproxy-1:null) Zone 1 is ready to launch console proxy
2013-11-09 22:03:49,956 DEBUG [network.resource.F5BigIpResource]
(DirectAgent-220:null) Creating a guest VLAN with tag 651
2013-11-09 22:03:49,976 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Exception caught in
Networking::urn:iControl:Networking/VLAN::create()
Exception: Common::OperationFailed
primary_error_code   : 16908390 (0x01020066)
secondary_error_code : 0
error_string : 01020066:3: The requested VLAN
(/Common/vlan-651) already exists in partition Common.
2013-11-09 22:03:49,977 ERROR [network.resource.F5BigIpResource]
(DirectAgent-220:null) Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Exception caught in
Networking::urn:iControl:Networking/VLAN::create()
Exception: Common::OperationFailed
primary_error_code   : 16908390 (0x01020066)
secondary_error_code : 0
error_string : 01020066:3: The requested VLAN
(/Common/vlan-651) already exists in partition Common.
2013-11-09 22:03:49,977 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-220:null) Seq 7-671875076: Response Received:

*Errors I see in the LTM log:*

*Nov  9 22:03:48 f5-ltmve-001 err mcpd[6030]: 01020066:3: The requested
VLAN (/Common/vlan-651) already exists in partition*
*Nov  9 22:03:48 f5-ltmve-001 err mcpd[6030]: 01020066:3: The requested
VLAN (/Common/vlan-651) already exists in partition*

Unfortunately the VLAN has been created that's why I see two errors (retry
parameter in cloudstack is 2) in F

Some feedback after going through cloudstack install

2013-11-09 Thread BJO ERN
Hi guys,

some critique to the overall cloudstack project in hope to improve it.
I personally would wish that this projects dedicates more resources into
documentation or ironing out the product.
Some issues I had during the installation of cloudstack :

- Lack of a feature matrix (What constellation is supported)

- Feature un-parity for KVM hypervisor
  - Snapshots finally improving
  - no native iscsi suppoort

- SG in Advanced Zones implementation is really bad in 4.2
  - Virtually downgrading advanced mode into a basic mode
  - No NAT, internal LB service implemented

- Lack of documentation in certain areas is shocking
  - Really bad is the external loadbalancer part

- Most user issues during installation are coming from the clunky SSVM
  - Get rid of this VM and use processes on the hypervisor

- No userdata support in the GUI (filed CLOUDSTACK-5120)

- Sill no hyper-V support ...

I personally want to support the project, even with dev activities but in
the current state I;m stuck with cloudstack I'm not optimistic if it can
advance against other IAAS solutions.
I created already ticket for some issues I found.

Cheers,
Bjoern