Category Archives: General

Cisco Live Header

Bridging Old Hypervisors to Cloud Native Platforms: What You’ll Learn at Cisco Live Amsterdam

Cisco, General, Kubernetes, , , , , , , , ,

Are you planning or already facing a migration from legacy hypervisors to modern, cloud native platforms? The toughest part usually isn’t compute or storage, it’s networking. If static IPs, subnet constraints, and complex topologies are slowing you down, Cisco Live Amsterdam is the place to fix that.

This year, I’m delivering two brand-new sessions focused on making VM migrations faster, safer, and more predictable using Cisco, Isovalent, and cloud native technologies like Kubernetes and KubeVirt.

1. Breakout Session: Taking Away the Network Pain from Cross-Hypervisor Migrations with Isovalent Network Bridge [BRKCLD-1713]

When: Thursday, Feb 12, 1:00 PM – 2:30 PM CET
Session Type: Breakout
Technical Level: Introductory
Technology: Observability, Cloud Native, Data Center
Content: 100% new
Session Link: View BRKCLD-1713 in the Cisco Live catalog

Migrating VMs between hypervisors and across datacenter boundaries is rarely “lift-and-shift.” Most tools help you move configurations and storage, but leave you with the hardest challenge: network accessibility, routing, and security.

This session focuses on removing that network friction using Isovalent Network Bridge, an eBPF-powered solution that enables seamless connectivity between VM and Kubernetes workloads, regardless of where they are placed or migrated to.

In this session you will learn how to:

  • Run virtual machines and containers together using cloud native hypervisors built on Kubernetes and KubeVirt.
  • Marry cloud native networking with your existing datacenter connectivity.
  • Assess migration tooling, risks, and considerations for cross-hypervisor moves.
  • Apply best practices when migrating VMs from legacy hypervisor platforms.
  • Leverage Cisco’s latest networking products to simplify VM network migration.

If you are an infrastructure, networking, or platform engineer and you want to de-risk VM moves without endless re-IP and downtime, this breakout session is for you.

→ Reserve your spot: BRKCLD-1713 – Taking Away the Network Pain from Cross-Hypervisor Migrations

2. Technical Seminar: Being Successful Moving from Legacy Hypervisors to Cloud Native Platforms with Cisco and Isovalent [TECCLD-1773]

When: Monday, Feb 9, 2:15 PM – 6:45 PM CET
Session Type: Technical Seminar
Technical Level: Introductory
Technology: Observability, Cloud Native, Data Center
Content: 100% new
Session Link: View TECCLD-1773 in the Cisco Live catalog

Note: Technical Seminars are priced in addition to your Full Conference or IT Leadership pass and can be added via the Cisco Live registration portal.

This in-depth Technical Seminar is designed for teams who want to build a clear, actionable roadmap from legacy hypervisors to cloud native platforms.

We will compare traditional hypervisors with emerging cloud native hypervisors, walk through Kubernetes networking fundamentals, and show how network and security design decisions directly impact the success of your migration strategy.

We then go deeper into Isovalent Network Bridge and how it preserves network identity to keep workloads reachable and secure, even as they move across VMware, OpenShift Virtualization, and other platforms.

By the end of this seminar, you will:

  • Understand the current state of VM migration between hypervisors and where networking complexity arises.
  • Gain working knowledge of Kubernetes networking and how it applies to virtual machines.
  • Explore strategies to minimize downtime and disruption during migrations.
  • Learn how Isovalent Network Bridge simplifies workload mobility across platforms.
  • See live technical demos of bridging datacenter networks with cloud native networking and security.

This seminar is ideal if you are responsible for VM operations, datacenter networking, or platform engineering and want a practical, end-to-end view of modernizing your stack.

→ Add this seminar to your registration: TECCLD-1773 – Being Successful Moving from Legacy Hypervisors to Cloud Native Platforms

Why You Should Attend Both Sessions

Together, these two sessions provide a complete journey:

  • TECCLD-1773 gives you the big-picture strategy, foundational knowledge, and detailed demos for moving from legacy hypervisors to cloud native platforms.
  • BRKCLD-1713 dives deep into network migration pain points and shows how to solve them with Isovalent Network Bridge and Cisco networking.

If your organization is planning a migration, modernizing your datacenter, or exploring cloud native architectures, these sessions will help you:

  • Reduce risk and downtime during migrations.
  • Avoid costly re-IP and redesign work.
  • Align network, platform, and application teams around a unified approach.

Join Me at Cisco Live Amsterdam

Cisco Live is the perfect place to learn, ask questions, and benchmark your strategy against what others in the industry are doing.

