Nothing in Studio 2.6 should change the rate at which a VM is transferred between ESX and the Studio appliance. In fact, by using the latest ovftool, it should be better. So, some particulars are probably missing from your description. What version of ESX? How large is the VM? When you deploy the VM, does it take as long to upload into ESX? Are there any errors on the ESX side?
Sorry for the brevity, wanted to first gage if this was a common known issue before getting into it. Please find the information you've requested below as well as a couple of files attached with the build log output for each vstudio version.
Version: ESXi 4.1.0 702113
VM Size: ~2.5GB
By deploying the VM I assume you mean the step where the image is transferred from the provisioning host to the ESXi host. This appears to take less than 1 minute.
I'm not seeing any errors on the ESXi side of things via the log bundle downloaded from the vSphere client, anything in particular I should be looking for?
By deploying the VM I assume you mean the step where the image is transferred from the provisioning host to the ESXi host.
No, that's not what I meant. Once the OVF has been created by Studio, and you deploy it manually into ESX, how long does that take? It is also possible that you are running out of Tasks in the ESX box, see http://communities.vmware.com/message/2004866#2004866
Deployment transfer is very quick, under 2 minutes. I think I've discovered the root of the issue from a comment you made in the thread linked above.
"Also, are you sure that you are not using an ESX box directly that is being managed by a vCenter? "
I moved to using an ESXi machine directly since I was unable to get the authentication mechanizim introduced in vstudio26 working in the first place. The problem is we use AD for vCenter auth and Local Authentication for ESXi auth which leads to the following error when I try to build.18/06/2012 13:46:17 [info] Transporting VM from Studio to provisioning host; this may take a few minutes...18/06/2012 13:46:58 [warn] Unable to upload /opt/vmware/www/build/test-build.1/10.1.52.114_test-build.1_provstart.iso to the vmh-rd10-local datastore.18/06/2012 13:46:58 [warn]%3 %7 %11 %15 %19 %23 %27 %30 %34 %38 %42 %46 %50 Failure: (55, 'select/poll returned error')18/06/2012 13:46:58 [error] Encountered a fatal build error!
The build studio app doesn't seem to provide any facility for specifying separate credentials for the datastore http access nor does the Validate action check that this connection can be made. Will I have to enable AD authentication on my ESXi machine or is there a workaround for this issue?
Figured this one out, looks like a bug. After moving back to using vCenter as the build environment and noting the issues handling odd characters in the following posts:
I took a shot in the dark and changed the top level folder in vCenter (see image) above our datacenters to remove the '&' character. After doing this I was able to build without issue using the AD credentials. As a side note we intentionally use odd characters in our environment since our product integrates with vCenter and we've found this useful druing our testing
Thanks for your help.
rd-vc2.png 7.9 K
I moved to using an ESXi machine directly since I was unable to get the authentication mechanizim introduced in vstudio26 working in the first place. The problem is we use AD for vCenter auth and Local Authentication for ESXi auth which leads to the following error when I try to build.
There is no new authentication mechanism in Studio 2.6. What we did do is remove a dependency on an unsupported (and no longer working) utility called "remote device connect". This utility used to connect a remote CD to a VM. Unfortunately, it stopped working in a later version of ESX, and it was never supported by the development group that we got it from, so we removed it. Instead, we send over the iso containing the build instructions into the datastore directly, using the same credentials that you specify for access to the ESX machine. I've never seen your particular setup (nor have I heard of any other customer with this setup), so I'm not sure what to tell you. Perhaps the easiest thing would be for you to install the free ESXi yourself somewhere, and use that to provision, instead of using your uniquely set up corporate one.
Yep, I was off base with the authentication stuff in my second to last post, the issue seemed to present as an auth error which is why I tried connecting to an ESXi machine directly as a workaround. In my most recent post I mentioned that I'm back to authenticating directly through vCenter and everything is working fine. I was led astray because of the following issue which I believe is a bug:
Steps to reproduce:
- Create a top level folder in vCenter with an '&' in the name.
- Attempt to provision an appliance with vstudio26 on an ESXi machine which is a child of a datacenter contained by the folder from the previous step.
- Note the error when running a build "18/06/2012 13:46:58 [warn] Unable to upload /opt/vmware/www/build/test-build.1/10.1.52.114_test-build.1_provstart.iso to the vmh-rd10-local datastore."
Workaround remove the '&' from step 1.
My apologies for replying to this post so long after it was initially written, but I just ran into this same problem with VMware Studio 2.6 running on ESXi 4.1, and I did solve the issue, so I hope this post will be useful to others who run into it.
My OVA packaging process took 4-5 hours because the datastore test process would hang for 2+ hours, and it appeared to be executed twice by the build process. I tried all kinds of debugging to no avail, but finally stumbled on this in the VMware Studio documentation (bolding mine):
"By default VMware Studio 2.6 copies the Windows ISO image over to the datastore, and places it into the iso subdirectory, that is, the [data store] /iso directory. If this directory does not already exist, VMware Studio creates it, except with ESX/ESXi 4.1, where you must create the directory yourself to prevent the build hanging."
I am not deploying a Windows ISO, but I noticed that the hanging process on my machine looked like this:
/opt/vmware/share/build/datastore --test --server 192.168.100.13 --port 443 --user root --datastore 'datastore2' --folder 'iso' --file 'CentOS-6.4-x86_64-bin-DVD1.iso.lock
Since the process was attempting to write to a [datastore]/iso folder, I manually created one in each of my 3 datastores. I rebuilt the appliance, and voila, the build process only takes ~12 minutes now!
Hope that helps,