Sunday, November 6, 2016

Creating SSH private keys (advice as of 11/2016)

You have probably heard that using SSH keys for authentication is more secure than using usernames and passwords. I'm a total n00b at this, so take all of this advice with a grain of salt. If you find i'm giving bad advice, please let me know in the comments.

SSH keys are made in pairs - the public (which whatever wants to authenticate you must have) and the private (which only you should have). To create the SSH keys, you use a command called ssh-keygen . This is part of the OpenSSH software released by the OpenBSD Project, supported by the OpenBSD Foundation. Most nix style operating systems use this software, which is amazing considering how small the OpenBSD community is - small, yet technically deep and experienced :)

Anyways, I was trying to find some guidelines on creating secure SSH keys. Most Google documents that turned up are outdated. From what little I've learned reading I came away with:

1) RSA: at least 2048, but this is the least secure of the modern options
2) Use bcrypt
3) Use the new key format in OpenSSH with option -o

From the documentation:


Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format. The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private key format.

So, let's see what happens on my freshly installed and patched Ubuntu 16.04 LTS laptop:

Let's make sure we are on a modern version

~$ ssh -V
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016

So, what are the current default options? I ran the ssh-keygen command without parameters and accepted all defaults, including leaving the passphrase blank:

~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/
The key fingerprint is:
SHA256:[lots of characters here] user@laptophostname
The key's randomart image is:
+---[RSA 2048]----+
[lots of ASCII characters here]

Seems if we just execute ssh-keygen with no options and press enter, we get a 2048 RSA key with a SHA256 cipher.

We can now run "ls -a" and see that a new .ssh directory was created. Inside it are two keys, our private (which only we should see from now on) and a .pub , the public matching pair that we would install where we want to have remote access:

~/.ssh$ ls

~/.ssh$ cat id_rsa
[lots of characters here]

~/.ssh$ cat 
ssh-rsa [lots of characters here] user@laptophostname

So we see that in the public key, we are sharing some information about us, that we probably want to avoid - even if this is meant to be a public key, we don't want to give more detail than needed to a potential attacker.

We can check the details of an existing key with

~/.ssh$ ssh-keygen -l -f keyfile_name
2048 SHA256:[lots of characters here] user@laptophostname (RSA)

One thing to note is that the output of this previous command is the same for the public or private key -  this means that it's useful to make sure they are indeed a pair!

Ok, fun enough, but let's delete this folder and try to create a more secure key.

~$ rm -r ./.ssh/

The current recommendation is to use ed25519 type keys instead of RSA. This is done with the -t option:

ssh-keygen -t ed25519

Note that when we explore the resulting files, the names and contents are a bit different

~/.ssh$ cat 
ssh-ed25519 [lots of characters here] user@laptophostname

~/.ssh$ cat id_ed25519

~/.ssh$ ssh-keygen -l -f 
256 SHA256:[lots of characters here] user@laptophostname (ED25519)

We're supposedly being a bit more secure now. Note that per the documentation, ed25519 is always bit size 256 so there's no point in specifying an option with -b. Also, the new format is used by default with this key type, so the -o parameter isn't needed either.

We can still secure this further. First, let's remove our username and laptop name with -C and a comment inside quotes.

~$ ssh-keygen -t ed25519 -C "cat"
Generating public/private ed25519 key pair.

~/.ssh$ ssh-keygen -l -f 
256 SHA256:CKhXQLlEa68uLCP9KRAhI9Bmg+0tRdEb47YuO2thuWU cat (ED25519)

Good - we can see that the string I gave as a comment is now shown in place of my username@hostname. Ideally you would put something in here that will help you use this key in the future. Most people create different keys for different services.

Now, let's make it so a brute force attack is tougher on our private key by adding computational rounds with the -a option. Apparently this is a protection we can specify that will future-proof our private keys a bit in case they fall into the wrong hands.

-a rounds
When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when the -o flag is set), this option specifies the number of KDF (key derivation function) rounds used. Higher numbers result in slower passphrase verification and increased resistance to brute-force password cracking (should the keys be stolen).

I've seen several people online recommend at least 1000 rounds, so this would be the final command:

~$ ssh-keygen -t ed25519 -C "cat" -a 1000

Note that I'm allowing the program to prompt for a pass phrase instead of specifying one - this makes it so my pass phrase is not stored in the shell log. A note on the passphrase - you basically want a long, character based pass phrase, not a real English phrase.

At this moment we have generated a "pretty secure" SSH key. The next post will be on actually using them on a local server or in GitHub.

Some links apart from what I already put in the beginning that I found were among the better ones:

Saturday, November 5, 2016

Running Ubuntu 16.04 LTS on Acer Aspire ES1-111M

Lovely laptop, but there are things that don't work out of the box. Linux is fun!

I tried several installation methods and the one that worked the best was UEFI install, connected to the wifi, accepting 3rd party (which does something with Secure Boot) and using LVM. To access all UEFI options you must set an administrator password, which is good policy anyways.

Important notes

  • F2 gets you into BIOS mode - press it repeatedly after you see the Acer sign. Since I had the Ubuntu image in a usb drive (made in Windows with Rufus) I needed to set it to boot before my hard drive, or enable the F12 option to get a boot menu
  • If you install in UEFI mode, all power options and acer hotkeys work out of the box - did not happen for me when disabling secure boot for a Legacy install. This is why I preferred it
  • If after installing  in UEFI mode you do not have a boot device, you probably didn't check the "Disable Secure Boot" option in the Ubuntu installer. This is fine - you can leave Secure Boot Enabled, but in the BIOS trusted UEFI boot, you have to add the shimx64.efi. This link is a good walkthrough. If you made a mistake, choose the option to delete all, reboot and then add it
  • Trackpad works ok in both Advanced and Basic modes, but you had to choose 3rd party installers in the setup while connected to the internet, and once you log in, press Fn+F7 to enable the mouse (why it's disabled by default is beyond me)
  • Two finger scrolling works, but so far, two finger right click doesn't - I really have to right click. It's weird and I'll have to check out why.
  • Wireless, bluetooth, volume, screen brightness, sleep - all work

I've seen google results for the Synaptics trackpad state that the I2C tools have to be installed, or blacklisted, or add this to grub... I didn't have to do any of that (and don't see any of those entries in the corresponding files in this working setup) and both setting it to Basic and Advanced work the same on Ubuntu 16.04 LTS. I even like how the mouse responds better in Ubuntu than it did in Windows!

Saturday, October 8, 2016

Setup Raspberry Pi 3 with Raspbian with PIXEL, VNC

I'm a total noob on Raspberry Pi's. I was given one as a vExpert gift in VMworld 2016 by Datrium. This was the coolest and nicest gift in my opinion.

Rapsberry Pi 3 Model B is a very capable device - much more than I anticipated. I'm having a lot of fun with it!

Some tips (amazon links are my affiliate links):

You need a good power supply that can give 2.5A at 5V - otherwise you will start seeing problems. I chose this one by Canakit from amazon because it was cheap, on Prime shipping, and well rated, and reviews of a cheaper one said the power block was too big, and this one is a good size.

I installed it on a SD card that I had around, only to find what anyone that manages servers knows - storage speed maters. I just bought a new Samsung EVO+ that had good reviews and a good price. This one had better random write than the Pro series, which is what really should matter for most things. Note that the Raspberry Pi 3 can't take full advantage of UHS so no point in getting a UHS-3 card. This was a great table showing different cards.

I used Rufus with the Raspbian Jessie with PIXEL. PIXEL is a new window manager ( and real nice to be honest). I checked the downloaded file with the SHA-1 signature, unzipped with 7zip and then opened Rufus, browsed to the img file and let it do it's thing, no need to select anything special, it selected DD mode on it's own, etc.

Connected a HDMI monitor, mouse, keyboard, popped SD card in and connected power - it came up quickly and without issues, and immediately you were logged in to a nice GUI.

From the graphical interface I was able to join my WPA wifi network without problems. Of note, SSH is enabled by default. The user is pi with password raspberry

Once you have internet you should update your linux server. This is debian, so you must use sudo apt-get update && sudo apt-get dist-upgrade to maintain the software with the latest release.

I was able to connect an apple ethernet dongle and it recognized it immediately, and now I can use this device as a small networking router/firewall on two separate subnets (and use wireless as management). Sent the pictures out in a tweet:

I wanted to get console access to the Pi - not a separate session through X (MobaTerm did this easily) but the actual console that I would see if I connected the monitor again. There are lots of tutorials out there that recommend installing TightVNC, but RealVNC is now included with Raspbian. It just has to be enabled. I find the raspi-config command and its matching options in the GUI to be a pleasure to usei.

One thing I found where I don't agree with the official instructions is how to prevent the minimal resolution if no HDMI cable is attached. Instead of forcing the HDMI connection (which if at some point later, if you connect a monitor, will conflict) you can change the default console resolution and achieve a similar thing - you just need to un-comment the two lines in /boot/config.txt . In my case, since my smallest laptop is 1366x768, the defaults of 1280x720 work great in full screen mode, and is decent enough from other screens.

You can also install Xming and redirect X from PuTTY, and it may be I use that in the future to disable VNC and save on resources - but since it was included already in Raspbian, I decided to give it a go and it works very well.

As I play more with it, I'll put more articles, but for now, I can open Chromium and practice against an always on Debian like system - great for studying for LFCS (choosing the Ubuntu track).

The only other thing I want to do is install OpenBSD, but from what i've read, some of the  Pi3 components are closed source and thus will never make it into the OS. Shame as I was looking to use pf instead of iptables!

Saturday, October 1, 2016

Nested Nutanix CE on ESXi - create your own vmdk descriptor

Why they don't provide a bootable ISO that can install to a bare VM disk, like everyone else does, is beyond me.

Instead, you get a bootable disk image, which you are supposed to rename, upload and use as the boot disk. All the tutorials I found on the net provided a text file to use as the vmdk descriptor. The ones I found were the best were by Joep Piscaer and Michael Webster.

None of the few posts I read ( and I only read 3 or 4) explained how the descriptor file was created. In my case, because the Nutanix CE file has changed from when the blog posts where published, I couldn't use the text file (not sure if just the cylinders value had to be adjusted, or what). So I created my own. I thought I would share how I did it.

1) Create a VM (following the other post's instructions) but instead of following the text file advice, add a new disk that is the exact size as the img file (that you extracted from the .gz download). For "ce-2016.08.27-stable.img" it was exactly 7100 MB.

2) Upload the img file to the datastore in the same folder as where you created the disk, with any name. In the following SSH session output, orange is the new empty disk created, green is the uploaded extracted file. Notice they are the same size.

[root@arielitox:/vmfs/volumes/5557fee9-bd5cfd2a-29f6-5404a61bb2db/Nutanix CE v1] ls -al
total 14550032
drwxr-xr-x    1 root     root          2380 Oct  2 02:01 .
drwxr-xr-t    1 root     root          4200 Sep 30 19:07 ..
-rw-------    1 root     root          8684 Oct  1 21:33 Nutanix CE v1.nvram
-rw-r--r--    1 root     root             0 Sep 30 19:07 Nutanix CE v1.vmsd
-rwxr-xr-x    1 root     root          3111 Oct  2 02:01 Nutanix CE v1.vmx
-rw-------    1 root     root     536870912000 Oct  1 21:39 Nutanix CE v1_2-flat.vmdk
-rw-------    1 root     root           506 Oct  1 21:39 Nutanix CE v1_2.vmdk
-rw-------    1 root     root     7444889600 Oct  2 01:59 Nutanix CE v1_3-flat.vmdk
-rw-------    1 root     root           472 Oct  2 02:01 Nutanix CE v1_3.vmdk
-rw-------    1 root     root     7444889600 Sep 30 19:24 ce.vmdk
-rw-r--r--    1 root     root         55642 Oct  1 21:36 vmware-3.log
-rw-r--r--    1 root     root         57243 Oct  1 21:36 vmware-4.log
-rw-r--r--    1 root     root         58555 Oct  1 21:37 vmware-5.log
-rw-r--r--    1 root     root         58340 Oct  1 21:39 vmware-6.log
-rw-r--r--    1 root     root         57322 Oct  1 21:39 vmware-7.log
-rw-r--r--    1 root     root         58631 Oct  1 21:44 vmware-8.log

3) Use the move command to overwrite the empty file with the same name as the file you created (your name will vary). I do this so we don't need to change the small vmdk descriptor file using vi. After running the command, notice the uploaded image file name no longer exists; move overwrites without confirmation, and now the image file contents are in the vmdk that we had created.

[root@arielitox:/vmfs/volumes/5557fee9-bd5cfd2a-29f6-5404a61bb2db/Nutanix CE v1] mv ce.vmdk "Nutanix CE v1_3-flat.vmdk"
[root@arielitox:/vmfs/volumes/5557fee9-bd5cfd2a-29f6-5404a61bb2db/Nutanix CE v1] ls -al
total 7279632
drwxr-xr-x    1 root     root          2240 Oct  2 02:02 .
drwxr-xr-t    1 root     root          4200 Sep 30 19:07 ..
-rw-------    1 root     root          8684 Oct  1 21:33 Nutanix CE v1.nvram
-rw-r--r--    1 root     root             0 Sep 30 19:07 Nutanix CE v1.vmsd
-rwxr-xr-x    1 root     root          3111 Oct  2 02:01 Nutanix CE v1.vmx
-rw-------    1 root     root     536870912000 Oct  1 21:39 Nutanix CE v1_2-flat.vmdk
-rw-------    1 root     root           506 Oct  1 21:39 Nutanix CE v1_2.vmdk
-rw-------    1 root     root     7444889600 Sep 30 19:24 Nutanix CE v1_3-flat.vmdk
-rw-------    1 root     root           472 Oct  2 02:01 Nutanix CE v1_3.vmdk
-rw-r--r--    1 root     root         55642 Oct  1 21:36 vmware-3.log
-rw-r--r--    1 root     root         57243 Oct  1 21:36 vmware-4.log
-rw-r--r--    1 root     root         58555 Oct  1 21:37 vmware-5.log
-rw-r--r--    1 root     root         58340 Oct  1 21:39 vmware-6.log
-rw-r--r--    1 root     root         57322 Oct  1 21:39 vmware-7.log
-rw-r--r--    1 root     root         58631 Oct  1 21:44 vmware-8.log

