Blog

Designing VMware Cloud Foundation 9.1: The 31 Decisions You Need to Make

Every VCF deployment starts the same way: someone hands you a blank whiteboard and says design it. The problem is that VCF 9.1 is a broad platform, and without a structured approach it is easy to make decisions out of order, miss dependencies, or find out three phases in that an early choice locked you into something you did not intend.

Broadcom organizes the VCF 9.1 design process into nine phases covering 31 distinct decisions. This post walks through each phase, what the decisions are, and why they matter in practice. If you are using the VCF Designer tool, this maps directly to the decision schema it uses.

Phase 1: Starting Point and Profile

Before touching any configuration, you need two things nailed down: the design blueprint and the scope.

The Design Blueprint is your baseline deployment profile. Broadcom defines several: single site minimal, single site, multi-site single region, multi-region, and others covering application and security modernization. This is not a technical decision as much as it is a business one. It defines the complexity ceiling for everything that follows.

Scope and Use Cases is where you gate the rest of the design. VCF 9.1 can cover private cloud IaaS, Kubernetes via Supervisor, Private AI Foundation, vDefend lateral security, VCF Edge, and disaster recovery. What you check here enables or disables options in later phases. Do not mark something in scope unless there is a real requirement behind it.

Phase 2: Fleet-Level Decisions

The VCF Fleet Deployment Model defines how the fleet is laid out. A single VCF instance is the most common for customers starting out or running a standalone private cloud. A connected fleet with multiple instances comes into play when you have multiple sites or organizational boundaries that require separate management planes.

The VCF Fleet Sizing Model covers appliance sizing: Small, Medium, HA Medium, Large, and HA Large. Sizing here is not about your workload VMs. It is about the management plane itself. Undersizing the fleet appliances is one of the most common mistakes in early VCF deployments.

Phase 3: Consumption Decisions

This phase covers how cloud consumers interact with the platform. Five decisions, and they are tightly interconnected.

The VCF Automation Model decides whether VCF Automation is deployed and in what topology. If your organization needs self-service provisioning or catalog-driven deployments, you need this. If not, skip it. Running it just because it is available adds operational overhead without benefit.

The Network Consumption Model is one of the most consequential decisions in the entire design. VLAN, NSX Overlay Segments, VPC, or Transit Gateway. This drives downstream decisions on edge clusters, load balancers, and how workloads connect. Get this wrong and you are rearchitecting the network mid-project.

Workload Connectivity and Load Balancer Model follow from the network consumption choice. For load balancing, NSX Native covers most use cases. Avi (VCF Advanced LB) is needed when you require full L7 with advanced policies, SSL offload, or WAF capabilities.

Phase 4: Operations Decisions

Six decisions covering management services, management networking, operations tooling, logging, network observability, and recovery.

The VCF Management Services Model defines availability for SDDC Manager, vCenter, and NSX Manager. Standard vs. Highly Available. For production environments, the answer is almost always HA. The cost of an HA management plane is small compared to the cost of a failed SDDC Manager during a critical operation.

The VCF Management Network Model determines whether management components share a VLAN, use isolated VLANs per component, or run on NSX segments. NSX segments require NSX to be up before management components can communicate, which creates a chicken-and-egg risk during recovery scenarios. Plan this carefully.

The VCF Recovery Option aligns to your RPO and RTO requirements. Backup and restore, component-level recovery, and instance-level recovery each have different complexity and cost profiles. Define your recovery requirements before choosing this, not after.

Phase 5: Security and Compliance

Identity Broker and SSO decisions define how users authenticate to VCF components. Most enterprise environments will federate to Active Directory or an external IdP. Plan this early since it affects every component that needs authentication.

vDefend Lateral Security only applies if it was included in scope in Phase 1. If deployed, the Security Services Platform adds distributed IDS/IPS and east-west traffic inspection.

Phase 6: Virtual Infrastructure

Seven decisions covering domains, clusters, networking, and storage. This is where the design gets concrete.

The VCF Domain Model defines your management and workload domain topology. Single-AZ with one management plus one workload domain is the most common starting point. Stretched (multi-AZ) adds complexity but is required for metro HA.

The Storage Model is one of the decisions with the most downstream impact. VCF 9.1 supports vSAN OSA, vSAN ESA, NFS, VMFS on Fibre Channel, iSCSI, and NVMe variants. vSAN ESA is the recommended path for new deployments using compatible hardware. If you are connecting to an existing SAN or NAS, the external storage options apply.

