Closed adeniyistephen closed 8 months ago
I'd re-try fresh:
make clean
and git clean -xffd
toovariables.yaml
and increase CPU/RAM - may give better performanceI've been testing this setup extensively over last few days and I found that all VM-s get up and provisioned successfully in 1 in 2-3 attempts. Most often I had/have to do vagrant reload --provision winw1
(rarely make 2-vagrant-up
).
Thanks @mloskot I would have to try that! I changed the ubuntu machine to another type, thinking the machine had issues, but still didn't come up. Just saying.
I have recently run make all
quite a lot of times and I haven't noticed such problem with the controlplane
node, it usually boots up fairly quick:
Bringing machine 'controlplane' up with 'virtualbox' provider...
==> controlplane: Importing base box 'roboxes/ubuntu2004'...
==> controlplane: Matching MAC address for NAT networking...
==> controlplane: Checking if box 'roboxes/ubuntu2004' version '4.2.14' is up to date...
==> controlplane: Setting the name of the VM: sig-windows-dev-tools_controlplane_1681726008743_81052
==> controlplane: Clearing any previously set network interfaces...
==> controlplane: Preparing network interfaces based on configuration...
controlplane: Adapter 1: nat
controlplane: Adapter 2: hostonly
==> controlplane: Forwarding ports...
controlplane: 22 (guest) => 2222 (host) (adapter 1)
==> controlplane: Running 'pre-boot' VM customizations...
==> controlplane: Booting VM...
==> controlplane: Waiting for machine to boot. This may take a few minutes...
controlplane: SSH address: 127.0.0.1:2222
controlplane: SSH username: vagrant
controlplane: SSH auth method: private key
controlplane: Warning: Connection reset. Retrying...
controlplane: Warning: Connection aborted. Retrying...
controlplane: Warning: Connection reset. Retrying...
controlplane: Warning: Connection aborted. Retrying...
controlplane: Warning: Connection reset. Retrying...
controlplane:
controlplane: Vagrant insecure key detected. Vagrant will automatically replace
controlplane: this with a newly generated keypair for better security.
controlplane:
controlplane: Inserting generated public key within guest...
controlplane: Removing insecure key from the guest if it's present...
controlplane: Key inserted! Disconnecting and reconnecting using new SSH key...
==> controlplane: Machine booted and ready!
...
But, I run it directly on Windows 11 (WSL) as you can see in my detailed notes here
yes, I can see it, mine is just a completely different environment - I'm running make all
on a fedora vm with a Windows 11 main laptop, that's my issue. I haven't retried the steps you talked about earlier tho: https://github.com/kubernetes-sigs/sig-windows-dev-tools/issues/246#issuecomment-1510485774 I'll do that now and let you know if the issue still remains the same, I might end up switching to WSL, I didn't try it earlier because I think someone said it wasn't working earlier - but if you did something to your WSL to make it work, it would be nice to update the readme.
I'm not a virtualization expert, but is it possible there is nested virtualization issue in your environment?
yeah, I enabled nested vt-x/amd-v, it still didn't work.
Although I was able to bring up the machine alone with just vagrant up controlplane
but not with other components if I run make all
@mloskot There are just such a whole lot of virtualization issues with fedora, after enabling nested vt-x - here's what I got next after starting from GUI:
sig-windows-dev-tools_controlplane_1681144330551_15000
Cannot enable nested VT-x/AMD-V without nested-paging and unrestricted guest execution!
(VERR_CPUM_INVALID_HWVIRT_CONFIG).
seen something like this before?
No, I haven't. It looks like trying simple Vagtantfile with basic generic Ubuntu and windows images would be a good test, before continuing with SWDT
Question: so, you have a Windows machine, on which you have a Fedora 36 in a virtualbox, in which you're trying to spawn a new virtualbox vm, in which the control plane will be created? I'm not sure that would work, I don't know if virtualbox supports nested virtualization in the first place, but if it did, the performance would be pretty low.
You could also try Hyper-V VMs (you should be able to enable it, especially if you have Windows Pro or Enterprise), and you can enable nested virtualization on those VMs.
Correct, that is what I wanted to do initially, but it didn't work - but now I'm running the WSL approach on my windows with @mloskot
now I'm running the WSL approach on my windows with @mloskot
@adeniyistephen I'd suggest to switch over to the new non-WSL approach on Windows, see #264
Yes, I have switched to your branch and I'll be running both the magefiles and WSL approaches.
@adeniyistephen FYA, I've just added tester's quickstart to #264
I personally wouldn't bother with WSL. The WSL is used as nothing else than just make
distribution for SWDT. I guess, you could equally use CygWin or GNU Make from GnuWin32.
Sure, Awesome.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I think this can be closed as replaced by the currently ongoing SWDT CLI sub-project
/cc @knabben
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
After running
make all
the ubuntu control plane is not coming up.Steps taken: Installed vagrant Installed VirtualBox version 7.0 Clone repo Run
make all
System Configuration: OS: VirtualBox (Fedora 36) on a Windows-based machine. RAM: 12GB (can be extended to 16GB, based on the workload)
Expected: Ubuntu control plane machine to come up and Windows machine to come up for a Kubernetes cluster.