All Posts

One thing that's special about datastores is that they don't extend ManagedEntity which means they don't have a "parent" property and which means they're not nodes in the heirarchy. Maybe your TraversalSpec doesn't take this into account. Marc

Here's another way of putting it: A PropSpec, that works for me may look like this: PropertySpec\[] pspecs = new PropertySpec[] \{ new PropertySpec() }; pspecs[0].all = true; pspecs[0].type = "VirtualMachine"; As soon as I change the type to "datastore" I get a SOAP exception. PropertySpec\[] pspecs = new PropertySpec[] \{ new PropertySpec() }; pspecs[0].all = true; pspecs[0].type = "datastore"; I did this without any TraversalSpecs. It just demonstrates, that, when type is "VirtualMachine" I get 0 objects (which is OK, since I did not specify a TraversalSpec). When the type is "datastore" I get a SOAP exception saying: "\n \n " So I can only conclude, that "datastore" can not be used as a type with PropSpec. This goes against the documentation which says nothing about not using "datastore" as a type. My goal is to retrieve all datastore managed objects and their full PropSet as can be seen in the MOB. OK... disregard what I just wrote... will put up an example shortly. This one is an obvious typo. Sorry! Message was edited by: deda

Here's how I would isolate it -- when I have time. I'm assuming that you have a VM that you can crash and burn. First, go to the esx console, cd /var/log/vmware tail -f hostd.log > debug Now, go into VI Client, and use Edit Settings for the VM and make the adds and changes that you intend on the target VM. This will do a ReconfigVM but with the same spec that you would use in the Clone. C on the console look at the debug file and you will see the XML that VI generated for the reconfig. This should give the hints of what to fix.

A further note: If I set the config spec for the existing NIC and do not set the adapter mapping, the error becomes: A general system error occured: Unrecognized handle property identifier[/i] Would something like this occur if a) the MAC addressed did not match or b) the network labels did not match?

The issue is definitely with the NIC that is already configured in the template. If I supply either a CustomizationAdapterMapping or a VirtualNicConfigSpec that references the installed NIC, it get the message in the original posting.

Sure! I am creating both config and customization specs. config spec (new NIC)[/b] VirtualEthernetCard nic = new VirtualVmxnet(); nic.setAddressType("manual"); nic.setMacAddress(_macAddress); nic.setBacking(backing); nic.setControllerKey(_controllerKey); nic.setKey(_key); VirtualDeviceConfigSpec spec = new VirtualDeviceConfigSpec(); spec.setDevice(nic); spec.setOperation(VirtualDeviceConfigSpecOperation.add); config spec (existing NIC)[/b] as above with spec.setOperation(VirtualDeviceConfigSpecOperation.edit);[/i] instead of add. Customization Spec[/b] // define the IP settings CustomizationIPSettings ips = new CustomizationIPSettings(); ips.setDnsDomain(params.get("dns_domain")); ips.setDnsServerList(buildDnsServerList(params)); ips.setGateway(new String[] \{ params.get("gateway."+i) } ); CustomizationFixedIp ip = new CustomizationFixedIp(); ip.setIpAddress(params.get("ip."+i)); ips.setIp(ip); ips.setNetBIOS(CustomizationNetBIOSMode.enableNetBIOSViaDhcp); ips.setSubnetMask(params.get("netmask."+i)); // define the Adapter CustomizationAdapterMapping cam = new CustomizationAdapterMapping(); cam.setMacAddress(params.get("mac_address."+i)); cam.setAdapter(ips); // add this adapter to the list nics.add(cam); NOTE:[/b] The ArrayLists get converted to arrays before going into the spec. Is this enough or would you like more?

I took some of my hosts out of the VC and put them back in again. It appears that when a host is added to the VC, you can connect via SDK to the ESX Host and look at the properties for "content->sessionManager". There are two sub properties of interest there: "content->sessionManager->message" : which shows as empty if host is not in VC and shows as "This host is currently being managed by the VirtualCenter with IP address ..." if host is managed by VC. "content->sessionManager->sessionList" : which will include the session with the fullName of "VMware VirtualCenter administration account" if the host is managed via VC. Does this work for you? I can write some specific examples you need more clarity. BTW, I did not have permission to get to the other links either that were posted previously.

Thanks This was the way we ended up doing it for 2.54. My question was really around whether it could be accomplished via the SDK (the answer to which is 'not yet'). We are constantly reviewing our product to try to minimize the number of places where we are going to an ESX agent to do something that can be accomplished via the Virtual Center (via the SDK) since that removes complexity from our application (or, at least, pushes some of the complexity onto the SDK).

Making more space is a two step process - 1 - vmkfstools -X 10G file-location.vmdk (its a capital X and will allow a smaller than 10Gb vmdk to become 10Gb) 2 - Once you've done this and powered on the VM you will then need to use diskpart or some other partition sizing tool, as although the vmdk will be bigger windows will not use it automatically.