NSX Manager topology and NSX Edge Cluster decisions define the control plane and data plane for your overlay network. Edge cluster sizing depends on the volume and type of north-south traffic. A shared NSX Manager cluster across domains reduces overhead. Dedicated per domain gives you blast radius isolation.

Phase 7: Physical Infrastructure

One decision: the Network Fabric Model. Routed VLAN fabric, Leaf-Spine VXLAN underlay, or EVPN-VXLAN fabric. This needs to be made in coordination with the network team. The fabric model affects how VLANs are extended across the environment and how the NSX overlay integrates with the underlay. EVPN-VXLAN provides the most flexibility for multi-site and stretched cluster scenarios.

Phase 8: Optional Workload Capabilities

VCF Edge and Private AI Foundation, both conditional on Phase 1 scope. For VCF Edge, single-host is suitable for small remote sites where HA is not required. Three-host provides local HA at the edge.

For Private AI Foundation, the compute model selection depends heavily on the type of workloads. Training workloads typically want full GPU passthrough or MIG. Inference workloads can often share via vGPU.

Phase 9: Closeout

Two workflow tasks, not configuration decisions. First, reconcile every decision made in Phases 1 through 8 against the Broadcom VCF Design Library to confirm alignment with supported patterns. Second, translate the finalized design into the VCF Planning and Preparation Workbook, which is the actual input consumed by the VCF Installer during bring-up. A clean design that does not translate into a properly completed workbook will cause bring-up failures. Budget time for this step.

The Full Decision Index

Step	Phase	Decision
1	Phase 1	Design Blueprint
2	Phase 1	Scope and Use Cases
3	Phase 2	VCF Fleet Deployment Model
4	Phase 2	VCF Fleet Sizing Model
5	Phase 3	VCF Automation Model
6	Phase 3	vSphere Supervisor Model
7	Phase 3	Network Consumption Model
8	Phase 3	Workload Connectivity Model
9	Phase 3	Load Balancer Model
10	Phase 4	VCF Management Services Model
11	Phase 4	VCF Management Network Model
12	Phase 4	VCF Operations Model
13	Phase 4	Log Management Model
14	Phase 4	VCF Operations for Networks Model
15	Phase 4	VCF Recovery Option
16	Phase 5	Identity Broker Model
17	Phase 5	VCF Single Sign-On Model
18	Phase 5	Lateral Security with vDefend
19	Phase 6	VCF Domain Model
20	Phase 6	vSphere Cluster Model
21	Phase 6	Distributed Switch Model
22	Phase 6	Storage Model
23	Phase 6	NSX Manager and Control Plane Model
24	Phase 6	NSX Edge Cluster Model
25	Phase 6	Virtual Network Appliance Cluster Model
26	Phase 7	Network Fabric Model
27	Phase 8	VCF Edge Model
28	Phase 8	Private AI Foundation Platform Model
29	Phase 8	Private AI Foundation Compute Model
30	Phase 9	Reconcile Against Broadcom Design Library
31	Phase 9	Produce the Planning and Preparation Workbook

June 1, 2026

Insights from a Nutanix Migration Specialist

My work life as an IT specialist has always been quite varied.

I spent part of my time installing traditional datacenter infrastructure, some of my time implementing cybersecurity solutions, and bits and pieces here and there, working on projects with a number of different technology vendors.

But over the past 18 months, my main focus has been: migrate customers’ virtualization environments to Nutanix.

The timing lines up with some big shakeups in the tech industry, as well as the continued growth of hyperconverged infrastructure (HCI). I heard my customers worry that support quality would decline for their existing environments, or that innovation might stall. In reality, what my customers have mostly seen is severe sticker shock on their renewal bills—partly due to inflation that has hit all sectors, but also due to dramatic changes to vendor licensing agreements.

Some customers have seen 3x, 5x, or even 10x increases in their virtualization costs, practically overnight. These are customers that have been with a vendor for 15 or 20 years, in many cases, and many had come to view their virtualization environments as something of a commodity with a stable pricing structure. But changes to licensing agreements have upended this stability. Before, customers could mostly purchase individual product licenses as needed, but they’re now being funneled into bundled packages with add-on features they don’t want and can’t use.

Some large enterprises are able to absorb these new costs. But for others—especially small and medium-sized companies—the impact to their business is comparable to tripling their rent, or adding a zero to their monthly utility bills. These smaller customers also find themselves in a poor negotiating position with tech giants.

For example, we recently worked with Norfolk Public Schools in Virginia to migrate to Nutanix. The district was facing an eye-popping 680% cost increase if it stayed with its previous provider, but a five-year licensing agreement saved it approximately $2 million.

For customers like Norfolk Public School, the numbers of the new virtualization landscape simply don’t add up. And for the first time, many of these organizations are willing to seriously consider a change.

Even non-technical people can understand the anxiety that comes with switching technology platforms. (Think of how rarely people change to a phone with a different operating system.) Most of my customers never even considered switching from their existing virtualization provider until recently. After all, virtualization is a foundational technology that supports their entire business. Many system administrators have built their careers and expertise around the environment they know, developed their own workflows around its interface and capabilities, and integrated their entire application environment with that platform.

Most importantly, businesses have come to rely on the stability of their virtualization environments to keep their mission-critical systems up and running. So, it’s understandable why many approach a change with a degree of trepidation. They want to know whether their applications will work the same way, how much downtime to expect, and whether their teams will need extensive retraining.

However, once customers make the move, they tend to find that Nutanix infrastructure provides everything they need—and often in a more intuitive way, at what essentially amounts to what they were paying before the market shifts of the past couple off years. During the pre-sales process, I sit with customers to walk them through the Nutanix interface. We spend much of this time exploring the equivalent functionality between the platforms, which is often mostly a matter of learning new terminology for familiar features.

At Norfolk Public Schools, we conducted site assessments, installed and configured new hardware, configured the Nutanix platform, and migrated more than 400 virtual machines—all in just over a month. The cutover to the new operating environment was seamless, and the district saw immediate improvements in performance and reliability.

For most organizations, the migration is just as painless. Some clients prefer to migrate in small batches of just a few virtual machines, while others are ready to move hundreds of virtual machines over a single weekend. The actual cutover process for each virtual machine takes only about five to ten minutes—comparable to the standard maintenance window for most security patches. Post-migration, customers typically notice improved performance (mostly due to new hardware). In addition to the cost savings, many also cite Nutanix’s simplified disaster recovery capabilities as a major benefit of the move.

After we start the migration, I can see the anxiety on my customers’ faces melt away, replaced by relief. Recently, one even started laughing. “This is so amazing!” he kept repeating. “This is so easy!”

February 4, 2026
Cloning Linux: A Step-by-Step Guide to Booting from iSCSI LUN
In this comprehensive guide, we demystify the process of cloning a Linux operating system (Ubuntu) and guide you through the intricacies of booting directly from an iSCSI LUN. We’ll walk you through the entire process, from selecting the right tools for cloning to configuring your system for iSCSI boot. Whether you’re a seasoned Linux administrator or a curious enthusiast, this step-by-step guide is tailored to empower you with the knowledge and skills needed to successfully clone and boot Linux from an iSCSI LUN.

Let’s begin with a summary of the technology prerequisites for accomplishing this task. Firstly, you’ll require a Linux box, whether physical or virtual. It’s essential to note that the method I propose involves system downtime, so scheduling a maintenance window is advisable, particularly if your system is in production. As part of this approach, a connection between the source system and the target Volume/LUN is crucial. I’ll explore the concept of cloning to a file from the source and transporting it to the target side in a future post.

Lastly, a target system capable of providing the iSCSI volume is indispensable for the successful execution of this process. Keep these key components in mind as we delve into the steps for cloning a Linux OS and booting from an iSCSI LUN in our detailed guide.

If you want to Lab the cloning, you’ll need three things:
1. Linux Box: I will be using Ubuntu, you can download Ubuntu here: https://ubuntu.com/
2. If you want to boot a Virtual Machine (VM) from iSCSI you will need iPXE: https://ipxe.org/download
3. For the iSCSI server I used the Nutanix Community Edition: https://next.nutanix.com/discussion-forum-14/download-community-edition-38417 (you’ll need a Nutanix Next Community login)
Here we go, in your Linux box gather a few nuggets of information by executing these commands:
1. Become a super user with: sudo su
2. List your disk drives with: fdisk -l
3. Verify the boot device with: df -f and cat /etc/fstab, and blkid
```
lab@lab-vm:~$ sudo su
[sudo] password for lab:*****

root@lab-vm:/home/lab# fdisk -l
...
Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2F122466-CF57-4DAB-A441-276FFFFE87BD
...
Device     Start      End  Sectors Size Type
/dev/sda1   2048     4095     2048   1M BIOS boot
/dev/sda2   4096 41940991 41936896  20G Linux filesystem

root@lab-vm:/home/lab# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           391M  1.2M  390M   1% /run
/dev/sda2        20G  6.1G   13G  33% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           391M  4.0K  391M   1% /run/user/1000
root@lab-vm:/home/lab#

root@lab-vm:/home/lab# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during curtin installation
/dev/disk/by-uuid/91cf8b5a-2c4d-49c4-bcb5-57b59339a2c0 / ext4 defaults 0 1
/swap.img       none    swap    sw      0       0

root@lab-vm:/home/lab# blkid
/dev/sda2: UUID="91cf8b5a-2c4d-49c4-bcb5-57b59339a2c0" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="853d57ea-8b35-4dc7-bb28-813d1a2e4769"
...
/dev/sda1: PARTUUID="3d8c878b-7431-4732-acd4-ba2a21f5458a"
root@lab-vm:/home/lab#
```
Based on the results of the earlier commands, we’ve identified that our system is installed directly on /dev/sda. With this understanding, let’s proceed to boot Linux from a Live Ubuntu ISO Image and open a Terminal window. See the following slideshow of the process:

While in the live Ubuntu you could enable ssh to make everything easier. From the terminal executed the following commands
1. sudo su
2. apt install openssh-server -y
3. systemctl enable ssh
4. ufw allow ssh
I already have my Nutanix CE deployed and an iSCSI lun configured. The Discovery IP address in my case is 192.168.1.51 and the name on the iSCSI Lun is iqn.2010-06.com.nutanix:lab-boot-lun-ee392c61-6958-4be2-88fc-636bed265e09. To configure the Lice Ubuntu to access the Lun execute these commands (while logged with root using ‘sudo su’):
- apt install open-iscsi -y
- apt install multipath-tools -y
- service multipath-tools start
- iscsiadm -m discovery -t sendtargets -p 192.168.1.51
- iscsiadm -m node –op=update -n node.conn[0].startup -v automatic
- iscsiadm -m node –op=update -n node.startup -v automatic
- systemctl enable open-iscsi
- systemctl enable iscsid
- systemctl restart iscsid.service
- iscsiadm -m node –loginall=automatic
- iscsiadm -m session -o show
The output of the last command should show something like this:

root@ubuntu:/home/ubuntu# iscsiadm -m session -o show
tcp: [1] 192.168.1.51:3260,1 iqn.2010-06.com.nutanix:lab-boot-lun-ee392c61-6958-4be2-88fc-636bed265e09-tgt0 (non-flash)
root@ubuntu:/home/ubuntu#

In my case the original drive is in /dev/sda and the new iSCSI lun is /dev/sdb, to start the cloning execute the following command: dd if=/dev/sda of=/dev/sdb bs=32M status=progress

The next step must be done before the reboot. It will configure the system to boot from the new iSCSI Lun.
- mount /dev/sdb2 /mnt
- mount –bind /dev /mnt/dev
- mount –bind /sys /mnt/sys
- chroot /mnt
- mount -t proc none /proc
- hostname -F /etc/hostname
- echo “nameserver 8.8.8.8” >> /etc/resolv.conf
- apt-get install initramfs-tools -y
- apt-get install open-iscsi -y
- echo “iscsi” >> /etc/initramfs-tools/modules
- touch /etc/iscsi/iscsi.initramfs
- update-initramfs -u
- Edit /etc/default/grub:
  - Replace:
    
    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
  - With:
    
    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash ip=dhcp ISCSI_INITIATOR=iqn.2004-10.com.ubuntu:01:a3ea501f8a8 ISCSI_TARGET_NAME=iqn.2010-06.com.nutanix:lab-boot-lun-ee392c61-6958-4be2-88fc-636bed265e09 ISCSI_TARGET_IP=192.168.1.51 ISCSI_TARGET_PORT=3260″
- update-grub
Now shutdown and boot the Linux from the iPXE iso. Follow the same steps and the slideshow above, except that you will use the ipxe.iso image now:

Be alert to use the ctrl-b early in the boot process:

Now, type ‘dhcp‘ to acquire an IP address and type ‘show net0/ip‘ to verify it.

It is time to boot from the iSCSI Lun using this command:

sanboot iscsi:192.168.1.51::::iqn.2010-06.com.nutanix:lab-boot-lun-ee392c61-6958-4be2-88fc-636bed265e09

And you should have a system booting from the iSCSI Lun. In case that you don’t have access to both the source and target drives, you can pipe the dd command to gzip and save it to a file that can be read at the target system. An example is:
- dd if=/dev/sda | gzip > file.gz
I hope you find this post useful and remember to have a good backup before attempting the cloning procedure.
January 11, 2024

CCNA DevNet Study Guide – Describe parsing of common data format (XML, JSON, YAML) to Python data structures

This is the second post in a series about the new CCNA DevNet certification (Previous Post Here). In this post, we will look at how to manage in Python the three formats that we previously discussed.

Example of XML parsing in Python

from __future__ import print_function
import xml.etree.ElementTree as ET
def main():
    # create element tree object
    with open('xmlfile.xml', 'r') as xmlFile:
        tree = ET.parse(xmlFile)
    # get root element
    root = tree.getroot()
    print("Root Tag: " + root.tag)
    print("Using a for Loop:")
    for child in root:
        print(child.tag)
        for attrib in child:
            print(attrib.tag, end=' ')
            print(attrib.text)

    print("Using Indexes:")
    print(root[0].tag)
    print(root[0][0].tag,end=' ')
    print(root[0][0].text)
    print(root[0][1].tag,end=' ')
    print(root[0][1].text)

    print(root[1].tag)
    print(root[1][0].tag,end=' ')
    print(root[1][0].text)
    print(root[1][1].tag,end=' ')
    print(root[1][1].text)

    print(root[2].tag)
    print(root[2][0].tag,end=' ')
    print(root[2][0].text)
    print(root[2][1].tag,end=' ')
    print(root[2][1].text)

    print("Other:")
    for hostname in root.iter('hostname'):
        print(hostname.tag,end=' ')
        print(hostname.text)

if __name__ == "__main__":
    # calling main function
    main()

Example run of the previous code:

Root Tag: esx
Using a for Loop:
XX1
hostname ESXi01
ipaddress 10.10.10.101
XX2
hostname ESXi02
ipaddress 10.10.10.102
XX3
hostname ESXi03
ipaddress 10.10.10.103
Using Indexes:
XX1
hostname ESXi01
ipaddress 10.10.10.101
XX2
hostname ESXi02
ipaddress 10.10.10.102
XX3
hostname ESXi03
ipaddress 10.10.10.103
Other:
hostname ESXi01
hostname ESXi02
hostname ESXi03

This is the XML file we used:

<?xml version="1.0" encoding="UTF-8"?>
<esx>
<XX1>
<hostname>ESXi01</hostname>
<ipaddress>10.10.10.101</ipaddress>
</XX1>
<XX2>
<hostname>ESXi02</hostname>
<ipaddress>10.10.10.102</ipaddress>
</XX2>
<XX3>
<hostname>ESXi03</hostname>
<ipaddress>10.10.10.103</ipaddress>
</XX3>
</esx>

To achieve something similar with the .json file we would use “import json”

import json

def main():
    with open('jason.json', 'r') as jsonFile:
        #load jason file
        myJasonFile = json.load(jsonFile)
    print(myJasonFile)

if __name__ == "__main__":
    # calling main function
    main()

And to parse YAML

import yaml

with open("yamlfile.yaml", 'r') as yamlFile:
    try:
        print(yaml.safe_load(yamlFile))
    except yaml.YAMLError as exc:
        print(exc)

Let us read the RSS feed (XML) directly from a Website (https://vwannabe.com/feed/)*

from urllib.request import urlopen
from xml.etree.ElementTree import parse

myURL = urlopen("https://vwannabe.com/feed/")
myXML=parse(myURL)

for item in myXML.iterfind('channel/item'):
    title = item.findtext('title')
    date = item.findtext('pubDate')
    link = item.findtext('link')

    print(title)
    print(date)
    print(link)
    print()

*adapted from “Python – How to Read XML from URL?” by Vinish Kapoor

This is the result of the previous code:

CCNA DevNet Study Guide – Part 1
Sun, 19 Jan 2020 17:17:45 +0000
CCNA DevNet Study Guide – Part 1

vSphere Upgrade 6.0 to 6.5 Fails with Replace Process Level Token error.
Wed, 19 Jun 2019 15:32:13 +0000
vSphere Upgrade 6.0 to 6.5 Fails with Replace Process Level Token error.

Vembu now supports Hyper-V Cluster
Thu, 01 Nov 2018 12:25:42 +0000
Vembu now supports Hyper-V Cluster

vCenter 6.7 upgrade walkthrough
Fri, 20 Apr 2018 19:26:54 +0000
vCenter 6.7 upgrade walkthrough

Vembu
Wed, 28 Mar 2018 19:11:09 +0000
Vembu

How to re-register the embedded VMware Update Manager (VUM) to its vCenter (VCSA) 6.5
Wed, 21 Feb 2018 23:06:36 +0000
How to re-register the embedded VMware Update Manager (VUM) to its vCenter (VCSA) 6.5

How to spin up a Linux instance in AWS
Thu, 08 Feb 2018 20:57:06 +0000
How to spin up a Linux instance in AWS

CCNA Cyber Ops – SECOPS 1.0
Tue, 02 Jan 2018 20:23:21 +0000
CCNA Cyber Ops – SECOPS 1.0

Hacking Public Speaking
Wed, 30 Aug 2017 16:50:28 +0000
Hacking Public Speaking

VMworld 2017 General Session Day Two
Tue, 29 Aug 2017 17:44:05 +0000
https://vwannabe.com/2017/08/29/vmworld-2017-general-session-day-two/

The CISCO Blueprint uses REST calls to a site and parses the JSON. You can find the example here. In the next port for this series, I will talk about “Describe the concepts of test-driven development”.

March 11, 2020

CCNA DevNet Study Guide – Part 1
I will start a series of posts on the new CCNA DevNet certification. I will keep my SOP of going through the curriculum and google the concepts for you. I will try to include Youtube videos of some of the topics that have more hands-on exercises. The certification name is Cisco Certified DevNet Associate. The first topic if about software development and design. It includes some essential topics that I synthesize in the rest of this post.

1.0 Software Development and Design – Compare data formats (XML, JSON, YAML)

The formats XML, JSON, and YAML are data-serialization formats, from Wikipedia: In computer science, in the context of data storage, serialization (or serialisation) is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer) or transmitted (for example, across a network connection link) and reconstructed later (possibly in a different computer environment). When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object.

Mostly you will probably accomplish your task with any of the three. If you are a javascript developer, you will probably feel more comfortable with JSON (JavaScript Object Notation), or if you code in Python, you might stick to YAML (YAML Ain’t Markup Language). The XML (eXtensible Markup Language) format comes from the World Wide Web Consortium (W3C).

One difference between them is the format used by each. The XML uses tags like HTML, JSON uses objects in attribute-value pairs, and YAML uses indentation like Python.

