Help Bootstrapping to ESXi

[Brett Bergner]

Good afternoon, hoping to get a little help.

I am trying to build a bootstrap candidate that allows me to build and run go programs on an ESXi server.

I am following this blog, and the issue is that my bootstrap candidate doesn't contain the go binary in the bin directory that is required when running all.bash.

Any help would be greatly appreciated.

[Mike Schinkel]

Is your ESXi server not running an Intel x86 processor?  That is what the article is about.

Also, what OS is your guest VM running?  

-Mike

[Brian Candler]

"Bootstrapping go" means "building the go compiler toolchain from scratch".  You almost certainly don't want to do this.  This is something you'd normally only attempt if there is not a suitable go binary distribution available for your system.

Go needs to run under an operating system. ESXi emulates a PC as a "virtual machine", but you cannot boot a PC directly into Go: that is, Go does not run on "bare metal".  So with ESXi you first need to create a VM, install an operating system inside it, and then you install Go inside that.

For example, if you installed a Linux VM under ESXi, then inside that VM you can install the Linux distribution of Go, which you can download from  https://go.dev/dl/.  Ditto if you chose to install a FreeBSD or Windows VM - you simply download the FreeBSD or Windows distribution of Go.

[Anthony Brown]

I haven't made a bootstrapped Go toolchain so I can't help with that but I can provide the following information:

ESXi knows how to run ELF binaries, the interesting part then becomes what architecture of CPU do you have the ESXi server installed on. If it's x86 or any other architecture that the Go toolchain already supports you don't have to make a bootstrap version for yourself. If it's not one of those, then it might be easier to compile your binaries on a different machine with the GOOS and GOARCH flags to specify your target OS (in this case Linux) and whatever architecture you are trying to build for.

Just to be sure, I just wrote a simple "Hello" binary in Go on Ubuntu. Did a simple 'go build' so that it would target my host OS and architecture then SCP'd it to an ESXi host I have available for testing also on x86. I was able to run this binary without issue within the shell of the ESXi server.

Hopefully that provides some insight.

[Mike Schinkel]

On Jan 13, 2023, at 1:32 AM, Anthony Brown <abrow...@gmail.com> wrote:

I haven't made a bootstrapped Go toolchain so I can't help with that but I can provide the following information:

ESXi knows how to run ELF binaries, the interesting part then becomes what architecture of CPU do you have the ESXi server installed on. If it's x86 or any other architecture that the Go toolchain already supports you don't have to make a bootstrap version for yourself. If it's not one of those, then it might be easier to compile your binaries on a different machine with the GOOS and GOARCH flags to specify your target OS (in this case Linux) and whatever architecture you are trying to build for.

Just to be sure, I just wrote a simple "Hello" binary in Go on Ubuntu. Did a simple 'go build' so that it would target my host OS and architecture then SCP'd it to an ESXi host I have available for testing also on x86. I was able to run this binary without issue within the shell of the ESXi server.

That is quite surprising. 

Brett sent me an off-list email and so I explored compiling and running Go on my VMware ESXi 7.3 server but ran into problems.

I SSHed into the ESXi server, used wget to pull down the Golang tarball, used tar to extract it from within the ESXi shell, and then used `go run hello.go` in the ESXi shell and got a runtime error of "epollwait on fd 4 failed with 38."  

That error is basically the same error from this ticket for an unsupported older version of CentOS: https://github.com/golang/go/issues/24980

From there I realized it was beyond my skills to pursue and so I dropped it.

I wonder if anyone on the list can speak to the difference between what you (Anthony) did and what I did, and Anthony's worked and mine didn't?  

Further, I wonder if other runtime errors are waiting as soon as other packages are pulled in that need greater access to the O/S?

Finally, I wonder if someone on the list would be able to help me get around that error and continue exploring the compilation and execution of Go programs on an ESXi server from within the ESXi SSH shell?

Thanks in advance for any insight into this.

-Mike

Hopefully that provides some insight.

On Monday, January 9, 2023 at 3:20:15 PM UTC-6 brett....@gmail.com wrote:

Good afternoon, hoping to get a little help.

I am trying to build a bootstrap candidate that allows me to build and run go programs on an ESXi server.

I am following this blog, and the issue is that my bootstrap candidate doesn't contain the go binary in the bin directory that is required when running all.bash.

Any help would be greatly appreciated.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/u2hKqDg24R4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/05acc8d9-fe55-49fc-bf97-2b51e4d6c5e2n%40googlegroups.com.

[Anthony Brown]

I think the difference is that I didn't actually do the compilation on the ESXi host itself, I just ran the binary there. 

'go run hello.go' on the ESXi host will, attempt, to both compile and execute the compiled binary; I'm guessing the ESXi host itself though doesn't have some of the same shared library updates the supported Linux kernels have which may be required for the compilation.

A insightful test here would be to use the go compiler on the ESXi host initially to see if a 'go build' will even work, if not it's an issue with compilation. If that works and execution itself breaks, then it's outside of the go build toolchain and a difference in the Go runtime itself on Linux and VMkernel targets.

-Tony

[Brian Candler]

On Friday, 13 January 2023 at 20:42:28 UTC mi...@newclarity.net wrote:

I SSHed into the ESXi server, used wget to pull down the Golang tarball, used tar to extract it from within the ESXi shell, and then used `go run hello.go` in the ESXi shell and got a runtime error of "epollwait on fd 4 failed with 38."  

That error is basically the same error from this ticket for an unsupported older version of CentOS: https://github.com/golang/go/issues/24980

From there I realized it was beyond my skills to pursue and so I dropped it.

I wonder if anyone on the list can speak to the difference between what you (Anthony) did and what I did, and Anthony's worked and mine didn't?  

Anthony wrote a very simple "Hello world" program.  You tried to run an extremely large and complex program (the Go compiler).

 

Further, I wonder if other runtime errors are waiting as soon as other packages are pulled in that need greater access to the O/S?

I think that's exactly right.  You can build simple binaries for Linux and they'll run under ESXi, but because it's running on an ancient Linux kernel which is below the minimum required by Go, anything sophisticated will fail.

 

Finally, I wonder if someone on the list would be able to help me get around that error and continue exploring the compilation and execution of Go programs on an ESXi server from within the ESXi SSH shell?

Not directly, no.  The Go team themselves have dropped support for ancient Linux kernels, and adding that back would be a major undertaking (which nobody wants to do).

I should ask though: what is the actual problem that you're trying to solve, i.e. what is your ultimate goal?  Is it that you want to write admin tools for managing your ESXi server? And your preference is that these tools run directly on the ESXi host, and that they are written in Go?

This doesn't require having a Go compiler which runs *on* the ESXi host, because you could do the compilation elsewhere.  But it does require a compiler which generates binaries which run on this host.  There are other Go compilers, like tinygo, that you could try.  These are designed to generate code for older/smaller machines so might work.

Next thought: would you be happy to have admin tools that don't run on the ESXi host itself, but instead talk to the ESXi API?  Are you using vcenter or standalone ESXi hosts?  That would be the "cleanest" way to administer them.

Finally: at worst you can write a Go program which runs on a different host, and simply ssh's to the ESXi server to run the ESXi command line tools there.  Go includes an ssh client library:

https://pkg.go.dev/golang.org/x/crypto/ssh

[Brian Candler]

P.S. For using tinygo to generate Linux executables, see:

https://tinygo.org/getting-started/install/linux/

https://tinygo.org/docs/guides/linux/

But I couldn't find the minimum kernel version requirements.