VMware #vSAN 6.6 – Features and expectations based on field-experience

The release of vSAN 6.6 came with a tremendous ‘what’s new feature set’ brining VMware’s software-defined storage and hyper-converged solution to the next level. Many bloggers out there in the community did a great to job to explain the details of the following new features:

  • Removal of the Multicast requirement
  • Encryption using existing KMS solutions (KMIP 1.1 compatible)
  • Stretched Cluster enhancements (changing of witness hosts and secondary level of failure protections within a site)
  • Re-synchronization enhancements (including throttling)
  • Web Client independant vSAN monitoring User Interface
  • Performance enhancements
  • Maintenance Mode enhancements including more information and prechecks
  • New ESXCLI commands (that can be used with PowerCLI, e.g. to easily get smart data of the physical devies)
  • and many more…

Read more

vSphere 6.5: Virtual Disk / VMDK Hot-extend beyond or equal to 2TB is NOW supported

When vSphere 6.5 was announced I was quite impressed about the features. Gathering more and more hands-on experience so far I am more than happy with it.

One of the new features that can have a real operational benefit hasn’t been documented so far that often (or at least I haven’t seen it anywhere).

Before vSphere 6.5 it was impossible to increase the VMDK size of a DISK that was larger than 2TB when the Virtual Machine was powered on. That was a fact that not many organizations were aware of it until they stumbled upon it.

From an architectural point of view there shouldn’t be many use cases where such a large disk layout would be the best practice. But from an operational point of view for many of my customers this has been a bigger issue.

Read more

VMware #vSAN Queue Depth: Call for input/discussions

During the week I was at a customer site that is using vSAN 6.2 as foundation for their upcoming virtual desktop infrastructure (Seems like 2016 is really really the year of the VDI). I love vSAN and believe that at the moment it’s a great fit for many dedicated use-cases within the virtualization field.

During some load- & failover tests of the vSAN installation I realized something regarding the IO-queues within the vSAN-stack and to be honest, I am not quiet sure what the risks, mitigations and therefore the correct actions are.

We open a VMware ticket in parallel, but if you have any more in-depth knowledge about this topic, please let me know since this might be interesting to more of people (since the number of vSAN implementations is increasing).

Since the integration of flash/SSD in the performance/cache tier of vSAN the performance is great compared to classical HDD-based solutions.

To ensure a good performance level Duncan Epping and Cormac Hogan talked about the queuing topics within some blog posts or the offical vSAN troubleshooting reference manual (great document btw.).

Screen Shot 2016-06-10 at 09.40.18


Screen Shot 2016-06-10 at 09.40.36

Read more

Let’s discover #vROPS Management Pack for #NSX

The more I work with #vROPS (vRealize Operations Manager) the more I love it (I know that it has a little bit of a learning curve).

The more I work with #NSX the more I love it (hell-yeah… the learning curve might be even bigger).

In both cases I did a lot of training and consulting work during 2016 and it is about time to bring those two solutions together and maximize our benefits. If you have licenced NSX and vRealize Operations Manager in the advanced edition you can make use of the SDDC Management pack, which includes the management pack for NSX 3.0.

In the following I want to give you a quick rush over the installation and features of the mentioned management pack.

Read more

NSX and nested ESXi environments: caveats and layer-2 troubleshooting

After having NSX running in a nested environment, I started last week to integrate / built a NSX environment between my physical and nested ESXi hosts. To be honest, achieving this was more complicated than I have expected. Anyway it was a good trip to improve my NSX troubleshooting skills and maybe the key-findings can help one or another to avoid the problems I had.

From a logical-level my goal was pretty straight forward. I have 3 physical (vSAN) ESXi hosts running n-nested ESXi hosts. All of them are managed from a single vCenter and should be part of a single transport zones where n-VXLANs (unfassbar viele) will be deployed.


Read more

Why learn VMware #PowerCLI

PowerCLI (based on Powershell) is one of those things that really boosted my productivity in the VMware field. It is an easy to use product that allows you to do incredible things within a vSphere… wait… VMware environment (it also includes cmdlets for vCloud, vRealize, View …. ). Do bulk operations? easy-as-that… Gather some data for reports? not-a-big-problem-at all… Delivering hot coffee to your desk? Okok… not that incredible things (yet)…

Nowadays I still meet so many people during my daily business that aren’t really into it or are kind of afraid of using Powershell/PowerCLI. Let me try to give you some arguments why learning PowerCLI is a great idea even though it’s principles are kind of / come close to ‘programming’ *WE-HATE-PROGRAMMING-ANGST*.

1.) Become a better admin / consultant (and even architect)

As an admin (especially from the windows world) we as administrators spent so much time configuring stuff multiple times. Doing it in a graphical user mouse-/pointer-based interface it might not just take a long time. To enable SSH on 5 ESXi hosts it would take you including the login to the webclient incredible many clicks (In the 5 hosts scenario you probably need 35 clicks, 0,3 meters of scrolling, 142 seconds in the web client).