Here is a JSON snippet that I use as part of the Cisco HyperFlex Installation.
```
{
    "esx": {
        "XX1": {
            "ipaddress": "10.10.10.101",
            "hostname": "ESXi01"
        },
        "XX2": {
            "ipaddress": "10.10.10.102",
            "hostname": "ESXi02"
        },
        "XX3": {
            "ipaddress": "10.10.10.103",
            "hostname": "ESXi03"
        }
    }
}
```
The previous example means that I have something called “esx”, which is the Hypervisor, and that I have three of them (XX1-XX3). Each has an IP address and a hostname. In XML it should like this:
```
<?xml version="1.0" encoding="UTF-8"?> 
<esx> 
  <XX1> 
    <hostname>ESXi01</hostname> 
    <ipaddress>10.10.10.101</ipaddress> 
  </XX1> 
  <XX2> 
    <hostname>ESXi02</hostname> 
    <ipaddress>10.10.10.102</ipaddress> 
  </XX2> 
  <XX3> 
    <hostname>ESXi03</hostname>
    <ipaddress>10.10.10.103</ipaddress> 
  </XX3>
</esx>
```
And in YAML, it should be something like this:
```
---
esx:
  XX1:
    ipaddress: 10.10.10.101
    hostname: ESXi01
  XX2:
    ipaddress: 10.10.10.102
   hostname: ESXi02
  XX3:
    ipaddress: 10.10.10.103
    hostname: ESXi03
```
I used two free online tools to convert one format to the other.
1. https://www.freeformatter.com/json-to-xml-converter.html
2. https://www.json2yaml.com/
It is recommended to use the builtin libraries and not make your own to avoid mistakes. For example, javascript uses the JSON.parse() method, and python uses the JSON library. Example of use of the JSON library:
```
import json
json_string = '{"name": "Jason", "last_name":"Parser"}'
parsed_json = json.loads(json_string)
print(parsed_json['name'])
"Jason"
```
That is all for this post, I will publish periodically to add more sections to the software development and design topic:
- Describe parsing of common data format (XML, JSON, YAML) to Python data structures
- Describe the concepts of test-driven development
- Compare software development methods (agile, lean, waterfall)
- Explain the benefits of organizing code into methods/ functions, classes, and modules
- Identify the advantages of common design patterns (MVC and Observer)
- Explain the advantages of version control
- Utilize common version control operations with Git
January 19, 2020
vSphere Upgrade 6.0 to 6.5 Fails with Replace Process Level Token error.
Recently I was upgrading a vCenter 6.0 U2 to 6.5, and after successfully upgrading the external PSC, the process failed at the vCenter. After some troubleshooting, I found out that I needed to add the user to the “Replace a Process Level Token” attribute under the Local Security Policy. You can find the Microsoft documentation here. The process is simple:
1. Login into the vCenter Windows Server with your Administrator account.
2. Open the Control Panel and click the Administrative Tools.
3. Browse to and double click the Local Security Policy and then expand the Local Policies.
4. Click on User Rights Assignment and open the Replace a Process Level Token attribute.
5. Click the Add User or Group button to add the service account.
June 19, 2019
Vembu now supports Hyper-V Cluster

With the release of Version 4.0, Vembu now extends support to Hyper-V cluster. Vembu already supports both physical and virtual environments, covering all your needs for backups and disaster recovery. Please check their website at https://www.vembu.com, and requested a demo to experience the different features here: https://www.vembu.com/vembu-product-demo/. There are a couple of new interesting features in version 4.0 that are worth trying, not to mention that the free tier comes with the protection of up to three VMs in your environment. One of these features is the Hyper-V cluster.

Hyper-V Failover Cluster

To view the latest Webinars, including one on how to manage a High Available Cluster, check the upcoming webinars here: https://www.vembu.com/webinars/#

November 1, 2018
vCenter 6.7 upgrade walkthrough

VMware recently announced a new vSphere release, version 6.7. It includes new features like the Per-VM EVC and support for embedded PSC and vCenter in enhanced link mode (ELM). In this post, I will show a slideshow of the upgrade process in a topology with the Platform Service Controller separate from the vCenter server. Basically, this only means that you have to perform the upgrade twice. Before starting your upgrade make sure you have a good backup of your system, consult the vSphere 6.7 Release Notes and the related essential information about compatibility. First, we upgrade the external PSC, you’ll need a temporary IP address to deploy the new image before doing the final cut. The upgrade order is published in this VMware KB-53710. Make sure that all the host and IP address information is resolvable using DNS and that the NTP servers are working.

This slideshow requires JavaScript.

Once you have the PSC upgraded and running, you can move on to the vCenter in a similar process.

This slideshow requires JavaScript.

The topologies must stay the same when using the upgrade script. If you want to change from two VMs into an embedded deployment with the PSC and the vCenter in a single VM, then you’ll have to re-deploy your vCenter appliance.

April 20, 2018
Vembu
Vembu is a Backup and Disaster Recovery company which extends it support to both physical and virtual environments at affordable pricing thus ensuring high availability of resources to data centers. Vembu BDR Suite is their current software offering that provides free Backup & DR solutions for VMware vSphere, Microsoft Hyper-V Virtual Machines, Physical Servers, Workstations, MS-Applications and SaaS applications (Office 365 and G Suite).

Vembu BDR Suite of Products – categorized based on following environments

Vembu VMBackup is an agentless backup solution for VMware vSphere Backup and Microsoft Hyper-V Backup. Vembu CBT driver along with the VSS technology for application consistency ensures up to 5 times improvement in performance over any other backup software.

Vembu ImageBackup, a part of Vembu BDR Suite, provides backup and disaster recovery solution for Windows IT environments. Quick VM Recovery helps the businesses to achieve an RTO of less than 15 mins.

Vembu NetworkBackup protects business data across File servers, Application servers and Endpoints can be protected. Vembu Universal Explorer is a free tool that is devised to provide Backup and Recovery to application files and folders.

