Case study: publicly connected VMware virtual machine on IBM Cloud

Background

IBM Cloud for VMware Solutions deploys VMware vCenter Server (VCS) environments using a network architecture consisting of three VLANs: one private VLAN used for management traffic and for NSX VTEPs, a second private VLAN used for storage traffic and vMotion, and a public VLAN.

Initially a sample NSX configuration is deployed for your use, including a distributed logical router (DLR), and an edge services gateway (ESG) that provides NAT service outbound from a logical switch (VXLAN) to both the IBM Cloud private network (10.0.0.0/8 addresses) and the public Internet.

edge-servicesThe simple case is to deploy your virtual machines onto the logical switch and take advantage of the ESG to access the private and public networks. (Note that the ESG is initially configured with the sample NAT rule disabled, so you will need to enable it.) However, in our case study we want to deploy a virtual machine that will be used as part of the management stack to manage vCenter, ESXi hosts, and deploy workloads into vCenter. As a result, we prefer to have our virtual machine live directly on the private management network, but it will still need access to the public network, for example to download updates. This means we will need both to assign a private IP to the VM, and also to reconfigure the ESG to provide NAT from the private network to the public network.

Additional Details

You can discover the management VLAN on which your VCS instance is deployed by logging into the IBM Cloud infrastructure portal, displaying details for your bare metal servers, and identifying the Private interface. This information is important if you later need to order additional private portable IP addresses for your use. IBM Cloud infrastructure provides two different kinds of IP addresses: (1) primary subnets whose allocation IBM Cloud manages for bare metal servers and virtual servers, and (2) portable subnets whose allocation is typically managed by you and not by IBM Cloud. Note however that IBM Cloud for VMware Solutions orders and manages several portable subnets for your VCS instance. The only portable subnets associated with the VCS that are available for your use are those that are attached to the private and public interfaces of the sample ESG deployed in your instance. We will use one of these addresses for our VM’s deployment.

Procedure

  1. Establish connectivity to your VCS environment (e.g., using the IBM Cloud VPN)
  2. Login to your vCenter web client UI
  3. Click the Home icon and navigate to Networking & Security
  4. Select NSX Edges and double click on the customer-nsx-edge
  5. Select the Manage tab, Settings item, and view the list of Interfaces. Note the interface with a 10.x.x.x/26 address. This represents the private portable subnet available to you for your use. One IP address is used by the ESG but the remaining addresses (excluding the network address, gateway address = network+1, broadcast address) are available to you for your use. The ESG can be configured to serve as a NAT for any address in the same subnet as itself. Note well that you will be responsible to manage the assignment of addresses within this subnet to prevent conflict!
  6. Configure the ESG firewall to allow outbound traffic from the 10.x.x.x/26 network
    1. Select the Firewall tab and add a new rule after the “All outgoing customer VMs” rule
    2. Configure this rule to allow outgoing traffic from the management network; the source IP specification should be the same subnet as the ESG, for example 10.123.171.128/26
    3. Click to Publish Changes
  7. Configure the ESG to NAT traffic from the private to the public network
    1. Select the NAT tab and add a new SNAT rule
    2. Configure this rule to operate on the Public Uplink, for all protocols, for the source IP range matching the ESG subnet (e.g., 10.123.171.128/26), and with a translated IP address matching the public IP address for the ESG (use the same address as the existing NAT rule). Ensure that the rule is enabled.
    3. Click to Publish Changes
  8. Deploy and configure your virtual machine
    1. IBM Cloud maintains a mirror of many popular Linux distributions, available only on the private network.
    2. Ensure that your VM is attached to the management network. Attach its adapter to the SDDC-DPortGroup-Mgmt port group.
    3. Configure the network adapter using an address from the ESG subnet. Set its default gateway to point to the ESG rather than to the IBM Cloud backend customer router (BCR). Identify the DNS server(s) for your instance by viewing one of your hosts’ TCP/IP configuration in vCenter. For example, if using RHEL:
      # ifcfg-ens192
      HWADDR=00:50:56:b0:88:39
      NAME=ens192
      GATEWAY=10.123.171.132
      DNS1=10.123.158.32
      DOMAIN=example.com
      DEVICE=ens192
      ONBOOT=yes
      USERCTL=no
      BOOTPROTO=static
      NETMASK=255.255.255.192
      IPADDR=10.123.171.133
      NETWORK=10.123.171.128
      BROADCAST=10.123.171.191
    4. Configure the adapter’s static routes to point to the BCR (i.e., the subnet gateway address) for all private network addresses. Note that IBM Cloud uses both subnets 10.0.0.0/8 and 161.26.0.0/16 for internal traffic. For example, if using RHEL:
      # route-ens192
      10.0.0.0/8 via 10.123.171.129 dev ens192
      161.26.0.0/16 via 10.123.171.129 dev ens192
    5. Configure NTP to point to time.service.networklayer.com

