Re: Physical network labels when using VXLAN

[Muhammad Hanis Irfan Mohd Zaid]

On the web UI, when setting up a zone, how would I create the physical
networks and assign the correct traffic types and labels?

You can refer to a simple diagram I drew below.
https://drive.google.com/file/d/1_xGUxEu-U2mJltdIj94CMK0s4zAH-Ret/view?usp=drive_link

So let's say based on the diagram, I create a physical network named
"Management", an isolation method "VLAN", with traffic type "MANAGEMENT"
and label of "cloudbr0". Next, I create another physical network named
"Public", an isolation method "VXLAN", with traffic type "PUBLIC" and label
of "lo". Lastly, I create another physical network named "Guest", an
isolation method "VXLAN", with traffic type "GUEST" and label of "lo".

Will this work? Is my understanding of physical networks correct?



On Thu, 20 Jun 2024 at 20:21, Wido den Hollander 
wrote:

>
>
> Op 20/06/2024 om 11:15 schreef Alex Mattioli:
> > Hi Muhammad,
> >
> > Are you planning on using VXLAN or bridges?  Those are mutually
> exclusive, with VXLAN you have a single VLAN interface with an IP which is
> the VTEP (Virtual Tunnel EndPoint) for your VXLAN encapsulated traffic.
>
> Yes, however, keep in mind that the script 'modifyvxlan.sh' creates
> Linux bridges on the fly, one for each VNI.
>
> The administrator doesn't need to do anything though, this is all done
> by CS.
>
> Just make sure you use this script:
> https://download.cloudstack.org/tools/scripts/vxlan/modifyvxlan.sh
>
> Wido
>
> >
> > Cheers
> > Alex
> >
> >
> >
> >
> > -Original Message-
> > From: Muhammad Hanis Irfan Mohd Zaid 
> > Sent: Thursday, June 20, 2024 8:59 AM
> > To: users@cloudstack.apache.org
> > Cc: w...@widodh.nl
> > Subject: Physical network labels when using VXLAN
> >
> > Hi. We're trying to deploy a POC environment with VXLAN EVPN. The
> underlay works perfectly and the overlay when creating a bridge for the
> management network (cloudbr0) can ping without any issues between the hosts
> and management server.
> >
> > Now I'm trying to figure out how the bridges should be configured for
> the guest and public network. The hosts are fully running L3 towards our
> leaf switches. I'm clueless when trying to configure the physical networks
> of the zone in the web UI.
> >
> > Any suggestions? Thanks
>

Re: [D] Building DEB packages: "mvn -P deps" [cloudstack]

[via GitHub]

GitHub user boring-cyborg[bot] added a comment to the discussion: Building DEB 
packages: "mvn -P deps"

Thanks for opening your first issue here! Be sure to follow the issue template!


GitHub link: 
https://github.com/apache/cloudstack/discussions/9280#discussioncomment-9833398


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Building DEB packages: "mvn -P deps" [cloudstack]

[via GitHub]

GitHub user abh1sar added a comment to the discussion: Building DEB packages: 
"mvn -P deps"

I wasn't able to reproduce the issue.
`mvn -P deps` is working for me fine. I tried with 4.19 and main on Ubunutu.

```
00:01 cloudstack $ mvn -P deps  
 
[INFO] Scanning for projects... 
 
[INFO] 
[INFO] Reactor Build Order: 
 
[INFO]  
 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration   [jar]
[INFO] Apache CloudStack  [pom] 

...
```

@scsynergy can you please check if this is still an issue.
cc @rohityadavcloud 

GitHub link: 
https://github.com/apache/cloudstack/discussions/9280#discussioncomment-9833400


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Building DEB packages: "mvn -P deps" [cloudstack]

[via GitHub]

GitHub user rohityadavcloud added a comment to the discussion: Building DEB 
packages: "mvn -P deps"

Hi @scsynergy thanks for sharing, I think the docs may be old/incorrect which 
we should fix in due course.
Meanwhile, you can refer to this on building cloudstack - 
https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#building-cloudstack 
and packaging 
https://github.com/shapeblue/hackerbook/blob/main/2-dev.md#cloudstack-packaging

GitHub link: 
https://github.com/apache/cloudstack/discussions/9280#discussioncomment-9833399


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache Ports 443 and 8443 are listening in CPVM...and IP are 
> reachable 
> ![image](https://private-user-images.githubusercontent.com/54799446/324764500-70144f4d-2818-42d5-b297-d767d79f56bc.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTM4NjM3MzgsIm5iZiI6MTcxMzg2MzQzOCwicGF0aCI6Ii81NDc5OTQ0Ni8zMjQ3NjQ1MDAtNzAxNDRmNGQtMjgxOC00MmQ1LWIyOTctZDc2N2Q3OWY1NmJjLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDIzVDA5MTAzOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTNhODY4MTk5MTM4MzNmMDU0MWRkNmEwN2IwYmM0Y2FlYjViYTg4ZWQ1ZGQ1Mjk4YTVmN2I0N2ZkMjg3ODA1NzkmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.P2cfhADI-NUpCAN60iLCnS-dtWTsoYiIRYNYfO6p8-o)

any error/exception in /var/log/cloud.log in CPVM ?


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831869


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
No errors found on CPVM..
![image](https://github.com/apache/cloudstack/assets/54799446/acecd838-7019-4474-97fb-a7a9975e2b19)


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831870


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache No errors found on CPVM.. 
> ![image](https://private-user-images.githubusercontent.com/54799446/324770823-acecd838-7019-4474-97fb-a7a9975e2b19.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTM4NjQ0ODMsIm5iZiI6MTcxMzg2NDE4MywicGF0aCI6Ii81NDc5OTQ0Ni8zMjQ3NzA4MjMtYWNlY2Q4MzgtNzAxOS00NDc0LTk3ZmItYTdhOTk3NWUyYjE5LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDIzVDA5MjMwM1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTlmY2E3YjBhNjdiNjg4NWIxNDQ5ZWQ2ZjlkNGJmYjg1ZDJmMzZiOWEyNzliNjc4NjBkZDJiYWNhYTcxYjQwMDYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.waYeEXdj3n_7GbdRexe_k0uRlMUJwSyrDe_AMMkKI5I)

is dns working ?

check dnsname:443 or dnsname:8443 by nc or telnet

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831871


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user DaanHoogland added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache I tried a telnet to 443 and 8443443 is not connected 
> ![image](https://private-user-images.githubusercontent.com/54799446/324776677-26027310-5031-4405-9aea-b21db0d3ac9c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTM5NTE3NDgsIm5iZiI6MTcxMzk1MTQ0OCwicGF0aCI6Ii81NDc5OTQ0Ni8zMjQ3NzY2NzctMjYwMjczMTAtNTAzMS00NDA1LTlhZWEtYjIxZGIwZDNhYzljLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDI0VDA5MzcyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThkZmJiYTE2OWVkY2VkYjA3ZTYzYzIyM2I2MmJkZGEyNDY1ZGFhYjNmZDNlMmRlMDA5NjBjMGViZDkwZjUwMWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.m0BUJXllwjU2yz2zlXgMPKX09zNsZ0LeURxUzQwRW0Y)

@vishnuvs369 are these attempts from outside your cloud?
if yes, check if there is a firewall keeping you from connecting.
if no, can you share the firewall rules in your cpvm, and a traceroute from 
where you are trying to access your console?

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831875


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache I tried a telnet to 443 and 8443443 is not connected 
> ![image](https://private-user-images.githubusercontent.com/54799446/324776677-26027310-5031-4405-9aea-b21db0d3ac9c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTM4NjUwNzUsIm5iZiI6MTcxMzg2NDc3NSwicGF0aCI6Ii81NDc5OTQ0Ni8zMjQ3NzY2NzctMjYwMjczMTAtNTAzMS00NDA1LTlhZWEtYjIxZGIwZDNhYzljLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDIzVDA5MzI1NVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMwZDQwN2NiZTIyYzkyMjZjNzJkMjQwYzUwYWNmMDA2N2VhMzliMmM3NzM2NGI4NTA5MDg0MWRiMWNlZTE0ZWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.Zm1LfEnhFrbvKKn_UoZedgUsPAf_RHER0ACNPNDdWZI)

both 443/8443 should work

you can go to CPVM, and check if 127.0.0.1 443/8443 and public ip 443/8443 work


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831873


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
Ports 443 and 8443 are listening in CPVM...and IP are reachable
![image](https://github.com/apache/cloudstack/assets/54799446/70144f4d-2818-42d5-b297-d767d79f56bc)


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831868


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache I restarted management server and destoyed system vm's, still 
> its not working.

@vishnuvs369 
is the DNS name resolvable ?
check if ip and port 443/8443 are reachable from the client/browser
check if port 443/8443 is on listen in CPVM
...

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831867


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user sureshanaparti added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> > @weizhouapache I tried a telnet to 443 and 8443443 is not connected 
> > ![image](https://private-user-images.githubusercontent.com/54799446/324776677-26027310-5031-4405-9aea-b21db0d3ac9c.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTM5NTE3NDgsIm5iZiI6MTcxMzk1MTQ0OCwicGF0aCI6Ii81NDc5OTQ0Ni8zMjQ3NzY2NzctMjYwMjczMTAtNTAzMS00NDA1LTlhZWEtYjIxZGIwZDNhYzljLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA0MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNDI0VDA5MzcyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPThkZmJiYTE2OWVkY2VkYjA3ZTYzYzIyM2I2MmJkZGEyNDY1ZGFhYjNmZDNlMmRlMDA5NjBjMGViZDkwZjUwMWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.m0BUJXllwjU2yz2zlXgMPKX09zNsZ0LeURxUzQwRW0Y)
> 
> @vishnuvs369 are these attempts from outside your cloud? if yes, check if 
> there is a firewall keeping you from connecting. if no, can you share the 
> firewall rules in your cpvm, and a traceroute from where you are trying to 
> access your console?

Hi @vishnuvs369 Any update on this, are you able to check the firewall rules, 
anything blocking there?

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831876


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
I'm able to telnet 443/8443 from public IP and 127.0.0.1 but not able to telnet 
443 from domain name where as 8443 is working.
where i have gone wrong?

![image](https://github.com/apache/cloudstack/assets/54799446/077d88d5-e5ec-4451-bfdd-7cf52aec040b)


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831874


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
I tried a telnet to 443 and 8443443 is not connected
![image](https://github.com/apache/cloudstack/assets/54799446/26027310-5031-4405-9aea-b21db0d3ac9c)


GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831872


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

> @weizhouapache I enabled the following settings in global settings 
> consoleproxy.ssl True secstorage.encrypt.copy True
> 
> Also Added domains in the below fields consoleproxy.url.domain 
> secstorage.ssl.cert.domain

If you have restarted the management server, destroy the system vms and retry

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831865


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user weizhouapache added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@vishnuvs369 
what are the related globals settings ?
check https://www.shapeblue.com/securing-cloudstack-4-11-with-https-tls/

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831863


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
I restarted management server and destoyed system vm's, still its not working.

GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831866


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: [D] Unable to Secure CloudStack System VMs with Dynamic URL [cloudstack]

[via GitHub]

GitHub user vishnuvs369 added a comment to the discussion: Unable to Secure 
CloudStack System VMs with Dynamic URL

@weizhouapache 
I enabled the following settings in global settings 
consoleproxy.ssl  True
secstorage.encrypt.copy True

Also Added domains in the below fields
consoleproxy.url.domain 
secstorage.ssl.cert.domain



GitHub link: 
https://github.com/apache/cloudstack/discussions/9278#discussioncomment-9831864


This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org

Re: Physical network labels when using VXLAN

[Wido den Hollander]

Op 20/06/2024 om 11:15 schreef Alex Mattioli:

Hi Muhammad,

Are you planning on using VXLAN or bridges?  Those are mutually exclusive, with 
VXLAN you have a single VLAN interface with an IP which is the VTEP (Virtual 
Tunnel EndPoint) for your VXLAN encapsulated traffic.


Yes, however, keep in mind that the script 'modifyvxlan.sh' creates 
Linux bridges on the fly, one for each VNI.


The administrator doesn't need to do anything though, this is all done 
by CS.


Just make sure you use this script: 
https://download.cloudstack.org/tools/scripts/vxlan/modifyvxlan.sh


Wido



Cheers
Alex

  



-Original Message-
From: Muhammad Hanis Irfan Mohd Zaid 
Sent: Thursday, June 20, 2024 8:59 AM
To: users@cloudstack.apache.org
Cc: w...@widodh.nl
Subject: Physical network labels when using VXLAN

Hi. We're trying to deploy a POC environment with VXLAN EVPN. The underlay 
works perfectly and the overlay when creating a bridge for the management 
network (cloudbr0) can ping without any issues between the hosts and management 
server.

Now I'm trying to figure out how the bridges should be configured for the guest 
and public network. The hosts are fully running L3 towards our leaf switches. 
I'm clueless when trying to configure the physical networks of the zone in the 
web UI.

Any suggestions? Thanks

Re: cloud-init fails on newer ubuntu?

[Jayanth Babu A]

Just remembered that Ubuntu 24.04 hasn't yet been added as a template. Testing 
this out and will let you know.

Thanks,
Jayanth

Sent on the move

Sent from Outlook for Android

From: jordan j 
Sent: Thursday, June 20, 2024 5:30:45 PM
To: users@cloudstack.apache.org 
Subject: cloud-init fails on newer ubuntu?

Hi everyone,

Currently I have a test setup where these 4 OSs are tested with cloud-init
and  Cloudstack 4.19.0.1 :
- Ubuntu 22 server - work!
- Ubuntu 24 server - does not work
- Ubuntu 22 desktop - does not work
- Ubuntu 24 desktop - does not work

The config script is the same on all 4 instances.
All template instances are started in the same network with the same VR.
The error on the failed ones is:
2024-06-20 09:07:18,172 - util.py[WARNING]: Getting data from  failed

I can query successfully the metadata from the failed instances.
Do you have any suggestions why those 3 fail while the 22 server is running
properly? I have been looking at the ins and outs of that for a few days
now with no success.

Regards,
Jordan
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: VM automation using API

[Jayanth Babu A]

IIRC, we had attempted to start over 200 instances as async jobs using API. 
Jobs were scheduled and hadn't really observed issues with the API. VMs were 
scheduled and took some time to start, and this was totally dependent on 
hypervisors.

Should be safe with Ansible, but test if possible.

Thanks,
Jayanth

Sent on the move

Sent from Outlook for Android


From: Gary Dixon 
Sent: Thursday, June 20, 2024 5:23:00 pm
To: users@cloudstack.apache.org 
Subject: FW: VM automation using API

Hi all – just giving this a bump if anyone has any suggestions ?

[cid:image447262.png@A7D7E810.87CE4A08]
Gary Dixon
Quadris Cloud Manager
[cid:image663715.png@3C367AE0.83D2B03D]
+44 (0) 161 537 4980
 +44 (0) 7989 717661
[cid:image897214.png@9D57B117.5F07090B]
gary.di...@quadris.co.uk
[cid:image385470.png@6A06D3CE.42F99D43]
https://checkpoint.url-protection.com/v1/url?o=www.quadris.com&g=Njk5ZDcxNGQ4ZmY1MjhiNg==&h=OGYxNjA0OGFjYmQ3NzRjYjRhMTRhNjFlMTQ2NmY4Y2I4MmE4OGUwZTU5NmU1N2RhZDYzNGIzMGJlMDc5YjMyOQ==&p=Y3AxZTpueHRnZW5pbmZpbml0ZWRhdGFjZW50ZXI6YzpvOjg0ZDQyNDNlMDI0YWE1ZjgyZjQwODNkNmZhZDkzMjQyOnYxOnQ6VA==
[cid:image331178.png@B826C723.3D6026E1]
Innovation House, 12‑13 Bredbury Business Park
Bredbury Park Way, Bredbury, Stockport, SK6 2SN
From: Gary Dixon 
Sent: Wednesday, June 19, 2024 10:25 AM
To: users@cloudstack.apache.org
Subject: VM automation using API

HI
ACS 4.15.2
Hypervisor: KVM on Ubuntu 20.04

We have noticed that when trying to start 50 VM’s via Ansible using the ACS API 
– the VM’s only start in batches of 5 VM’s at a time – is this down to the 
default setting of “Number of worker threads handling remote agent connections” 
= 5 ?

If so is there any danger of increasing this number to say 25 ?

Also our API rate limit is set to disabled – could there be any other global 
config settings that would impact VM automation ?

BR

Gary

[cid:image001.png@01DAC231.C1D9E680]
Gary Dixon
Quadris Cloud Manager
[cid:image002.png@01DAC231.C1D9E680]
+44 (0) 161 537 4980
 +44 (0) 7989 717661
[cid:image003.png@01DAC231.C1D9E680]
gary.di...@quadris.co.uk
[cid:image004.png@01DAC231.C1D9E680]
www.quadris.com
[cid:image005.png@01DAC231.C1D9E680]
Innovation House, 12‑13 Bredbury Business Park
Bredbury Park Way, Bredbury, Stockport, SK6 2SN


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***

cloud-init fails on newer ubuntu?

[jordan j]

Hi everyone,

Currently I have a test setup where these 4 OSs are tested with cloud-init
and  Cloudstack 4.19.0.1 :
- Ubuntu 22 server - work!
- Ubuntu 24 server - does not work
- Ubuntu 22 desktop - does not work
- Ubuntu 24 desktop - does not work

The config script is the same on all 4 instances.
All template instances are started in the same network with the same VR.
The error on the failed ones is:
2024-06-20 09:07:18,172 - util.py[WARNING]: Getting data from  failed

I can query successfully the metadata from the failed instances.
Do you have any suggestions why those 3 fail while the 22 server is running
properly? I have been looking at the ins and outs of that for a few days
now with no success.

Regards,
Jordan

Re: [DISCUSS] Deprecate/remove support for EOL distros and hypervisors

[Nux]

By all means, remove CentOS7 and any EOL OS or component from the matrix 
and recommendations!


Regards

On 2024-06-20 11:45, Rohit Yadav wrote:

+ Users

Just to be clear, what this thread is about - Deprecating/removing 
documentation via the compatibility matrix for a component does not 
necessarily mean CloudStack will not work on it, in fact it might (with 
some additional pkg installation if required if we decide to transition 
to JRE17/21) and community's testing. The discussion is whether from a 
project point of view, what should users be advised that is considered 
supported via the compatibility matrix page in the release notes. The 
same applies for other distro/hosts, hypervisors, MySQL DB version.


Just a note for the community to be aware: EL7/CentOS7 active support 
has already ended in 2020, and we've already supported it since the 
last 3-4 years. It's only the security update/support ending by end 
June 2024. So, if there's any future/potential security issue around 
EL7, we will not be able to support that 18months moving forward (18 
months being typical ACS LTS release support period). That's risk, I 
think we logistically wouldn't be able to carry forward for the next 
major release (4.20) in Q3/Q4 '24.


Refer: https://endoflife.date/centos


Regards.





From: Nux 
Sent: Thursday, June 20, 2024 15:21
To: d...@cloudstack.apache.org 
Cc: Alex Mattioli 
Subject: Re: [DISCUSS] Deprecate/remove support for EOL distros and 
hypervisors


+1 what Alex said.
It's kind of wrong, but CentOS7 has such a large install base 
(generally

and for Cloudstack, too) that I feel deprecating it right away would be
a mistake.


On 2024-06-20 10:45, Alex Mattioli wrote:

I'd like if we keep EL7 for at least one more version, the transition
path out of that is clear now but many cloud operators haven't 
replaced

it yet.

On the rest +1




-Original Message-
From: Rohit Yadav 
Sent: Thursday, June 20, 2024 11:43 AM
To: d...@cloudstack.apache.org
Subject: [DISCUSS] Deprecate/remove support for EOL distros and
hypervisors

All,

Referencing
https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/compat.html,
some of the distros and hypervisors we support have reached or 
reaching

EOL by end of this month.

Please review and advise how we should deprecating/remove the 
following

for the next 4.20 release (i.e. compatibility matrix for the future
4.20 release notes):

Distros:

  *
EL7 (CentOS 7, RHEL7, https://endoflife.date/centos)
  *
Ubuntu 18.04 (https://endoflife.date/ubuntu)


Software requirements:

  *
JRE 11 (Discuss - should we transition to support JRE/JDK 17 or 21, 
for

4.20? https://endoflife.date/oracle-jdk And are all supported distros
have a JRE17/21 package/dependency availalble)
  *
MySQL 5.6, 5.7 (https://endoflife.date/mysql)

Hypervisors:

  *
KVM: Ubuntu 18.04 (https://endoflife.date/ubuntu), EL7
(https://endoflife.date/centos)
  *
XenServer All versions except 8.x (retain note that it's not tested,
https://www.citrix.com/support/product-lifecycle/legacy-product-matrix.html)
  *
XCP-ng: All versions except 8.2/LTS (https://endoflife.date/xcp-ng)
  *
VMware: 6.5, 6.7 (https://endoflife.date/vcenter)


Regards.

FW: VM automation using API

[Gary Dixon]

Hi all – just giving this a bump if anyone has any suggestions ?


Gary Dixon
Quadris Cloud Manager
+44 (0) 161 537 4980 +44 (0) 7989 717661
gary.di...@quadris.co.uk
www.quadris.com
Innovation House, 12-13 Bredbury Business Park
Bredbury Park Way, Bredbury, Stockport, SK6 2SN
From: Gary Dixon 
Sent: Wednesday, June 19, 2024 10:25 AM
To: users@cloudstack.apache.org
Subject: VM automation using API

HI
ACS 4.15.2
Hypervisor: KVM on Ubuntu 20.04

We have noticed that when trying to start 50 VM’s via Ansible using the ACS API 
– the VM’s only start in batches of 5 VM’s at a time – is this down to the 
default setting of “Number of worker threads handling remote agent connections” 
= 5 ?

If so is there any danger of increasing this number to say 25 ?

Also our API rate limit is set to disabled – could there be any other global 
config settings that would impact VM automation ?

BR

Gary

[cid:image001.png@01DAC231.C1D9E680]
Gary Dixon
Quadris Cloud Manager
[cid:image002.png@01DAC231.C1D9E680]
+44 (0) 161 537 4980
 +44 (0) 7989 717661
[cid:image003.png@01DAC231.C1D9E680]
gary.di...@quadris.co.uk
[cid:image004.png@01DAC231.C1D9E680]
www.quadris.com
[cid:image005.png@01DAC231.C1D9E680]
Innovation House, 12‑13 Bredbury Business Park
Bredbury Park Way, Bredbury, Stockport, SK6 2SN

Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

[Nux]

+1 as well, based on similar test to Wei's.

Good job, Vishesh.

On 2024-06-20 12:34, Kiran Chavala wrote:

Hi Vishesh

+1

I tried the same steps as Wei did,  but deployed a cks cluster in a vpc 
network tier with acl rule of default_allow


1. Create a CKS cluster with k8s 1.28.4 and Select a vpc network

2. Delete cloudstack-kubernetes-provider 1.0.0

kubectl delete -f
https://raw.githubusercontent.com/apache/cloudstack-kubernetes-provider/main/deployment.yaml

3.  Install 1.1.0-rc1

kubectl apply -f
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

4. Create nginx deployment and expose the service with 
type=LoadBalancer.


kubectl  expose deploy/nginx-deployment3 --port=80 --type=LoadBalancer.

The public ip is qcuired

kubectl  get svc
NAMETYPE   CLUSTER-IP  EXTERNAL-IP   
PORT(S)AGE
kubernetes  ClusterIP  10.96.0.1   
443/TCP12m
nginx-deployment3   LoadBalancer   10.105.61.120   10.0.54.125   
80:31053/TCP   7m37s




5.  Delete the nginx service.
Public IP is released

Regards
Kiran

From: Rohit Yadav 
Date: Thursday, 20 June 2024 at 12:04 PM
To: d...@cloudstack.apache.org , 
users@cloudstack.apache.org 

Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1
Lucian,

The convenience binary in case of this sub-project is the 
docker/container image, users can test RC1 builds from: 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags



Regards.








From: Nux 
Sent: Thursday, June 20, 2024 04:03
To: d...@cloudstack.apache.org 
Cc: users@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

In community's interest, do we have binary packages anywhere, ie
deb/rpms?

Cheers

On 2024-06-19 07:12, Vishesh Jindal wrote:

Hi All,

I made a mistake and didn't create the release on dist.apache.org.
Please discard my previous email.

I've created a new CloudStack Kubernetes Provider 1.1.0 release (RC1),
with the following artifacts up for a vote:

Git Branch and Commit SHA:
https://github.com/apache/cloudstack-kubernetes-provider/tree/59c3e7b21c39eefb2306bb8504bcef901a9d
Commit: 59c3e7b21c39eefb2306bb8504bcef901a9d

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/kubernetes-provider-1.1.0/

PGP release keys (signed using
5ED1E1122DC5E8A4A45112C2484248210EE3D884):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

For users convenience:
* docker hub -
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags

* Kubernetes manifest for the rc release:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Vote will be open for 120 hours.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Regards
Vishesh





From: Vishesh Jindal
Sent: Tuesday, June 18, 2024 6:36 PM
To: users@cloudstack.apache.org ;
d...@cloudstack.apache.org 
Subject: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

Hi All,

I've created a 1.1.0 release (RC1) for Apache CloudStack Kubernetes
Provider, with the following artifacts up for
a vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack-kubernetes-provider/tree/v1.1.0-rc1

Commit: 774a144876d2c875c61becab00e0487692130302

Deployment manifest:
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

Docker image:
apache/cloudstack-kubernetes-provider:v1.1.0-rc1

Docker image manifest digest:
sha256:38dc0a4413657b9c88cdcb28ef330e49aee6fb972a4cbc4055a0608b9f8bf7b8

You can check the changelog for the release
here:https://github.com/apache/cloudstack-kubernetes-provider/releases/tag/v1.1.0-rc1

Vote will be open for 120 hours.

For sanity in tallying the vote, can PMC members please be sure to
indicate
"(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Regards
Vishesh

Re: UI Slowness while populating Instance

[Nixon Varghese K S]

Hi,

Sure I will keep an eye on it... This is more helpful, thank you...

With regards,
Nixon Varghese

On Thu, Jun 20, 2024 at 5:01 PM Andrei Mikhailovsky
 wrote:

> Nixon,
>
> also, i would suggest keeping an eye on the amount of rows in the vm_stats
> table. In my case, ACS hasn't been removing them properly and as a result
> i've accumulated over 25m rows in that table, which caused the slow
> response in the acs gui.
>
> Something like this:
>
> SELECT table_name, table_rows FROM information_schema.tables WHERE
> table_schema = 'cloud';
>
> check the vm_stats rows. If you need to remove some old data, you could do
> something like this:
>
> DELETE FROM vm_stats WHERE timestamp < '2024-05-20 00:00:01';
>
> that will remove all rows with the timestamp older than 20th of May 2024.
> If you have a lot of data, you might need remove the data in shorter
> increments. I've found that my /tmp folder didn't have enough space, so i
> had to play around with dates to remove all the old data.
>
> Now, the ACS ui is pretty fast and usable again.
>
> Hope that helps.
>
> Andriej
>
> - Original Message -
> > From: "Nixon Varghese K S" 
> > To: "users" 
> > Sent: Thursday, 20 June, 2024 12:14:16
> > Subject: Re: UI Slowness while populating Instance
>
> > Hi,
> >
> > Thank you for the suggestions..
> >
> > @Andrei I had done the same settings on global configuration and now UI
> > seems to be pretty fast.. Thank you so much for the help...
> >
> > @Joao Thanks for the information that 14.19.1 will have much improved
> > functions...
> >
> > Thank you guys...
> >
> > With Regards
> > Nixon Varghese
> >
> > On Tue, Jun 18, 2024 at 11:47 PM João Jandre Paraquetti <
> > j...@scclouds.com.br> wrote:
> >
> >> Hi, Nixon
> >>
> >> What you are experiencing is most likely the same as Andrei (see
> >> https://lists.apache.org/thread/ltsw9tkkxv6pl2tr9r4q5m34xwlxxbqg), by
> >> default, the API used by the UI to list the VMs also lists the VM's
> >> metrics; since you have 100+ VMs, it is understandable that it would
> >> take some time to list all of those metrics. This behavior has been
> >> discussed and changed with PR
> >> https://github.com/apache/cloudstack/pull/8782. On the next minor
> >> release (4.19.1) there will be a configuration to let you change the
> >> behavior of the `listVirtualMachines` API so that it does not return the
> >> metrics by default.
> >>
> >> Also, if you have too many metrics collected, you might run into the
> >> issue that is described here
> >> https://github.com/apache/cloudstack/pull/8740, where due to the amount
> >> of metrics that ACS tries to delete in a single query, the query always
> >> times out, snowballing into a huge amount of metrics on your DB, slowing
> >> you down even more. The linked PR solves this adding another
> >> configuration to limit the amount of metrics deleted per query,
> >> hopefully it will be in by 4.19.1.0. Until then, if you notice that the
> >> metrics are not being deleted, you might have to manually delete the old
> >> ones on the DB.
> >>
> >> Best regards,
> >>
> >> João Jandre
> >>
> >> On 6/18/24 06:31, Nixon Varghese K S wrote:
> >> > Hello,
> >> >
> >> > I am using ACS 4.18.0.0v in my production environment, and more than
> 100
> >> > instances, including Kubernetes instances, are running on my setup.
> The
> >> > user interface appears to be stuck in the loading phase when you
> click on
> >> > the instance page; you will need to wait five to ten minutes for the
> >> > instance list to appear. Not just the instance page, but also the
> place
> >> > where instances are listed out; for example, adding port forwarding or
> >> > listing instances running in VR everywhere they are the same. Is
> anyone
> >> > facing the same issue?
> >> > I checked the management log and saw that there was no error message
> and
> >> > that the management server's resource utilization was normal. . If
> >> someone
> >> > could provide some troubleshooting steps to identify the issue, that
> >> would
> >> > be very helpful.
> >> >
> >>
> >
> >
> > --
> > With Regards,
> > Nixon Varghese
>
>

-- 
With Regards,
Nixon Varghese

Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

[Kiran Chavala]

Hi Vishesh

+1

I tried the same steps as Wei did,  but deployed a cks cluster in a vpc network 
tier with acl rule of default_allow

1. Create a CKS cluster with k8s 1.28.4 and Select a vpc network

2. Delete cloudstack-kubernetes-provider 1.0.0

kubectl delete -f
https://raw.githubusercontent.com/apache/cloudstack-kubernetes-provider/main/deployment.yaml

3.  Install 1.1.0-rc1

kubectl apply -f
https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml

4. Create nginx deployment and expose the service with type=LoadBalancer.

kubectl  expose deploy/nginx-deployment3 --port=80 --type=LoadBalancer.

The public ip is qcuired

kubectl  get svc
NAMETYPE   CLUSTER-IP  EXTERNAL-IP   PORT(S)
AGE
kubernetes  ClusterIP  10.96.0.1   443/TCP
12m
nginx-deployment3   LoadBalancer   10.105.61.120   10.0.54.125   80:31053/TCP   
7m37s



5.  Delete the nginx service.
Public IP is released

Regards
Kiran

From: Rohit Yadav 
Date: Thursday, 20 June 2024 at 12:04 PM
To: d...@cloudstack.apache.org , 
users@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1
Lucian,

The convenience binary in case of this sub-project is the docker/container 
image, users can test RC1 builds from: 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags


Regards.




 



From: Nux 
Sent: Thursday, June 20, 2024 04:03
To: d...@cloudstack.apache.org 
Cc: users@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1

In community's interest, do we have binary packages anywhere, ie
deb/rpms?

Cheers

On 2024-06-19 07:12, Vishesh Jindal wrote:
> Hi All,
>
> I made a mistake and didn't create the release on dist.apache.org.
> Please discard my previous email.
>
> I've created a new CloudStack Kubernetes Provider 1.1.0 release (RC1),
> with the following artifacts up for a vote:
>
> Git Branch and Commit SHA:
> https://github.com/apache/cloudstack-kubernetes-provider/tree/59c3e7b21c39eefb2306bb8504bcef901a9d
> Commit: 59c3e7b21c39eefb2306bb8504bcef901a9d
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/kubernetes-provider-1.1.0/
>
> PGP release keys (signed using
> 5ED1E1122DC5E8A4A45112C2484248210EE3D884):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> For users convenience:
> * docker hub -
> https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/tags
>
> * Kubernetes manifest for the rc release:
> https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml
>
> Vote will be open for 120 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Regards
> Vishesh
>
> 
>
>
>
> From: Vishesh Jindal
> Sent: Tuesday, June 18, 2024 6:36 PM
> To: users@cloudstack.apache.org ;
> d...@cloudstack.apache.org 
> Subject: [VOTE] Apache CloudStack Kubernetes Provider 1.1.0 RC1
>
> Hi All,
>
> I've created a 1.1.0 release (RC1) for Apache CloudStack Kubernetes
> Provider, with the following artifacts up for
> a vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack-kubernetes-provider/tree/v1.1.0-rc1
>
> Commit: 774a144876d2c875c61becab00e0487692130302
>
> Deployment manifest:
> https://github.com/apache/cloudstack-kubernetes-provider/releases/download/v1.1.0-rc1/deployment.yaml
>
> Docker image:
> apache/cloudstack-kubernetes-provider:v1.1.0-rc1
>
> Docker image manifest digest:
> sha256:38dc0a4413657b9c88cdcb28ef330e49aee6fb972a4cbc4055a0608b9f8bf7b8
>
> You can check the changelog for the release
> here:https://github.com/apache/cloudstack-kubernetes-provider/releases/tag/v1.1.0-rc1
>
> Vote will be open for 120 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate
> "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Regards
> Vishesh

Re: UI Slowness while populating Instance

[Andrei Mikhailovsky]

Nixon, 

also, i would suggest keeping an eye on the amount of rows in the vm_stats 
table. In my case, ACS hasn't been removing them properly and as a result i've 
accumulated over 25m rows in that table, which caused the slow response in the 
acs gui.

Something like this:

SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema 
= 'cloud';

check the vm_stats rows. If you need to remove some old data, you could do 
something like this:

DELETE FROM vm_stats WHERE timestamp < '2024-05-20 00:00:01';

that will remove all rows with the timestamp older than 20th of May 2024. If 
you have a lot of data, you might need remove the data in shorter increments. 
I've found that my /tmp folder didn't have enough space, so i had to play 
around with dates to remove all the old data.

Now, the ACS ui is pretty fast and usable again.

Hope that helps.

Andriej

- Original Message -
> From: "Nixon Varghese K S" 
> To: "users" 
> Sent: Thursday, 20 June, 2024 12:14:16
> Subject: Re: UI Slowness while populating Instance

> Hi,
> 
> Thank you for the suggestions..
> 
> @Andrei I had done the same settings on global configuration and now UI
> seems to be pretty fast.. Thank you so much for the help...
> 
> @Joao Thanks for the information that 14.19.1 will have much improved
> functions...
> 
> Thank you guys...
> 
> With Regards
> Nixon Varghese
> 
> On Tue, Jun 18, 2024 at 11:47 PM João Jandre Paraquetti <
> j...@scclouds.com.br> wrote:
> 
>> Hi, Nixon
>>
>> What you are experiencing is most likely the same as Andrei (see
>> https://lists.apache.org/thread/ltsw9tkkxv6pl2tr9r4q5m34xwlxxbqg), by
>> default, the API used by the UI to list the VMs also lists the VM's
>> metrics; since you have 100+ VMs, it is understandable that it would
>> take some time to list all of those metrics. This behavior has been
>> discussed and changed with PR
>> https://github.com/apache/cloudstack/pull/8782. On the next minor
>> release (4.19.1) there will be a configuration to let you change the
>> behavior of the `listVirtualMachines` API so that it does not return the
>> metrics by default.
>>
>> Also, if you have too many metrics collected, you might run into the
>> issue that is described here
>> https://github.com/apache/cloudstack/pull/8740, where due to the amount
>> of metrics that ACS tries to delete in a single query, the query always
>> times out, snowballing into a huge amount of metrics on your DB, slowing
>> you down even more. The linked PR solves this adding another
>> configuration to limit the amount of metrics deleted per query,
>> hopefully it will be in by 4.19.1.0. Until then, if you notice that the
>> metrics are not being deleted, you might have to manually delete the old
>> ones on the DB.
>>
>> Best regards,
>>
>> João Jandre
>>
>> On 6/18/24 06:31, Nixon Varghese K S wrote:
>> > Hello,
>> >
>> > I am using ACS 4.18.0.0v in my production environment, and more than 100
>> > instances, including Kubernetes instances, are running on my setup. The
>> > user interface appears to be stuck in the loading phase when you click on
>> > the instance page; you will need to wait five to ten minutes for the
>> > instance list to appear. Not just the instance page, but also the place
>> > where instances are listed out; for example, adding port forwarding or
>> > listing instances running in VR everywhere they are the same. Is anyone
>> > facing the same issue?
>> > I checked the management log and saw that there was no error message and
>> > that the management server's resource utilization was normal. . If
>> someone
>> > could provide some troubleshooting steps to identify the issue, that
>> would
>> > be very helpful.
>> >
>>
> 
> 
> --
> With Regards,
> Nixon Varghese

Re: UI Slowness while populating Instance

[Nixon Varghese K S]

Hi,

Thank you for the suggestions..

@Andrei I had done the same settings on global configuration and now UI
seems to be pretty fast.. Thank you so much for the help...

@Joao Thanks for the information that 14.19.1 will have much improved
functions...

Thank you guys...

With Regards
Nixon Varghese

On Tue, Jun 18, 2024 at 11:47 PM João Jandre Paraquetti <
j...@scclouds.com.br> wrote:

> Hi, Nixon
>
> What you are experiencing is most likely the same as Andrei (see
> https://lists.apache.org/thread/ltsw9tkkxv6pl2tr9r4q5m34xwlxxbqg), by
> default, the API used by the UI to list the VMs also lists the VM's
> metrics; since you have 100+ VMs, it is understandable that it would
> take some time to list all of those metrics. This behavior has been
> discussed and changed with PR
> https://github.com/apache/cloudstack/pull/8782. On the next minor
> release (4.19.1) there will be a configuration to let you change the
> behavior of the `listVirtualMachines` API so that it does not return the
> metrics by default.
>
> Also, if you have too many metrics collected, you might run into the
> issue that is described here
> https://github.com/apache/cloudstack/pull/8740, where due to the amount
> of metrics that ACS tries to delete in a single query, the query always
> times out, snowballing into a huge amount of metrics on your DB, slowing
> you down even more. The linked PR solves this adding another
> configuration to limit the amount of metrics deleted per query,
> hopefully it will be in by 4.19.1.0. Until then, if you notice that the
> metrics are not being deleted, you might have to manually delete the old
> ones on the DB.
>
> Best regards,
>
> João Jandre
>
> On 6/18/24 06:31, Nixon Varghese K S wrote:
> > Hello,
> >
> > I am using ACS 4.18.0.0v in my production environment, and more than 100
> > instances, including Kubernetes instances, are running on my setup. The
> > user interface appears to be stuck in the loading phase when you click on
> > the instance page; you will need to wait five to ten minutes for the
> > instance list to appear. Not just the instance page, but also the place
> > where instances are listed out; for example, adding port forwarding or
> > listing instances running in VR everywhere they are the same. Is anyone
> > facing the same issue?
> > I checked the management log and saw that there was no error message and
> > that the management server's resource utilization was normal. . If
> someone
> > could provide some troubleshooting steps to identify the issue, that
> would
> > be very helpful.
> >
>


-- 
With Regards,
Nixon Varghese

Re: [DISCUSS] Deprecate/remove support for EOL distros and hypervisors

[Rohit Yadav]

+ Users

Just to be clear, what this thread is about - Deprecating/removing 
documentation via the compatibility matrix for a component does not necessarily 
mean CloudStack will not work on it, in fact it might (with some additional pkg 
installation if required if we decide to transition to JRE17/21) and 
community's testing. The discussion is whether from a project point of view, 
what should users be advised that is considered supported via the compatibility 
matrix page in the release notes. The same applies for other distro/hosts, 
hypervisors, MySQL DB version.

Just a note for the community to be aware: EL7/CentOS7 active support has 
already ended in 2020, and we've already supported it since the last 3-4 years. 
It's only the security update/support ending by end June 2024. So, if there's 
any future/potential security issue around EL7, we will not be able to support 
that 18months moving forward (18 months being typical ACS LTS release support 
period). That's risk, I think we logistically wouldn't be able to carry forward 
for the next major release (4.20) in Q3/Q4 '24.

Refer: https://endoflife.date/centos


Regards.

 



From: Nux 
Sent: Thursday, June 20, 2024 15:21
To: d...@cloudstack.apache.org 
Cc: Alex Mattioli 
Subject: Re: [DISCUSS] Deprecate/remove support for EOL distros and hypervisors

+1 what Alex said.
It's kind of wrong, but CentOS7 has such a large install base (generally
and for Cloudstack, too) that I feel deprecating it right away would be
a mistake.


On 2024-06-20 10:45, Alex Mattioli wrote:
> I'd like if we keep EL7 for at least one more version, the transition
> path out of that is clear now but many cloud operators haven't replaced
> it yet.
>
> On the rest +1
>
>
>
>
> -Original Message-
> From: Rohit Yadav 
> Sent: Thursday, June 20, 2024 11:43 AM
> To: d...@cloudstack.apache.org
> Subject: [DISCUSS] Deprecate/remove support for EOL distros and
> hypervisors
>
> All,
>
> Referencing
> https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/compat.html,
> some of the distros and hypervisors we support have reached or reaching
> EOL by end of this month.
>
> Please review and advise how we should deprecating/remove the following
> for the next 4.20 release (i.e. compatibility matrix for the future
> 4.20 release notes):
>
> Distros:
>
>   *
> EL7 (CentOS 7, RHEL7, https://endoflife.date/centos)
>   *
> Ubuntu 18.04 (https://endoflife.date/ubuntu)
>
>
> Software requirements:
>
>   *
> JRE 11 (Discuss - should we transition to support JRE/JDK 17 or 21, for
> 4.20? https://endoflife.date/oracle-jdk And are all supported distros
> have a JRE17/21 package/dependency availalble)
>   *
> MySQL 5.6, 5.7 (https://endoflife.date/mysql)
>
> Hypervisors:
>
>   *
> KVM: Ubuntu 18.04 (https://endoflife.date/ubuntu), EL7
> (https://endoflife.date/centos)
>   *
> XenServer All versions except 8.x (retain note that it's not tested,
> https://www.citrix.com/support/product-lifecycle/legacy-product-matrix.html)
>   *
> XCP-ng: All versions except 8.2/LTS (https://endoflife.date/xcp-ng)
>   *
> VMware: 6.5, 6.7 (https://endoflife.date/vcenter)
>
>
> Regards.

RE: Physical network labels when using VXLAN

[Alex Mattioli]

Hi Muhammad,

Are you planning on using VXLAN or bridges?  Those are mutually exclusive, with 
VXLAN you have a single VLAN interface with an IP which is the VTEP (Virtual 
Tunnel EndPoint) for your VXLAN encapsulated traffic.

Cheers
Alex

 


-Original Message-
From: Muhammad Hanis Irfan Mohd Zaid  
Sent: Thursday, June 20, 2024 8:59 AM
To: users@cloudstack.apache.org
Cc: w...@widodh.nl
Subject: Physical network labels when using VXLAN

Hi. We're trying to deploy a POC environment with VXLAN EVPN. The underlay 
works perfectly and the overlay when creating a bridge for the management 
network (cloudbr0) can ping without any issues between the hosts and management 
server.

Now I'm trying to figure out how the bridges should be configured for the guest 
and public network. The hosts are fully running L3 towards our leaf switches. 
I'm clueless when trying to configure the physical networks of the zone in the 
web UI.

Any suggestions? Thanks

Re: VM migration to different host

[Boris Stoyanov]

Hi Jimmy,

If all the host are using same type of infra (ie Local storage), it’s likely 
the specifics of the offering, check tags and availability for the given 
resources.

Bobby.

From: Jimmy Huybrechts 
Date: Thursday, 13 June 2024 at 17:40
To: users@cloudstack.apache.org 
Subject: VM migration to different host
Hi,

If I want to migrate a VM to a different host (I have 4) with local storage.

And it’s on currently 1 for example, I can pick 3,4 but not 2 because it’s not 
“suitable”.

But the problem I have is why is it not suitable? It doesn’t say why it’s not, 
you can just not pick it and that’s it.

Is it maybe because of the memory use or cpu usage? I know it works because I 
migrated vm’s to that before.

How can I find that out?

--
Jimmy