How can I import a virtual machine programmatically using Perl?
If you're using vSphere you can use ImportVApp. Full disclosure: it's not easy.
If you're running 3.5 or earlier, there is no exposed API. You can use ovftool to do it through an external process.
Is there ANY way to programatically import a Virtual Machine prior to vSphere...cli...anything?
If you copy the files into your datastore by whatever means, including a VMX file, you can use the RegisterVM function to register it.
When you mention including a vmx file, I therefore assume this is intended for only vm imports. What about programatic imports of other than vm images (see import wizard)?
Do you mean automating the P2V process? I know some VARs have created some online reporting and automation tools to assist with the P2V process, but it usually has so many ties into production requirements its difficult to completely automate it.
Also, there's the HTTP upload/download option in ESX. I haven't used it or know all the details, but that should provide an easy way to move a Virtual Machine to a new environment and then you can register it via the API.
But I suspect you're actually interested in P2V automation. So I was working on a project a while ago where a P2V could be automated. However, it ended up requiring PXE (with a bootable ghost/altiris image and was script driven to ghost the drive to the destination VM), pre-creating the Virtual Machine (which also booted with PXE and ran ghost/alitiris, ready to receive the new ghost image from the source). The original system was then shut down, and the new system was started. At this point someone would have to log in and do the post-P2V tweaking and clean up. This process allowed for the disks to be aligned as well.
However, all said and done, more often than not this was not used and instead was done manually. Primarily b/c the systems were production--babysitting and reporting was required. We were starting to look into ways to script the post-P2V process, but the project didn't catch on so it didn't go too far from there.
Not quite. WIthin VMClient you have the ability to "import an image". When you select this, you are guided (via a wizard) through an import process that supports standard VM images as well as other "virtualized" images (by selecting "other"). We were attempting to somewhat automate that process, but hit a roadblock with no exposed API's. Our two options at that point are either upgrading to vSphere (which DOES have exposed API's), or finding some other mechanism (cli, etc) to allow for this process to be automated. If our only option is to upgrade to vSphere, then I'm ok with that...but wanted to make very sure before we devote development assets to this endeavor...does that make sense?
I tried HTTP upload as a means of importing a VM and found it too slow.
To get more specific about my suggestions they would be:
1. Use vSphere 4.
2. Use scp to copy the VM onto 3.5, then ssh in, untar it and register it.
3. Use converter enterprise which has a command line and can do automated P2V or V2V imports.
4. Or you could try ovftool, which I believe will work against 3.5 but I've never tried it personally.
Makes perfect sense. I don't know of any SDK API options until vSphere. I did look at ovftool, but never really used it much. It might give you another option.
Can I use the VMWare Converter Enterprise CLI (converter-tool.exe) to import, as mentioned in the Converter Enterprise Administration Guide for VirtualCenter 2.5?
We tried the following XML file as input vmimport.xml ...
<?xml version="1.0" encoding="UTF-8" ?>
<p2v version="1.0" xmlns="http://www.vmware.com/v2/sysimage/p2v"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.vmware.com/v2/sysimage/p2v p2v.xsd">
<source>
<hostedSpec
path="
x.x.x.x\C_VOL-b001.spf"
password=""
networkUsername="user"
networkPassword="pwd"
/>
</source>
<dest>
<managedSpec vmName="VMTEST01">
<creds
host="vc_hostname/IP"
username="user"
password="pwd"
/>
</managedSpec>
</dest>
<importParams targetProductVersion="PRODUCT_MANAGED" />
<postProcessingParams>
<reconfigParams />
</postProcessingParams>
</p2v>
And this is what we saw when we executed it ...
E:\Program Files\VMware\Infrastructure\Converter Enterprise>converter-tool.exe --vH vc_hostname --vC user:pwd --jE vmimport.xml
converter-tool version 4.0.3 build-146268
Reading P2V input from file vmimport.xml...
Check dest available in progress...
...failed with error P2VError IMPORT_DEST_HOST_NOT_UNIQUE()
problem checking destination available
converter-tool failed
Ok...that's a stumper. Any reason why it would error out like that?
Just to clarify....we cant figure out why we see the above stated error
Any chance there is already a VM with that name or path name already in your VC inventory?
No, we checked that ... it almost sounds like it err'ed out much earlier ... while validating the VC host ... We have only one VC in this envronment.
As per the Admin guide, the host is destination_vc ... and IMPORT_DEST_HOST_NOT_UNIQUE error code seems to correspond to that field. Dont know how to get around this one
For the converter-specific problems you may have more luck in the converter forum.
