-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual desktop pods are not found + crashing KVDI manager #64
Comments
I got the same error too and I think it has something to do with this line. I think that I created this yaml configuration in volume.yaml: vdi:
spec:
userdataSpec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
retainPVCs: true and then ran I hope this helps! |
Thanks for the input. But I keep having the same problem 😭
Same error in the manager pod:
I cannot even start the web server. This is odd, the uninstalling the helm chart should wipe clean everything |
Okay I was able to fix the crashing manager somehow when deleting this crds - helm does not do that by default for some reason:
But I still have the problem of the missing pod (with or without the volume.yaml):
|
Huh, that's weird. I would recommend deleting and re-adding the helm repo after uninstalling so the CRDs update. Also, creating a separate namespace for kvdi could be the issue. I think you have to specify which namespace to launch in when you start the connection. Here are the exact commands I ran (I'm using minikube by the way) minikube start
helm repo remove kvdi
helm repo add kvdi https://kvdi.github.io/helm-charts/charts
helm repo update
helm install kvdi kvdi/kvdi -f volume.yaml
kubectl apply -f deploy/examples/example-desktop-templates.yaml
# Get base64 admin password
kubectl get secret kvdi-admin-secret -o go-template="{{ .data.password }}"
# Run this in seperate terminal
kubectl port-forward svc/kvdi-app 8443:443
# Access https://localhost:8443, login, and connect to ubuntu-xfce Make sure to watch the logs of the kvdi-manager for any errors. |
Hmm. Did that. But I am still getting the same errors ( |
I would check the configuration of the VDICluster to make sure the userdataSpec is set, by running
at the bottom of config. Also, running |
Hey! First of all, I am not using minikube. I am using a bare metal cluster on debian 11.
You are right. My Userdata Spec are empty instead |
If you can set the |
Ok sorry my bad. The file was empty for some reason. Thanks for pointing that out.
Now I can start the template, but it stays on pending:
There is nothing about that in the logs, the best I could find is this from the manager:
|
Ah, ran into that issue too. It stays on pending because are not enough resources available to start the pod. |
Hmm thats wierd. Check this output. Looks like the node does have enough capacity (its only at 15% load):
|
I think you don't have enough memory for the |
I think the limit of 340Mi refer to the two requests from coredns (2x 170Mi). This does not refer to the overall capacity of the node. Actually, this node has 16GB of RAM and I did not set any limits there, so this should not be the concern. 🤔 |
I found that there is a not working pvc:
|
Sorry, my bad, you are right. minikube automatically creates everything for me, so I don't have to worry about managing persistent volumes. You could follow the advice set out here https://stackoverflow.com/questions/55780083/error-no-persistent-volumes-available-for-this-claim-and-no-storage-class-is-se or here https://kubernetes.io/docs/concepts/storage/dynamic-provisioning to fix it. |
I was having this issue on k3s. I followed @just-luk advice for using a volume.yaml This setting will depend on what kind of storage you are using but for my default k3s install this is what worked for me |
Hey. Thanks, @just-luk I tried to change the storage class of the pvc that kvdi creates, but it is not possible:
Then, I tried to create a pvc without a storage class name, but it is ignored by kvdi nevertheless:
|
The solution for Helm pointed by @just-luk worked for me, however on GKE I had yet another error after that. It was related to missing the accessMode attribute for PVC requests. The Helm command below handled both: helm upgrade --install |
When I tried to run a template of a virtual desktop, I get these errors:
I then realised that the kvdi manager is crashing, which might be the reason for it (
CrashLoopBackOff
)When I look into the logs I see
panic: runtime error: invalid memory address or nil pointer dereference
KVDI Manager Logs
Excerpt of App Logs
System:
KVDI Installation:
helm install kvdi kvdi/kvdi -n kvdi --create-namespace
Docker Version: 20.10.12
Debian 11
Thanks in advance for any help!
The text was updated successfully, but these errors were encountered: