Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi Wei,

I created a discussion with the details.
https://github.com/apache/cloudstack/issues/8684

Please check.

Thanks and Regards,
Bharat Saini

[signature_2287529980]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 11:53 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


Hi,

The image is not visible .

You can create a github discussion instead.


-Wei

On Tue, 20 Feb 2024 at 18:53, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> Public IP is reachable from the local machine. Everything is working.
>
> But when I access the dashboard I encountered with the below Json format
>
>
>
>
>
> Also I am able to get all the details regarding deployment which I already
> below but unable to access the dashboard of K8s.
>
> Please check and help out from this situation. If any details or info you
> need pls let me know.
>
>
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_4184978167]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 7:44 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> so, it looks like the kubernetes-dashboard is working well.
> your question is, how to access the dashboard of the kubernetes cluster
> whose Public IP is unreachable from a local machine ?
>
>
>
> -Wei
>
> On Tue, 20 Feb 2024 at 12:41, Bharat Bhushan Saini
>  wrote:
>
> > Hi Wei,
> >
> >
> >
> > The cloudstack is setup on a single node and the info I provided is from
> > that node.
> >
> > I think as the control node and worker node is CLI based, Need to access
> > dashboard from outside the control node.
> >
> > Please guide me for that.
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
> > [image: signature_1512528664]
> >
> >
> >
> > *From: *Wei ZHOU 
> > *Date: *Tuesday, 20 February 2024 at 4:27 PM
> > *To: *users@cloudstack.apache.org 
> > *Subject: *Re: K8s Dashboard Not Found
> >
> > EXTERNAL EMAIL: Please verify the sender email address before taking any
> > action, replying, clicking any link or opening any attachment.
> >
> >
> > The output in the control nodes looks good.
> >
> > Are you able to access the dashboard following the instruction on
> > https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?
> >
> > -Wei
> >
> > On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
> >  wrote:
> >
> > > Hi Wei,
> > >
> > >
> > >
> > > Please check the below info I think you will get it
> > >
> > > kubectl --kubeconfig kube.conf get pods --all-namespaces
> > >
> > > NAMESPACE  NAME
> > > READY   STATUSRESTARTS  AGE
> > >
> > > kube-systemcoredns-76f75df574-lfgzj
> > > 1/1 Running   0 22h
> > >
> > > kube-systemcoredns-76f75df574-mtktc
> > > 1/1 Running   0 22h
> > >
> > > kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-system
> > >   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
> > >   Running   0 22h
> > >
> > > kube-systemkube-proxy-74zcb
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-proxy-hts4p
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-systemweave-net-8j6j2
> > > 2/2 Running   0 22h
> > >
> > > kube-systemweave-net-mlv6t
> > > 2/2 Running   1 (22h ago)   22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> > > 1/1 Running   0 22h
> > >
> > > kubernetes-dashboard
> > kubernetes-dashboard-metrics-scraper-b847579df-tjw86
> > >   1/1 Running   0 22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> > > 1/1 Running   0 22h
> > >
> > >
> > >
> > > kubectl --kubeconfig kube.conf get nodes --all-namespaces
> > >
> > > NAMESTATUS   ROLES   AGE
> > VERSION
> > >
> > > kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h
> > v1.29.2
> > >
> > > kloudspot-app-node-18dc0a3f52e  Ready  22h
> > v1.29.2
> > >
> > >
> > >
> > > kubectl --kubeconfig kube.conf get services --all-namespaces
> > >
> > > NAMESPACE  NAME   TYPE
> > >   CLUSTER-IP   EXTERNAL-IP   PORT(S)  

Re: Console Proxy VM has high CPU usage

2024-02-20 Thread Leo Leung
Just a quick update:

- I see 100% CPU on the console proxy's java process if one or more VNC session 
is in use, even if nothing is happening in the session (such as a blank 
screen). Is this normal?
- The persistent 100% CPU appears to be triggered when I try to VNC to the 
console proxy itself. Connecting the console proxy to itself somehow causes the 
VNC connection to persist until I run 'systemctl restart cloud' on the console 
proxy and immediately disconnect from the console. Since the VNC connection 
happens to the underlying KVM process on the hypervisor, I'm not quite sure why 
this is even a problem.

Is this a potential bug with the cloud/proxy service? 

-Leo


> On 02/20/2024 4:16 PM MST Leo Leung  wrote:
> 
>  
> Hello everyone,
> 
> I am running CloudStack 4.18 and 4.19 in two separate environments and notice 
> that in both environments, the Console Proxy SystemVM is pretty much pegging 
> its single CPU. Logging in to the SystemVM, top reports the java process that 
> handles the VNC connections is constantly using ~100% CPU. This behaviour 
> happens even on a cleanly provisioned console proxy (after 
> deleting/recreating it) with only a 4-5 established VNC connections (as 
> reported by netstat -ntp).
> 
> Is this normal? Does anyone else experience this behaviour? Should I assign a 
> larger console proxy compute offering?
> 
> Thank-you in advance.
> -Leo


Console Proxy VM has high CPU usage

2024-02-20 Thread Leo Leung
Hello everyone,

I am running CloudStack 4.18 and 4.19 in two separate environments and notice 
that in both environments, the Console Proxy SystemVM is pretty much pegging 
its single CPU. Logging in to the SystemVM, top reports the java process that 
handles the VNC connections is constantly using ~100% CPU. This behaviour 
happens even on a cleanly provisioned console proxy (after deleting/recreating 
it) with only a 4-5 established VNC connections (as reported by netstat -ntp).

Is this normal? Does anyone else experience this behaviour? Should I assign a 
larger console proxy compute offering?

Thank-you in advance.
-Leo


Re: K8s Dashboard Not Found

2024-02-20 Thread Wei ZHOU
Hi,

The image is not visible .

You can create a github discussion instead.


-Wei

On Tue, 20 Feb 2024 at 18:53, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> Public IP is reachable from the local machine. Everything is working.
>
> But when I access the dashboard I encountered with the below Json format
>
>
>
>
>
> Also I am able to get all the details regarding deployment which I already
> below but unable to access the dashboard of K8s.
>
> Please check and help out from this situation. If any details or info you
> need pls let me know.
>
>
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_4184978167]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 7:44 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> so, it looks like the kubernetes-dashboard is working well.
> your question is, how to access the dashboard of the kubernetes cluster
> whose Public IP is unreachable from a local machine ?
>
>
>
> -Wei
>
> On Tue, 20 Feb 2024 at 12:41, Bharat Bhushan Saini
>  wrote:
>
> > Hi Wei,
> >
> >
> >
> > The cloudstack is setup on a single node and the info I provided is from
> > that node.
> >
> > I think as the control node and worker node is CLI based, Need to access
> > dashboard from outside the control node.
> >
> > Please guide me for that.
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
> > [image: signature_1512528664]
> >
> >
> >
> > *From: *Wei ZHOU 
> > *Date: *Tuesday, 20 February 2024 at 4:27 PM
> > *To: *users@cloudstack.apache.org 
> > *Subject: *Re: K8s Dashboard Not Found
> >
> > EXTERNAL EMAIL: Please verify the sender email address before taking any
> > action, replying, clicking any link or opening any attachment.
> >
> >
> > The output in the control nodes looks good.
> >
> > Are you able to access the dashboard following the instruction on
> > https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?
> >
> > -Wei
> >
> > On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
> >  wrote:
> >
> > > Hi Wei,
> > >
> > >
> > >
> > > Please check the below info I think you will get it
> > >
> > > kubectl --kubeconfig kube.conf get pods --all-namespaces
> > >
> > > NAMESPACE  NAME
> > > READY   STATUSRESTARTS  AGE
> > >
> > > kube-systemcoredns-76f75df574-lfgzj
> > > 1/1 Running   0 22h
> > >
> > > kube-systemcoredns-76f75df574-mtktc
> > > 1/1 Running   0 22h
> > >
> > > kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-system
> > >   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
> > >   Running   0 22h
> > >
> > > kube-systemkube-proxy-74zcb
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-proxy-hts4p
> > > 1/1 Running   0 22h
> > >
> > > kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> > > 1/1 Running   0 22h
> > >
> > > kube-systemweave-net-8j6j2
> > > 2/2 Running   0 22h
> > >
> > > kube-systemweave-net-mlv6t
> > > 2/2 Running   1 (22h ago)   22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> > > 1/1 Running   0 22h
> > >
> > > kubernetes-dashboard
> > kubernetes-dashboard-metrics-scraper-b847579df-tjw86
> > >   1/1 Running   0 22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> > > 1/1 Running   0 22h
> > >
> > >
> > >
> > > kubectl --kubeconfig kube.conf get nodes --all-namespaces
> > >
> > > NAMESTATUS   ROLES   AGE
> > VERSION
> > >
> > > kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h
> > v1.29.2
> > >
> > > kloudspot-app-node-18dc0a3f52e  Ready  22h
> > v1.29.2
> > >
> > >
> > >
> > > kubectl --kubeconfig kube.conf get services --all-namespaces
> > >
> > > NAMESPACE  NAME   TYPE
> > >   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
> > >
> > > defaultkubernetes
> > >   ClusterIP   10.96.0.1443/TCP
> 22h
> > >
> > > kube-systemkube-dns
> > >   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP
> 22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-api
> > >   ClusterIP   10.102.124.599000/TCP
> 22h
> > >
> > > kubernetes-dashboard   kubernetes-dashboard-metrics-scraper
> > ClusterIP   

Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi Wei,

Public IP is reachable from the local machine. Everything is working.
But when I access the dashboard I encountered with the below Json format

[Image]

Also I am able to get all the details regarding deployment which I already 
below but unable to access the dashboard of K8s.
Please check and help out from this situation. If any details or info you need 
pls let me know.


Thanks and Regards,
Bharat Saini

[signature_3933537397]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 7:44 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


so, it looks like the kubernetes-dashboard is working well.
your question is, how to access the dashboard of the kubernetes cluster
whose Public IP is unreachable from a local machine ?



-Wei

On Tue, 20 Feb 2024 at 12:41, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> The cloudstack is setup on a single node and the info I provided is from
> that node.
>
> I think as the control node and worker node is CLI based, Need to access
> dashboard from outside the control node.
>
> Please guide me for that.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_1512528664]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 4:27 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> The output in the control nodes looks good.
>
> Are you able to access the dashboard following the instruction on
> https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?
>
> -Wei
>
> On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
>  wrote:
>
> > Hi Wei,
> >
> >
> >
> > Please check the below info I think you will get it
> >
> > kubectl --kubeconfig kube.conf get pods --all-namespaces
> >
> > NAMESPACE  NAME
> > READY   STATUSRESTARTS  AGE
> >
> > kube-systemcoredns-76f75df574-lfgzj
> > 1/1 Running   0 22h
> >
> > kube-systemcoredns-76f75df574-mtktc
> > 1/1 Running   0 22h
> >
> > kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-system
> >   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
> >   Running   0 22h
> >
> > kube-systemkube-proxy-74zcb
> > 1/1 Running   0 22h
> >
> > kube-systemkube-proxy-hts4p
> > 1/1 Running   0 22h
> >
> > kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemweave-net-8j6j2
> > 2/2 Running   0 22h
> >
> > kube-systemweave-net-mlv6t
> > 2/2 Running   1 (22h ago)   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> > 1/1 Running   0 22h
> >
> > kubernetes-dashboard
> kubernetes-dashboard-metrics-scraper-b847579df-tjw86
> >   1/1 Running   0 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> > 1/1 Running   0 22h
> >
> >
> >
> > kubectl --kubeconfig kube.conf get nodes --all-namespaces
> >
> > NAMESTATUS   ROLES   AGE
> VERSION
> >
> > kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h
> v1.29.2
> >
> > kloudspot-app-node-18dc0a3f52e  Ready  22h
> v1.29.2
> >
> >
> >
> > kubectl --kubeconfig kube.conf get services --all-namespaces
> >
> > NAMESPACE  NAME   TYPE
> >   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
> >
> > defaultkubernetes
> >   ClusterIP   10.96.0.1443/TCP  22h
> >
> > kube-systemkube-dns
> >   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api
> >   ClusterIP   10.102.124.599000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-metrics-scraper
> ClusterIP   10.111.159.255   
> >   8000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web
> >   ClusterIP   10.108.135.214   8000/TCP 22h
> >
> >
> >
> >
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
>
> --- Disclaimer: --
> This message and its contents are intended solely for the designated
> addressee and are proprietary to Kloudspot. The 

Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi Wei,

Public IP is reachable from the local machine. Everything is working.
But when I access the dashboard I encountered with the below Json format

[cid:image002.png@01DA6452.E6F80240]

Also I am able to get all the details regarding deployment which I already 
below but unable to access the dashboard of K8s.
Please check and help out from this situation. If any details or info you need 
pls let me know.


Thanks and Regards,
Bharat Saini

[signature_4184978167]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 7:44 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


so, it looks like the kubernetes-dashboard is working well.
your question is, how to access the dashboard of the kubernetes cluster
whose Public IP is unreachable from a local machine ?



-Wei

On Tue, 20 Feb 2024 at 12:41, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> The cloudstack is setup on a single node and the info I provided is from
> that node.
>
> I think as the control node and worker node is CLI based, Need to access
> dashboard from outside the control node.
>
> Please guide me for that.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_1512528664]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 4:27 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> The output in the control nodes looks good.
>
> Are you able to access the dashboard following the instruction on
> https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?
>
> -Wei
>
> On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
>  wrote:
>
> > Hi Wei,
> >
> >
> >
> > Please check the below info I think you will get it
> >
> > kubectl --kubeconfig kube.conf get pods --all-namespaces
> >
> > NAMESPACE  NAME
> > READY   STATUSRESTARTS  AGE
> >
> > kube-systemcoredns-76f75df574-lfgzj
> > 1/1 Running   0 22h
> >
> > kube-systemcoredns-76f75df574-mtktc
> > 1/1 Running   0 22h
> >
> > kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-system
> >   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
> >   Running   0 22h
> >
> > kube-systemkube-proxy-74zcb
> > 1/1 Running   0 22h
> >
> > kube-systemkube-proxy-hts4p
> > 1/1 Running   0 22h
> >
> > kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemweave-net-8j6j2
> > 2/2 Running   0 22h
> >
> > kube-systemweave-net-mlv6t
> > 2/2 Running   1 (22h ago)   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> > 1/1 Running   0 22h
> >
> > kubernetes-dashboard
> kubernetes-dashboard-metrics-scraper-b847579df-tjw86
> >   1/1 Running   0 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> > 1/1 Running   0 22h
> >
> >
> >
> > kubectl --kubeconfig kube.conf get nodes --all-namespaces
> >
> > NAMESTATUS   ROLES   AGE
> VERSION
> >
> > kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h
> v1.29.2
> >
> > kloudspot-app-node-18dc0a3f52e  Ready  22h
> v1.29.2
> >
> >
> >
> > kubectl --kubeconfig kube.conf get services --all-namespaces
> >
> > NAMESPACE  NAME   TYPE
> >   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
> >
> > defaultkubernetes
> >   ClusterIP   10.96.0.1443/TCP  22h
> >
> > kube-systemkube-dns
> >   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api
> >   ClusterIP   10.102.124.599000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-metrics-scraper
> ClusterIP   10.111.159.255   
> >   8000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web
> >   ClusterIP   10.108.135.214   8000/TCP 22h
> >
> >
> >
> >
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
>
> --- Disclaimer: --
> This message and its contents are intended solely for the designated
> addressee and are 

AW: testing with uefi on Ubuntu22 KVM

2024-02-20 Thread me
Thx Wei!

I updated the db and it worked. Host value of UEFI supported is false again.

Does it make sense to open an issue to add a code for a check to CS?

Regards,
Swen

-Ursprüngliche Nachricht-
Von: Wei ZHOU  
Gesendet: Dienstag, 20. Februar 2024 13:56
An: users@cloudstack.apache.org
Betreff: Re: testing with uefi on Ubuntu22 KVM

Hi,

> guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd

This is incorrect, please use `OVMF_VARS.ms.fd` or `OVMF_VARS_4M.ms.fd`.

> Is it safe to just delete the row in the db?

Yes, it is safe.


-Wei

On Tue, 20 Feb 2024 at 13:31,  wrote:

> Hi,
>
> I started testing with uefi on Ubuntu 22 KVM. I search the mailinglist 
> and found some discussion and problems with uefi secure mode on Ubuntu22 KVM.
>
> Is there already a fix for "Guest has not initialized the display 
> (yet)."-prolem on console proxy?
>
>
>
> For my test I added /etc/cloudstack/agent/uefi.properties with the 
> following
> values:
>
> guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd
>
> guest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS.fd
>
> guest.loader.secure=/usr/share/OVMF/OVMF_CODE.secboot.fd
>
> guest.loader.legacy=/usr/share/OVMF/OVMF_CODE.fd
>
> guest.nvram.path=/var/lib/libvirt/qemu/nvram/
>
>
>
> I also added the following line to /etc/libvirt/qemu.conf:
>
> nvram =
> ["/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd"]
>
>
>
> I restarted the following services:
>
> service libvirtd restart
>
> service cloudstack-agent restart
>
>
>
> I can see that CS is now showing the host as UEFI supported = true and 
> CS added a row to db table host_details:
>
> | 7176 |   4 | host.uefi.enable   |
> true
> |
>
>
>
> I tried to disable UEFI support for this host by deleting the 
> uefi.properties file and deleted the added line in qemu.conf file. I 
> restarted both services.
>
> It looks like CS is not being updated. UI still shows me UEFI 
> supported = true and db still shows me the row.
>
> Is this expected? I know that there is a check if UEFI is supported by 
> the agent. This was implemented in 4.15 or 4.16 if I remember 
> correctly. But is there also a check which will disable the support for a 
> host?
>
>
>
> Is it save to just delete the row in the db?
>
>
>
> Regards,
>
> Swen
>
>




