vmware - revert to snapshot from within the GUEST? - vmware

i have virtual machines running on vmware ESXi and vmware workstation.
i need to execute "revert to snapshot" from inside the guest.
i have done so much searching, but all solutions proposed so far suggest doing it from "outside" - either some external machine or the host itself.
other workarounds suggest to enable automatic reverting to snapshot on power off event.
please do not suggest anything in that direction. i really need to execute it from within the guest. for example:
as scheduled task
as batch script (at the end of completing some other tasks)
edit:
this is the reason why i think there must be some way to achieve this: inside the guest there are "vmare tools" running as system service. so i would expect this component to also expose a functionality to trigger the host / hypervisor reverting the current VM to snapshot.
if this is not possible currently it should be implemented as new feature :)
in case it's currently not possible to execute it "from inside": that would also be an "answer" ...

I've actually done this pretty recently, try this:
Install VMware vSphere PowerCLI 5.1 (it's a command line scripting interface for ESX)
Write a script (perhaps in Notepad) that contains the following code:
Connect-VIServer <vCenter Server IP>
Set-VM <VM name> -Snapshot <Snapshot name> -Confirm:$false
This will connect to your vCenter server and revert your VM to the specified snapshot.
Save the script as revert_snapshot.ps1 (PowerShell file extension)
Using Windows Task Schedule, create a new tasks. The General and Triggers tabs are self
explanatory, but the Actions tab is where you'll configure the scheduled tasks to launch
your PowerShell script.
For 'Action' select 'Start a Program'. Under 'Program/script', enter the following:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
For the 'Add arguments' field, you'll specify the path of your PowerShell script:
-psc "C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1" "<path to your script>"
note: vim.psc1 is not available in the latest version of PowerCLI.
Save your task and run it manually as a test. Be patient as sometimes the cmdlet for logging into vCenter (Connect-VIServer) can take a few seconds to connect.

Related

set (guest) metadata from host and update from inside VM

I pass a custom startup script when I instantiate a VM. This startup script can take a while to finish and I want to be able to block (or at least poll) on the host and wait for the VM to get to the end of the startup script before proceeding to next steps.
The official documents recommends using guest attributes for this exact purpose but as far as I can see you can only instantiate them from inside VM. This is fine but ideally I'd like to be able to read a ready=FALSE value from the beginning and then see it changing to TRUE instead of starting with "ready doesnt't exist" error.
Is it possible to provide an initial value for guest attributes when starting a VM?
For normal metadata there's a ?wait_for_change=true that allows a VM to block and react to changes made to the VM from the outside but I'm looking for the opposite.
We use cloud-init in the startup-script to configure some instances. Cloud-init modules run at multiple stages of the boot process, some very early such as bootcmd.
Perhaps you could put a curl command in the bootcmd module to set the desired guest attributes in the metadata?

How to apply rolling updates in VM instances instead of using Managed Instance group in GCP?

Problem: I want to apply patch updates in a VM instance which is not a part of a Managed Instance Group. The patch update could be-
A change in the version of the current OS of a VM instance, that is, change from Ubuntu-16-v1 to Ubuntu-16-v2.
An upgrade of the OS boot, that is, changing from Ubuntu-16 OS to Ubuntu-18 OS.
Installation of a new package in the existing machine.
Exploration:
For Problem 1 & 2 stated above
I have explored and tried the rolling update feature present in Managed Instance Group in the Google Cloud Platform and this seems to be a good approach for the problem stated, but what should be the best approach with best practices if someone is not using a Managed Instance Group? You may find the details here.
For Problem 3 stated above
I have tried the Os-patch Management service of GCP but is there any other method that I could use?
Create an "image" from the boot disks of your existing Compute Engine instances.
For updating with newer configurations and software, group images in "image family" which always points to the latest image.
See https://cloud.google.com/compute/docs/images/create-delete-deprecate-private-images#setting_families
For your use case, I think you should use IAC script like terraform to recreate similar VMs with the same name, disk, internal address, etc..and call the script from the repo directly on a scheduled date automatically or provide self patch instructions.
Here is the likely process:
Send Email Notification to all the VM owners that Auto-Patch is
scheduled on XYZ.
Email content should include an Instance list going to be
patched/update, list of action, patch team contact details.
An email should also include a link for skipping this auto-update and perform "Self Patching instruction"
documents
Self patching documents should have a command to call autopatch
wrapper script like: "curl -u "encrypted-auth:x-oauth-basic" -k -H 'Accept:
application/vnd.github.VERSION.raw'
'https://github.com/api/v3/repos/xyz/images/contents/gcp/patch_OS_update.sh?ref=master'
|bash -s -- -q"
The above script can also have other options like to query patchset available for particular VM or scan the VM for pending updates

Startup script not running on GCP Compute Engine windows server with autoscaling turned on

I have a Managed Group in Computer engine on GCP. Autoscaling is set up and running but when a new server comes on or if I do a "Rolling Replace" the start up script is not being run. It is a very simple script that makes sure the latest code is running on the website. This is a screenshot from the "Template" that is used to create the new VMs
If I RDP into the box and run the exact same two lines of code, it works fine.
Is there something that I need to do before or after the script to make sure that the VM is fully up and ready for the command? Or something else that needs to be done.
When using a Startup Script in Windows, you need to use a specific key depending on what type of startup up script you would like to run. In your case, you are running cmd commands so in this case you have to replace the key "startup-script" with "windows-startup-script-cmd" within the Template as described here.

How do you deploy VirtualSystemCollection enabled OVF/OVAs to ESXi?

When building an OVF, you can specify a tag for VirtualSystemCollection that allows you to have multiple VMs to share the same base disk image, but any changes that the individual machines make are Copy-On-Write into a private disk area for each specific VM.
When you try to deploy images setup this way to EXSi, it complains Unsupported element 'VirtualSystemCollection'. It would appear that you need the commercial vCenter or vApp servers from VMWare to utilize this feature. (From what I've been able to grok so far)
Is there a way to do this through free software (Free like ESXi, or opensource)
The ultimate goal is that I want to have a single disk image that's used as a base - and to bring up a cluster of VMs that are then individually configured so that for a VM with a 500 meg disk, I only need '500M + (num_vms * delta_per_vm)' rather than '500M * num_vms'
An ESXi connected to a vCenter should support this via vApps but since you wanted a non-commercial solution, the closest things is to use VirtualBox.
The open source VirtualBox has multi-attach support to achieve this with different disk formats and it works very well. It also has special qcow, qemu copy on write disk support. Basically, you create a master disk and attach to multiple VMs. (Huge disk space saving.)
It can also happily import multiple VMs from a single OVA file with VirtualSystemCollection but unfortunately, it still requires manual intervention to tell VirtualBox that disks are shared after importing all the VMs. (Well, it defeats the appliance deployement in the first place...)
After creating master disk (or after deployment), attaching to multiple VMs can be done with GUI or with the following command:
VBoxManage storageattach "vm-name" --storagectl "sata1" --port 0 --device 0 --type hdd --medium base.vdi --mtype multiattach
For more information, see http://www.electricmonk.nl/log/2011/09/24/multiple-virtualbox-vms-using-one-base-image-copy-on-write/ and http://virtbjorn.blogspot.com.tr/2012/12/virtualbox-multi-attach-disk.html
If you really want to use VMWare ESXi, you can use data deduplication to achieve the same task on block level. (which is generally used with cloud hosting companies). You can see the deduplication success rates with open source tools here: http://opendedup.org/deduprates
In VMware products, a multi-tier appliance (VirtualSystemCollection) is called a vApp. In vSphere, vApps live in vCenter and not ESX. So yes, you need vCenter to import a VirtualSystemCollection.
If you are using Workstation, you can also try the free vApprun tool:
https://labs.vmware.com/flings/vapprun
Here is what I did successfully to have such OVF images imported into my free ESXi server.
In the OVF file a XML element VirtualSystemCollection defines the vApp.
You can manually edit the OVF file and remove or comment this part as shown bellow. This will allow to import the VM into ESXi without vCenter once the OVF image is converted using VMware OVF Tool.
<!-- ovf:VirtualSystemCollection ovf:id="dummy-id">
<ovf:Info>A collection of virtual machines</ovf:Info>
<ovf:Name>dummy-name</ovf:Name>
<ovf:StartupSection>
<ovf:Info>VApp startup section</ovf:Info>
<ovf:Item ovf:id="dummy-id" ovf:order="0" ovf:startAction="powerOn" ovf:startDelay="0" ovf:stopAction="powerOff" ovf:stopDelay="0"/>
</ovf:StartupSection-->
Keep the remaining part intact and remove the following line at the end.
</ovf:VirtualSystemCollection>
Also make sure you have the last ESXi Embedded Host Client installed to avoid other bug related problems during import.
https://labs.vmware.com/flings/esxi-embedded-host-client
Converting OVF to VMX can be done using VMWare OVF Tool. In command line it looks simply as following:
ovftool <path_to_source>/<myvm>.ovf <path_to_target>/<myvm>.vmx

move a virtual machine from one vCenter to another vCenter

I have the following problem:
There two separate vCenters (ESXi). They cannot see each other or communicate in any way.
I can create a Clone of a VM in vCenter1 but then I want to move that Clone in vCenter2.
Is there a way that I can copy the Cloned VM (files) on an external HDD and move them in the other vCenter?
I've figure it out the solution to my problem:
Step 1: from within the vSphere client, while connected to vCenter1, select the VM and then from "File" menu select "Export"->"Export OVF Template" (Note: make sure the VM is Powered Off otherwise this feature is not available - it will be gray). This action will allow you to save on your machine/laptop the VM (as an .vmdk, .ovf and a .mf file).
Step 2: Connect to the vCenter2 with your vSphere client and from "File" menu select "Deploy OVF Template..." and then select the location where the VM was saved in the previous step.
That was all!
Thanks!
Yes, you can do this.
Copy all of the cloned VM's files from its directory, and place it on its destination datastore.
In the VI client connected to the destination vCenter, go to the Inventory->Datastores view.
Open the datastore browser for the datastore where you placed the VM's files.
Find the .vmx file that you copied over and right-click it.
Choose 'Register Virtual Machine', and follow whatever prompts ensue. (Depending on your version of vCenter, this may be 'Add to Inventory' or some other variant)
The VM registration process should finish with the cloned VM usable in the new vCenter!
Good luck!
For moving a virtual machine you need not clone the VM, just copy the VM files (after powering the VM off) to external HDD and register the same on destination host.
A much simpler way to do this is to use vCenter Converter Standalone Client and do a P2V but in this case a V2V. It is much faster than copying the entire VM files onto some storage somewhere and copy it onto your new vCenter. It takes a long time to copy or exporting it to an OVF template and then import it. You can set your vCenter Converter Standalone Client to V2V in one step and synchronize and then have it power up the VM on the new Vcenter and shut off on the old vCenter. Simple.
For me using this method I was able to move a VM from one vCenter to another vCenter in about 30 minutes as compared to copying or exporting which took over 2hrs. Your results may vary.
This process below, from another responder, would work even better if you can present that datastore to ESXi servers on the vCenter and then follow step 2. Eliminating having to copy all the VMs then follow rest of the process.
Copy all of the cloned VM's files from its directory, and place it on its destination datastore.
In the VI client connected to the destination vCenter, go to the Inventory->Datastores view.
Open the datastore browser for the datastore where you placed the VM's files.
Find the .vmx file that you copied over and right-click it.
Choose 'Register Virtual Machine', and follow whatever prompts ensue. (Depending on your version of vCenter, this may be 'Add to Inventory' or some other variant)
Copying the VM files onto an external HDD and then bringing it in to the destination will take a lot longer and requires multiple steps. Using vCenter Converter Standalone Client will do everything for you and is much faster. No external HDD required. Not sure where you got the cloning part from. vCenter Converter Standalone Client is simply copying the VM files by importing and exporting from source to destination, shutdown the source VM, then register the VM at destination and power on. All in one step. Takes about 1 min to set that up vCenter Converter Standalone Client.
You don't have to export your VMs at all. You can move the VM and clone to a TAXI host in vCenter 1. Then add the host to vCenter 2, and vMotion away whatever VMs to other hosts previously managed by vCenter 2. When done, you can add the TAXI host back to vCenter 1.
If you'd like to do this using the command line, you can do this if you have ESXi 6.0 (or possibly even ESXi 5.5) running, by using govc, which is a very helpful utility for interacting with both your vCenter and its associated resources.
Depending on your setup, you can
# setup your credentials
export GOVC_USERNAME=YOUR_USERNAME GOVC_PASSWORD=YOUR_PASSWORD
govc export.ovf -u your-vcsa-url.example.com -vm VM_NAME -dc VMS_DATACENTER export-folder
Then, you'll have your VM VM_NAME exported in the folder export-folder. From there, you can then
govc import.ovf -u your-other-vcsa-url.example.com -vm NEW_VM_NAME -dc NEW_DATACENTER export-folder/VM_NAME.ovf
That'll import it into your other vCenter. You might have to specify -ds NEW_DATASTORE too, if you have more than one datastore available, but govc will tell you so if you need to.
The commands above require that govc is installed, which you should, because it's far better than ovftool either way.