答复: 回复：退订

[xusz]

申请退订 



 

-邮件原件-
发件人: users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.org
[mailto:users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.org]
代表 起观照智
发送时间: 2016年1月6日 10:26
收件人: users-cn
主题: 回复：退订

不予批准




-- 原始邮件 --
发件人: "王红雨";;
发送时间: 2016年1月6日(星期三) 上午8:42
收件人: "users-cn"; 

主题: 退订



sers-cn，您好！
 退订致礼！

Usage service with external database

[Dmitriy Pavlov]

Hello,

Is there any official way to separate "cloud" and "cloud_usage" 
databases between different servers? Like following:

mysql_server1 - runs "cloud" database
mysql_server2 - runs "cloud_usage" database

I have tried to dump cloud_usage database, move it to alternative server 
and point db.properties file via db.usage.host option to the IP address 
of new server, but cloudstack-usage service still tries to query 
cloud.usage_event table locally to server separated in db.usage.host and 
not via IP address from db.cloud.host.


Thanks,

Dmitriy

Billing software for CloudStack

[France]

Hi guys,

we need to be able to divide expenses of running the cloud on per compartment 
(customer).
We have been doing it by hand (with some simple scripts - and mistakes), but I 
would like to find an automated solution.
It can be payable/proprietary or open-source, as long as we can see how much of 
which resources who uses.

Any ideas?

Regards,
F.

Re: Billing software for CloudStack

[Rene Moser]

Hi

There is are a few, see slide 16 in
http://www.slideshare.net/ShapeBlue/introduction-and-news

Using Amysta.

Regards
René

Re: Billing software for CloudStack

[Calvin]

Hello ,



As you are looking for a billing solution for cloudstack, my company have a
great billing software that supports cloudStack, the solution is already
running in many production environments.

If you need more clarification about our solution please contact me
privately.



Best Regards.





2016-01-06 15:28 GMT+01:00 France :

> Hi guys,
>
> we need to be able to divide expenses of running the cloud on per
> compartment (customer).
> We have been doing it by hand (with some simple scripts - and mistakes),
> but I would like to find an automated solution.
> It can be payable/proprietary or open-source, as long as we can see how
> much of which resources who uses.
>
> Any ideas?
>
> Regards,
> F.
>
>
>

Re: Billing software for CloudStack

[Dustin Wright]

I used Ubersmith with some success.

> On Jan 6, 2016, at 9:38 AM, Calvin  wrote:
> 
> Hello ,
> 
> 
> 
> As you are looking for a billing solution for cloudstack, my company have a
> great billing software that supports cloudStack, the solution is already
> running in many production environments.
> 
> If you need more clarification about our solution please contact me
> privately.
> 
> 
> 
> Best Regards.
> 
> 
> 
> 
> 
> 2016-01-06 15:28 GMT+01:00 France :
> 
>> Hi guys,
>> 
>> we need to be able to divide expenses of running the cloud on per
>> compartment (customer).
>> We have been doing it by hand (with some simple scripts - and mistakes),
>> but I would like to find an automated solution.
>> It can be payable/proprietary or open-source, as long as we can see how
>> much of which resources who uses.
>> 
>> Any ideas?
>> 
>> Regards,
>> F.
>> 
>> 
>> 

Re: Billing software for CloudStack

[Mohammad Rastgoo]

We use Hostbill. We are satisfied but you need to redo the UI to make it
more fluent.

On Wed, Jan 6, 2016 at 11:21 AM Jeremy Peterson 
wrote:

> We use WHMCS and a custom built module.  The module will integrate with
> cloudstack to add domains networks users vm's from template and allow
> outbound traffic.  We integrate with the API.  I will talk to my co worker
> who built it and see if he can respond if anyone wants to know more about
> it.
>
> Jeremy
>
>
> -Original Message-
> From: Rene Moser [mailto:m...@renemoser.net]
> Sent: Wednesday, January 6, 2016 9:56 AM
> To: users@cloudstack.apache.org
> Subject: Re: Billing software for CloudStack
>
> Hi
>
> There is are a few, see slide 16 in
> http://www.slideshare.net/ShapeBlue/introduction-and-news
>
> Using Amysta.
>
> Regards
> René
>