RE: restrict Instance console access

2024-02-20 Thread Gary Dixon
Many thanks Wei
In another test ACS 4.18 environment I can see the new role permission. We will 
look to update our production ACS 4.15.2 as soon as we are able


Gary Dixon
Quadris Cloud Manager
0161 537 4980 +44 7989717661
gary.di...@quadris.co.uk
www.quadris.com
Innovation House, 12-13 Bredbury Business Park
Bredbury Park Way, Bredbury, Stockport, SK6 2SN
-Original Message-
From: Wei ZHOU 
Sent: Monday, February 19, 2024 10:30 PM
To: users 
Cc: Gary Dixon 
Subject: Re: restrict Instance console access

In 4.18+, an API is used to create the console URL:
https://cloudstack.apache.org/api/apidocs-4.19/apis/createConsoleEndpoint.html
Denying the API can disable the VM console.

It is not available in 4.15.2

-Wei
Nux  于 2024年2月19日周一 22:23写道:

> Hi,
>
> I do not think there is one in that version - or later ones, although
> certain things do change, you'll have to do it outside Cloudstack
> somehow.
>
> On 2024-02-19 15:52, Gary Dixon wrote:
> > HI
> >
> > ACS 4.15.2
> >
> > Ubuntu 20.04
> >
> > We have a requirement to restrict access to the VM console for
> > certain tenants within our ACS implementation - however I cannot see
> > a way to accomplish this via Role permissions.
> >
> > Is there a way to restrict VM Console access for specific users ?
> >
> > BR
> >
> > Gary
> >
> >   Gary Dixon
> >
> >   Quadris Cloud Manager
> >
> >   0161 537 4980 [1]
> >
> >+44 7989717661 [2]
> >
> >   gary.di...@quadris.co.uk
> >
> > http://www/
> > .quadris.com%2F=05%7C02%7CGary.Dixon%40quadris.co.uk%7C7d03b57a
> > 59d742cc6e2e08dc319a70bb%7Cf1d6abf3d3b44894ae16db0fb93a96a2%7C0%7C0%
> > 7C638439786597983405%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=W0Hg1
> > 7S5ogJEMZ9mVHfe3vhQNmWT6IOjWVA6H4GH1lk%3D=0
> >
> > Innovation House, 12‑13 Bredbury Business Park Bredbury Park Way,
> > Bredbury, Stockport, SK6 2SN
> >
> >
> >
> > Links:
> > --
> > [1] tel:0161%20537%204980
> > [2] tel:+44%207989717661
>


Re: K8s Dashboard Not Found

2024-02-20 Thread Wei ZHOU
so, it looks like the kubernetes-dashboard is working well.
your question is, how to access the dashboard of the kubernetes cluster
whose Public IP is unreachable from a local machine ?



-Wei

On Tue, 20 Feb 2024 at 12:41, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> The cloudstack is setup on a single node and the info I provided is from
> that node.
>
> I think as the control node and worker node is CLI based, Need to access
> dashboard from outside the control node.
>
> Please guide me for that.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_1512528664]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 4:27 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> The output in the control nodes looks good.
>
> Are you able to access the dashboard following the instruction on
> https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?
>
> -Wei
>
> On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
>  wrote:
>
> > Hi Wei,
> >
> >
> >
> > Please check the below info I think you will get it
> >
> > kubectl --kubeconfig kube.conf get pods --all-namespaces
> >
> > NAMESPACE  NAME
> > READY   STATUSRESTARTS  AGE
> >
> > kube-systemcoredns-76f75df574-lfgzj
> > 1/1 Running   0 22h
> >
> > kube-systemcoredns-76f75df574-mtktc
> > 1/1 Running   0 22h
> >
> > kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-system
> >   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
> >   Running   0 22h
> >
> > kube-systemkube-proxy-74zcb
> > 1/1 Running   0 22h
> >
> > kube-systemkube-proxy-hts4p
> > 1/1 Running   0 22h
> >
> > kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> > 1/1 Running   0 22h
> >
> > kube-systemweave-net-8j6j2
> > 2/2 Running   0 22h
> >
> > kube-systemweave-net-mlv6t
> > 2/2 Running   1 (22h ago)   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> > 1/1 Running   0 22h
> >
> > kubernetes-dashboard
> kubernetes-dashboard-metrics-scraper-b847579df-tjw86
> >   1/1 Running   0 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> > 1/1 Running   0 22h
> >
> >
> >
> > kubectl --kubeconfig kube.conf get nodes --all-namespaces
> >
> > NAMESTATUS   ROLES   AGE
> VERSION
> >
> > kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h
> v1.29.2
> >
> > kloudspot-app-node-18dc0a3f52e  Ready  22h
> v1.29.2
> >
> >
> >
> > kubectl --kubeconfig kube.conf get services --all-namespaces
> >
> > NAMESPACE  NAME   TYPE
> >   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
> >
> > defaultkubernetes
> >   ClusterIP   10.96.0.1443/TCP  22h
> >
> > kube-systemkube-dns
> >   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-api
> >   ClusterIP   10.102.124.599000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-metrics-scraper
> ClusterIP   10.111.159.255   
> >   8000/TCP 22h
> >
> > kubernetes-dashboard   kubernetes-dashboard-web
> >   ClusterIP   10.108.135.214   8000/TCP 22h
> >
> >
> >
> >
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
>
> --- Disclaimer: --
> This message and its contents are intended solely for the designated
> addressee and are proprietary to Kloudspot. The information in this email
> is meant exclusively for Kloudspot business use. Any use by individuals
> other than the addressee constitutes misuse and an infringement of
> Kloudspot's proprietary rights. If you are not the intended recipient,
> please return this email to the sender. Kloudspot cannot guarantee the
> security or error-free transmission of e-mail communications. Information
> could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. Therefore, Kloudspot shall not be liable
> for any issues arising from the transmission of this email.
>


Re: testing with uefi on Ubuntu22 KVM

2024-02-20 Thread Wei ZHOU
Hi,

> guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd

This is incorrect, please use `OVMF_VARS.ms.fd` or `OVMF_VARS_4M.ms.fd`.

> Is it safe to just delete the row in the db?

Yes, it is safe.


-Wei

On Tue, 20 Feb 2024 at 13:31,  wrote:

> Hi,
>
> I started testing with uefi on Ubuntu 22 KVM. I search the mailinglist and
> found some discussion and problems with uefi secure mode on Ubuntu22 KVM.
>
> Is there already a fix for "Guest has not initialized the display
> (yet)."-prolem on console proxy?
>
>
>
> For my test I added /etc/cloudstack/agent/uefi.properties with the
> following
> values:
>
> guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd
>
> guest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS.fd
>
> guest.loader.secure=/usr/share/OVMF/OVMF_CODE.secboot.fd
>
> guest.loader.legacy=/usr/share/OVMF/OVMF_CODE.fd
>
> guest.nvram.path=/var/lib/libvirt/qemu/nvram/
>
>
>
> I also added the following line to /etc/libvirt/qemu.conf:
>
> nvram =
> ["/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd"]
>
>
>
> I restarted the following services:
>
> service libvirtd restart
>
> service cloudstack-agent restart
>
>
>
> I can see that CS is now showing the host as UEFI supported = true and CS
> added a row to db table host_details:
>
> | 7176 |   4 | host.uefi.enable   |
> true
> |
>
>
>
> I tried to disable UEFI support for this host by deleting the
> uefi.properties file and deleted the added line in qemu.conf file. I
> restarted both services.
>
> It looks like CS is not being updated. UI still shows me UEFI supported =
> true and db still shows me the row.
>
> Is this expected? I know that there is a check if UEFI is supported by the
> agent. This was implemented in 4.15 or 4.16 if I remember correctly. But is
> there also a check which will disable the support for a host?
>
>
>
> Is it save to just delete the row in the db?
>
>
>
> Regards,
>
> Swen
>
>


testing with uefi on Ubuntu22 KVM

2024-02-20 Thread me
Hi,

I started testing with uefi on Ubuntu 22 KVM. I search the mailinglist and
found some discussion and problems with uefi secure mode on Ubuntu22 KVM.

Is there already a fix for "Guest has not initialized the display
(yet)."-prolem on console proxy?

 

For my test I added /etc/cloudstack/agent/uefi.properties with the following
values:

guest.nvram.template.secure=/usr/share/OVMF/OVMF_VARS.fd

guest.nvram.template.legacy=/usr/share/OVMF/OVMF_VARS.fd

guest.loader.secure=/usr/share/OVMF/OVMF_CODE.secboot.fd

guest.loader.legacy=/usr/share/OVMF/OVMF_CODE.fd

guest.nvram.path=/var/lib/libvirt/qemu/nvram/

 

I also added the following line to /etc/libvirt/qemu.conf:

nvram =
["/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd"]

 