How do we solve it with PowerCLI?

Get-VMHost | Get-VMhostService | Where-Object {$_.Key -eq “TSM-SSH”} | Start-VMHostService

Much easier, especially if you archive your helper scripts somewhere so you can re-use them when ever there is a need (I know my Github repository is small, but it’s growing)

2.) Easy to learn – hard to master

The best way to describe PowerCLI / Powershell is by comparing it with Mario Kart. One of the best (and funny) video games the world has ever seen. Why is it so? Because it is so easy to get started with that even beginners might win with a little bit of luck. But anyway, if you want to start to reach maximum goals you will realise that there is so much you can do better.

The same is applicable with PowerCLI. Instead of getting a lame ‘hello world’ output in the beginning you can really create something you are familiar with (VMs, gathering useful data, etc.).

BUT remember… Mario Kart is a game… if you lose, you lose and start all over again… In the real life you would not want to go the racetrack as a beginner and start throwing bananas at other cars (at least I hope you wouldn’t do that). Learn and increase your PowerCLI skills in test-environments and only go with it into production if you understand the impact/risk and functionality of the scripts you are using.

One-liners like Get-VM | Stop-VM can create huge service impacts within your environment with minimum effort.

3.) Getting familiar with programmatical and automation approaches

The datacenter is getting more and more complex. Every component is getting abstracted multiple times ending up in a api-programmable resource. This creates new challenges (complexity) but gives us new opportunities in forms of service delivery speed / automation. In the future it will become more and more important that proccesses/workflows needs to be created (and maintained). And no matter how you are going to implement it (Orchestrator, Powershell, etc.) – the logical way of achieving it is always the same and always related to approaches coming from the programming field.

Learning PowerCLI means getting familiar with those approaches. You need to know why we need if-/else-/switch statements. Why do we need loops. What are datatypes. What is the reason that object-oriented thinking is so valuable.

Powershell (and therefore PowerCLI) abstracts away much of the mentioned complexity, but you will still touch them from time to time. Therefore if you are curious you will get a much deeper insight every time you confront yourself with those topics.

Once you are familiar with how to logically automate specific workflows (because you created your own automation mechanisms), you don’t really care which solution the automation does.

4.) The PowerCLI community is one of the best I have seen in the tech-field

There is nothing more to say. For almost every problem someone has already created a solution and has posted it in a blog / board. So what to do? Google for PowerCLI <What you want to achieve>, e.g. PowerCLI get vCPU in a cluster

Screen Shot 2016-01-21 at 11.07.31

in 95% of the cases you will find a suitable solution (maybe you need to edit the final script a little bit) on the first page of google.

And if you don’t find a solution. Just post them to the official VMware PowerCLI community

p.s. In 4 out of 5 posts Luc Dekens will help you within 72 seconds after you have posted a question there. This guy brings so much value to the PowerCLI community. Thanks for that.

5.) For nearly every problem a script or a snippet is already available

<If you have just read passage 4) too quickly…. you should read it in more detail now ;-) >

6.) PowerCLI forces you to work more accurate

Yes PowerCLI is pretty easy, but it is also a text-based user interaction. And it’s pretty typical if you configure something via text that you need to know for 100% what you are doing (in GUIs you can more easily have a trial- and error click experience).

Planning in advance what are you going to do & having a powerful tool at your hand that can shutdown your whole environment within seconds will force you to work more accurate and think more ahead in your daily doing. A skill that is IMO very very important.

Always remember what the uncle of a good’s friend’s friend told some guy:

“With great Power(CLI) comes great responsibility”


Get ready for NSX phase 0: Migrate from a vSphere Standard to a distributed switch: manual and auto

The distributed switch (vDS) is a really nice piece of software within the vSphere environment. It offers a variety of very useful features (NIOC, Health Check, Central management, LACP, LBT, Netflow, and so many (features with fancy abbreviations) more). Especially if you want to move to NSX the distributed switch is mandatory. Since analytics showed me that views about my vDS blogposts are increasing it seems that there is a demand for the vDS within our virtualized environments (it’s still an enterprise+ only feature)

Migrating from a vSphere standard switch to a distributed switch is not that complicated at all if you plan it properly. Over the years I collected a lot of (troubleshooting) experiences with the vDS. Anyway I want you to learn from my mistakes to do (not-so-daily) tasks right from the beginning.

Read more

Password change of the vRealize Automation service account for the vCenter

If you ever feel the need to change the service user account of the vRealize automation user (the account that has a dedicated user/role at the vCenter configured), make sure to do the following afterwards.

It’s not sufficient to change the credentials of the vCenter user in the endpoint section of vRA.


Remember that our vRealize Orchestrator and the IaaS componets needs to connect to the vCenter as well. If you miss the following steps your next requests will fail:

Read more