-
Notifications
You must be signed in to change notification settings - Fork 175
vsphere-iso: unexpected EOF #87
Comments
The error happens at VM creation moment. I'd suggest two tests to localize the root cause:
|
I don't have access to vCenter, only to vShpere and here I don't see any useful log or event.
|
Then start with a config with a minimal set of parameters, and add them one by one.
|
need to warn you in advance. |
I receive the same error with this minimal file:
I can't use a
|
Does the |
There is a discussion about permissions in #97 |
I've just seen a similar error, but in a different piece of the code. |
|
This is definitely permissions related. We really need to sort out the minimally viable permissions for this plugin. Got this when trying to replicate #97 multi-role approach. |
This goes away when you do this from #97:
|
After working around #104 and #119, I experience this bug as well. While waiting for an IP, while the VM is working through its installation, I get the dreaded
Is there a way to get any more information? I haven't been able to pinpoint it as a problem with #97 per @xenithorb's suggestion, as we already have Low level operations set on our vCenter. In fact, in this case it was run with an administrator account. Any ideas as to how to debug what goes wrong, or what it tries to send or read when the EOF occurs? Which file to even begin in? Could it simply be reading a fixed set from the stream? Does it expire at a point and needs to be reestablished? |
@mkuzmin We've looked closer into this bug, and we think it's a lot more specific than originally thought to be: To reproduce it, simply create an installation takes more than 5 minutes (exactly) to finish the installation and yield an IP address. We looked into the context object, and in the end also the |
I think that my user is lacking some permissions in the remote vSphere, but at least I would expect a clearer error message.
|
Spent some time on this today, and was able to build without globally inhereted permissions. |
That's good! From our own testing though, this issue isn't really an issue specific to permissions, but is a timeout on the vCSA side of things. Any build that results in waiting for longer than 5 minutes for any property to update (in this case, the IP address) will result in an Currently we run our builds in debug mode as to get around the timeout, meaning we manually let it know that it can run, but it's quite tedious and not very sustainable. |
I've updated README with a list of required permissions. Our builds may take hours, and do work fine. The only known timeout is 30-minute sessions, and it's especially handled in packer-builder-vsphere/driver/driver.go Lines 41 to 56 in 6f7ec33
|
for test, try to change |
I have the exact same issue as @thor. Consistently at the 5 min mark after creating the VM and waiting for an IP. Packer decides to destroy the VM after getting the EOF message from vSphere 6.5 I've just tried @mkuzmin suggestion of rebuilding the plugin with the keepalive set to 3 mins. Unfortunately it had no effect. The really strange thing was that this packer process was working perfectly up until about a week ago. I really have no idea what has happened. Any ideas would be great. Thanks |
@jgibbarduk I'm glad to hear we're not alone, so maybe we could throw some ideas back and forth.
Thanks for taking a look @mkuzmin and pointing to ´driver.go´ -- I can't confirm changing that didn't help yet, but I'll this week. All I could find of related documentation for the fact that it always times out exactly when waiting for the IP address is that it's utilising the ´WaitForUpdatesEx´ function, which refers to the ´WaitOptions´ parameter which may have an unset ´maxWaitSeconds´ property that defers the timeout to some policy (see second paragraph for the property). |
No, I go via a UTM/Firewall device. When I run the same packer process from a machine with a direct connection, the process works successfully.
Not that I know of. Our vCSA is not managed by me, but the admins have said there has been no recent change. This packer process work working up until a few weeks ago.
Yes, they have always been long than 5 mins. Especially some of the older windows platforms. I still think that it is to do with the connection being terminated somehow after 5 mins, when going through our UTM. |
My setup:
The odd thing was that I errored out at the ~1min mark...
HAproxy had a default of 1min... setting it to 10min (in line with Caddy) for TCP connections solved this issue for me:
Success:
|
Hello guys! I am experiencing, I think, the same error with the packer version 1.7.9:
The build machine from where the packer commands are being executed stays in a different DataCenter than the VCenter one (No FW Rules would be between them). The awkward topic would be that in debug mode (command Any ideas would be welcome! |
@luciantuce I think you'll need to take this issue to the new Packer plugin repository: https://github.com/hashicorp/packer-plugin-vsphere |
I'm trying to creare a VM from iso using
vsphere-iso 2.0-beta4
with vCenter Server 6.0.0, but I receive this error:I'm using a configuration adapted from the ubuntu example:
The
preseed.cfg
file is in the same directory of the template, and it's content is unchanged. I also tested withoutfloppy_files
andboot_command
but I receive the same errror.It's not a connection problem because I can create VMs using
vsphere-clone 2.0-beta4
.I can't see any recent task or error in vSphere UI.
The text was updated successfully, but these errors were encountered: