In this case it was just choosing dc1, when the host in question was in dc3. This may have actually been the crux of my problem when using vCenter, as the default datastore chosen was actually the first entry in dc1 (which incidentally was also a folder and not a datastore). It may also have accounted for why it couldn't locate the network I specified, and may not be a problem with distributed vswitches as I had thought before...some more investigation is needed. 

--jc

Sent from my iPhone

On Jan 30, 2013, at 6:24 PM, "Jason A. Beranek" <notifications@github.com> wrote:

> In lib/veewee/provider/vsphere/box/create.rb:
> 
> > +          datastore = dc.find_datastore datastore_name
> > +
> > +          # These checks need to be done in this order
> > +          # otherwise the requests to the datastore over
> > +          # http will hang. (Observed in ESXi 4.1 update 3)
> > +          unless datastore.exists? "isos/"
> > +            vim.serviceContent.fileManager.MakeDirectory :name => "[#{datastore_name}] isos", :datacenter => dc
> > +          end
> > +          unless datastore.exists? "isos/"+filename
> > +            env.ui.info "Loading ISO to vSphere Host"
> > +            datastore.upload "isos/"+filename, local_path
> > +          end
> > +        end
> > +
> > +        def retrieve_datastore options
> > +          dc = vim.serviceInstance.find_datacenter
> The above code actually picks the first datacenter returned by the vSphere APIs (per the rbvmomi spec), rather than assume there is only one. That said, this behavior is not a sane default in a multiple datacenter environment as it who knows how random that selection might be.
> 
> I assume you were seeing behavior where you didn't know which datacenter was chosen, or did you see an actual error? If it was an actual error, then that gives me concerns that even when the datacenter is selected, things may still fail for some other reason.
> 
> —
> Reply to this email directly or view it on GitHub.
>