Your VM should be able to boot. In my case, I did assign this disk a SATA controller, so I went in BIOS and set that one to be the first boot disk, and now I could see the Nutanix splash screen, and get the installer prompt a bit later.

This procedure should work for any other release of Nutanix CE (as long as this awkward img method is used). Feel free to use this text file for release 2016.08.27-stable, but at least you know how it was created in case it doesn't work for you:

[root@arielitox:/vmfs/volumes/5557fee9-bd5cfd2a-29f6-5404a61bb2db/Nutanix CE v1] vi "Nutanix CE v1_3.vmdk"

# Disk DescriptorFile

# Extent description
RW 14540800 VMFS "Nutanix CE v1_3-flat.vmdk"

# The Disk Data Base

ddb.adapterType = "ide"
ddb.geometry.cylinders = "14425"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "f93da8daf3cd8a949323e2d55c98c0d4"
ddb.uuid = "60 00 C2 90 85 79 c8 33-48 87 1c 59 12 32 c3 6a"
ddb.virtualHWVersion = "11"

Wednesday, September 14, 2016

vCenter 5.0 decommission checklist (windows)

Here's a small checklist I do when decommissioning Windows based vCenters where we have already moved all hosts out. 5.0 is super easy in this sense since the roles aren't distributed. This assumes the server will be decommissioned and was dedicated to just vCenter.

  1. Remove all licenses that were already migrated (you can't remove the last vCenter license)
  2. Rename the vDC explaining where the hosts are now and let it sit there for a while so admins that may log in get it (there should have been proper emails and stuff through other channels about the change)
  3. Confirm where VUM (upgrade manager) is installed in the VUM config
  4. Check the Add/Remove programs for installed programs
  5. Run odbcad32.exe to check the DB server for vCenter (in the System DSN)
  6. Where VUM is installed in the same server, which you may have confirmed from the installed programs list, use c:\Windows\SysWOW64\odbcad32.exe to check the 32-bit System DSN and DB server details
  7. Uninstall VMware add-on programs that will need vCenter access to remove their plugins
  8. Uninstall additional software like PowerCLI, Converter, etc
  9. Uninstall vCenter (which uninstalls orchestrator).
  10. Uninstall the vSphere client
  11. Uninstall the embedded or standard SQL server (you really want to make sure the database server wasn't used for anything else!). If the DB is in a remote location, work with your DBAs to archive/decommission the database
  12. Update your documentation, CMDB details, etc

Now take care of OS decommissioning tasks

Wednesday, July 20, 2016

VMware VSAN basics (nested lab)

With everything VSAN it's important to remember to work through the web client, and at this moment, only the flex version supports all commands (h5 doesn't have them yet).

  1. Create 3 or more nested hosts with at least 6GB RAM (add more for your VMs). 
  2. Setup a separate VMK that you will tag for VSAN traffic. I set these on a separate NIC and subnet, in a vSS with no uplink, using VMXNET3 interfaces (10GB) to separate from the 1GB where i'm running management and VM traffic. Don't forget to set promiscuous mode on the switch so everyone can ping each other.
  3. Add an SSD disk, and a capacity disk (in the case of hybrid). I found that my nested host picked up the type automatically, but I'm pretty sure you can "tag" the device as SSD or HD from the interface as needed, in case you want to test all flash.
  4. Create a cluster, move 3 or more hosts in
  5. Enable VSAN, which will take you through the wizard that enables VSAN.

That's really it. You will see a new vsanDatastore datastore that is shared among all hosts. You can rename this datastore. There's a performance service and a health service you can check. If you did everything well, you will pass all tests except the HCL, for obvious reasons.

Very important - when putting a host in maintenance mode, always do it from the webclient. There are new options that VSAN exposes in a drop down!

Wednesday, June 29, 2016

Symantec Endpoint Protection 12.1.6 MP5 addresses important vulnerabilities

Seems even the client needs to be updated (not just the managers) which means you need to have the whole environment upgraded. This requires downtime on each server (normally a reboot if things go well).

There was another set of vulnerabilities fixed (SYM16-011), for the manager side particularly, in this same release

Otherwise it does include some fun new capabilities, like certified compatibility with vsphere 6, sql server 2016, and the latest Ubuntu LTS release

Friday, June 3, 2016

What disk was ESXi installed to?

I was talking with a colleague on how to find out which device ESXi was installed to. This is important especially when 

1) you don't have documentation and are adding a new host and you want to be consistent
2) are doing a hardware change and are not sure if replacing a SD card or disks could also remove ESXi