RE: Billing software for CloudStack

[Jeremy Peterson]

We use WHMCS and a custom built module.  The module will integrate with 
cloudstack to add domains networks users vm's from template and allow outbound 
traffic.  We integrate with the API.  I will talk to my co worker who built it 
and see if he can respond if anyone wants to know more about it.

Jeremy


-Original Message-
From: Rene Moser [mailto:m...@renemoser.net] 
Sent: Wednesday, January 6, 2016 9:56 AM
To: users@cloudstack.apache.org
Subject: Re: Billing software for CloudStack

Hi

There is are a few, see slide 16 in
http://www.slideshare.net/ShapeBlue/introduction-and-news

Using Amysta.

Regards
René

Re: Network ACL granularity

[Erik Weber]

Can't answer your question, but to help out with ideas; are you mostly
looking for ingress, egress or both?

Also, is it primarily north-south traffic you want to isolate per vm or
east-west as well?

-- 

Erik

Den mandag 4. januar 2016 skrev Geoffrey Corey  følgende:

> What is the lowest granularity level that a network ACL can be applied?
>
> We would like to be able to apply a network ACL on a per-vm basis, but
> initial investigation points to only being able to apply it to a network
> tier.
>
> Also, if a network acl can be applied on a per-vm basis, how can that be
> accomplished?
>
> Thanks
>
> 
> Geoff Corey
> Apache Infrastructure
>

Re: Network ACL granularity

[Geoffrey Corey]

So we have a vpc, and we are trying to carve it up.

Ideally, we'd have an IP range for just "infrastructure" related vms, like
MXs, LDAP, etc. We want to be able to apply an ACL specifically to the MXs
whre only smtp and ssh (and possibly ping) are allowed into that VM, and
similar for ldap, etc, and have th ability to select these ACLs on a per-vm
basis (similar to how AWS allows this for network ACLs).

Right now, from what I can tell in the UI, we'd have to carve up, so to
speak, that "infrastructure" ip range into smaller networks in order to
apply these service related network acls

(Hope I was able to word that correctly)

On Wed, Jan 6, 2016 at 2:55 PM, Erik Weber  wrote:

> Can't answer your question, but to help out with ideas; are you mostly
> looking for ingress, egress or both?
>
> Also, is it primarily north-south traffic you want to isolate per vm or
> east-west as well?
>
> --
>
> Erik
>
>
> Den mandag 4. januar 2016 skrev Geoffrey Corey 
> følgende:
>
>> What is the lowest granularity level that a network ACL can be applied?
>>
>> We would like to be able to apply a network ACL on a per-vm basis, but
>> initial investigation points to only being able to apply it to a network
>> tier.
>>
>> Also, if a network acl can be applied on a per-vm basis, how can that be
>> accomplished?
>>
>> Thanks
>>
>> 
>> Geoff Corey
>> Apache Infrastructure
>>
>

Re: VPC virtual router NIC limit

[Erik Weber]

A theoretical change could be to switch from VLAN assigned VIFs to using
the VLAN feature in Linux kernel. That would give interface names like
eth0.100 instead of eth0-6. Would need one NIC for each physical Network
though.

And I do not know if all hypervisors supports trunk ports.


Erik

Den mandag 28. desember 2015 skrev Davide Pala 
følgende:

> Hi all.
> I've read about vpc and tiers, now i've a question. VPC's virtual router
> is a virtual machine and as the other vm it have some limit such as the max
> number of nic that an hypervisor can provide to vm (in xenserver this limit
> is set to 7) ...this mean that the vpc can have only 6 tier? there is a way
> to bypass this limit?
> thanks to all
>
> Davide Pala
> Infrastructure Specialist
> Gesca srl
>
> Via degli Olmetti, 18
> 00060 Formello (Roma)
> Office:  +39 06 9040661
> Fax: +39 06 9040
> E-mail: davide.p...@gesca.it  >
> Web:www.gesca.it
>
> [Descrizione: Descrizione: Descrizione: Descrizione: Descrizione:
> Descrizione: logoGescaPER FIRMA]
>
>

