Applications are lifeblood of a modern business. This means that IT groups everywhere are looking for ways to develop, test, and deploy applications quicker, while reducing risk of mistakes and thus potential defects and security issues.
In this post, we’ll have a quick look at how an approach called “Infrastructure as Code” can help.
I am a long time user of Apple’s Airport Extreme base stations. I loved pretty much everything about them – compact design, lack of protruding external antennae, stable connectivity, ease of configuration through a well-designed Airport Configuration Utility, and on-going firmware updates, even for the 9-year old one (!). For a variety of reasons, over time I ended up owning three of them – 2nd, 4th, and 5th gen, extending WiFi around the house (it’s a rental, so no CAT cabling).
In recent years, however, things have slowly but surely drifted toward sour. Airport Configuration Utility has been dumbed down a lot, and firmware stability seems to have taken a hit, too – I don’t remember ever needing to reboot a base station until a few years ago. The number of connected devices in the house has grown steadily – I consistently see around 10–15 connected at any given time. More and more neighbours’ access points popped up around. Usage patterns have also changed – kids have grown up, and now study and entertain themselves on various devices around the house.
So the connectivity grew spottier and less stable, and I couldn’t make things happy again no matter what I tried. Real-time online games kept stuttering, and chatting over the net kept breaking up. Not all the time, but often enough to be a nuisance. And in the backyard.. Well, there was no usable reception there, let’s leave it at that.
So enough was enough, and search for a replacement has begun.
..which includes the session on NSX Troubleshooting methodology that I presented.
To find my session called “NET5488 – Troubleshooting Methodology for VMware NSX”, search for “NET5488”. Both US and Europe versions are available.
In this session, I walk through how NSX-v’s VXLAN-based logical switching works, what commands you can use to see what’s happening under the covers, and how to make sense of what you’re seeing. This should provide a good base for your troubleshooting practice.
(Hat tip to @ericsiebert and @scott_lowe for the info that sessions are now online, free for all)
It is fairly common for VMs to talk to SMB / NFS shares hosted by physical storage arrays, or send their backups to physical appliances.
In this blog post, we’ll have a look at connectivity options for this use case.
VMware NSX for vSphere has been shipping beta support for hardware VTEPs since version 6.2.0, with General Availability (GA) coming in the next few months. With this in mind, I thought it would be useful to provide an overview of HW VTEP’s use cases and considerations.
Nested ESXi is a staple of resource-strapped labs. There is, however, a little something that’s worth keeping in mind when using NSX-v / VXLAN.
For a little while, I was bummed by poor peformance of a Windows 8.1 guest running in Fusion 8.1 on El Capitan. Not sure which one of these was the main contributor, but the experience was painful – switching between apps was taking few seconds, which just didn’t seem right considering it’s running on a current MacBook Pro with plenty of RAM, CPU power, and a fast SSD.
Long story short – looks like I’ve found a cure. This solution worked like magic for me:
For those not willing to visit the source – I added the following to the vmx file:
mainMem.backing = "swap"
scsi0:0.virtualSSD = 1
MemTrimRate = "0"
sched.mem.pshare.enable = "FALSE"
MemAllowAutoScaleDown = "FALSE"
Looks like these settings have originated from the following post:
Happy computing! 🙂