Re: KVM FC shared storage

[Kristian Liivak]

Indeed, Xenserver is good and our primary choice. We allready have it up and 
running..  
Why i ask KVM cluster its cloudstack lacks kubernetes csi driver support for 
xenserver.
And we want to use kubernetes.  My idea is just make one kvm cluster for 
kubernetes users.

Of cource we will check cloudstack csi integration, maybe we can make some 
changes to current csi to support xenserver..
But its wise to evaluete all options :)

Lugupidamisega / Best regards, 

Kristian Liivak 
Tegevjuht / CEO 
[ mailto:k...@wavecom.ee | k...@wavecom.ee ] | +372 5685 0001 

WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services 


Endla 16, Tallinn 10142 | [ http://www.wavecom.ee/ | www.wavecom.ee ] | [ 
http://www.facebook.com/wavecom.ee | www.facebook.com/wavecom.ee ]

- Original Message -
From: "Vivek Kumar" 
To: "CloudStack Users Mailing list" 
Sent: Tuesday, 21 May, 2024 08:47:22
Subject: Re: KVM FC shared storage

We once tried to setup PCS cluster with GFS2 In production, and it required a 
lot of expertise to manage PCS cluster and our experience was very bad with 
that too, after a year we had to move to NFS due to so many issue.  FC works 
better XenServer, We had almost for 5-6 year with Xenserver And FC and that too 
without any single downtime.

Vivek Kumar
Sr. Manager - Cloud & DevOps
TechOps | Indiqus Technologies

vivek.ku...@indiqus.com 
www.indiqus.com 




> On 20 May 2024, at 9:34 PM, Andreas S. Kerber  wrote:
> 
> We're running FC with OCFS2 (OS: Oracle Linux 9) on a demo 2 node cluster.
> Works kind of nice, but of course is not the same as ESXi. For now it works 
> well enough but expanding that to a actual >10 node setup with hundreds of 
> VMs doesn't feel right.
> 
> 
> Am Mon, May 20, 2024 at 03:48:12PM +0300 schrieb Kristian Liivak:
>> Hi All 
>> 
>> Currently, we can see from the documentation that KVM supports Fiber Channel 
>> via shared mountpoints. 
>> Can someone recommend or share their experience with usable solutions for 
>> shared mountpoint technical solutions? It seems there are quite a few 
>> options, such as shared/clustered file systems: GFS2, OCFS2, cLVM. 
>> From the information I have found, OCFS2 seems to be the best option. 
>> 
>> P.S. I don't want to use any distributed storage like Ceph, etc. 
>> We are partially moving away from VMware, and we believe in FC NVMe 
>> old-school storages, which are the most reliable, in my opinion. 
>> 
>> 
>> 
>> 
>> Lugupidamisega / Best regards, 
>> 
>> Kristian Liivak 
>> Tegevjuht / CEO 
>> [ mailto:k...@wavecom.ee | k...@wavecom.ee ] | +372 5685 0001 
>> 
>> WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services 
>> 
>> 
>> Endla 16, Tallinn 10142 | [ http://www.wavecom.ee/ | www.wavecom.ee ] | [ 
>> http://www.facebook.com/wavecom.ee | www.facebook.com/wavecom.ee ] 
>> 


-- 
This message is intended only for the use of the individual or entity to 
which it is addressed and may contain confidential and/or privileged 
information. If you are not the intended recipient, please delete the 
original message and any copy of it from your computer system. You are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited unless proper authorization has been 
obtained for such action. If you have received this communication in error, 
please notify the sender immediately. Although IndiQus attempts to sweep 
e-mail and attachments for viruses, it does not guarantee that both are 
virus-free and accepts no liability for any damage sustained as a result of 
viruses.

Re: KVM FC shared storage

[Vivek Kumar]

We once tried to setup PCS cluster with GFS2 In production, and it required a 
lot of expertise to manage PCS cluster and our experience was very bad with 
that too, after a year we had to move to NFS due to so many issue.  FC works 
better XenServer, We had almost for 5-6 year with Xenserver And FC and that too 
without any single downtime.

Vivek Kumar
Sr. Manager - Cloud & DevOps
TechOps | Indiqus Technologies

vivek.ku...@indiqus.com 
www.indiqus.com 




> On 20 May 2024, at 9:34 PM, Andreas S. Kerber  wrote:
> 
> We're running FC with OCFS2 (OS: Oracle Linux 9) on a demo 2 node cluster.
> Works kind of nice, but of course is not the same as ESXi. For now it works 
> well enough but expanding that to a actual >10 node setup with hundreds of 
> VMs doesn't feel right.
> 
> 
> Am Mon, May 20, 2024 at 03:48:12PM +0300 schrieb Kristian Liivak:
>> Hi All 
>> 
>> Currently, we can see from the documentation that KVM supports Fiber Channel 
>> via shared mountpoints. 
>> Can someone recommend or share their experience with usable solutions for 
>> shared mountpoint technical solutions? It seems there are quite a few 
>> options, such as shared/clustered file systems: GFS2, OCFS2, cLVM. 
>> From the information I have found, OCFS2 seems to be the best option. 
>> 
>> P.S. I don't want to use any distributed storage like Ceph, etc. 
>> We are partially moving away from VMware, and we believe in FC NVMe 
>> old-school storages, which are the most reliable, in my opinion. 
>> 
>> 
>> 
>> 
>> Lugupidamisega / Best regards, 
>> 
>> Kristian Liivak 
>> Tegevjuht / CEO 
>> [ mailto:k...@wavecom.ee | k...@wavecom.ee ] | +372 5685 0001 
>> 
>> WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services 
>> 
>> 
>> Endla 16, Tallinn 10142 | [ http://www.wavecom.ee/ | www.wavecom.ee ] | [ 
>> http://www.facebook.com/wavecom.ee | www.facebook.com/wavecom.ee ] 
>> 


-- 
This message is intended only for the use of the individual or entity to 
which it is addressed and may contain confidential and/or privileged 
information. If you are not the intended recipient, please delete the 
original message and any copy of it from your computer system. You are 
hereby notified that any dissemination, distribution or copying of this 
communication is strictly prohibited unless proper authorization has been 
obtained for such action. If you have received this communication in error, 
please notify the sender immediately. Although IndiQus attempts to sweep 
e-mail and attachments for viruses, it does not guarantee that both are 
virus-free and accepts no liability for any damage sustained as a result of 
viruses.

Re: Let's Encrypt

[Jayanth Babu A]

Hi Ian,
Yes. In this case, the ACS management server doesn’t need any additional 
configuration but you’ll have to take care of CPVM and SSVM (optionally) like 
Ruben suggested. Also see [1] where you should have a CA signed one instead.

[1] https://github.com/apache/cloudstack/discussions/9013

Regards,
Jayanth Reddy

From: Ian Tobin 
Date: Tuesday, 21 May 2024 at 5:40 AM
To: users@cloudstack.apache.org 
Subject: RE: Let's Encrypt
Hi Ruben,

Thanks for the info, do you mean running ACME on the reverse proxy? Anything 
needing to be configured on the ACS management server?

Thanks

Ian




-Original Message-
From: Ruben Bosch 
Sent: 20 May 2024 23:38
To: users@cloudstack.apache.org
Subject: Re: Let's Encrypt

Ian, this is easily achievable by means of an ACME client (Certbot) and running 
ACS management behind a reverse proxy. You can write a hook to upload a 
certificate to the CPVM as well. (
https://checkpoint.url-protection.com/v1/url?o=https%3A//cloudstack.apache.org/api/apidocs-4.16/apis/uploadCustomCertificate.html&g=NTI4NzIzY2NiZTM4YzE1Yw==&h=N2JiM2Q5ZTFmY2NiZDUwYTkxM2U0ODY5MmM2MjhlNjNkMWY4ZjlhNTQ0MWFjMDQwNTAwYWU1YzI4NDEwNjllMQ==&p=Y3AxZTpueHRnZW5pbmZpbml0ZWRhdGFjZW50ZXI6YzpvOmU1YWQ3MDZjNDAzYjhiMGQzNTM0MmZhMjcyZGIyODFhOnYxOnA6VA==)
Just be mindful that the CPVM requires a wildcard certificate.

On Mon, May 20, 2024 at 2:50 PM Ian Tobin 
wrote:

> Hi,
>
> Are there any plans to implement Let's Encrypt with CS? More so
> securing the Management console and Proxy.
>
> Thanks
>
> Ian
>
>
>
Disclaimer *** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
intended solely for the use of the addressee(s). If you are not the intended 
recipient, please notify the sender by e-mail and delete the original message. 
Further, you are not authorised to copy, disclose, or distribute this e-mail or 
its contents to any other person and any such actions are unlawful and strictly 
prohibited. This e-mail may contain viruses. NxtGen Datacenter & Cloud 
Technologies Private Ltd (“NxtGen”) has taken every reasonable precaution to 
minimize this risk but is not liable for any damage you may sustain as a result 
of any virus in this e-mail. You should carry out your own virus checks before 
opening the e-mail or attachment. NxtGen reserves the right to monitor and 
review the content of all messages sent to or from this e-mail address. 
Messages sent to or from this e-mail address may be stored on the NxtGen e-mail 
system. *** End of Disclaimer ***NXTGEN***

RE: BGP EVPN with CloudStack

[Hanis Irfan]

Hi Wido,

I'm currently running Rocky Linux 9 for the HV. 

> Why are you setting anything on cloudbr0? There is no need to create cloudbr0 
> with VXLAN.

cloudbr0 is just a naming choice on my end. Is it okay for me to use something 
like NetworkManager to create the bridge?

So, no need to create a VXLAN interface the as the bridge slave? Then how would 
the bridge communicate through the VXLAN tunnels? 

Assuming we're using VNI 10027.

lo (VTEP) < vxlan10027 (slave of bridge) < cloudbr0/cloudbr1

Shouldn't it be the same for the guest VNIs later on? E.g:

lo < vxlan1000 < vxlan1000br < vnet1 < Guest VM
^
|-vnet2 < Guest VM


> This /20 IPv4 is used for everything within CloudStack's communcation.
When talking about subnet size, the /20 is used for a couple of pods (row of 
racks) and not just a single pod, correct?
How do you calculate to allocate the range for system VMs in a pod? Considering 
maximum 16 hosts per cluster.
If let's say in the future we ran out of the /20 space (more than 4k host in a 
zone), we can connect new /20 subnets via a router, right?

> In *agent.properties* we have only set 'private.network.device=cloudbr1'
I actually got an issue when trying to add a new KVM host before. I got the 
error "resource not found". I was able to add the host if we restart the host 
OS while adding the host in the web UI.
I don't really configure anything in the *agent.properties* file before adding 
the host via the web UI. Did I did it wrong? Is there any deployment procedure 
that you can share with me?

> You first need to make sure that the HV can ping all the other loopback 
> addresses of the Leaf and Spine switches and all HVs can connect to eachother 
> via their loopback addresses.
I can assure you that the spine switches, leaf switches and HV can all ping 
each other via their loopback addresses. Just a note, all the L3 routing 
between the switches and the HV is configured BGP unnumbered and eBGP.

Thank you and sorry if there are unrelated questions in the thread.

Best Regards,

Hanis Irfan

-Original Message-
From: Wido den Hollander  
Sent: Tuesday, 21 May, 2024 04:06
To: Hanis Irfan ; users@cloudstack.apache.org
Subject: Re: BGP EVPN with CloudStack

Hi Hanis,

See my reply inline.

Op 17/05/2024 om 12:38 schreef Hanis Irfan:
> I think this is more about BGP EVPN than CloudStack but would 
> appreciate anyone that could help. So basically, I’ve tried the 
> Advanced Networking with VLAN isolation for my POC and now want to migrate to 
> VXLAN.
> 
> I would say that I’ve little to no knowledge about VXLAN in particular 
> and BGP EVPN. Why don’t I use multicast instead is because our spine 
> leaf switches have been already configured with basic EVPN (though not 
> tested yet).
> 
> We have 2 spine switches (Mellanox SN2700) and 2 leaf switches 
> (Mellanox
> SN2410) running BGP unnumbered for underlay between them. Underlay 
> between the hypervisor that is running FRR and the leaf switches also 
> configured with BGP unnumbered.
> 
> All the switches and hypervisor are assigned with 4-byte private ASN 
> individually. Here is the FRR config on the hypervisor, all basic config:
> 
> ```
> 
> ip forwarding
> 
> ipv6 forwarding
> 
> interface ens3f0np0
> 
>  no ipv6 nd suppress-ra
> 
> exit
> 
> interface ens3f1np1
> 
>  no ipv6 nd suppress-ra
> 
> exit
> 
> router bgp 420015
> 
>  bgp router-id 10.XXX.118.1
> 
>  no bgp ebgp-requires-policy
> 
>  neighbor uplink peer-group
> 
>  neighbor uplink remote-as external
> 
>  neighbor ens3f0np0 interface peer-group uplink
> 
>  neighbor ens3f1np1 interface peer-group uplink
> 
>  address-family ipv4 unicast
> 
>  network 10.XXX.118.1/32
> 
>  exit-address-family
> 
>  address-family ipv6 unicast
> 
>  network 2407::0:1::1/128
> 
>  neighbor uplink activate
> 
>  neighbor uplink soft-reconfiguration inbound
> 
>  exit-address-family
> 
>  address-family l2vpn evpn
> 
>  neighbor uplink activate
> 
>  neighbor uplink attribute-unchanged next-hop
> 
>  advertise-all-vni
> 
>  advertise-svi-ip
> 
>  exit-address-family
> 
> ```
> 
> Now I want to configure cloudbr0 bridge as the management interface 
> for ACS. I’ve done it like so:
> 
> ```
> 
> nmcli connection add type bridge con-name cloudbr0 ifname cloudbr0 \
> 
> ipv4.method manual ipv4.addresses 10.XXX.113.11/24 ipv4.gateway
> 10.XXX.113.1 \
> 
> ipv4.dns 1.1.1.1,8.8.8.8 \
> 
> ipv6.method manual ipv6.addresses 2407::200:c002::11/64 
> ipv6.gateway
> 2407::200:c002::1 \
> 
> ipv6.dns 2606:4700:4700::,2001:4860:4860:: \
> 
> bridge.stp no ethernet.mtu 9216
> 
> nmcli connection add type vxlan slave-type bridge con-name vxlan10027 
> ifname vxlan10027 \
> 
> id 10027 destination-port 4789 local 2407::0:1::1 vxlan.learning 
> no \
> 
> mast

RE: Let's Encrypt

[Ian Tobin]

Hi Ruben,

Thanks for the info, do you mean running ACME on the reverse proxy? Anything 
needing to be configured on the ACS management server?

Thanks

Ian




-Original Message-
From: Ruben Bosch  
Sent: 20 May 2024 23:38
To: users@cloudstack.apache.org
Subject: Re: Let's Encrypt

Ian, this is easily achievable by means of an ACME client (Certbot) and running 
ACS management behind a reverse proxy. You can write a hook to upload a 
certificate to the CPVM as well. (
https://cloudstack.apache.org/api/apidocs-4.16/apis/uploadCustomCertificate.html)
Just be mindful that the CPVM requires a wildcard certificate.

On Mon, May 20, 2024 at 2:50 PM Ian Tobin 
wrote:

> Hi,
>
> Are there any plans to implement Let's Encrypt with CS? More so 
> securing the Management console and Proxy.
>
> Thanks
>
> Ian
>
>
>

Re: Let's Encrypt

[Ruben Bosch]

Ian, this is easily achievable by means of an ACME client (Certbot) and
running ACS management behind a reverse proxy. You can write a hook to
upload a certificate to the CPVM as well. (
https://cloudstack.apache.org/api/apidocs-4.16/apis/uploadCustomCertificate.html)
Just be mindful that the CPVM requires a wildcard certificate.

On Mon, May 20, 2024 at 2:50 PM Ian Tobin 
wrote:

> Hi,
>
> Are there any plans to implement Let's Encrypt with CS? More so securing
> the Management console and Proxy.
>
> Thanks
>
> Ian
>
>
>

Re: Ubuntu templates CloudStack

[Ruben Bosch]

Take a look here https://github.com/CLDIN/packer-templates/ :)

On Mon, May 20, 2024 at 2:32 PM Francisco Arencibia Quesada <
arencibia.franci...@gmail.com> wrote:

> Thank you very much Alex
>
> Regards
>
> *Francisco Arencibia Quesada.*
> *DevOps Engineer*
>
>
> On Mon, 20 May 2024 at 14:30, Dietrich, Alex  .invalid>
> wrote:
>
> > Hi Francisco,
> >
> > I have found the existing Linux template guides as still valid for Ubuntu
> > 22.04 LTS template creation.
> >
> > There are some broken links in the documentation provided by CloudStack,
> > but I essentially completed it with the following articles:
> >
> >
> >   *
> >
> https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates.html#creating-a-linux-template
> >   *
> >
> https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates/_cloud_init.html
> >
> > Thanks,
> > Alex
> >
> > [photo]
> >
> > Alex Dietrich
> > Senior Network Engineer, US Signal
> >
> > 616-233-5094  |  www.ussignal.com<
> > https://www.ussignal.com>  |  adietr...@ussignal.com > adietr...@ussignal.com>
> >
> > 201 Ionia Ave SW, Grand Rapids, MI 49503
> > <
> https://www.google.com/maps/search/201+Ionia+Ave+SW,+Grand+Rapids,+MI+49503?entry=gmail&source=g
> >
> > <
> >
> https://maps.google.com/?q=201%20Ionia%20Ave%20SW,%20Grand%20Rapids,%20MI%2049503
> > >
> >
> > [linkedin]
> >
> > [facebook]
> >
> > [youtube]
> >
> > IMPORTANT: The contents of this email are confidential. Information is
> > intended for the named recipient(s) only. If you have received this email
> > by mistake, please notify the sender immediately and do not disclose the
> > contents to anyone or make copies thereof.
> >
> > [__tpx__]
> > From: Francisco Arencibia Quesada 
> > Date: Monday, May 20, 2024 at 7:45 AM
> > To: users@cloudstack.apache.org 
> > Subject: Ubuntu templates CloudStack
> > EXTERNAL
> >
> > Good morning guys,
> >
> > Do you have any updated guide to create ubuntu templates for cloudstack?
> > I'm testing some, but I can't find an updated one for 22.04TLS
> >
> > Regards
> > Thanks in advance
> >
> > --
> > *Francisco Arencibia Quesada.*
> > *DevOps Engineer*
> >
>

Re: BGP EVPN with CloudStack

[Wido den Hollander]

Hi Hanis,

See my reply inline.

Op 17/05/2024 om 12:38 schreef Hanis Irfan:
I think this is more about BGP EVPN than CloudStack but would appreciate 
anyone that could help. So basically, I’ve tried the Advanced Networking 
with VLAN isolation for my POC and now want to migrate to VXLAN.


I would say that I’ve little to no knowledge about VXLAN in particular 
and BGP EVPN. Why don’t I use multicast instead is because our spine 
leaf switches have been already configured with basic EVPN (though not 
tested yet).


We have 2 spine switches (Mellanox SN2700) and 2 leaf switches (Mellanox 
SN2410) running BGP unnumbered for underlay between them. Underlay 
between the hypervisor that is running FRR and the leaf switches also 
configured with BGP unnumbered.


All the switches and hypervisor are assigned with 4-byte private ASN 
individually. Here is the FRR config on the hypervisor, all basic config:


```

ip forwarding

ipv6 forwarding

interface ens3f0np0

     no ipv6 nd suppress-ra

exit

interface ens3f1np1

     no ipv6 nd suppress-ra

exit

router bgp 420015

     bgp router-id 10.XXX.118.1

     no bgp ebgp-requires-policy

     neighbor uplink peer-group

     neighbor uplink remote-as external

     neighbor ens3f0np0 interface peer-group uplink

     neighbor ens3f1np1 interface peer-group uplink

     address-family ipv4 unicast

     network 10.XXX.118.1/32

     exit-address-family

     address-family ipv6 unicast

     network 2407::0:1::1/128

     neighbor uplink activate

     neighbor uplink soft-reconfiguration inbound

     exit-address-family

     address-family l2vpn evpn

     neighbor uplink activate

     neighbor uplink attribute-unchanged next-hop

     advertise-all-vni

     advertise-svi-ip

     exit-address-family

```

Now I want to configure cloudbr0 bridge as the management interface for 
ACS. I’ve done it like so:


```

nmcli connection add type bridge con-name cloudbr0 ifname cloudbr0 \

ipv4.method manual ipv4.addresses 10.XXX.113.11/24 ipv4.gateway 
10.XXX.113.1 \


ipv4.dns 1.1.1.1,8.8.8.8 \

ipv6.method manual ipv6.addresses 2407::200:c002::11/64 ipv6.gateway 
2407::200:c002::1 \


ipv6.dns 2606:4700:4700::,2001:4860:4860:: \

bridge.stp no ethernet.mtu 9216

nmcli connection add type vxlan slave-type bridge con-name vxlan10027 
ifname vxlan10027 \


id 10027 destination-port 4789 local 2407::0:1::1 vxlan.learning no \

master cloudbr0 ethernet.mtu 9216 dev lo

nmcli connection up cloudbr0

nmcli connection up vxlan10027

```



Why are you setting anything on cloudbr0? There is no need to create 
cloudbr0 with VXLAN.


We only have created cloudbr1 (using systemd-networkd) for the POD 
communcation, but that's all:


*cloudbr1.network*
[Match]
Name=cloudbr1

[Network]
LinkLocalAddressing=no

[Address]
Address=10.100.2.108/20

[Route]
Gateway=10.100.1.1

[Link]
MTUBytes=1500

*cloudbr1.netdev*
[NetDev]
Name=cloudbr1
Kind=bridge


This /20 IPv4 is used for everything within CloudStack's communcation.

In *agent.properties* we have only set 'private.network.device=cloudbr1'

I can see that the EVPN route with MAC address of cloudbr0 can be seen 
on both leaf switches. However, I can’t ping from the hypervisor to its 
gateway (.1) which is a firewall running somewhere that’s connected to a 
switchport tagged with VLAN 27.




You first need to make sure that the HV can ping all the other loopback 
addresses of the Leaf and Spine switches and all HVs can connect to 
eachother via their loopback addresses.


Can you check that? That's not EVPN nor VXLAN, just /32 (IPv4) routing 
with BGP.


Wido

Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Wido den Hollander]

Op 20/05/2024 om 14:45 schreef Alex Mattioli:

Hi Alex,

In this scenario:


I think adding the ability to add network specific peers as mentioned in one of 
>your prior replies would still allow the level of control some operators (myself 
>included) may desire.


How do you propose network specific peers to be implemented?



I do agree with Alex (Dietrich) that I think BGP peers should be 
configured per network. There is no guarantee that every VLAN/VNI 
(VXLAN) ends up at the same pair of routers. Technically there is also 
no need to do so.


Let's say I have two VNI (VXLAN):

VNI 500:
Router 1: 192.168.153.1 / 2001:db8::153:1
Router 2: 192.168.153.2 / 2001:db8::153:2

VNI 600:
Router 1: 192.168.155.1 / 2001:db8::155:1
Router 2: 192.168.155.2 / 2001:db8::155:2

In these case you would say that the upstream BGP peers are .153.1/2, 
.155.1/2 (and their IPv6 addresses). No need for BGP multihop.


Talking about multihop, I would make that optional, people might want to 
have two central BGP routers where each VR peers with (multihop) and 
those routers distribute the routes into the network again.


Per network you create you also provide the ASN range, but even better 
would be to refer to a pool. You can use one pool for your zone by 
referencing every network to the same pool are simply use multiple pools 
if your network requires so.


That said, you could also opt that you can specify BGP peers are peer 
level and override them at network level if one prefers. Nothing 
specified at the network? The zone-level peers are used. If you do 
specify them at the network level those are used. Again, think about 
multihop.


Wido


Regards
Alex


  



-Original Message-
From: Dietrich, Alex 
Sent: Monday, May 20, 2024 2:21 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

This may be a difference in perspective in implementation of BGP at the tenant 
level. I see the ability this would provide to seamlessly establishing those 
peering relationships with minimal intervention (helping scalability).

I think adding the ability to add network specific peers as mentioned in one of 
your prior replies would still allow the level of control some operators 
(myself included) may desire.

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  |  
adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Alex Mattioli 
Date: Monday, May 20, 2024 at 7:51 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,


I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the >network configuration, or another 
more specific level.


I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Thursday, May 16, 2024 2:23 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


   *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: users@cloudst

Re: KVM FC shared storage

[Andreas S. Kerber]

We're running FC with OCFS2 (OS: Oracle Linux 9) on a demo 2 node cluster.
Works kind of nice, but of course is not the same as ESXi. For now it works 
well enough but expanding that to a actual >10 node setup with hundreds of VMs 
doesn't feel right.


Am Mon, May 20, 2024 at 03:48:12PM +0300 schrieb Kristian Liivak:
> Hi All 
> 
> Currently, we can see from the documentation that KVM supports Fiber Channel 
> via shared mountpoints. 
> Can someone recommend or share their experience with usable solutions for 
> shared mountpoint technical solutions? It seems there are quite a few 
> options, such as shared/clustered file systems: GFS2, OCFS2, cLVM. 
> From the information I have found, OCFS2 seems to be the best option. 
> 
> P.S. I don't want to use any distributed storage like Ceph, etc. 
> We are partially moving away from VMware, and we believe in FC NVMe 
> old-school storages, which are the most reliable, in my opinion. 
> 
> 
> 
> 
> Lugupidamisega / Best regards, 
> 
> Kristian Liivak 
> Tegevjuht / CEO 
> [ mailto:k...@wavecom.ee | k...@wavecom.ee ] | +372 5685 0001 
> 
> WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services 
> 
> 
> Endla 16, Tallinn 10142 | [ http://www.wavecom.ee/ | www.wavecom.ee ] | [ 
> http://www.facebook.com/wavecom.ee | www.facebook.com/wavecom.ee ] 
> 

Re: debian iso download

[Embedded Devel]

Welp, that did it, fixed... its in a lab we own so 3 people have access. 
thanks


On Monday 20 May 2024 09:18:46 PM (+07:00), Wei ZHOU wrote:

> If you use 4.19.0.1/4.18.2.0/4.18.1.1, URL redirection is disabled by
> default due to security reasons.
> 
> Please search global setting by keyword "follow.redirect" and update the

> value to true then retry.
> 
> 
> -Wei
> 
> On Monday, May 20, 2024, Embedded Devel 

> wrote:
> 
> > trying to download debian iso from https://cdimage.debian.org/deb

> > ian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
> >
> >
> > via the register iso button fails with Failed to download
> > https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/deb
> > ian-12.5.0-amd64-netinst.iso due to redirection, response code: 302
> >
> >
> > any way to manually upload an iso from cli ?
> > --
> > Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
> >
> 


--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

RE: debian iso download

[Fabricio Duarte]

Hello,

You should be able to upload an ISO via CLI using CloudMonkey and cURL:

1. Via CloudMonkey, call the `getUploadParamsForIso` API in order to 
obtain the parameters that will be used for upload.


```
(admin) 🐱 > get uploadparamsforiso name= 
displaytext= format="iso" zoneid=

```

The output should look like this:
```
{
  "getuploadparams": {
    "expires": "2024-05-20T14:17:30.466Z",
    "id": "afbd9fa8-ec98-4886-a958-29cb978e46e7",
    "metadata": 
"PmZ7p+TpMJNiNotZ+xzaNanPNbezskK5w2I7YX8A+tZQsVsCier5wMlO4mjf6wodvu2mUheKrBA2QTGf4wB/1+FQk/RVpMbJmbwJjOGh0huIqwnV9DWqmI7NodLitCvFVvoMg90+WR888mo5mgkoYKJ7qUEKtNH3c39gbh2eYC4VxDP9ELJOJLsW76KxG8298cmXV76gqzFHDQcVVJ+32HOTuX/innx3C6WvtcfuUH+XVG+6qbFFSMMtN1icMQWbgpkvJmuRr0hXMiWvTTZ1YcE0Xtlk/NSN2V6b42b46kawfPP0HzfsVo9RQijZ2y7UdjBKIbFkabQnVnXHNxONW/3aYmVfRtXqNhL+7x/xhfI4uLk8XbFyHm2Gx8OdPdjbV3/RBvbwUK5scWDjEczAyynxQGfRNkLjDCOGzSNv2JRT1qiHUm1srIFy/sMb7UP9E4REtk2WXUJRESf2ZgPiqsZxlsOz2oKpA8sTjhmM1kQu1j9iKyK1qAYY1yopiqleaI1tpMn/Yswu8+P1MnnKTn+0wOJNI013oW+OIW0zf4wd7Mw/PDSaXAtdJMzUGfoWxSRuoLLSEBYlkQOR1zV5/Xn9cMjQQoGboqJrW6o=",
    "postURL": 
"https://172.16.200.100/upload/afbd9fa8-ec98-4886-a958-29cb978e46e7";,

    "signature": "u9dvlWl9CdbtWnpon3LibWIAC64="
  }
}
```

2. Upload the ISO using cURL.

```
curl -X POST "" -H "X-signature:" -H 
"X-metadata:" \

    -H "X-expires:" -H "Expect:" \
    -F "file=@" -v
```

Replace the placeholders in the command with the values you got from 
`getUploadParamsForIso` and with the ISO's path. The header `Expect` 
should remain blank; otherwise, cURL will wait until the SSVM sends a 
signal to begin the upload, which will result in a timeout as the SSVM 
does not implement this feature. If your SSVMs do not have SSL 
termination configured or you do not have the CA keys, also add 
`--insecure` at the end of the command in order to disable certificate 
validation.


This method can be used to upload templates and volumes as well, calling 
either `getUploadParamsForTemplate` or `getUploadParamsForVolume` 
instead of the `getUploadParamsForIso` API.


On 2024/05/20 13:00:37 Embedded Devel wrote:
> trying to download debian iso from
> 
https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso

>
>
> via the register iso button fails with
> Failed to download
> 
https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso 


> due to redirection, response code: 302
>
>
> any way to manually upload an iso from cli ?
> --
> Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
>

Re: debian iso download

[Wei ZHOU]

If you use 4.19.0.1/4.18.2.0/4.18.1.1, URL redirection is disabled by
default due to security reasons.

Please search global setting by keyword "follow.redirect" and update the
value to true then retry.


-Wei

On Monday, May 20, 2024, Embedded Devel 
wrote:

> trying to download debian iso from https://cdimage.debian.org/deb
> ian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
>
>
> via the register iso button fails with Failed to download
> https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/deb
> ian-12.5.0-amd64-netinst.iso due to redirection, response code: 302
>
>
> any way to manually upload an iso from cli ?
> --
> Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
>

RE: KVM FC shared storage

[Alex Mattioli]

If you are 100% FC/NVME then OCFS2 is probably the best (or least bad) option.

I personally always tried to stick to NFS for KVM, it just works.

Reliability wise, I personally consider CEPH to be more reliable (and 
supportable) than OCFS2.

Regards
Alex

From: Kristian Liivak 
Sent: Monday, May 20, 2024 2:48 PM
To: users 
Subject: KVM FC shared storage

Hi All

Currently, we can see from the documentation that KVM supports Fiber Channel 
via shared mountpoints.
Can someone recommend or share their experience with usable solutions for 
shared mountpoint technical solutions? It seems there are quite a few options, 
such as shared/clustered file systems: GFS2, OCFS2, cLVM.
From the information I have found, OCFS2 seems to be the best option.

P.S. I don't want to use any distributed storage like Ceph, etc.
We are partially moving away from VMware, and we believe in FC NVMe old-school 
storages, which are the most reliable, in my opinion.




Lugupidamisega / Best regards,

Kristian Liivak
Tegevjuht / CEO
k...@wavecom.ee | +372 5685 0001

[cid:image001.png@01DAAACA.9761B690]
WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services
Endla 16, Tallinn 10142 | www.wavecom.ee | 
www.facebook.com/wavecom.ee


 

debian iso download

[Embedded Devel]

trying to download debian iso from 
https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso



via the register iso button fails with 
Failed to download 
https://cdimage.debian.org/debian-cd/12.5.0/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso 
due to redirection, response code: 302



any way to manually upload an iso from cli ?
--
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: KVM FC shared storage

[Dietrich, Alex]

Hello Kristian,

Take this perspective with a grain of salt given our time spent on this was in 
a proof-of-concept deployment.

We tested iSCSI connectivity with OCFS2 as the underlying technology to provide 
the shared mount point. We found that throughout the course of host reboots, 
the reliability of varying components re-establishing connectivity was not up 
to par with the reliability of the underlying storage technology (iSCSI). In a 
few cases, I found OCFS2 unable to establish peers with the other KVM 
hypervisors, which required rebuilding the OCFS2 cluster to re-establish 
connectivity.

The other mechanisms to create a shared mountpont were not tested as we pivoted 
away from the idea given our experience with OCFS2.

Thanks,
Alex


[__tpx__]
From: Kristian Liivak 
Date: Monday, May 20, 2024 at 8:48 AM
To: users 
Subject: KVM FC shared storage
EXTERNAL
Hi All

Currently, we can see from the documentation that KVM supports Fiber Channel 
via shared mountpoints.
Can someone recommend or share their experience with usable solutions for 
shared mountpoint technical solutions? It seems there are quite a few options, 
such as shared/clustered file systems: GFS2, OCFS2, cLVM.
From the information I have found, OCFS2 seems to be the best option.

P.S. I don't want to use any distributed storage like Ceph, etc.
We are partially moving away from VMware, and we believe in FC NVMe old-school 
storages, which are the most reliable, in my opinion.




Lugupidamisega / Best regards,

Kristian Liivak
Tegevjuht / CEO
k...@wavecom.ee | +372 5685 0001

[cid:58154b1f50b08ffef0dccd912a90853b36251804@zimbra]
WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services
Endla 16, Tallinn 10142 | 
www.wavecom.ee
 | 
www.facebook.com/wavecom.ee

Let's Encrypt

[Ian Tobin]

Hi,

Are there any plans to implement Let's Encrypt with CS? More so securing the 
Management console and Proxy.

Thanks

Ian

KVM FC shared storage

[Kristian Liivak]

Hi All 

Currently, we can see from the documentation that KVM supports Fiber Channel 
via shared mountpoints. 
Can someone recommend or share their experience with usable solutions for 
shared mountpoint technical solutions? It seems there are quite a few options, 
such as shared/clustered file systems: GFS2, OCFS2, cLVM. 
>From the information I have found, OCFS2 seems to be the best option. 

P.S. I don't want to use any distributed storage like Ceph, etc. 
We are partially moving away from VMware, and we believe in FC NVMe old-school 
storages, which are the most reliable, in my opinion. 




Lugupidamisega / Best regards, 

Kristian Liivak 
Tegevjuht / CEO 
[ mailto:k...@wavecom.ee | k...@wavecom.ee ] | +372 5685 0001 

WaveCom AS | ISO 9001, 27001 & 27017 Certified DC and Cloud services 


Endla 16, Tallinn 10142 | [ http://www.wavecom.ee/ | www.wavecom.ee ] | [ 
http://www.facebook.com/wavecom.ee | www.facebook.com/wavecom.ee ] 

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Alex,

In this scenario:

>I think adding the ability to add network specific peers as mentioned in one 
>of >your prior replies would still allow the level of control some operators 
>(myself >included) may desire.

How do you propose network specific peers to be implemented?

Regards
Alex


 


-Original Message-
From: Dietrich, Alex  
Sent: Monday, May 20, 2024 2:21 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

This may be a difference in perspective in implementation of BGP at the tenant 
level. I see the ability this would provide to seamlessly establishing those 
peering relationships with minimal intervention (helping scalability).

I think adding the ability to add network specific peers as mentioned in one of 
your prior replies would still allow the level of control some operators 
(myself included) may desire.

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  
|  adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Alex Mattioli 
Date: Monday, May 20, 2024 at 7:51 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> I am not convinced that specifying BGP peers at the zone level is a good idea 
> given the impacts BGP can have on a given network. I would much rather see 
> both peer and AS specification handled at the >network configuration, or 
> another more specific level.

I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Thursday, May 16, 2024 2:23 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


  *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> Would zone-level BGP peers be those used by default for establishing new BGP 
> peers in networks where dynamic routing is enabled?

Correct, so far we plan to allow for up to 4 BGP peers for a zone, with the 
possibility to setup different metrics to each peer.

> This could affect a multi-tenant model where there may be different BGP peers 
> presented based on what the upstream network provides. An example of >this 
> would be where the VLANs associated to a given account are associated to 
> distinct VRFs and may have different peering IP addresses.
> I would like to see the peering IP addresses specific to the networks where 
> dynamic routing is enabled instead of specifying defaults at the zone level.


This is a very valid point.  We could add network specific BGP peers as well, 
which would override the automatic AS allocation, in the same way that we now 
allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Cheers,
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 2:34 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: D

Re: Ubuntu templates CloudStack

[Francisco Arencibia Quesada]

Thank you very much Alex

Regards

*Francisco Arencibia Quesada.*
*DevOps Engineer*


On Mon, 20 May 2024 at 14:30, Dietrich, Alex 
wrote:

> Hi Francisco,
>
> I have found the existing Linux template guides as still valid for Ubuntu
> 22.04 LTS template creation.
>
> There are some broken links in the documentation provided by CloudStack,
> but I essentially completed it with the following articles:
>
>
>   *
> https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates.html#creating-a-linux-template
>   *
> https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates/_cloud_init.html
>
> Thanks,
> Alex
>
> [photo]
>
> Alex Dietrich
> Senior Network Engineer, US Signal
>
> 616-233-5094  |  www.ussignal.com<
> https://www.ussignal.com>  |  adietr...@ussignal.com adietr...@ussignal.com>
>
> 201 Ionia Ave SW, Grand Rapids, MI 49503
> 
> <
> https://maps.google.com/?q=201%20Ionia%20Ave%20SW,%20Grand%20Rapids,%20MI%2049503
> >
>
> [linkedin]
>
> [facebook]
>
> [youtube]
>
> IMPORTANT: The contents of this email are confidential. Information is
> intended for the named recipient(s) only. If you have received this email
> by mistake, please notify the sender immediately and do not disclose the
> contents to anyone or make copies thereof.
>
> [__tpx__]
> From: Francisco Arencibia Quesada 
> Date: Monday, May 20, 2024 at 7:45 AM
> To: users@cloudstack.apache.org 
> Subject: Ubuntu templates CloudStack
> EXTERNAL
>
> Good morning guys,
>
> Do you have any updated guide to create ubuntu templates for cloudstack?
> I'm testing some, but I can't find an updated one for 22.04TLS
>
> Regards
> Thanks in advance
>
> --
> *Francisco Arencibia Quesada.*
> *DevOps Engineer*
>

Re: Ubuntu templates CloudStack

[Dietrich, Alex]

Hi Francisco,

I have found the existing Linux template guides as still valid for Ubuntu 22.04 
LTS template creation.

There are some broken links in the documentation provided by CloudStack, but I 
essentially completed it with the following articles:


  *   
https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates.html#creating-a-linux-template
  *   
https://docs.cloudstack.apache.org/en/4.19.0.0/adminguide/templates/_cloud_init.html

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  
|  adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Francisco Arencibia Quesada 
Date: Monday, May 20, 2024 at 7:45 AM
To: users@cloudstack.apache.org 
Subject: Ubuntu templates CloudStack
EXTERNAL

Good morning guys,

Do you have any updated guide to create ubuntu templates for cloudstack?
I'm testing some, but I can't find an updated one for 22.04TLS

Regards
Thanks in advance

--
*Francisco Arencibia Quesada.*
*DevOps Engineer*

Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Dietrich, Alex]

Hi Alex,

This may be a difference in perspective in implementation of BGP at the tenant 
level. I see the ability this would provide to seamlessly establishing those 
peering relationships with minimal intervention (helping scalability).

I think adding the ability to add network specific peers as mentioned in one of 
your prior replies would still allow the level of control some operators 
(myself included) may desire.

Thanks,
Alex

[photo]

Alex Dietrich
Senior Network Engineer, US Signal

616-233-5094  |  www.ussignal.com  
|  adietr...@ussignal.com

201 Ionia Ave SW, Grand Rapids, MI 
49503

[linkedin]

[facebook]

[youtube]

IMPORTANT: The contents of this email are confidential. Information is intended 
for the named recipient(s) only. If you have received this email by mistake, 
please notify the sender immediately and do not disclose the contents to anyone 
or make copies thereof.

[__tpx__]
From: Alex Mattioli 
Date: Monday, May 20, 2024 at 7:51 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks
EXTERNAL

Hi Alex,

> I am not convinced that specifying BGP peers at the zone level is a good idea 
> given the impacts BGP can have on a given network. I would much rather see 
> both peer and AS specification handled at the >network configuration, or 
> another more specific level.

I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Thursday, May 16, 2024 2:23 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


  *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> Would zone-level BGP peers be those used by default for establishing new BGP 
> peers in networks where dynamic routing is enabled?

Correct, so far we plan to allow for up to 4 BGP peers for a zone, with the 
possibility to setup different metrics to each peer.

> This could affect a multi-tenant model where there may be different BGP peers 
> presented based on what the upstream network provides. An example of >this 
> would be where the VLANs associated to a given account are associated to 
> distinct VRFs and may have different peering IP addresses.
> I would like to see the peering IP addresses specific to the networks where 
> dynamic routing is enabled instead of specifying defaults at the zone level.


This is a very valid point.  We could add network specific BGP peers as well, 
which would override the automatic AS allocation, in the same way that we now 
allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Cheers,
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 2:34 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

I appreciate the clarity!

Excuse my ignorance if I am misunderstanding the intention of specifying BGP 
peers at the zone level.

Would zone-level BGP peers be those used by default for establishing new BGP 
peers in networks where dynamic routing is enabled?

This could affect a multi-tenant model where there may be different BGP peers 
presented based on what the upstream network provides. An example of this would 
be where the VLANs associate

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Alex,

> I am not convinced that specifying BGP peers at the zone level is a good idea 
> given the impacts BGP can have on a given network. I would much rather see 
> both peer and AS specification handled at the >network configuration, or 
> another more specific level.

I don't see how else end users would be able to automatically create routed 
networks without intervention from the operator.


Cheers
Alex

 


-Original Message-
From: Dietrich, Alex  
Sent: Thursday, May 16, 2024 2:23 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate this back and forth as I am excited about the potential this 
feature would hold.


  *   This is a very valid point.  We could add network specific BGP peers as 
well, which would override the automatic AS allocation, in the same way that we 
now allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Why does the network specific BGP peers need to override automatic AS 
allocation? In my mind there isn’t a dependency that needs to exist to those 
two as they are somewhat independent of one another.

I am not convinced that specifying BGP peers at the zone level is a good idea 
given the impacts BGP can have on a given network. I would much rather see both 
peer and AS specification handled at the network configuration, or another more 
specific level.

Thanks,
Alex

From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 10:15 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

> Would zone-level BGP peers be those used by default for establishing new BGP 
> peers in networks where dynamic routing is enabled?

Correct, so far we plan to allow for up to 4 BGP peers for a zone, with the 
possibility to setup different metrics to each peer.

> This could affect a multi-tenant model where there may be different BGP peers 
> presented based on what the upstream network provides. An example of >this 
> would be where the VLANs associated to a given account are associated to 
> distinct VRFs and may have different peering IP addresses.
> I would like to see the peering IP addresses specific to the networks where 
> dynamic routing is enabled instead of specifying defaults at the zone level.


This is a very valid point.  We could add network specific BGP peers as well, 
which would override the automatic AS allocation, in the same way that we now 
allocate DNS servers in the zone level but can override that by manually 
selecting different DNS servers at network creation time.  Would that address 
your point?

Cheers,
Alex




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 2:34 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hi Alex,

I appreciate the clarity!

Excuse my ignorance if I am misunderstanding the intention of specifying BGP 
peers at the zone level.

Would zone-level BGP peers be those used by default for establishing new BGP 
peers in networks where dynamic routing is enabled?

This could affect a multi-tenant model where there may be different BGP peers 
presented based on what the upstream network provides. An example of this would 
be where the VLANs associated to a given account are associated to distinct 
VRFs and may have different peering IP addresses.

I would like to see the peering IP addresses specific to the networks where 
dynamic routing is enabled instead of specifying defaults at the zone level.


  *   Alex

[__tpx__]
From: Alex Mattioli 
Date: Wednesday, May 15, 2024 at 9:27 AM
To: users@cloudstack.apache.org , 
d...@cloudstack.apache.org 
Subject: RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks EXTERNAL

Hi Alex,

Answers inline below with >

Cheers




-Original Message-
From: Dietrich, Alex 
Sent: Wednesday, May 15, 2024 3:12 PM
To: users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

Hello Alex,

I appreciate you taking on this initiative as I’d like to see similar 
functionality made available in CloudStack.

I do have some feedback on your implementation approach:

1 - Operator configures one or more BGP peers for a given Zone (with different 
metrics)

What is the intention behind specifying BGP peers at the zone level? I would 
think this would need to be specific to the network that you want to enable BGP 
on and does not need to concern the entire zone.

>The goal is for the process to be drive by the end user without operator 
>intervention. In the current design we'd enable the VR to share routes with 
>upstream routers

Ubuntu templates CloudStack

[Francisco Arencibia Quesada]

Good morning guys,

Do you have any updated guide to create ubuntu templates for cloudstack?
I'm testing some, but I can't find an updated one for 22.04TLS

Regards
Thanks in advance

-- 
*Francisco Arencibia Quesada.*
*DevOps Engineer*

RE: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC networks

[Alex Mattioli]

Hi Wido,

Thanks for the feedback,  comments below:

> I would suggest that the upstream router (Juniper, Frr, etc) should then use 
> Dynamic BGP neihbors.

That's the plan.

> I do suggest we add BGP passwords/encryption from the start for safety 
> reasons.

That's very likely to be there from day one.

> On the VR you just need to make sure you properly configure the BGP daemon 
> and it points to the right upstream routers.
Indeed, and we plan to use FRR for that.


Thanks for the link to the doc, I'll review it.

Cheers
Alex

 


-Original Message-
From: Wido den Hollander  
Sent: Friday, May 17, 2024 5:24 PM
To: d...@cloudstack.apache.org; Alex Mattioli ; 
users@cloudstack.apache.org
Subject: Re: Dynamic routing for routed mode IPv6 and IPv4 Isolated and VPC 
networks

My apologies! I totally missed this one. Commments inline.

Op 15/05/2024 om 14:55 schreef Alex Mattioli:
> Hi all,
> 
> Does anyone have an opinion on the implementation of dynamic routing in 
> Isolated networks and VPCs?
> 
> So far the design is:
> 
> 1 - Operator configures one or more BGP peers for a given Zone (with 
> different metrics)
> 2 - Operator presents a pool of Private AS numbers to the Zone (just 
> like we do for VLANs)
> 3 - When a network is created with an offering which has dynamic 
> routing enabled an AS number is allocated to the network
> 4 - ACS configures the BGP session on the VR (using FRR), advertising 
> all its connected networks
> 

I would suggest that the upstream router (Juniper, Frr, etc) should then use 
Dynamic BGP neihbors.

On JunOS this is the "allow" statement [0]. The VR would indeed get an AS 
assigned by ACS and the network should know the 1, 2 or X upstream routers it 
can peer with. I do suggest we add BGP passwords/encryption from the start for 
safety reasons.

"allow 192.168.1.0/24"

On JunOS this allows any router within that subnet to establish a BGP sessions 
(and when the BGP password matches).

On the VR you just need to make sure you properly configure the BGP daemon and 
it points to the right upstream routers.

[0]: 
https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/allow-edit-protocols-bgp.html

> Any and all input will be very welcome.
> 
> Cheers,
> Alex
> 
> 
>   
> 
> From: Alex Mattioli
> Sent: Wednesday, April 17, 2024 3:25 AM
> To: users@cloudstack.apache.org; d...@cloudstack.apache.org
> Subject: Dynamic routing for routed mode IPv6 and IPv4 Isolated and 
> VPC networks
> 
> Hi all,
> 
> I'd like to brainstorm dynamic routing in ACS (yes, again... for the 
> newcomers to this mailing list - this has been discussed multiple 
> times in the past 10+ years)
> 
> ACS 4.17 has introduced routed mode for IPv6 in Isolated networks and VPCs, 
> we are currently working on extending that to IPv4 as well, which will 
> support the current NAT'ed mode and also a routed mode (inspired by the NSX 
> integration https://www.youtube.com/watch?v=f7ao-vv7Ahk).
> 
> With stock ACS (i.e. without NSX or OpenSDN) this routing is purely static, 
> with the operator being responsible to add static routes to the Isolated 
> network or VPC tiers via the "public" (outside) IP of the virtual router.
> 
> The next step on this journey is to add some kind of dynamic routing. One way 
> that I have in mind is using dynamic BGP:
> 
> 1 - Operator configures one or more BGP peers for a given Zone (with 
> different metrics)
> 2 - Operator presents a pool of Private AS numbers to the Zone (just 
> like we do for VLANs)
> 3 - When a network is created with an offering which has dynamic 
> routing enabled an AS number is allocated
> 4 - ACS configures the BGP session on the VR, advertising all its 
> connected networks
> 
> This way there's no need to reconfigure the upstream router for each 
> new ACS network (it just needs to allow dynamic BGP peering from the 
> pool of AS numbers presented to the zone)
> 
> This implementation could also be used for Shared Networks, in which case the 
> destination advertised via BGP is to the gateway of the shared network.
> 
> There could also be an offering where we allow for end users to setup the BGP 
> parameters for their Isolated or VPC networks, which can then peer with 
> upstream VNF(s).
> 
> Any and all input is very welcome...
> 
> Taking the liberty to tag some of you: @Wei 
> Zhou @Wido den 
> Hollander @Kristaps 
> Čudars
> 
> Cheers,
> Alex
> 

Re: Create untagged guest VMs

[Alex K]

On Mon, May 20, 2024 at 10:47 AM Wei ZHOU  wrote:

> What type of zone and network do you use ?
>
I have tried both edge and core/advanced zones with KVM as hypervisor and
OVS switching as the underlying network stack. Now testing with
core-advanced zone. I have configured several traffic types and have
defined the labels for them. For example the public network is defined at
the physical network 1 and has label cloudbr0 as below:

[image: image.png]

But I am not able to add a vNIC at the guest VM which will be connected at
the cloudbr0 interface. Whatever I try all the VM NICs will be connected at
the guest network which is cloudbr2.


> Try network with vlan = "vlan://untagged"
>
For some reason all guest networks get a VLAN from the guest VLAN range
defined at the initial zone creation. There does not seem to be a way to
avoid this.

>
>
>
>
>
> On Friday, May 17, 2024, Alex K  wrote:
>
> > Hi All,
> >
> > Is it possible to create untagged guest networks in cloudstack and have
> > them assigned to different OVS bridges?
> >
> > I have created several OVS bridges at the KVM host and then tried to
> attach
> > the different VM NICs to the different OVS bridges without any VLAN
> > tagging, but it seems that whatever I try there is always VLAN tagging at
> > the guest VM interfaces at the VLAN ID range given at the initial zone
> > creation.
> >
> > Also any NIC I add at the VM seems to be mapped only at the single guest
> > network. Although I have defined different types of networks (guest,
> > management, public) during zone creation, defining also the traffic
> labels
> > according to the OVS bridge names, there does not seems to be a way to
> > attach these different networks to the different OVS bridges through the
> > cloudstack UI. My intention is to have the VM connected to different
> > networks, with or without VLAN tag.
> >
> > I am testing now with an edge zone with a KVM server.
> >
> > Thanks for any input.
> > Alex
> >
>

Re: Create untagged guest VMs

[Wei ZHOU]

What type of zone and network do you use ?

Try network with vlan = "vlan://untagged"





On Friday, May 17, 2024, Alex K  wrote:

> Hi All,
>
> Is it possible to create untagged guest networks in cloudstack and have
> them assigned to different OVS bridges?
>
> I have created several OVS bridges at the KVM host and then tried to attach
> the different VM NICs to the different OVS bridges without any VLAN
> tagging, but it seems that whatever I try there is always VLAN tagging at
> the guest VM interfaces at the VLAN ID range given at the initial zone
> creation.
>
> Also any NIC I add at the VM seems to be mapped only at the single guest
> network. Although I have defined different types of networks (guest,
> management, public) during zone creation, defining also the traffic labels
> according to the OVS bridge names, there does not seems to be a way to
> attach these different networks to the different OVS bridges through the
> cloudstack UI. My intention is to have the VM connected to different
> networks, with or without VLAN tag.
>
> I am testing now with an edge zone with a KVM server.
>
> Thanks for any input.
> Alex
>

Re: Create untagged guest VMs

[Alex K]

I understand this is not possible in cloudstack?

On Fri, May 17, 2024 at 3:57 PM Alex K  wrote:

> Hi All,
>
> Is it possible to create untagged guest networks in cloudstack and have
> them assigned to different OVS bridges?
>
> I have created several OVS bridges at the KVM host and then tried to
> attach the different VM NICs to the different OVS bridges without any VLAN
> tagging, but it seems that whatever I try there is always VLAN tagging at
> the guest VM interfaces at the VLAN ID range given at the initial zone
> creation.
>
> Also any NIC I add at the VM seems to be mapped only at the single guest
> network. Although I have defined different types of networks (guest,
> management, public) during zone creation, defining also the traffic labels
> according to the OVS bridge names, there does not seems to be a way to
> attach these different networks to the different OVS bridges through the
> cloudstack UI. My intention is to have the VM connected to different
> networks, with or without VLAN tag.
>
> I am testing now with an edge zone with a KVM server.
>
> Thanks for any input.
> Alex
>
>