If you want to turn VM migration from a risky project into a repeatable, well-understood process, make sure you add these sessions to your schedule:

  • BRKCLD-1713: Taking Away the Network Pain from Cross-Hypervisor Migrations with Isovalent Network Bridge – View & enroll
  • TECCLD-1773: Being Successful Moving from Legacy Hypervisors to Cloud Native Platforms with Cisco and Isovalent – View & add to your registration

I’m looking forward to meeting you in Amsterdam and diving into how we can make your next migration smoother, safer, and truly cloud native.

If you’d like to stay in touch or discuss your migration plans, feel free to connect with me on LinkedIn.

Kubernetes Header Image

How to Increase CPU & Memory Limits and Set Node Selector for Splunk Operator on Kubernetes

General, Kubernetes, , , , , , ,

The Issue

When deploying a Splunk instance using the Splunk Operator on Kubernetes, the default resource limits are set to 4 CPUs and 8GB of RAM. Users often want to increase these limits to better utilize available hardware resources. Additionally, users may want to schedule the Splunk pods on a specific Kubernetes node by using a nodeSelector.

However, attempts to set nodeSelector directly in the Splunk Operator’s Custom Resource (CR) manifest result in errors, and the operator does not apply the node selection as expected. This leads to deployment failures or pods not being scheduled on the desired node.

The Cause

The root cause is that the Splunk Operator’s Custom Resource Definition (CRD) for Standalone does not support the nodeSelector field inside the spec section of the CR manifest. When you try to add nodeSelector there, Kubernetes rejects the manifest with errors like:

The request is invalid: patch: Invalid value: ...: strict decoding error: unknown field "spec.nodeSelector"

This happens because nodeSelector is not defined in the manifest according to the CRD schema, and the Splunk Operator currently does not expose nodeSelector as a configurable field in the CR.

The Fix

To increase CPU and memory limits for your Splunk instance, update the resources section under spec in your Splunk Standalone manifest like this:

spec:
  resources:
    limits:
      cpu: "6"              # Max 6 CPUs allowed
      memory: "12Gi"        # Max 12 GB memory allowed

This change is supported by the operator and will apply the resource limits correctly.

For node selection, since the operator does not support setting nodeSelector in the CR, you need to manually patch the StatefulSet that the operator creates. Use the following kubectl patch command to restrict the pods to run only on a specific node (replace the hostname with your target node):

kubectl patch statefulset splunk-splunk-01-standalone -n splunk --type='merge' -p='{
  "spec": {
    "template": {
      "spec": {
        "nodeSelector": {
          "kubernetes.io/hostname": "ip-10-1-1-15.us-east-2.compute.internal"
        }
      }
    }
  }
}'

This patch adds the nodeSelector to the pod template spec of the StatefulSet, ensuring pods are scheduled only on the specified node.

 

Zoom header

Zoom Error 5456000 – An unknown error occurred – Unable to Connect

General, , ,
The Issue

I’ve been plagued with this issue on one single macos device for a while and I’ve not been sure as to why, I’ve tried uninstalling and reinstalling to no avail, and google wasn’t much help.

Ultimately the Zoom app itself couldn’t connect to meetings.

An unknown error occurred
Error code: 5456000

Zoom an unknown error occurred 5456000

The Cause

I’ve no idea what the exact cause is, however I realised the app had zero network connectivity when it couldn’t even check for updates, even after uninstall and reinstall.

The Fix

Don’t uninstall by moving the app to the trash bin, instead uninstall it this way:

Applications > Zoom > Right Click - Show Package Contents > Click into the Contents Folder > Click into Frameworks > Run the ZoomUninstaller file

Once completed, I’d say it’s a good idea to do a full restart of your macbook, and then reinstall from the latest package downloaded on zoom.us.

How to fix Zoom Error 5456000 Unable to Connect

 

Regards


Bluesky Icon
Follow me on Bluesky

Dean Lewis

So you want to work in Technical Marketing or other associated roles - cover image

So you want to work in Technical Marketing or other associated roles?

General, , , , ,

Does working in Tech Marketing appeal to you? Or another associated role, maybe DevRel, or a similar title?

Are you looking for the next career ladder step, or do you already have your heart set on this goal?

Yeah, I’ve been there, too, and as time passes, I’ve considered writing this post for a while.

Why? I think it’s because I like the sound of my keyboard clacking away as I type words. No, in all seriousness, I’ve been in this role for a while now, and somewhere on this timeline, I believed I had something worth sharing.

