When installing a new Vsphere environment one gets a 60 trial license, that includes all the bells & whistles of the full VMware suite. Including one of my personal favorites SVmotion. This feature allows one to move a running VM between datastores, very cool. Often during hardware & software refreshes we use this tool, for instance getting a new SAN; VMware even suggests utilizing the trail period to complete these tasks!
Unfortunately, if one upgrades their Virtual Center, IE one already has a 64bit Windows OS running Virtual Center 4.X and one does an upgrade to Virtual Center v5.0 over the top; there is NO trial period! The licenses are required immediately! Bummer! Also if one has only purchased a package, say VMware Essentials, there is no SVmotion capabilities.
VMware: Moving a Virtual, Virtual Center from one datastore to another.
During a SAN migration we moved all the VM's from a datastore on the older SAN to a datastore on the newer SAN. Not a big deal, except when it came to moving Virtual Center which is also VM.
My first attempt was to use VMware Converter and do a P2V. Simply launch VM Converter, point it at the ESXi host that is currently housing the VM, and choose another host as the destination. Unfortunately, one cannot do that. Turns out that one cannot use an ESXi host as a destination if that host belongs to a VMware cluster, aka if Virtual Center manages it. DOH! See VMware KB article.
What I ended up doing, was shutting down the VC VM. Connecting directly to the ESXi host, browsing to the old data store, right clicked the folder that contains the VM, select "Move", chose the destination datastore, click next, wait. Once done, remove the old VM from inventory, go back to the datastore, and the folder where that VM lives, find the XXXX.vmx file, right click, "add to inventory" start the VM up. Vmware will complain, choose "I moved it", and life is good!
Another option: I haven't tried this yet, but supposidly one can do an SVmotion using the CLI.
Storage vMotion Command-Line Syntax
My first attempt was to use VMware Converter and do a P2V. Simply launch VM Converter, point it at the ESXi host that is currently housing the VM, and choose another host as the destination. Unfortunately, one cannot do that. Turns out that one cannot use an ESXi host as a destination if that host belongs to a VMware cluster, aka if Virtual Center manages it. DOH! See VMware KB article.
What I ended up doing, was shutting down the VC VM. Connecting directly to the ESXi host, browsing to the old data store, right clicked the folder that contains the VM, select "Move", chose the destination datastore, click next, wait. Once done, remove the old VM from inventory, go back to the datastore, and the folder where that VM lives, find the XXXX.vmx file, right click, "add to inventory" start the VM up. Vmware will complain, choose "I moved it", and life is good!
Another option: I haven't tried this yet, but supposidly one can do an SVmotion using the CLI.
Storage vMotion Command-Line Syntax
VMware migration from 3.5 to 5: Snapshots & CID mismatch
During a migration from an ESX v3.5 to ESXi v5.0, we ran across a stumbling block. Since the new SAN was implemented using VMFS v5, and ESX v3.5 cannot see that, a new volume was created in the VMFS 3 format, and both hosts were attached to this LUN. We used sVmotion to move the VM from the local storage of the ESX 3.5 box to the SAN for the v5 enviroment.
What I didn't know, is that despite snapshot manager reporting that there weren't any snapshots present; there was! Turns out that a flawed backup software had created four uncommited snapshots. The VM would no longer boot!
During the sVmotion, the ESXi 5 snapshot manager did pick this up and report them; okay so let's use Snapshot Manager to commit the snapshots. After some time, Snapshot manager reports that all snapshots have been taken care of; however the VM still would not boot, and browsing the data store yielded that the snapshot files where still there.
At this point, VMware has a nice feature called "Consolidate Snapshots". After some time all of the snapshot files were now gone, however the VM still would not boot! An error message of a "CID mismatch" showed up. Following this KB article from VMware we were able to fix the issue.
In a nut shell, the vmdk descriptor file has a pointer linking it to it's parent drive, and one had to go in and edit this line.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007969
What I didn't know, is that despite snapshot manager reporting that there weren't any snapshots present; there was! Turns out that a flawed backup software had created four uncommited snapshots. The VM would no longer boot!
During the sVmotion, the ESXi 5 snapshot manager did pick this up and report them; okay so let's use Snapshot Manager to commit the snapshots. After some time, Snapshot manager reports that all snapshots have been taken care of; however the VM still would not boot, and browsing the data store yielded that the snapshot files where still there.
At this point, VMware has a nice feature called "Consolidate Snapshots". After some time all of the snapshot files were now gone, however the VM still would not boot! An error message of a "CID mismatch" showed up. Following this KB article from VMware we were able to fix the issue.
In a nut shell, the vmdk descriptor file has a pointer linking it to it's parent drive, and one had to go in and edit this line.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007969
Subscribe to:
Posts (Atom)