Re: VPC virtual router NIC limit

[Remi Bergsma]

I don't think that would work. Instead, we could change to openvswitch as that 
makes it way more flexibele. As far as I know there are no plans / is no one 
working on that right now. 

Sent from my iPhone

> On 06 Jan 2016, at 23:52, Erik Weber  wrote:
> 
> A theoretical change could be to switch from VLAN assigned VIFs to using
> the VLAN feature in Linux kernel. That would give interface names like
> eth0.100 instead of eth0-6. Would need one NIC for each physical Network
> though.
> 
> And I do not know if all hypervisors supports trunk ports.
> 
> 
> Erik
> 
> Den mandag 28. desember 2015 skrev Davide Pala 
> følgende:
> 
>> Hi all.
>> I've read about vpc and tiers, now i've a question. VPC's virtual router
>> is a virtual machine and as the other vm it have some limit such as the max
>> number of nic that an hypervisor can provide to vm (in xenserver this limit
>> is set to 7) ...this mean that the vpc can have only 6 tier? there is a way
>> to bypass this limit?
>> thanks to all
>> 
>> Davide Pala
>> Infrastructure Specialist
>> Gesca srl
>> 
>> Via degli Olmetti, 18
>> 00060 Formello (Roma)
>> Office:  +39 06 9040661
>> Fax: +39 06 9040
>> E-mail: davide.p...@gesca.it > >
>> Web:www.gesca.it
>> 
>> [Descrizione: Descrizione: Descrizione: Descrizione: Descrizione:
>> Descrizione: logoGescaPER FIRMA]
>> 
>> 

Working Debian template

[S . Brüseke - proIO GmbH]

Hi,

does someone created a working template with Debian 7 for CS?
I used 
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.6/templates.html#creating-a-linux-template
 but still have a problem with /etc/hosts.
I also tried https://gist.github.com/makuk66/6379642 and the fork at 
https://gist.github.com/srics/8e59654004fc38bed9fe

But I can still see "127.0.1.1 localhost.cs2cloud.internal localhost" and no 
replacement with the dhcp ip and the active hostname. hostname itself was 
changed to the correct one.

Any ideas?

Mit freundlichen Grüßen / With kind regards,

Swen




- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet. 

This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail in error) 
please notify 
the sender immediately and destroy this e-mail.  
Any unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden. 

Re: 答复: 回复：退订

[Peng Wei]

退订，谢谢。

2016-01-06 18:26 GMT+08:00 xusz :

> 申请退订
>
>
>
>
>
> -邮件原件-
> 发件人: users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.org
> [mailto:users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.org
> ]
> 代表 起观照智
> 发送时间: 2016年1月6日 10:26
> 收件人: users-cn
> 主题: 回复：退订
>
> 不予批准
>
>
>
>
> -- 原始邮件 --
> 发件人: "王红雨";;
> 发送时间: 2016年1月6日(星期三) 上午8:42
> 收件人: "users-cn";
>
> 主题: 退订
>
>
>
> sers-cn，您好！
>  退订 致礼！
>

RE: 答复: 回复：退订

[shenyefeng]

退订请查看
http://cloudstack.apache.org/mailing-lists.html

不要想当然

> -Original Message-
> From: Peng Wei [mailto:pwpeng...@gmail.com]
> Sent: Thursday, January 07, 2016 11:28 AM
> To: users-cn@cloudstack.apache.org
> Subject: Re: 答复: 回复：退订
> 
> 退订，谢谢。
> 
> 2016-01-06 18:26 GMT+08:00 xusz :
> 
> > 申请退订
> >
> >
> >
> >
> >
> > -邮件原件-
> > 发件人:
> users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.org
> >
> [mailto:users-cn-return-4890-xusz=chinanetcenter@cloudstack.apache.or
> g
> > ]
> > 代表 起观照智
> > 发送时间: 2016年1月6日 10:26
> > 收件人: users-cn
> > 主题: 回复：退订
> >
> > 不予批准
> >
> >
> >
> >
> > -- 原始邮件 --
> > 发件人: "王红雨";;
> > 发送时间: 2016年1月6日(星期三) 上午8:42
> > 收件人: "users-cn";
> >
> > 主题: 退订
> >
> >
> >
> > sers-cn，您好！
> >  退订 致礼！
> >

Re: Network ACL granularity

[Christopher Falk]

Hi Geoffrey, 

I asked a similar question a while back. You are correct - ACLs can be applied 
only to tiers in a VPC, and all rules apply to all *destination* IP addresses 
in the VPC. Of course any server without a static NAT will not receive traffic. 

If you want to open only port 25 to a mail server and only port 443 to a web 
server, they either need to be in different tiers or you need to use firewalls 
on the VM end to block the unwanted ports. 

The design of the tiers seems intended for a traditional web app with front end 
web servers, an app server tier, and a DB tier. It expects tiers to be used 
mostly for servers with similar firewalling requirements. 

What would make this much easier would be to provide both source and 
destination options in the ACL so that traffic could be limited to a specific 
destination IP address in the VPC. It could even be done by providing a 
drop-down of existing static NATs configured at the time of the ACL edit. 

Coming from a network administration background I would expect to see ACLs in 
VPCs work like a firewall normally does - source and destination IP and port. 
The current model of source, port and ingress/egress with the implied 
destination of the entire tier is a security risk in most actual use cases 
where an administrator doesn't want certain ports to be exposed for all the VMs 
in a tier. 

c 


From: "Geoffrey Corey"  
To: "Erik Weber"  
Cc: users@cloudstack.apache.org 
Sent: Wednesday, January 6, 2016 6:03:02 PM 
Subject: Re: Network ACL granularity 

So we have a vpc, and we are trying to carve it up. 

Ideally, we'd have an IP range for just "infrastructure" related vms, like 
MXs, LDAP, etc. We want to be able to apply an ACL specifically to the MXs 
whre only smtp and ssh (and possibly ping) are allowed into that VM, and 
similar for ldap, etc, and have th ability to select these ACLs on a per-vm 
basis (similar to how AWS allows this for network ACLs). 

Right now, from what I can tell in the UI, we'd have to carve up, so to 
speak, that "infrastructure" ip range into smaller networks in order to 
apply these service related network acls 

(Hope I was able to word that correctly) 

On Wed, Jan 6, 2016 at 2:55 PM, Erik Weber  wrote: 

> Can't answer your question, but to help out with ideas; are you mostly 
> looking for ingress, egress or both? 
> 
> Also, is it primarily north-south traffic you want to isolate per vm or 
> east-west as well? 
> 
> -- 
> 
> Erik 
> 
> 
> Den mandag 4. januar 2016 skrev Geoffrey Corey  
> følgende: 
> 
>> What is the lowest granularity level that a network ACL can be applied? 
>> 
>> We would like to be able to apply a network ACL on a per-vm basis, but 
>> initial investigation points to only being able to apply it to a network 
>> tier. 
>> 
>> Also, if a network acl can be applied on a per-vm basis, how can that be 
>> accomplished? 
>> 
>> Thanks 
>> 
>>  
>> Geoff Corey 
>> Apache Infrastructure 
>> 
> 

Re: Network ACL granularity

[Geoffrey Corey]

Thanks Christopher for the feedback.

Just wanted to confirm I wasn't missing an option somewhere. :-)
On Jan 6, 2016 6:50 PM, "Christopher Falk" <
christopher.f...@reliablenetworks.com> wrote:

> Hi Geoffrey,
>
> I asked a similar question a while back. You are correct - ACLs can be
> applied only to tiers in a VPC, and all rules apply to all *destination* IP
> addresses in the VPC. Of course any server without a static NAT will not
> receive traffic.
>
> If you want to open only port 25 to a mail server and only port 443 to a
> web server, they either need to be in different tiers or you need to use
> firewalls on the VM end to block the unwanted ports.
>
> The design of the tiers seems intended for a traditional web app with
> front end web servers, an app server tier, and a DB tier. It expects tiers
> to be used mostly for servers with similar firewalling requirements.
>
> What would make this much easier would be to provide both source and
> destination options in the ACL so that traffic could be limited to a
> specific destination IP address in the VPC. It could even be done by
> providing a drop-down of existing static NATs configured at the time of the
> ACL edit.
>
> Coming from a network administration background I would expect to see ACLs
> in VPCs work like a firewall normally does - source and destination IP and
> port. The current model of source, port and ingress/egress with the implied
> destination of the entire tier is a security risk in most actual use cases
> where an administrator doesn't want certain ports to be exposed for all the
> VMs in a tier.
>
> c
>
> --
> *From: *"Geoffrey Corey" 
> *To: *"Erik Weber" 
> *Cc: *users@cloudstack.apache.org
> *Sent: *Wednesday, January 6, 2016 6:03:02 PM
> *Subject: *Re: Network ACL granularity
>
> So we have a vpc, and we are trying to carve it up.
>
> Ideally, we'd have an IP range for just "infrastructure" related vms, like
> MXs, LDAP, etc. We want to be able to apply an ACL specifically to the MXs
> whre only smtp and ssh (and possibly ping) are allowed into that VM, and
> similar for ldap, etc, and have th ability to select these ACLs on a per-vm
> basis (similar to how AWS allows this for network ACLs).
>
> Right now, from what I can tell in the UI, we'd have to carve up, so to
> speak, that "infrastructure" ip range into smaller networks in order to
> apply these service related network acls
>
> (Hope I was able to word that correctly)
>
> On Wed, Jan 6, 2016 at 2:55 PM, Erik Weber  wrote:
>
> > Can't answer your question, but to help out with ideas; are you mostly
> > looking for ingress, egress or both?
> >
> > Also, is it primarily north-south traffic you want to isolate per vm or
> > east-west as well?
> >
> > --
> >
> > Erik
> >
> >
> > Den mandag 4. januar 2016 skrev Geoffrey Corey 
> > følgende:
> >
> >> What is the lowest granularity level that a network ACL can be applied?
> >>
> >> We would like to be able to apply a network ACL on a per-vm basis, but
> >> initial investigation points to only being able to apply it to a network
> >> tier.
> >>
> >> Also, if a network acl can be applied on a per-vm basis, how can that be
> >> accomplished?
> >>
> >> Thanks
> >>
> >> 
> >> Geoff Corey
> >> Apache Infrastructure
> >>
> >
>

Re: VPC virtual router NIC limit

[Erik Weber]

>From a technical or code perspective?

How would changing to openvswitch change anything in this scenario?

-- 
Erik

On Thu, Jan 7, 2016 at 7:16 AM, Remi Bergsma 
wrote:

> I don't think that would work. Instead, we could change to openvswitch as
> that makes it way more flexibele. As far as I know there are no plans / is
> no one working on that right now.
>
> Sent from my iPhone
>
> > On 06 Jan 2016, at 23:52, Erik Weber  wrote:
> >
> > A theoretical change could be to switch from VLAN assigned VIFs to using
> > the VLAN feature in Linux kernel. That would give interface names like
> > eth0.100 instead of eth0-6. Would need one NIC for each physical Network
> > though.
> >
> > And I do not know if all hypervisors supports trunk ports.
> >
> >
> > Erik
> >
> > Den mandag 28. desember 2015 skrev Davide Pala 
> > følgende:
> >
> >> Hi all.
> >> I've read about vpc and tiers, now i've a question. VPC's virtual router
> >> is a virtual machine and as the other vm it have some limit such as the
> max
> >> number of nic that an hypervisor can provide to vm (in xenserver this
> limit
> >> is set to 7) ...this mean that the vpc can have only 6 tier? there is a
> way
> >> to bypass this limit?
> >> thanks to all
> >>
> >> Davide Pala
> >> Infrastructure Specialist
> >> Gesca srl
> >>
> >> Via degli Olmetti, 18
> >> 00060 Formello (Roma)
> >> Office:  +39 06 9040661
> >> Fax: +39 06 9040
> >> E-mail: davide.p...@gesca.it  >> >
> >> Web:www.gesca.it
> >>
> >> [Descrizione: Descrizione: Descrizione: Descrizione: Descrizione:
> >> Descrizione: logoGescaPER FIRMA]
> >>
> >>
>