Understanding this means you need to understand how ESXi partitions whatever disk device you gave it for installation. ESXi creates several partitions, and if there's free space, will create a VMFS partition on the remaining disk space and call it datastoreX. From the vCenter/ESXi console, the administrator is mostly looking at datastores, not realizing they are partitions.

Datastores are type VMFS partitions, and the ESXi installation files are stored on partitions of type vfat. When we ask ESXi where it's installed, the answer is a partition; however, we are probably more interested in getting the disk information. Typically, this means we need to translate the partition to the naa ID of the disk. 

Fastest way i've found:

You need three (for just device info) or four commands if you want to know what datastore was also created on that same disk device. Follow the colors to know what to use for command inputs:

1 ~ # esxcfg-info -b


2 ~ # esxcfg-scsidevs -f | grep dea75b72-115e5271-3e7b-9b3ef7301455

naa.6b8ca3a0e704b3001bb807e52a66aad5:5                           /vmfs/devices/disks/naa.6b8ca3a0e704b3001bb807e52a66aad5:5 dea75b72-115e5271-3e7b-9b3ef7301455

3 ~ # esxcli storage core device list -d naa.6b8ca3a0e704b3001bb807e52a66aad5

   Display Name: Local DELL Disk (naa.6b8ca3a0e704b3001bb807e52a66aad5)
   Has Settable Display Name: true
   Size: 6673408
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/naa.6b8ca3a0e704b3001bb807e52a66aad5
   Vendor: DELL
   Model: PERC H710
   Revision: 3.13
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   Is RDM Capable: false
   Is Local: true
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unsupported
   Other UIDs: vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048
   Is Local SAS Device: false
   Is USB: false
   Is Boot USB Device: false

   No of outstanding IOs with competing worlds: 32

Now you know the Display Name, Size (MB, meaning the above is 6.36TB), Vendor and Model of the device where ESXi was installed (in the case of a RAID disk, you get the controller details).

However, you may still not be sure of what that device is. Since we tend to think of datastores, we can issue one more command to find out which VMFS datastore is on that same disk:

4 ~ # esxcli storage vmfs extent list | grep naa.6b8ca3a0e704b3001bb807e52a66aad5

RAID6-9x1TB-SAS     54255423-f706a47a-6e39-90b11c4fcfc5              0  naa.6b8ca3a0e704b3001bb807e52a66aad5          3

And there you have it. You probably remember which virtual disk ties to a datastore name.

Sadly, I haven't yet found a way to assure you that you have picked the right device, if, for example, you have two identical virtual drives. I wish there was a command in racadm that showed the naa (SasAddress) of a virtual disk, but I have not found it. The closest I found was 

racadm raid get vdisks -o

