About deployment of VM packaged in OVF way of deployment from ESXi Console

[rohitdevkulshre]

Hi all,

I was wondering that, is their anyway to deploy an VMDK packaged in OVF descriptor from the ESXi service console?

I'm aware of the ovftool & VI Client way.But i'm specifically looking @ a solution from ESXI service console.

Regards,

Rohitdev

[lamw]

There is nothing native on the ESXi Busybox console to support the deploymen tof an OVF package ... any reason you're doing it directly on ESXi? As you mentioned, ovftool is an option which can be executed remotely to deploy the package.

[rohitdevkulshre]

We are building the appliance as an OVF package.

But when it gets deployed on an "appliance" server , its completly different.

So now dev has an OVF packaged vmdk which would be sent as an upgrade to the client appliance.The VM is supposed to accept it from the portal it hosts & update itself which is not possible since it cannot deploy.We cannot have another VM like vMA on our appliance.

The VIB boots this VM when the appliance is turned on.

So how do we update the VM from within itself?

I thought of this approach.

1. The deployed VM is vm1. So VM1 deploys the uploaded VM as vm2.

2. The appliance reboots & the esxi rename vm1 as vmold & vm2 as vm1 using the vmkfstools(rename vdisk).

3. Register the vm2 as vm1 .

4. Continue.

Will this workout?

[lamw]

Why not create an upgrade package that can be executed within the guestOS? Why make the upgrade an entirely new VM? VMware and other vendors who distribute virtual appliances generally provide packages in the form of VIBs, RPMS, TARBALLS, etc. to perform an upgrade of whatever application that runs within the virtual appliance and also providing the latest OVF.

If I was a customer and an upgrade meant that I had to re-deploy a new VM each and everytime, I would not be happy with that.

The approach you speak of is a little confusing, because you now have VM1 deploying VM2 .... this is based on the assumption that vSphere admins allows VM1 to communicate with the management network that vCenter & ESX(i) host resides on which is a bad assumption. Also if VM1 is doing the work, you're already doing something in the guest, why not write something to just update itself? So no, your approach would not fly in most environments ... the only way I could even see that working is a user deploys VM2 via OVF deployment means using vSphere Client and some magic way it extracts info ... perhaps a login to VM1 to download whatever files it needs to import into VM2 and then allowing user to shutdown VM1 and then manually power on VM2.  Again this workflow is no ideal and customers would not be happy with this

I would recommend you talk to your DEVs and have them write an update package like all other vendors out there. A new OVF should only be considered for NEW deployments, not upgrades.