I restarted the following services:

service libvirtd restart

service cloudstack-agent restart

 

I can see that CS is now showing the host as UEFI supported = true and CS
added a row to db table host_details:

| 7176 |   4 | host.uefi.enable   | true
|

 

I tried to disable UEFI support for this host by deleting the
uefi.properties file and deleted the added line in qemu.conf file. I
restarted both services.

It looks like CS is not being updated. UI still shows me UEFI supported =
true and db still shows me the row.

Is this expected? I know that there is a check if UEFI is supported by the
agent. This was implemented in 4.15 or 4.16 if I remember correctly. But is
there also a check which will disable the support for a host?

 

Is it save to just delete the row in the db?

 

Regards,

Swen



Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi Wei,

The cloudstack is setup on a single node and the info I provided is from that 
node.

I think as the control node and worker node is CLI based, Need to access 
dashboard from outside the control node.
Please guide me for that.

Thanks and Regards,
Bharat Saini

[signature_1512528664]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 4:27 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


The output in the control nodes looks good.

Are you able to access the dashboard following the instruction on
https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?

-Wei

On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> Please check the below info I think you will get it
>
> kubectl --kubeconfig kube.conf get pods --all-namespaces
>
> NAMESPACE  NAME
> READY   STATUSRESTARTS  AGE
>
> kube-systemcoredns-76f75df574-lfgzj
> 1/1 Running   0 22h
>
> kube-systemcoredns-76f75df574-mtktc
> 1/1 Running   0 22h
>
> kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-system
>   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
>   Running   0 22h
>
> kube-systemkube-proxy-74zcb
> 1/1 Running   0 22h
>
> kube-systemkube-proxy-hts4p
> 1/1 Running   0 22h
>
> kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-systemweave-net-8j6j2
> 2/2 Running   0 22h
>
> kube-systemweave-net-mlv6t
> 2/2 Running   1 (22h ago)   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> 1/1 Running   0 22h
>
> kubernetes-dashboard   kubernetes-dashboard-metrics-scraper-b847579df-tjw86
>   1/1 Running   0 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> 1/1 Running   0 22h
>
>
>
> kubectl --kubeconfig kube.conf get nodes --all-namespaces
>
> NAMESTATUS   ROLES   AGE   VERSION
>
> kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h   v1.29.2
>
> kloudspot-app-node-18dc0a3f52e  Ready  22h   v1.29.2
>
>
>
> kubectl --kubeconfig kube.conf get services --all-namespaces
>
> NAMESPACE  NAME   TYPE
>   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
>
> defaultkubernetes
>   ClusterIP   10.96.0.1443/TCP  22h
>
> kube-systemkube-dns
>   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api
>   ClusterIP   10.102.124.599000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-metrics-scraper   ClusterIP   
> 10.111.159.255   
>   8000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web
>   ClusterIP   10.108.135.214   8000/TCP 22h
>
>
>
>
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>

--- Disclaimer: --
This message and its contents are intended solely for the designated addressee 
and are proprietary to Kloudspot. The information in this email is meant 
exclusively for Kloudspot business use. Any use by individuals other than the 
addressee constitutes misuse and an infringement of Kloudspot's proprietary 
rights. If you are not the intended recipient, please return this email to the 
sender. Kloudspot cannot guarantee the security or error-free transmission of 
e-mail communications. Information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. Therefore, Kloudspot 
shall not be liable for any issues arising from the transmission of this email.


Re: K8s Dashboard Not Found

2024-02-20 Thread Wei ZHOU
The output in the control nodes looks good.

Are you able to access the dashboard following the instruction on
https://github.com/apache/cloudstack/pull/7764#issuecomment-1647247993 ?

-Wei

On Tue, 20 Feb 2024 at 11:10, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> Please check the below info I think you will get it
>
> kubectl --kubeconfig kube.conf get pods --all-namespaces
>
> NAMESPACE  NAME
> READY   STATUSRESTARTS  AGE
>
> kube-systemcoredns-76f75df574-lfgzj
> 1/1 Running   0 22h
>
> kube-systemcoredns-76f75df574-mtktc
> 1/1 Running   0 22h
>
> kube-systemetcd-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-system
>   kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1
>   Running   0 22h
>
> kube-systemkube-proxy-74zcb
> 1/1 Running   0 22h
>
> kube-systemkube-proxy-hts4p
> 1/1 Running   0 22h
>
> kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
> 1/1 Running   0 22h
>
> kube-systemweave-net-8j6j2
> 2/2 Running   0 22h
>
> kube-systemweave-net-mlv6t
> 2/2 Running   1 (22h ago)   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
> 1/1 Running   0 22h
>
> kubernetes-dashboard   kubernetes-dashboard-metrics-scraper-b847579df-tjw86
>   1/1 Running   0 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
> 1/1 Running   0 22h
>
>
>
> kubectl --kubeconfig kube.conf get nodes --all-namespaces
>
> NAMESTATUS   ROLES   AGE   VERSION
>
> kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h   v1.29.2
>
> kloudspot-app-node-18dc0a3f52e  Ready  22h   v1.29.2
>
>
>
> kubectl --kubeconfig kube.conf get services --all-namespaces
>
> NAMESPACE  NAME   TYPE
>   CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
>
> defaultkubernetes
>   ClusterIP   10.96.0.1443/TCP  22h
>
> kube-systemkube-dns
>   ClusterIP   10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api
>   ClusterIP   10.102.124.599000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-metrics-scraper   ClusterIP   
> 10.111.159.255   
>   8000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web
>   ClusterIP   10.108.135.214   8000/TCP 22h
>
>
>
>
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>


Re: [D] Changing compute offering / scaling VM and root disk [cloudstack]

2024-02-20 Thread via GitHub


GitHub user DaanHoogland added a comment to the discussion: Changing compute 
offering / scaling VM and root disk

Do you mean that the the user can still call `updateDiskOffering` despite it 
being denied in their role?
With thin provisioning the initial size should be just what is really used and 
it should auto grow up to it's limit.
Please describe the scenario you feel is symptomatic of a bug?

GitHub link: 
https://github.com/apache/cloudstack/discussions/8578#discussioncomment-8528040


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



RE: [VOTE] next version 20 instead of 4.20

2024-02-20 Thread Paul Angus
Hi Daan,


>From our wiki page:

-- Quote
For those that may not be familiar with Semantic Versioning, the number format 
is: X.Y.Z, where X is the major version, Y is the minor version, Z is the patch 
number. The community strives to ensure backward API compatibility within each 
major version (i.e.: code written against the CloudStack 4.0.0-incubating API 
should work with all future 4.y.z versions). The community may decide to 
increment the major version number in situations where underlying 
implementation details require a cloud operator to face significant challenges 
in upgrading from one version to the next. This should be rare situation.

In practice, feature releases will normally be an increment of the minor 
version number of the project. Feature releases that break backward 
compatibility will cause the major version number to be incremented. Bug fix 
releases will never increment anything except the patch number.
-- End quote.


Specifically:
The community may decide to increment the major version number in situations 
where underlying implementation details require a cloud operator to face 
significant challenges in upgrading from one version to the next. This should 
be rare situation.


>From this I can't see how we have broken the versioning.  Have we introduced 
>anything that meets the criteria above?  Again, the term 'minor version' is an 
>unfortunate one because it makes it sound like it wouldn’t contain big new 
>features.  However, that isn't the case, it can and should.

Also, I'd like to see fully laid out for the next few versions, how versioning 
is proposed to work, and what each part of x.y.z.n is then going to denote.

- Paul

-Original Message-
From: Daan Hoogland  
Sent: Tuesday, February 20, 2024 10:05 AM
To: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: [VOTE] next version 20 instead of 4.20

Vivek, we could, but the main idea is that we repair our versioning system and 
make clear how we are actually dealing with our current system, which is major 
- new , possibly breaking features minor - improvements and enhancements tiny - 
urgent (security) fixes

and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current versioning 
system.