The result is that we can access both the private and public networks from our VM:

[root@localhost ~]# ### Ping vCenter
[root@localhost ~]# ping -c 1 10.123.170.130 | fgrep transmitted
1 packets transmitted, 1 received, 0% packet loss, time 0ms
[root@localhost ~]# ### Ping Google DNS
[root@localhost ~]# ping -c 1 8.8.8.8 | fgrep transmitted
1 packets transmitted, 1 received, 0% packet loss, time 0ms

Difficulty

Mark Horne writes of strength training:

The rule seems to be that your body adapts so that the most difficult thing you do eventually feels hard to do. As you age this process accelerates. When you give up an activity because it feels hard another one starts to feel hard to do. As your body loses strength you start to avoid tasks and chores that were once easier. You accumulate weakness. In the words of Seneca, “Soft living imposes on us the penalty of debility; we cease to be able to do the things we have long been grudging about doing.”

But this is true not only of your body but also your mind and will and spirit: the hardest thing you do feels hard. This leads us to several helpful insights:

First, it helps us sympathize with others who are experiencing difficulty. It is tempting to despise others who have greater difficulty with smaller challenges compared to yourself. However, this principle allows you to sympathize, since you know that difficulty is relative rather than absolute.

Second, this teaches us that contentment, peace, and joy are not primarily related to our circumstances but to our philosophy and outlook on life. Excluding obvious exceptions such as injustice and extreme hardship, this principle reveals that if you are complaining or anxious in one difficulty, you will still be complaining or anxious in other and even lighter difficulties. Therefore, your work to cultivate contentment, peace, and joy cannot wait; you must find deep roots unrelated to your circumstances. And even in cases of injustice and extreme hardship, this reveals that there is a possible path to contentment, peace, and joy even while you wait on, plead for, and pray for relief.

Third, this also indicates a way to grow in our capacity for work and difficulty. It is helpful simply to recognize that difficulty is relative, since you can cultivate gratitude that you are not experiencing greater difficulty. But this also gives you a tool to expand your capacity: you can periodically subject yourself to greater or artificial difficulty, combined with periods of rest and recovery, in order for your current difficulties to become lighter. In the physical sphere, you increase your capacity with sprint exercises, intervals, and progressive loading. Furthermore, growth in self-discipline and capacity in one sphere of life tends to have a side effect benefit across all of life. It is strangely easier to wake up early and to eat well if you are working hard at strength training; there is a kind of snowball effect to growing in health and strength and capacity.

Finally, all this applies not only to yourself but also to how you can lead others to grow in joy and capacity. As Edwin Friedman writes, “increasing one’s pain threshold for others helps them mature.”

Crossposted to I gotta have my orange juice.

Spectrum Protect Plus on IBM Cloud

Spectrum Protect Plus on IBM Cloud

IBM Cloud for VMware Solutions recently made available IBM Spectrum Protect Plus as part of our family of VMware offerings. Spectrum Protect Plus provides powerful and easy to use backup and restore capabilities for your VMware infrastructure and workload. It is now the default backup offering for VMware on IBM Cloud, complementing our existing offering of Veeam Backup & Replication.

At the same time, the IBM Cloud architecture team just published our Spectrum Protect Plus on IBM Cloud reference architecture. Read it and the associated references for information on how we have deployed Spectrum Protect Plus, how you should plan and size your deployment, and how to manage it.

VMware on IBM Cloud architecture updates

VMware on IBM Cloud architecture updates

Recently the IBM Cloud for VMware architecture team posted two new networking related architecture documents related to VMware on the IBM Cloud:

FortiGate Virtual Appliance: IBM Cloud for VMware offers the FortiGate–VM virtual appliance to complement our existing physical FortiGate Security Appliance offering. The physical offering is limited to providing edge services for your VMware workload, while the virtual offering allows you to provide security services across all of your VMware networks.

F5 BIG–IP: IBM Cloud for VMware offers F5 BIG–IP virtual edition, providing load balancing, traffic management, and security services for your applications.

 

Updates to VMware HCX on IBM Cloud

Updates to VMware HCX on IBM Cloud

IBM Cloud announced plans to offer VMware HCX included with our IBM Cloud for VMware offerings: Helping simplify cloud migration with updates to VMware HCX on IBM Cloud.

VMware is unifying their networking strategy around the Virtual Cloud Network, and as part of this, HCX (Hybrid Cloud Extension) will now be named NSX Hybrid Connect: VMware Advances Networking for the Digital Era with the Virtual Cloud Network.

Test drive IBM Cloud for VMware Solutions

A full–fledged VMware virtualization environment is powerful but not cheap. So getting a first–hand picture of the IBM Cloud for VMware Solutions experience, as simple and streamlined as it is, hasn’t been easy until now.

Recently, IBM’s Digital Technical Engagement team addressed this by building a guided demo. Their tutorial allows you to experience VMware on the IBM Cloud without having to purchase a VMware instance.

Try the VMware on IBM Cloud demo now!

Encryption at rest for VMware on IBM Cloud

Encryption at rest for VMware on IBM Cloud

One of the key topics we covered as part of our Fast Start education was encryption at rest for VMware on the IBM Cloud. There are many options for encrypting your workloads at rest, including:

  • VMware vSAN encryption
  • VMware vSphere encryption
  • HyTrust Data Control, part of IBM Cloud Secure Virtualization
  • Any other existing encryption solution you wish to bring to IBM Cloud

The first three offerings are available today directly from IBM Cloud for VMware Solutions, although some assembly is required in each case. There are important tradeoffs between these options that you need to take into consideration, such as ease of use, interoperability with other solutions like workload migration tooling, and the nature of what is encrypted. The following table that I shared at Fast Start summarizes the differences between these solutions:

Comparison vSAN encryption vSphere encryption HyTrust Data Control
Encryption type Datastore disks encrypted @ hypervisor

Secures: disk drives

VM disks encrypted @ hypervisor

Secures: VMDK files, disk traffic en route to datastore

Agent-based encryption of disks within VM

Secures: VMDK files, disk traffic en route to datastore

Key management External KMS must be provided (not included) supporting KMIP 1.1 (e.g., IBM KMIP for VMware, IBM SKLM, or HyTrust Key Control) External KMS must be provided (not included) supporting KMIP 1.1 (e.g., IBM KMIP for VMware, IBM SKLM, or HyTrust Key Control) HyTrust Key Control (included)
Additional capabilities Together with HyTrust Cloud Control, provides advanced access control, auditing, approval, and compliance capabilities; and enables Boundary Control for geofencing and hardware trust
Cost
  • vSAN Enterprise is required (per socket)
  • Key management server
Key management server
  • HyTrust Data Control (per socket)
  • HyTrust Cloud Control (optional, per socket)
Limitations
  • Not compatible with other storage types (e.g., IBM Cloud Endurance storage, NetApp ONTAP Select)
  • Does not encrypt storage traffic in flight between hosts
Eliminates benefit of vSAN deduplication and compression Eliminates benefit of vSAN deduplication and compression
Migration Compatible with all migration technologies
  • Compatible with Veeam
  • Compatible with VMware SRM when using array based replication
  • Not currently compatible with VMware HCX
  • Not currently compatible with Zerto
  • Not currently compatible with vSphere replication
  • Not currently compatible with cross-vCenter vMotion
Compatible with all migration technologies provided that HyTrust key management server availability and host compliance (if applicable) are maintained across sites. Some extra recovery steps are required post migration if the workload IP addressing has changed.