It’s official, VMware vSphere 7 is here. VMware has put together tons of content for the launch of the new version.
First and foremost, check out their blog at https://blogs.vmware.com/vsphere/vsphere-7. This page will have tons of information on the launch and will host some important materials in one place for you to access.
I’ll be posting more information when available!
It’s finally here! VMware has released the alpha (test) of the vSphere Mobile Client for Android Devices. This will allow you to manage your vSphere instance via your Android mobile device.
Some of you may remember the vSphere Mobile Watchlist app for android. It was great because it allowed you to manage your vSphere environment (and I still use it), but one day it was abruptly removed from the Google Play store and no longer available. However, those that had it installed could keep using it.
This new version of the vSphere Mobile Client is only available for Android as of the time of this post.
The VMware fling is here: https://labs.vmware.com/flings/vsphere-mobile-client
While there is a tarball download, you’ll actually want to forget that and follow the instructions for a proper install. The tarball is only needed if you want to deploy the notification service.
First, you need to join the alpha testers group here: https://groups.google.com/forum/#!forum/vsphere-mobile-client/join
Second, you need to opt-in to the Google Play Test app here: https://play.google.com/apps/testing/com.vmware.vsphere.cloudsmith
Then simply follow the instruction after the opt-in and download it for your device.
The app is a slick but simple one. Since it’s alpha, functionality is limited, but gives you the ability shutdown, restart, view performance and do a couple other things.
Shortly after using the app, I noticed that I couldn’t log in subsequent tries due to an “incorrect user name or password”. I know I was typing it right, so I’m assuming this is a bug. To resolve this, you have to delete the app cache, then you will be able to log in properly.
Unfortunately the app also doesn’t allow you to save your password, like the previous watchlist app.
See below for some screenshots:
All in all, it’s pretty exciting that VMware is finally working on an official mobile app. I still use watchlist almost daily, so I see tremendous value in this!
Leave a comment below and let me know what you think of the new app!
When running VMware vSphere 6 or vSphere 7 and ESXi on your hosts with VMFS6, you may notice that auto unmap (space reclamation) is not working even though it is enabled. In addition, you’ll find that manual unmap functions still work.
This is because your storage array (SAN) may have a larger unmap granularity block size than 1MB. VMFS version 6 (source) requires an unmap granularity of 1MB and does not support automatic unmap on arrays that are larger.
For example, on the HPE MSA 2040 the page size when using virtual storage is 4MB, hence auto unmap is not supported and does not work. You can still manually perform unmap on arrays with block/page sizes larger than 1MB.
Perform manual VMFS unmap on vSphere 6.5 and 6.7 with VMFS 6 – https://www.stephenwagner.com/2017/02/07/vmfs-unmap-command-vsphere-6-5-with-vmfs-6-auto/
vSphere 6.5, 6.7 and VMFS 6 – Change storage reclaim priority from low to medium or high – https://www.stephenwagner.com/2017/02/08/vsphere-vmfs-6-change-storage-reclaim-priority-low-medium-high/
Release unused space on host and guest filesystems with thin-provisioned Sophos UTM appliance (SW) – https://www.stephenwagner.com/2018/01/18/release-unused-space-vmdk-thin-provisioned-sophos-utm/
VMware announced the end of availability for the vDP (vSphere Data Protection) product last year. In their release, it was mentioned that no more updates would be issued for the product.
At that time, I recommended to most customers to start planning to upgrade/migrate to a different product. VMware then released some ESXi and vSphere upgrades, but didn’t immediately update the vDP appliance. It appeared as though no more updates would be issued.
Due to the the previous announcement, and a lack of an updated vDP appliance, this increased the urgency of migrating to a different product.
However, just recently I noticed that VMware is still maintaining the vDP appliance for vSphere 6.5, so you can continue to use it while you plan your migration to a new Backup/DR product, and your upgrade to vSphere version 6.7.
Please note: I noticed the updates to the vDP appliance are being released later than the vSphere/ESXi updates. I wouldn’t upgrade your ESXi hosts to 6.5 certain update levels until the applicable vDP updated appliance is available for that version.
On an ESXi host when performing a manual unmap on your storage datastore, you may notice a very large (hidden) file on the datastore root called “.asyncUnmapFile”. This file could be taking up terabytes of space, and you aren’t able to delete this file.
Typically the asyncUnmapFile is used by the UNMAP feature on ESXi hosts to deal with unmapping and unallocating storage blocks on the SAN. When you run a manual UNMAP, this file should be created and should appear to using “0” (no) space (even if it is). When an UNMAP completes, this file should disappear and be automatically removed by the function. If an UNMAP is interupted, this file will not be deleted, allowing you to restart the process and upon a full successful completion, it should then be deleted.
Some time ago, I had an issue when performing a manual UNMAP, where the ESXi host became unresponsive (due to memory issues). The command appeared to be completed, however I believe it caused potential issues or corruption on the iSCSI datastore. In subsequent runs, the UNMAP appeared to be functioning and working, however I didn’t realize that the asyncUnmapFile had grown to around 1.5TB.
This was noticed during a SAN storage audit, where we saw that the virtual pool on the SAN was using up way more storage than it should be on the datastore.
When we identified the file was this large and causing issues, we attempted to perform 2 UNMAPs (different reclaim sizes) to see if it would be automatically cleared afterwards. It had no effect and the file was unchanged.
We also tried to modify the permissions on the file, however when trying to delete it, it would report that the file or folder was not found, or that it does not exist. This was concerning as we were worried about potential datastore corruption.
It was also noticed that in the hostd.log and vmkernel.log we saw some errors where the host believed that the blocks on the datastore had already been freed: “on volume labeled ‘iSCSIDatastore01’ already freed by another host: This may be a non-issue”
Unfortunately with all the research we did, we couldn’t find a clear-cut solution. With worries that the datastore may be corrupted, we needed to do something.
A decision was ultimately made to Storage vMotion all the VMs (Virtual Machines) to another datastore on a separate storage pool, delete the now empty LUN, and recreate it from scratch. After this, we used Storage vMotion again to move the VMs back.
Instantly I noticed that the VMs on that datastore were running faster (it’s only been 12 hours, so I’ll be adding an update in a few days to confirm). We no longer have the file on any of our datastores.
If anyone has further insight in to this issue, please leave a comment!