FIX: Multiple volumes on AWS EC2 root partition

So, I'm dealing with some AWS EC2 instances that were imported by a tool used by contracted third party.

Some of those imports had a typo that put the boot and data partitions on the same root volume, which is definitely not within best practices. A large part of my issue was in not having messed with much partition management prior to this.

The solution (in rough form) is to:

1) add a disk the same size or larger as your current C partition
2a) mirror your System Volume (if you have one) to the new disk via diskpart
2b) mirror your C: to it (yes you can add both partitions to the same mirror)
3) add a disk the same size as your data volume
4) mirror your data volume to it
5) wait for all mirrors to finish syncing
6) in msconfig, point to the new C volume as your default boot volume
7) shut down
8) detach all drives
9) attach the new C as /dev/sda1
10) break the mirror
11) attach the new data volume
12) break the mirror

Let's maybe try this again (?)

So, it has been a while since I have posted here. There have been some life changes between then and now.

Notsomuch doing the VMware these days. More Windows, PowerShell, AWS and maybe some Ansible or Puppet on the horizon.

Excessive snapshot size but Snapshot Manager shows no snapshots?

Okay, so we got the alarm about excessive snapshot size and deleted snapshots.

It came back a while later and said "Unable to access file <unspecified filename> since it is locked"

Looking a little more closely, the snapshot was from commvault and it hadn't "Released disk lease" yet.

The end result is we still have a snapshot, which you can tell from the files in the VM's folder in the datastore, but snapshot manager shows no snapshots.

FIX:
Take a snapshot manually.

It will take a minute or so extra, but in the end it shows not only the one you created, but also the "Consolidate Helper- 0" snapshot

OVF

So, I rarely have to work with OVF files and they're a big pain every time I do and there are probably better ways to do this, but here's what I got to work:

C:\Program Files\VMware\VMware OVF Tool>ovftool --network="<network you want to connect the VM to>" -ds=<datastore name> "<full path to appliance>" vi://<user>:<password>@<vcenter fqdn>/?ip=<ip of the host you want to initiate the copy to>

One additional thing I had to overcome was that the appliance was set to be hardware level 9 and I needed this in a v4.1 environment ... and the .mf file has checksums on the .ovf and the .vmdk

Special thanks to me already having a XUBUNTU instance going and to Jon Giffard's Blog for the instruction:

"openssl sha1  <filename>
This will give you the sha1 checksum.  Now edit the MF file and replace the old value with your new one.
vSphere will now deploy your appliance without complaining of a checksum error"

So yes, you can install Windoes8/Server12 in a VMware 4.x environment using the bios.400.rom trick.

That has worked well enough, but I learned a couple somethings over the last week.

Long story, but I'm moving my VMs to new datastores.

I could not get a Server12 VM to move. It is a heftier than normal VM, weighing in at 800GB and the move would go for hours and fail with:

A general system error occurred: Source detected that destination failed to resume.

Frustrating.

Eventually I asked the server owner if I could take it down for a day and get the move done, which went well until I went to power the VM back up.

Could not open bios.440.rom (No such file or directory).

I looked and no, the bios.440.rom file had not been moved. I re-uploaded it and the server booted fine.

VMware View Third-Party Certificates (Pre 5.0.1)

I always have to go back and do the searches again to find these when I need them.

For pre-View 5.0.1, doing the cert with keytool... These are the resources you need:

Familiarize yourself with both of them before proceeding. The TcpDump one is particularly good, buit it omits making a 2048-bit request.

TcpDump

VMware KB 1008705

FIX - VMware Windows 7 VM with no Audio [ESXi]

I have a template we make some persistent VMs from and they haven't been getting audio. For some reason it took me a little bit to track this one down.

Device Manager, add Legacy Hardware, Have Disk

C:\Program Files\Common Files\VMware\Drivers\vmwvaudio\vmwvaudio.inf

No reboot needed.

[If you don't have this directory you'll need to copy it from a system with working audio.]