There’s also a slight irony highlighted to me in writing a blog post on this subject of being a blog post writer; maybe I should record a video, too!

Figuring out why you want this role!

If there is one piece of advice I can give anyone with their heart and mind set on a specific next role, it’s to figure out why you want that particular role. And be completely honest with yourself, whether it’s money, getting away from a shitty boss or colleagues, furthering your experiences, or even just because it’s an interim step to something else.

Most people I know who work in the technology field at some point want or have wanted to work in the role generally known as “Technical Marketing”, myself included (and currently I do).

Most of the time, it stems from meeting someone in the role, either at a conference or watching a presentation delivered by someone in this role. Next, you learn about the supposed glitz and glamour of the role, the travel to various conference rooms across the area, maybe even the globe, working with your latest favourite technologies, and seemingly endless knowledge about a particular area.

You may pick up a slight sense of sarcasm in that last paragraph, and that’s because I remind myself of the rose-tinted glasses I wore looking on at those who worked in vendor-land as I yearned to make a move across. Unfortunately, I have to dispel a myth for you now. It’s not all first-class flights, full-expense trips, and parties across the globe; sometimes, you must create PowerPoint presentations!

I already do the tech marketing role anyway, kind of!

Continue reading So you want to work in Technical Marketing or other associated roles? →

VMware Change Block Tracking Issue - Header

vSphere data loss bug returns – CBT issues in vSphere ESXI 8.0 update 2

General, Veeam, VMware, , , , , , , , , ,
The Issue

I keep saying, there are no new ideas in technology, just re-hashes of old ones. That is also true for VMware and their data loss issues.

The vSphere-based change block tracking (CBT) bug is back! I think I wrote 5 articles on this back in 2014/2015 with explanations and fixes!

Veeam reported this at the start of week commencing 11th December 2023, with VMware confirming the issue by the end of the same week.

The Cause

Change block tracking is the feature used to see which blocks of data have changed since a known point in time, to enable backup software to capture only the incremental changes.

If this feature fails, you could lose data in your backups, as the backup software doesn’t know which blocks to protect.

as per VMware:

CBT's QueryChangedDiskAreas may lose some data changed on the disk after disk is hot-extended.
It only happens on ESXi 8.0u2.
The Fix/Workaround

Directly from VMware’s newly published KB, which took them only a few days to confirm this behaviour after Veeam noticed at the start of the week!

  • Resolution
    • Unfortunately, there is no fix available for this bug at this time. However, you can use the following workaround to work around the issue until a fix is released
  • Workaround
    1. Reset CBT after disk is hot-extended. Then, user need to take a full backup immediately.
      It does not fix existing backups, but it makes sure the new ones are good.
    2. Or, user extend disk in offline.

You cannot fix your existing incremental backups if they have been affected, if they missed the correct data to backup, it’s been missed! But you can run an Active Full backup to capture everything, certainly for Veeam this is the case, other backup vendors you’ll need to double check with!

How do I reset Change Block Tracking?

If you are using Veeam, you can just perform an Active Full backup, and ensure the reset CBT option is configured. This is enabled by default.

If you aren’t using Veeam, then the following will be your next steps.

To reset Change Block Tracking, as per this older VMware KB article from the last time this was an issue. VMware may update this article or produce another one now this recent bug has been found.

  • Find your VM in the vCenter Client
    • Power the VM off
    • Click the Options tab, select the Advanced section and then click Configuration Parameters.
  • Disable CBT for the virtual machine by setting the ctkEnabled value to false.
  • If you need to do this for specific virtual disks attached to your virtual machine
    • Disable CBT by configuring the scsix:x.ctkEnabled value for each attached virtual disk to false. (scsix:x is SCSI controller and SCSI device ID of your virtual disk.)
  • Ensure there are no snapshot files (.delta.vmdk) present in the virtual machine’s working directory. For more information, see Determining if there are leftover delta files or snapshots that VMware vSphere or Infrastructure Client cannot detect (1005049).
  • Delete any -CTK.VMDK files within the virtual machine’s working directory.

Now power on your virtual machine.

Depending on your backup software vendor, you may need to manually re-enable Change Block Tracking, you can find a full list of steps and considerations in this VMware KB article. It’s essentially power down the VM, enable in value again in configuration parameters.

Summary

Let’s hope VMware produces a fix for this quickly, I remember they had this issue in vSphere 5.5 and 6.0 and some fixes didn’t resolved the issue, it was a pain being a consultant having to install fixes at customers sites.

It’s good that VMware have only taken a short amount of time to validate this bug and publish something officially about it!

 

Regards

Dean Lewis