Vembu OffsiteDR allows users to replicate the backed up data from their primary on-site backup server to an offsite server location in a highly secure and reliable manner through AES 256-bit encryption.

Following are the collection of products under Vembu Cloud Services:

Vembu CloudDR allows users to replicate your VMware, Hyper-V and Windows Server backup to Vembu cloud storage thus ensuring high protectivity.

Vembu OnlineBackup lets you backup the data across File Servers, Application Servers and Endpoints in Vembu cloud residing on Amazon Web Services (AWS) through AES 256-bit encryption.

Vembu SaaSBackup is designed to backup the Mails, Calendars, Contacts and Drives content of Office 365 and Google Apps. The data after the backup will be sent to the Vembu Cloud for storage over a secured network.

Vembu BDR360 significantly increases administrator’s productivity by providing end to end visibility to all your IT environments. Thus, making it easier for the business to manage their overall IT setup through an efficient report generation process.

To Download the free trial version of Vembu BDR Suite click below: https://www.vembu.com/vembu-bdr-suite-download/

Other Free Products offered by Vembu are as follows:

Free Windows Workstations Backup

Free File Backup of Workstations

Free Vembu Universal Explorer

Free Vembu Recovery CD

Product Presentations and Webinars:
- Presentations
- Webinars
Download the following Whitepapers for Free:
March 28, 2018
How to re-register the embedded VMware Update Manager (VUM) to its vCenter (VCSA) 6.5
The time comes when you have to upgrade your system to add new features and functionality. Sometimes you find bugs and need to troubleshoot a little bit the situation. Precisely what happened to me when upgrading from VCSA 6.0 to VCSA 6.5 with embedded VMware Update Manager (VUM). It took me a little digging here and there and few messages to my colleagues in the VMware community, but finally I came up with the solution. The problem the system presented was this:
```
Error

Error attempting Vcintegrity Export file does not exist or is corrupted, abort import
Resolution

Please check vcIntegrity migration logs for details.
```
That came up at the end of the vCenter migration. The cause is that I had a VCSA with an external VUM. The migration assistant won’t help because the process is expecting to find the service in the old vCenter appliance (VCSA 6.0). This is a documented problem, and you’ll see the KB here. The first step is to remove the VUM from the old server, then deregister the Web Plugin from the new vCenter. At this moment go ahead and restart(stop and start) the web client service in the VCSA command line. Use the command “service-control –start vsphere-client” (VMware KB found here). And then either disable the VMware Update Manager plugin from the web client using the GUI or the MOB, these are the steps:
1. In a web browser, navigate to http://vCenter_Server_name_or_IP/mob.
  Where vCenter_Server_name_or_IP/mob is the name of your vCenter Server or its IP address.
2. Click Content.
3. Click ExtensionManager.
4. Select and copy the name of the plug-in you want to remove from the list of values under Properties. For a list of default plug-ins, see the Additional Information section of this article.
5. Click UnregisterExtension. A new window appears.
6. Paste the key (vcIntegrity) of the plug-in and click Invoke Method. This removes the plug-in and results in void.
7. Close the window.
8. Refresh the Managed Object Type:ManagedObjectReference:ExtensionManager window to verify that the plug-in is removed successfully.
The previous steps are found in this other VMware KB.

Then to register the VUM with the vCenter, you need to follow this procedure:
```
cd /lib/vmware-updatemgr/bin
mkdir backup
cp -p extension.xml backup/
cp -p vci-integrity.xml backup/
cp -p jetty-vum* backup/
```
Now go ahead and finish the failed registration with this command:
```
/lib/vmware-updatemgr/bin/vmware-vciInstallUtils -C /lib/vmware-updatemgr/bin/ -L /var/log/vmware/vmware-updatemgr/ -I /lib/vmware-updatemgr/bin/ -v <your vCenter FQDN> -p 80 -U administrator@<your SSO domain> -P <password> -S /lib/vmware-updatemgr/bin/extension.xml -O extupdate

chown updatemgr:updatemgr vci-integrity.xml

service-control --start vmware-updatemgr
```
In the command above replace the information within the <> with your own, for example <your vCenter FQDN> could be vcenter01.google.com.

Hopefully, that will save you some time in this specific case of a failed vCenter upgrade because the VUM was on a separate server than the vCenter.
February 21, 2018