On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar  
wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future.  Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus  wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 
> > breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level 
> > updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will 
> > it be 21 ?  is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is 
> > a misunderstanding as to what semantic versioning means. For our project 
> > its explained here [1].   Major versions meaning "probably going to break a 
> > load of people's stuff', with minor versions not breaking stuff (at least 
> > not on purpose). So I get calling them minor versions really underplays the 
> > changes it can hold.
> >
> >
> > I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think 
> > the vote should be on 'A change to the version numbering scheme' and then 
> > what is proposed properly laid out.
> >
> >
> >
> >
> > [1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 
> > (section on versioning about 2/3 down)
> >
> > -Original Message-
> > From: Daan Hoogland 
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev 
> > Cc: users 
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be 
> > counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning 
> > scheme. The result would be that the next major version will be 20 instead 
> > of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the 
> > versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> 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 

Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi,



Also check below as well

kubectl --kubeconfig kube.conf get secrets -A

NAMESPACE  NAME  TYPE   
   DATA   AGE

kube-systembootstrap-token-6770b3
bootstrap.kubernetes.io/token 6  24h

kubernetes-dashboard   kubernetes-dashboard-csrf Opaque 
   1  24h

kubernetes-dashboard   kubernetes-dashboard-key-holder   Opaque 
   2  24h

kubernetes-dashboard   kubernetes-dashboard-token
kubernetes.io/service-account-token   3  22h


Thanks and Regards,
Bharat Saini

[signature_146620117]

From: Bharat Bhushan Saini 
Date: Tuesday, 20 February 2024 at 3:40 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
Hi Wei,

Please check the below info I think you will get it
kubectl --kubeconfig kube.conf get pods --all-namespaces
NAMESPACE  NAME 
   READY   STATUSRESTARTS  AGE
kube-systemcoredns-76f75df574-lfgzj 
   1/1 Running   0 22h
kube-systemcoredns-76f75df574-mtktc 
   1/1 Running   0 22h
kube-systemetcd-kloudspot-app-control-18dc0a3d55e   
   1/1 Running   0 22h
kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e 
   1/1 Running   0 22h
kube-system
kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1 Running   0 
22h
kube-systemkube-proxy-74zcb 
   1/1 Running   0 22h
kube-systemkube-proxy-hts4p 
   1/1 Running   0 22h
kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e 
   1/1 Running   0 22h
kube-systemweave-net-8j6j2  
   2/2 Running   0 22h
kube-systemweave-net-mlv6t  
   2/2 Running   1 (22h ago)   22h
kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
   1/1 Running   0 22h
kubernetes-dashboard   kubernetes-dashboard-metrics-scraper-b847579df-tjw86 
   1/1 Running   0 22h
kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
   1/1 Running   0 22h

kubectl --kubeconfig kube.conf get nodes --all-namespaces
NAMESTATUS   ROLES   AGE   VERSION
kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h   v1.29.2
kloudspot-app-node-18dc0a3f52e  Ready  22h   v1.29.2

kubectl --kubeconfig kube.conf get services --all-namespaces
NAMESPACE  NAME   TYPE
CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
defaultkubernetes ClusterIP   
10.96.0.1443/TCP  22h
kube-systemkube-dns   ClusterIP   
10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
kubernetes-dashboard   kubernetes-dashboard-api   ClusterIP   
10.102.124.599000/TCP 22h
kubernetes-dashboard   kubernetes-dashboard-metrics-scraper   ClusterIP   
10.111.159.255   8000/TCP 22h
kubernetes-dashboard   kubernetes-dashboard-web   ClusterIP   
10.108.135.214   8000/TCP 22h



Thanks and Regards,
Bharat Saini

[signature_4051908585]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 1:32 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


Also, can you try with the CKS 1.27.8 or 1.28.4 on
https://download.cloudstack.org/cks/ ?

-Wei


On Tue, 20 Feb 2024 at 08:31, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> I made the ISO from cloudstack-comman and that ISO was of latest version
> 1.29.1.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_698188016]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 12:28 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> Which CKS ISO do you use?
>
> On Tuesday, February 20, 2024, Bharat Bhushan Saini
>  wrote:
>
> > Hi All,
> >
> > I enabled the CKS service in the cloudstack dashboard. After all the
> > things done I am unable to access the K8s dashboard.
> >
> > I encountered in the browser that 

Re: K8s Dashboard Not Found

2024-02-20 Thread Bharat Bhushan Saini
Hi Wei,

Please check the below info I think you will get it
kubectl --kubeconfig kube.conf get pods --all-namespaces
NAMESPACE  NAME 
   READY   STATUSRESTARTS  AGE
kube-systemcoredns-76f75df574-lfgzj 
   1/1 Running   0 22h
kube-systemcoredns-76f75df574-mtktc 
   1/1 Running   0 22h
kube-systemetcd-kloudspot-app-control-18dc0a3d55e   
   1/1 Running   0 22h
kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e 
   1/1 Running   0 22h
kube-system
kube-controller-manager-kloudspot-app-control-18dc0a3d55e   1/1 Running   0 
22h
kube-systemkube-proxy-74zcb 
   1/1 Running   0 22h
kube-systemkube-proxy-hts4p 
   1/1 Running   0 22h
kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e 
   1/1 Running   0 22h
kube-systemweave-net-8j6j2  
   2/2 Running   0 22h
kube-systemweave-net-mlv6t  
   2/2 Running   1 (22h ago)   22h
kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
   1/1 Running   0 22h
kubernetes-dashboard   kubernetes-dashboard-metrics-scraper-b847579df-tjw86 
   1/1 Running   0 22h
kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
   1/1 Running   0 22h

kubectl --kubeconfig kube.conf get nodes --all-namespaces
NAMESTATUS   ROLES   AGE   VERSION
kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h   v1.29.2
kloudspot-app-node-18dc0a3f52e  Ready  22h   v1.29.2

kubectl --kubeconfig kube.conf get services --all-namespaces
NAMESPACE  NAME   TYPE
CLUSTER-IP   EXTERNAL-IP   PORT(S)  AGE
defaultkubernetes ClusterIP   
10.96.0.1443/TCP  22h
kube-systemkube-dns   ClusterIP   
10.96.0.10   53/UDP,53/TCP,9153/TCP   22h
kubernetes-dashboard   kubernetes-dashboard-api   ClusterIP   
10.102.124.599000/TCP 22h
kubernetes-dashboard   kubernetes-dashboard-metrics-scraper   ClusterIP   
10.111.159.255   8000/TCP 22h
kubernetes-dashboard   kubernetes-dashboard-web   ClusterIP   
10.108.135.214   8000/TCP 22h



Thanks and Regards,
Bharat Saini

[signature_4051908585]

From: Wei ZHOU 
Date: Tuesday, 20 February 2024 at 1:32 PM
To: users@cloudstack.apache.org 
Subject: Re: K8s Dashboard Not Found
EXTERNAL EMAIL: Please verify the sender email address before taking any 
action, replying, clicking any link or opening any attachment.


Also, can you try with the CKS 1.27.8 or 1.28.4 on
https://download.cloudstack.org/cks/ ?

-Wei


On Tue, 20 Feb 2024 at 08:31, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> I made the ISO from cloudstack-comman and that ISO was of latest version
> 1.29.1.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_698188016]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 12:28 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> Which CKS ISO do you use?
>
> On Tuesday, February 20, 2024, Bharat Bhushan Saini
>  wrote:
>
> > Hi All,
> >
> > I enabled the CKS service in the cloudstack dashboard. After all the
> > things done I am unable to access the K8s dashboard.
> >
> > I encountered in the browser that ‘services “Kubernetes-dashboard” not
> > found’.
> >
> > Kindly suggest any resolvement for this.
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
> > [image: signature_2321445983]
> >
> > --- Disclaimer: --
> > This message and its contents are intended solely for the designated
> > addressee and are proprietary to Kloudspot. The information in this email
> > is meant exclusively for Kloudspot business use. Any use by individuals
> > other than the addressee constitutes misuse and an infringement of
> > Kloudspot's proprietary rights. If you are not the intended recipient,
> > please return this email to the sender. Kloudspot cannot guarantee the
> > security or error-free transmission of e-mail communications. Information
> > could be 

Re: [VOTE] next version 20 instead of 4.20

2024-02-20 Thread Daan Hoogland
Vivek, we could, but the main idea is that we repair our versioning
system and make clear how we are actually dealing with our current
system, which is
major - new , possibly breaking features
minor - improvements and enhancements
tiny - urgent (security) fixes

and in addition we would go to 20 to indicate that is the follower of
4.19 not of 4. Someone may implement a new cloudstack (cloudstack5 for
instance) but this would not have anything to do with our current
versioning system.

On Tue, Feb 20, 2024 at 5:06 AM Vivek Kumar
 wrote:
>
> Why not 5.0 ? Then it will be like 5.1, 5.2 in the future.  Just asking ..!
>
>
> > On 19-Feb-2024, at 10:49 PM, Paul Angus  wrote:
> >
> > Hi Daan,
> >
> > Can you clarify what we are actually voting on please.
> >
> > In thread that is linked I've seen:
> >
> > "[the vote] will be to adjust to the semantic versioning system."
> > - you can't go to 20 AND keep semantic versioning. The act of going to 20 
> > breaks semantic versioning [1].
> >
> > " drop the 4 at version 20 and continue as usual with minor and patch level 
> > updates as we have in the past."
> > - what's supposed to come next ? in lieu of what would have been 4.21 will 
> > it be 21 ?  is it going to be 20.1 then 20.2 ?
> >
> > From the thread and how people are referring to 'minor versions', there is 
> > a misunderstanding as to what semantic versioning means. For our project 
> > its explained here [1].   Major versions meaning "probably going to break a 
> > load of people's stuff', with minor versions not breaking stuff (at least 
> > not on purpose). So I get calling them minor versions really underplays the 
> > changes it can hold.
> >
> >
> > I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think 
> > the vote should be on 'A change to the version numbering scheme' and then 
> > what is proposed properly laid out.
> >
> >
> >
> >
> > [1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 
> > (section on versioning about 2/3 down)
> >
> > -Original Message-
> > From: Daan Hoogland 
> > Sent: Monday, February 19, 2024 12:50 PM
> > To: dev 
> > Cc: users 
> > Subject: [VOTE] next version 20 instead of 4.20
> >
> > LS,
> >
> > This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be 
> > counted please reply to dev@.
> >
> > As discussed in [1] we are deciding to drop the 4 from our versioning 
> > scheme. The result would be that the next major version will be 20 instead 
> > of 4.20, as it would be in a traditional upgrade. As 20 > 4 and the 
> > versions are processed numerically there are no technical impediments.
> >
> > +1 agree (next major version as 20
> > 0 (no opinion)
> > -1 disagree (keep 4.20 as the next version, give a reason)
> >
> > As this is a lazy consensus vote any -1 should be accompanied with a reason.
> >
> > [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
> >
> > --
> > Daan
>
>
> --
> 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.



-- 
Daan


Re: [VOTE] next version 20 instead of 4.20

2024-02-20 Thread Daan Hoogland
Paul,

On Mon, Feb 19, 2024 at 6:21 PM Paul Angus  wrote:
>
> Hi Daan,
>
> Can you clarify what we are actually voting on please.
>
> In thread that is linked I've seen:
>
> "[the vote] will be to adjust to the semantic versioning system."
> - you can't go to 20 AND keep semantic versioning. The act of going to 20 
> breaks semantic versioning [1].

We are using a crooked semantic versioning system and that is entirely
due to maintaining the 4 in our versioning scheme. We have been
changing and adding major features on updating the second number (20
to be). We have been using the third number for bug fixes and minor
enhancements. And we have been using the fourth number for emergency
security fixes.

So we are not maintaining semantic versioning but going to semantic
versioning by repairing our system of versioning. You could say this
is a minor bugfix.

>
> " drop the 4 at version 20 and continue as usual with minor and patch level 
> updates as we have in the past."
> - what's supposed to come next ? in lieu of what would have been 4.21 will it 
> be 21 ?  is it going to be 20.1 then 20.2 ?

Yes, exactly. Except for dropping the 4, nothing will change.

>
> From the thread and how people are referring to 'minor versions', there is a 
> misunderstanding as to what semantic versioning means. For our project its 
> explained here [1].   Major versions meaning "probably going to break a load 
> of people's stuff', with minor versions not breaking stuff (at least not on 
> purpose). So I get calling them minor versions really underplays the changes 
> it can hold.
>
>
> I'm going to stick in a -1.  Not as hard 'no' to any changes, but I think the 
> vote should be on 'A change to the version numbering scheme' and then what is 
> proposed properly laid out.
>
>
>
>
> [1]   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases 
> (section on versioning about 2/3 down)
>
> -Original Message-
> From: Daan Hoogland 
> Sent: Monday, February 19, 2024 12:50 PM
> To: dev 
> Cc: users 
> Subject: [VOTE] next version 20 instead of 4.20
>
> LS,
>
> This is a vote on dev@c.a.o with cc to users@c.a.o. If you want to be counted 
> please reply to dev@.
>
> As discussed in [1] we are deciding to drop the 4 from our versioning scheme. 
> The result would be that the next major version will be 20 instead of 4.20, 
> as it would be in a traditional upgrade. As 20 > 4 and the versions are 
> processed numerically there are no technical impediments.
>
> +1 agree (next major version as 20
> 0 (no opinion)
> -1 disagree (keep 4.20 as the next version, give a reason)
>
> As this is a lazy consensus vote any -1 should be accompanied with a reason.
>
> [1] https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
>
> --
> Daan



-- 
Daan


AW: ha checks on kvm hosts running even with ha disabled

2024-02-20 Thread me
Thx again, Slavka!
I am going to open an issue regarding this. I would expect another behavior as 
an administrator.

Regards,
Swen


-Ursprüngliche Nachricht-
Von: Slavka Peleva  
Gesendet: Dienstag, 20. Februar 2024 09:22
An: users@cloudstack.apache.org
Betreff: Re: ha checks on kvm hosts running even with ha disabled

Unfortunately, there is no check if the HA is enabled/disabled in the agent's 
code. The `reboot.host.and.alert.management.on.heartbeat.timeout`
property is enabled by default and only manually you can disable it.

Best regards,
Slavka

On Tue, Feb 20, 2024 at 10:14 AM  wrote:

> Hi Slavka,
>
> thx for your reply!
>
> Do you know the reason why KVMHAMonitor will be initialized even when 
> host ha has been disabled by UI?
> From an admin point of view
> reboot.host.and.alert.management.on.heartbeat.timeout=false should be 
> set automatically when you disable host ha. Is there a reason for not doing 
> it?
>
> Regards,
> Swen
>
> -Ursprüngliche Nachricht-
> Von: Slavka Peleva 
> Gesendet: Dienstag, 20. Februar 2024 08:50
> An: users@cloudstack.apache.org
> Betreff: Re: ha checks on kvm hosts running even with ha disabled
>
> Hi Swen,
>
> The KVMHAMonitor is initialised here
> <
> https://github.com/apache/cloudstack/blob/8f6721ed4c4e1b31081a951c62ff
> be5331cf16d4/plugins/hypervisors/kvm/src/main/java/com/cloud/hyperviso
> r/kvm/resource/LibvirtComputingResource.java#L1202
> >
> even
> if you didn't enable the HA.
> If I may advise you to disable in the `agent.properties` file the 
> property 
> `reboot.host.and.alert.management.on.heartbeat.timeout=false`. 
> CloudStack will still execute the heartbeat check but won't restart the agent 
> host on failure.
>
> Best regards,
> Slavka
>
> On Tue, Feb 20, 2024 at 12:41 AM Swen  wrote:
>
> > Hi all,
> >
> > we encountered a strange issue today in our lab installation. We are 
> > running CS 4.19.0 upgraded from CS 4.18.1 with linstor as primary 
> > storage. We are using a linstor jar file provided by Linbit which is 
> > not the default one part of default 4.19.0!
> >
> > This updated plugin already includes a new feature to use linstor 
> > storage for host ha. I provide this only for information reasons.
> >
> > The issue we encountered was that even we do not have HA enabled on 
> > cluster and host level, cloudstack agent on our KVM hosts triggered 
> > HA actions and rebooted our hosts. We found this on our agent.log:
> >
> > Feb 19 11:53:05 pc-kvm-2 java[6617]: WARN  
> > [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool 
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 2 of 5.
> >
> > Feb 19 11:58:58 pc-kvm-2 java[9465]: WARN  
> > [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool 
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 3 of 5.
> >
> > Feb 19 12:00:08 pc-kvm-2 java[9465]: WARN  
> > [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool 
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 4 of 5.
> >
> > Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  
> > [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool 
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 5 of 5.
> >
> > Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  
> > [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool 
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; stopping 
> > cloudstack-agent.
> >
> > Feb 19 12:02:08 pc-kvm-2 heartbeat: kvmspheartbeat.sh will reboot 
> > system because it was unable to write the heartbeat to the storage.
> >
> > We and Linbit did some debugging. We tried to understand why the 
> > cloudstack agent is running those checks in the first place. We were 
> > unable to find any code which checks if host HA is enabled or not 
> > and will not perform HA tasks if HA is disabled. Can somebody please 
> > double-check this?
> >
> > Thank you very much!
> >
> > Regards,
> > Swen
> >
> >
> >
>
>
>




Community Over Code Asia 2024 Travel Assistance Applications now open!

2024-02-20 Thread Gavin McDonald
Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this year's applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, May 10th, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you to
apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)


KVM VM consoles connection timing out due to authentication failure

2024-02-20 Thread Kapil Bhuskute
Hello,
We have a POD setup with CloudStack 4.19 latest version and all schema with a 
Zone, POD, and cluster has been setup using a Advance Shared networking 
Architecture.
We have a couple of VMs spun up on this environment now and were trying to 
access its VM console via VNC port. However, it has been observed that the VM 
console connections are getting timed out due to failed authentication errors 
observed on the vmconsoleproxy System VM logs.

VM Console not working . We have mysql ssl enabled and console proxy ssl is 
disabled for now.
Failed to connect/access token expired.
While checking logs on CCVM ..we see vnc auth failed.
2024-02-13 16:12:12,926 INFO [vnc.security.VncTLSSecurity] (Thread-86:null) 
Processing VNC TLS security
2024-02-13 16:12:12,930 INFO [utils.nio.Link] (Thread-86:null) Conf file found: 
/usr/local/cloud/systemvm/conf/agent.properties
2024-02-13 16:12:12,964 INFO [vnc.security.VncAuthSecurity] (Thread-83:null) 
Finished VNCAuth security
2024-02-13 16:12:12,966 ERROR [consoleproxy.vnc.NoVncClient] (Thread-83:null) 
Connection to VNC server failed: wrong password.
2024-02-13 16:12:12,966 ERROR [consoleproxy.vnc.NoVncClient] (Thread-83:null) 
Connection to VNC server failed: wrong password. - Reason: Authentication failed
2024-02-13 16:12:13,164 INFO [vnc.security.VncAuthSecurity] (Thread-86:null) 
VNC server requires password authentication
2024-02-13 16:12:13,184 INFO [vnc.security.VncAuthSecurity] (Thread-86:null) 
Finished VNCAuth security


Kindly suggest if anyone is aware of any fix for this.

Regards,
Kapil B


Re: IPv4+IPv6 Dual Stack Networking for Shared Networks

2024-02-20 Thread Wido den Hollander




Op 20/02/2024 om 09:16 schreef Wei ZHOU:

Hi,

For a shared network with IPv6, you need to configure SLAAC on the upstream
router, as CloudStack VR is not the IPv6 gateway.



Correct with a few additions:

- Make sure you set the lifetime of the RA to something like 60s and the 
interval to 10s, this makes for a fast failover


OR

- Use VRRPv3 and sent out SLAAC with the Unicast VRRPv3 address


- You might want to sent the rDNS servers with SLAAC as well
- Make sure privacy extensions are disabled inside the VMs

Wido


-Wei


On Tue, 20 Feb 2024 at 09:00, Ozhan Karaman  wrote:


Hi All;

I am using Cloudstack 4.19, I am trying to enable IPv4+IPv6 Dual Stack
Networking for Shared Networks, so I add a new network with both dual stack
ip definitions in Shared Mode. I started the vm and I noticed that I don't
get ipv6 ip from VR.

I connected to VR to check dhcp server/dnsmasq setup and it's setup is ok
but I noticed that VR's eth0 does only have an ipv4 ip address not v6. I
started to investigate more in VR and I noticed that ipv6 is disabled by
sysctl settings so network setup could not be successfully applied. By the
way, I am using the 4.19 SystemVM template.

So it looks like the VR image does not like to work with IPv6, I started to
investigate Network Offerings to check out if ipv6 needs to be enabled for
shared networking somewhere but I could not find any specific settings.

Does anyone have any clue for the missing piece?

Thanks
Ozhan





Re: ha checks on kvm hosts running even with ha disabled

2024-02-20 Thread Slavka Peleva
Unfortunately, there is no check if the HA is enabled/disabled in the
agent's code. The `reboot.host.and.alert.management.on.heartbeat.timeout`
property is enabled by default and only manually you can disable it.

Best regards,
Slavka

On Tue, Feb 20, 2024 at 10:14 AM  wrote:

> Hi Slavka,
>
> thx for your reply!
>
> Do you know the reason why KVMHAMonitor will be initialized even when host
> ha has been disabled by UI?
> From an admin point of view
> reboot.host.and.alert.management.on.heartbeat.timeout=false should be set
> automatically when you disable host ha. Is there a reason for not doing it?
>
> Regards,
> Swen
>
> -Ursprüngliche Nachricht-
> Von: Slavka Peleva 
> Gesendet: Dienstag, 20. Februar 2024 08:50
> An: users@cloudstack.apache.org
> Betreff: Re: ha checks on kvm hosts running even with ha disabled
>
> Hi Swen,
>
> The KVMHAMonitor is initialised here
> <
> https://github.com/apache/cloudstack/blob/8f6721ed4c4e1b31081a951c62ffbe5331cf16d4/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1202
> >
> even
> if you didn't enable the HA.
> If I may advise you to disable in the `agent.properties` file the property
> `reboot.host.and.alert.management.on.heartbeat.timeout=false`. CloudStack
> will still execute the heartbeat check but won't restart the agent host on
> failure.
>
> Best regards,
> Slavka
>
> On Tue, Feb 20, 2024 at 12:41 AM Swen  wrote:
>
> > Hi all,
> >
> > we encountered a strange issue today in our lab installation. We are
> > running CS 4.19.0 upgraded from CS 4.18.1 with linstor as primary
> > storage. We are using a linstor jar file provided by Linbit which is
> > not the default one part of default 4.19.0!
> >
> > This updated plugin already includes a new feature to use linstor
> > storage for host ha. I provide this only for information reasons.
> >
> > The issue we encountered was that even we do not have HA enabled on
> > cluster and host level, cloudstack agent on our KVM hosts triggered HA
> > actions and rebooted our hosts. We found this on our agent.log:
> >
> > Feb 19 11:53:05 pc-kvm-2 java[6617]: WARN  [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 2 of 5.
> >
> > Feb 19 11:58:58 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 3 of 5.
> >
> > Feb 19 12:00:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 4 of 5.
> >
> > Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 5 of 5.
> >
> > Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> > (Thread-1:) (logid:) Write heartbeat for pool
> > [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; stopping
> > cloudstack-agent.
> >
> > Feb 19 12:02:08 pc-kvm-2 heartbeat: kvmspheartbeat.sh will reboot
> > system because it was unable to write the heartbeat to the storage.
> >
> > We and Linbit did some debugging. We tried to understand why the
> > cloudstack agent is running those checks in the first place. We were
> > unable to find any code which checks if host HA is enabled or not and
> > will not perform HA tasks if HA is disabled. Can somebody please
> > double-check this?
> >
> > Thank you very much!
> >
> > Regards,
> > Swen
> >
> >
> >
>
>
>


Re: IPv4+IPv6 Dual Stack Networking for Shared Networks

2024-02-20 Thread Wei ZHOU
Hi,

For a shared network with IPv6, you need to configure SLAAC on the upstream
router, as CloudStack VR is not the IPv6 gateway.

-Wei


On Tue, 20 Feb 2024 at 09:00, Ozhan Karaman  wrote:

> Hi All;
>
> I am using Cloudstack 4.19, I am trying to enable IPv4+IPv6 Dual Stack
> Networking for Shared Networks, so I add a new network with both dual stack
> ip definitions in Shared Mode. I started the vm and I noticed that I don't
> get ipv6 ip from VR.
>
> I connected to VR to check dhcp server/dnsmasq setup and it's setup is ok
> but I noticed that VR's eth0 does only have an ipv4 ip address not v6. I
> started to investigate more in VR and I noticed that ipv6 is disabled by
> sysctl settings so network setup could not be successfully applied. By the
> way, I am using the 4.19 SystemVM template.
>
> So it looks like the VR image does not like to work with IPv6, I started to
> investigate Network Offerings to check out if ipv6 needs to be enabled for
> shared networking somewhere but I could not find any specific settings.
>
> Does anyone have any clue for the missing piece?
>
> Thanks
> Ozhan
>


AW: ha checks on kvm hosts running even with ha disabled

2024-02-20 Thread me
Hi Slavka,

thx for your reply!

Do you know the reason why KVMHAMonitor will be initialized even when host ha 
has been disabled by UI?
>From an admin point of view 
>reboot.host.and.alert.management.on.heartbeat.timeout=false should be set 
>automatically when you disable host ha. Is there a reason for not doing it?

Regards,
Swen

-Ursprüngliche Nachricht-
Von: Slavka Peleva  
Gesendet: Dienstag, 20. Februar 2024 08:50
An: users@cloudstack.apache.org
Betreff: Re: ha checks on kvm hosts running even with ha disabled

Hi Swen,

The KVMHAMonitor is initialised here

even
if you didn't enable the HA.
If I may advise you to disable in the `agent.properties` file the property 
`reboot.host.and.alert.management.on.heartbeat.timeout=false`. CloudStack will 
still execute the heartbeat check but won't restart the agent host on failure.

Best regards,
Slavka

On Tue, Feb 20, 2024 at 12:41 AM Swen  wrote:

> Hi all,
>
> we encountered a strange issue today in our lab installation. We are 
> running CS 4.19.0 upgraded from CS 4.18.1 with linstor as primary 
> storage. We are using a linstor jar file provided by Linbit which is 
> not the default one part of default 4.19.0!
>
> This updated plugin already includes a new feature to use linstor 
> storage for host ha. I provide this only for information reasons.
>
> The issue we encountered was that even we do not have HA enabled on 
> cluster and host level, cloudstack agent on our KVM hosts triggered HA 
> actions and rebooted our hosts. We found this on our agent.log:
>
> Feb 19 11:53:05 pc-kvm-2 java[6617]: WARN  [kvm.resource.KVMHAMonitor]
> (Thread-1:) (logid:) Write heartbeat for pool 
> [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 2 of 5.
>
> Feb 19 11:58:58 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> (Thread-1:) (logid:) Write heartbeat for pool 
> [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 3 of 5.
>
> Feb 19 12:00:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> (Thread-1:) (logid:) Write heartbeat for pool 
> [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 4 of 5.
>
> Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> (Thread-1:) (logid:) Write heartbeat for pool 
> [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; try: 5 of 5.
>
> Feb 19 12:01:08 pc-kvm-2 java[9465]: WARN  [kvm.resource.KVMHAMonitor]
> (Thread-1:) (logid:) Write heartbeat for pool 
> [71c272d3-b180-4b18-a0fc-cfc1dc5b86c9] failed: Down; stopping 
> cloudstack-agent.
>
> Feb 19 12:02:08 pc-kvm-2 heartbeat: kvmspheartbeat.sh will reboot 
> system because it was unable to write the heartbeat to the storage.
>
> We and Linbit did some debugging. We tried to understand why the 
> cloudstack agent is running those checks in the first place. We were 
> unable to find any code which checks if host HA is enabled or not and 
> will not perform HA tasks if HA is disabled. Can somebody please 
> double-check this?
>
> Thank you very much!
>
> Regards,
> Swen
>
>
>




Re: K8s Dashboard Not Found

2024-02-20 Thread Wei ZHOU
Also, can you try with the CKS 1.27.8 or 1.28.4 on
https://download.cloudstack.org/cks/ ?

-Wei


On Tue, 20 Feb 2024 at 08:31, Bharat Bhushan Saini
 wrote:

> Hi Wei,
>
>
>
> I made the ISO from cloudstack-comman and that ISO was of latest version
> 1.29.1.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_698188016]
>
>
>
> *From: *Wei ZHOU 
> *Date: *Tuesday, 20 February 2024 at 12:28 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> Which CKS ISO do you use?
>
> On Tuesday, February 20, 2024, Bharat Bhushan Saini
>  wrote:
>
> > Hi All,
> >
> > I enabled the CKS service in the cloudstack dashboard. After all the
> > things done I am unable to access the K8s dashboard.
> >
> > I encountered in the browser that ‘services “Kubernetes-dashboard” not
> > found’.
> >
> > Kindly suggest any resolvement for this.
> >
> >
> >
> > Thanks and Regards,
> >
> > Bharat Saini
> >
> >
> >
> > [image: signature_2321445983]
> >
> > --- Disclaimer: --
> > This message and its contents are intended solely for the designated
> > addressee and are proprietary to Kloudspot. The information in this email
> > is meant exclusively for Kloudspot business use. Any use by individuals
> > other than the addressee constitutes misuse and an infringement of
> > Kloudspot's proprietary rights. If you are not the intended recipient,
> > please return this email to the sender. Kloudspot cannot guarantee the
> > security or error-free transmission of e-mail communications. Information
> > could be intercepted, corrupted, lost, destroyed, arrive late or
> > incomplete, or contain viruses. Therefore, Kloudspot shall not be liable
> > for any issues arising from the transmission of this email.
> >
>
> --- Disclaimer: --
> This message and its contents are intended solely for the designated
> addressee and are proprietary to Kloudspot. The information in this email
> is meant exclusively for Kloudspot business use. Any use by individuals
> other than the addressee constitutes misuse and an infringement of
> Kloudspot's proprietary rights. If you are not the intended recipient,
> please return this email to the sender. Kloudspot cannot guarantee the
> security or error-free transmission of e-mail communications. Information
> could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. Therefore, Kloudspot shall not be liable
> for any issues arising from the transmission of this email.
>


IPv4+IPv6 Dual Stack Networking for Shared Networks

2024-02-20 Thread Ozhan Karaman
Hi All;

I am using Cloudstack 4.19, I am trying to enable IPv4+IPv6 Dual Stack
Networking for Shared Networks, so I add a new network with both dual stack
ip definitions in Shared Mode. I started the vm and I noticed that I don't
get ipv6 ip from VR.

I connected to VR to check dhcp server/dnsmasq setup and it's setup is ok
but I noticed that VR's eth0 does only have an ipv4 ip address not v6. I
started to investigate more in VR and I noticed that ipv6 is disabled by
sysctl settings so network setup could not be successfully applied. By the
way, I am using the 4.19 SystemVM template.

So it looks like the VR image does not like to work with IPv6, I started to
investigate Network Offerings to check out if ipv6 needs to be enabled for
shared networking somewhere but I could not find any specific settings.

Does anyone have any clue for the missing piece?

Thanks
Ozhan


Re: K8s Dashboard Not Found

2024-02-20 Thread Wei ZHOU
Hi,

The old way to access k8s dashboard does not work any more.
please refer to https://github.com/apache/cloudstack/pull/7764


-Wei



On Tue, 20 Feb 2024 at 08:27, Bharat Bhushan Saini
 wrote:

> Hi,
>
>
>
> I am hittine below URL
>
>
> http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/
>
> Below some more info that will help you to recognise as below
>
> kubectl --kubeconfig kube.conf get pods --all-namespaces
>
> NAMESPACE  NAME
>   READY   STATUSRESTARTS  AGE
>
> kube-systemcoredns-76f75df574-lfgzj
>   1/1 Running   0 22h
>
> kube-systemcoredns-76f75df574-mtktc
>   1/1 Running   0 22h
>
> kube-systemetcd-kloudspot-app-control-18dc0a3d55e
>   1/1 Running   0 22h
>
> kube-systemkube-apiserver-kloudspot-app-control-18dc0a3d55e
>   1/1 Running   0 22h
>
> kube-system
> kube-controller-manager-kloudspot-app-control-18dc0a3d55e
>   1/1 Running   0 22h
>
> kube-systemkube-proxy-74zcb
>   1/1 Running   0 22h
>
> kube-systemkube-proxy-hts4p
>   1/1 Running   0 22h
>
> kube-systemkube-scheduler-kloudspot-app-control-18dc0a3d55e
>   1/1 Running   0 22h
>
> kube-systemweave-net-8j6j2
>   2/2 Running   0 22h
>
> kube-systemweave-net-mlv6t
>   2/2 Running   1 (22h ago)   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api-645688966c-8xqjp
>   1/1 Running   0 22h
>
> kubernetes-dashboard
> kubernetes-dashboard-metrics-scraper-b847579df-tjw861/1 Running
>   0 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web-648b489598-psn94
>   1/1 Running   0 22h
>
>
>
> kubectl --kubeconfig kube.conf get nodes --all-namespaces
>
> NAMESTATUS   ROLES   AGE   VERSION
>
> kloudspot-app-control-18dc0a3d55e   Readycontrol-plane   22h   v1.29.2
>
> kloudspot-app-node-18dc0a3f52e  Ready  22h   v1.29.2
>
>
>
> kubectl --kubeconfig kube.conf get services --all-namespaces
>
> NAMESPACE  NAME   TYPE
> CLUSTER-IP
>   EXTERNAL-IP   PORT(S)  AGE
>
> defaultkubernetes ClusterIP
> 10.96.0.1443/TCP  22h
>
> kube-systemkube-dns   ClusterIP   
> 10.96.0.10
>   53/UDP,53/TCP,9153/TCP   22h
>
> kubernetes-dashboard   kubernetes-dashboard-api   ClusterIP
> 10.102.124.599000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-metrics-scraper   ClusterIP   
> 10.111.159.255
>   8000/TCP 22h
>
> kubernetes-dashboard   kubernetes-dashboard-web   ClusterIP   
> 10.108.135.214
>   8000/TCP 22h
>
>
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> [image: signature_828139211]
>
>
>
> *From: *Vivek Kumar 
> *Date: *Tuesday, 20 February 2024 at 12:17 PM
> *To: *Bharat Bhushan Saini 
> *Cc: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
>
> Can you share me the URL which you are hitting on the browser ?
>
>
>
>
> Vivek Kumar
>
> Sr. Manager - Cloud & DevOps
>
> TechOps | Indiqus Technologies
>
> [image: Image removed by sender.]
>
> vivek.ku...@indiqus.com
>
> [image: Image removed by sender.]
>
> www.indiqus.com
>
>
>
>
>
>
>
> On 20-Feb-2024, at 12:12 PM, Bharat Bhushan Saini <
> bharat.sa...@kloudspot.com> wrote:
>
>
>
> Hi Vivek,
>
>
>
> I am trying to access the dashboard from kubectl proxy.
>
>
>
> Thanks and Regards,
>
> Bharat Saini
>
>
>
> 
>
>
>
> *From: *Vivek Kumar via users 
> *Date: *Tuesday, 20 February 2024 at 12:08 PM
> *To: *users@cloudstack.apache.org 
> *Subject: *Re: K8s Dashboard Not Found
>
> EXTERNAL EMAIL: Please verify the sender email address before taking any
> action, replying, clicking any link or opening any attachment.
>
>
> Hello Bharat,
>
> How are you accessing the dashboard ?  Using the kubeclt proxy ?
>
> Vivek Kumar
> Sr. Manager - Cloud & DevOps
> TechOps | Indiqus Technologies
>
> vivek.ku...@indiqus.com  >
> www.indiqus.com 
>
>
>
>
> > On 20-Feb-2024, at 12:00 PM, Bharat Bhushan Saini <
> bharat.sa...@kloudspot.com.INVALID> wrote:
> >
> > Hi All,
> >
> > I enabled the CKS service in the cloudstack dashboard. After all the
> things done I am unable to access the K8s dashboard.
> > I encountered in the browser that ‘services