and it doesn't show the SasAddress, although it's clearly shown in the ESXi installation steps (this is from another server so the naa IDs don't match, but you see my point):

By the way, getting the naa identifier of a physical disk from racadm is easy 
racadm raid get pdisks -o -p name,SasAddress,MediaType
and very useful for VSAN - this post by @sebastiangrugel shows it well.

Thanks to @sjin2008 who made an excellent post on esxcli commands and showed up in google when I needed to get a table relating mount points / UUIDs to Volume Name

Other ways

Googling around I found two related KBs:

KB2014558 tells us the type of installation, but not where it was installed. However, it's a good idea to check the installation type, just in case this host was booted off PXE.
KB2030957 is useful. It will tell you the device, but if you were trying to figure out what datastore it relates to, it doesn't do that and you do the 4th command above.

Here are a few commands related to this.

Good command to show the bootbank , altbootbank and scratch partitions

~ # ls -l /
total 525
lrwxrwxrwx    1 root     root            49 Sep 30  2014 altbootbank -> /vmfs/volumes/6308247d-8d9ec099-ae26-5ec2d9ba9e00
drwxr-xr-x    1 root     root           512 Sep 30  2014 bin
lrwxrwxrwx    1 root     root            49 Sep 30  2014 bootbank -> /vmfs/volumes/dea75b72-115e5271-3e7b-9b3ef7301455
-r--r--r--    1 root     root        300059 Aug 23  2014 bootpart.gz
drwxr-xr-x    1 root     root           512 Jun  3 09:29 dev
drwxr-xr-x    1 root     root           512 Jun  3 08:35 etc
drwxr-xr-x    1 root     root           512 Sep 30  2014 lib
drwxr-xr-x    1 root     root           512 Sep 30  2014 lib64
-r-x------    1 root     root         14040 Sep 29  2014 local.tgz
lrwxrwxrwx    1 root     root             6 Sep 30  2014 locker -> /store
drwxr-xr-x    1 root     root           512 Sep 30  2014 mbr
drwxr-xr-x    1 root     root           512 Sep 30  2014 opt
drwxr-xr-x    1 root     root        131072 Jun  3 09:29 proc
lrwxrwxrwx    1 root     root            22 Sep 30  2014 productLocker -> /locker/packages/5.5.0
lrwxrwxrwx    1 root     root             4 Aug 23  2014 sbin -> /bin
lrwxrwxrwx    1 root     root            49 Sep 30  2014 scratch -> /vmfs/volumes/54255423-287d3e20-5dd5-90b11c4fcfc5
lrwxrwxrwx    1 root     root            49 Sep 30  2014 store -> /vmfs/volumes/5425541a-bbf00056-e4c2-90b11c4fcfc5
drwxr-xr-x    1 root     root           512 Sep 30  2014 tardisks
drwxr-xr-x    1 root     root           512 Sep 30  2014 tardisks.noauto
drwxrwxrwt    1 root     root           512 Jun  3 09:01 tmp
drwxr-xr-x    1 root     root           512 Sep 30  2014 usr
drwxr-xr-x    1 root     root           512 Sep 30  2014 var
drwxr-xr-x    1 root     root           512 Sep 30  2014 vmfs
drwxr-xr-x    1 root     root           512 Sep 30  2014 vmimages
lrwxrwxrwx    1 root     root            17 Aug 23  2014 vmupgrade -> /locker/vmupgrade

All these are a good way of seeing the partitions and their different formats, and the disk devices.

~ # df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-5     557.5G 212.5G    345.0G  38% /vmfs/volumes/RAID10-4x300GB-SSD
VMFS-5       6.4T   1.2T      5.2T  18% /vmfs/volumes/RAID6-9x1TB-SAS
VMFS-5       1.1T 392.5G    722.7G  35% /vmfs/volumes/RAID10-8x300GB-SSD
vfat         4.0G  28.7M      4.0G   1% /vmfs/volumes/54255423-287d3e20-5dd5-90b11c4fcfc5
vfat       249.7M 157.3M     92.4M  63% /vmfs/volumes/dea75b72-115e5271-3e7b-9b3ef7301455
vfat       249.7M   8.0K    249.7M   0% /vmfs/volumes/6308247d-8d9ec099-ae26-5ec2d9ba9e00
vfat       285.8M 193.4M     92.4M  68% /vmfs/volumes/5425541a-bbf00056-e4c2-90b11c4fcfc5

~ # esxcli storage filesystem list
Mount Point                                        Volume Name         UUID                                 Mounted  Type             Size           Free
-------------------------------------------------  ------------------  -----------------------------------  -------  ------  -------------  -------------
/vmfs/volumes/54290d18-1f6d577a-44e2-90b11c4fcfc5  RAID10-4x300GB-SSD  54290d18-1f6d577a-44e2-90b11c4fcfc5     true  VMFS-5   598611066880   370453512192
/vmfs/volumes/54255423-f706a47a-6e39-90b11c4fcfc5  RAID6-9x1TB-SAS     54255423-f706a47a-6e39-90b11c4fcfc5     true  VMFS-5  6989522403328  5715596935168
/vmfs/volumes/54290d55-396ddecc-89f2-90b11c4fcfc5  RAID10-8x300GB-SSD  54290d55-396ddecc-89f2-90b11c4fcfc5     true  VMFS-5  1197490569216   776033271808
/vmfs/volumes/54255423-287d3e20-5dd5-90b11c4fcfc5                      54255423-287d3e20-5dd5-90b11c4fcfc5     true  vfat       4293591040     4258988032
/vmfs/volumes/dea75b72-115e5271-3e7b-9b3ef7301455                      dea75b72-115e5271-3e7b-9b3ef7301455     true  vfat        261853184       96870400
/vmfs/volumes/6308247d-8d9ec099-ae26-5ec2d9ba9e00                      6308247d-8d9ec099-ae26-5ec2d9ba9e00     true  vfat        261853184      261844992
/vmfs/volumes/5425541a-bbf00056-e4c2-90b11c4fcfc5                      5425541a-bbf00056-e4c2-90b11c4fcfc5     true  vfat        299712512       96935936

~ # esxcli storage core device partition listDevice                                Partition  Start Sector   End Sector  Type           Size
------------------------------------  ---------  ------------  -----------  ----  -------------
naa.6b8ca3a0e704b3001bb807e52a66aad5          0             0  13667139584     0  6997575467008
naa.6b8ca3a0e704b3001bb807e52a66aad5          1            64         8192     0        4161536
naa.6b8ca3a0e704b3001bb807e52a66aad5          2       7086080     15472640     6     4293918720
naa.6b8ca3a0e704b3001bb807e52a66aad5          3      15472640  13667139551    fb  6989653458432
naa.6b8ca3a0e704b3001bb807e52a66aad5          5          8224       520192     6      262127616
naa.6b8ca3a0e704b3001bb807e52a66aad5          6        520224      1032192     6      262127616
naa.6b8ca3a0e704b3001bb807e52a66aad5          7       1032224      1257472    fc      115326976
naa.6b8ca3a0e704b3001bb807e52a66aad5          8       1257504      1843200     6      299876352
naa.6b8ca3a0e704b3001bb807e52a66aad5          9       1843200      7086080    fc     2684354560
naa.6b8ca3a0e704b3001bb807902555b244          0             0   2339373056     0  1197759004672
naa.6b8ca3a0e704b3001bb807902555b244          1          2048   2339373023    fb  1197757939200
naa.6b8ca3a0e704b3001bb806fa1c66c62d          0             0   1169686528     0   598879502336
naa.6b8ca3a0e704b3001bb806fa1c66c62d          1          2048   1169686495    fb   598878436864

~ # esxcli storage core device partition showguid
Device                                Partition  Layout  GUID
------------------------------------  ---------  ------  --------------------------------
naa.6b8ca3a0e704b3001bb807e52a66aad5          0  GPT     00000000000000000000000000000000
naa.6b8ca3a0e704b3001bb807e52a66aad5          1  GPT     c12a7328f81f11d2ba4b00a0c93ec93b
naa.6b8ca3a0e704b3001bb807e52a66aad5          2  GPT     ebd0a0a2b9e5443387c068b6b72699c7
naa.6b8ca3a0e704b3001bb807e52a66aad5          3  GPT     aa31e02a400f11db9590000c2911d1b8
naa.6b8ca3a0e704b3001bb807e52a66aad5          5  GPT     ebd0a0a2b9e5443387c068b6b72699c7
naa.6b8ca3a0e704b3001bb807e52a66aad5          6  GPT     ebd0a0a2b9e5443387c068b6b72699c7
naa.6b8ca3a0e704b3001bb807e52a66aad5          7  GPT     9d27538040ad11dbbf97000c2911d1b8
naa.6b8ca3a0e704b3001bb807e52a66aad5          8  GPT     ebd0a0a2b9e5443387c068b6b72699c7
naa.6b8ca3a0e704b3001bb807e52a66aad5          9  GPT     9d27538040ad11dbbf97000c2911d1b8
naa.6b8ca3a0e704b3001bb807902555b244          0  GPT     00000000000000000000000000000000
naa.6b8ca3a0e704b3001bb807902555b244          1  GPT     aa31e02a400f11db9590000c2911d1b8
naa.6b8ca3a0e704b3001bb806fa1c66c62d          0  GPT     00000000000000000000000000000000
naa.6b8ca3a0e704b3001bb806fa1c66c62d          1  GPT     aa31e02a400f11db9590000c2911d1b8

~ # esxcli system visorfs ramdisk list
Ramdisk Name  System  Include in Coredumps   Reserved      Maximum       Used  Peak Used   Free  Reserved Free  Maximum Inodes  Allocated Inodes  Used Inodes  Mount Point
------------  ------  --------------------  ---------  -----------  ---------  ---------  -----  -------------  --------------  ----------------  -----------  ---------------------------
root            true                  true  32768 KiB    32768 KiB    532 KiB    544 KiB   98 %           98 %            8192              4096         3654  /
etc             true                  true  28672 KiB    28672 KiB    184 KiB    216 KiB   99 %           99 %            4096              1024          463  /etc
tmp            false                 false   2048 KiB   196608 KiB      4 KiB    228 KiB   99 %           99 %            8192               256            3  /tmp
hostdstats     false                 false      0 KiB  1078272 KiB  12704 KiB  12892 KiB   98 %            0 %            8192                32            5  /var/lib/vmware/hostd/stats
snmptraps      false                 false      0 KiB     1024 KiB      0 KiB      0 KiB  100 %            0 %            8192                32            1  /var/spool/snmp

~ # ls -alh /vmfs/devices/disks 
total 17176196976
drwxr-xr-x    1 root     root         512 Jun  3 09:25 .
drwxr-xr-x    1 root     root         512 Jun  3 09:25 ..
-rw-------    1 root     root           0 Jun  3 09:25 mpx.vmhba32:C0:T0:L1
-rw-------    1 root     root      557.8G Jun  3 09:25 naa.6b8ca3a0e704b3001bb806fa1c66c62d
-rw-------    1 root     root      557.7G Jun  3 09:25 naa.6b8ca3a0e704b3001bb806fa1c66c62d:1
-rw-------    1 root     root        1.1T Jun  3 09:25 naa.6b8ca3a0e704b3001bb807902555b244
-rw-------    1 root     root        1.1T Jun  3 09:25 naa.6b8ca3a0e704b3001bb807902555b244:1
-rw-------    1 root     root        6.4T Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5
-rw-------    1 root     root        4.0M Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:1
-rw-------    1 root     root        4.0G Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:2
-rw-------    1 root     root        6.4T Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:3
-rw-------    1 root     root      250.0M Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:5
-rw-------    1 root     root      250.0M Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:6
-rw-------    1 root     root      110.0M Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:7
-rw-------    1 root     root      286.0M Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:8
-rw-------    1 root     root        2.5G Jun  3 09:25 naa.6b8ca3a0e704b3001bb807e52a66aad5:9
lrwxrwxrwx    1 root     root          20 Jun  3 09:25 vml.0000010000766d68626133323a303a31 -> mpx.vmhba32:C0:T0:L1
lrwxrwxrwx    1 root     root          36 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb806fa1c66c62d504552432048 -> naa.6b8ca3a0e704b3001bb806fa1c66c62d
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb806fa1c66c62d504552432048:1 -> naa.6b8ca3a0e704b3001bb806fa1c66c62d:1
lrwxrwxrwx    1 root     root          36 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807902555b244504552432048 -> naa.6b8ca3a0e704b3001bb807902555b244
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807902555b244504552432048:1 -> naa.6b8ca3a0e704b3001bb807902555b244:1
lrwxrwxrwx    1 root     root          36 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048 -> naa.6b8ca3a0e704b3001bb807e52a66aad5
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:1 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:1
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:2 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:2
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:3 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:3
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:5 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:5
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:6 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:6
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:7 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:7
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:8 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:8
lrwxrwxrwx    1 root     root          38 Jun  3 09:25 vml.02000000006b8ca3a0e704b3001bb807e52a66aad5504552432048:9 -> naa.6b8ca3a0e704b3001bb807e52a66aad5:9