diff --git a/modules/installation-user-infra-machines-advanced.adoc b/modules/installation-user-infra-machines-advanced.adoc
index f23a2837be94..337191333b12 100644
--- a/modules/installation-user-infra-machines-advanced.adoc
+++ b/modules/installation-user-infra-machines-advanced.adoc
@@ -62,7 +62,7 @@ intervene to override the default partitioning when installing an
 * Creating separate partitions: For greenfield installations on an empty
 disk, you may want to add separate storage to a partition. This is only
 officially supported for making `/var` or a subdirectory of `/var` a separate
-partition (not both). If you create more than one partitoin, Kubernetes
+partition (not both). If you create more than one partition, Kubernetes
 will not be able to monitor them both.
 
 * Retaining existing partitions: For a brownfield installation, where you
@@ -72,7 +72,7 @@ starting the installation, there are both boot arguments and options to
 `coreos-installer` that let you retain existing data partitions.
 
 [id="installation-user-infra-machines-advanced_vardisk_{context}"]
-=== Creating a separate /var partition
+=== Creating a separate `/var` partition
 In general, disk partitioning for {product-title} should be left to the
 installer. However, there are cases where you might want to create a
 separate partition in a part of the filesystem that you expect to grow.
@@ -83,11 +83,11 @@ For example:
 
 * `/var/lib/containers`: Holds container-related content that can grow
 as more images and containers are added to a system.
-* `/var/log`: Holds logging data that you might want to keep separate for
-auditing purposes later.
+* `/var`: Holds data that you might want to keep separate for purposes such as
+auditing.
 
-Storing the contents of a `/var` directory separately lets you more easily
-grow storage to those areas as needed and possibly reinstall {product-title}
+Storing the contents of a `/var` directory separately allows you to more easily
+grow storage to those areas as needed, and to reinstall {product-title}
 at a later date and keep that data intact. In other words, you would not have
 to pull all your containers again or copy off massive log files when you
 update your systems.
@@ -122,9 +122,9 @@ $ ls $HOME/clusterconfig/openshift/
 ----
 
 . Create a MachineConfig and add it to a file in the `openshift` directory.
-For example, name the file `98-var-log-partition.yaml`,
-changing the device name to the name of the storage device on the `worker` systems
-and set storage size as appropriate. It will attach storage to a separate `/var/log`
+For example, name the file `98-var-partition.yaml`,
+change the device name to the name of the storage device on the `worker` systems,
+and set the storage size as appropriate. This attaches storage to a separate `/var`
 directory.
 
 +
@@ -135,36 +135,38 @@ kind: MachineConfig
 metadata:
   labels:
     machineconfiguration.openshift.io/role: worker
-  name: 98-var-log-partition
+  name: 98-var-partition
 spec:
   config:
     ignition:
       version: 3.1.0
     storage:
       disks:
-      - device: /dev/nvme0n1
-        wipeTable: false
+      - device: /dev/<device_name> <1>
         partitions:
-        - sizeMiB: 47000
-          startMiB: 47000
-          label: var-log
+        - sizeMiB: <partition_size>
+          startMiB: <partition_start_offset> <2>
+          label: var
       filesystems:
-        - path: /var/log
-          device: /dev/disk/by-partlabel/var-log
+        - path: /var
+          device: /dev/disk/by-partlabel/var
           format: xfs
     systemd:
       units:
-        - name: var-log.mount
+        - name: var.mount
           enabled: true
           contents: |
             [Unit]
             Before=local-fs.target
             [Mount]
-            Where=/var/log
-            What=/dev/disk/by-partlabel/var-log
+            Where=/var
+            What=/dev/disk/by-partlabel/var
             [Install]
             WantedBy=local-fs.target
 ----
++
+<1> The storage device name of the disk that you want to partition.
+<2> When adding a data partition to the boot disk, a minimum value of 25000 mebibytes is recommended. The root filesystem is automatically resized to fill all available space up to the specified offset. If no value is specified, or if the specified value is smaller than the recommended minimum, the resulting root filesystem will be too small, and future reinstalls of {op-system} might overwrite the beginning of the data partition.
 
 . Run `openshift-install` again to create Ignition configs from a set of files in the `manifest` and
 `openshift` subdirectories:
@@ -176,17 +178,17 @@ $ ls $HOME/clusterconfig/
 auth  bootstrap.ign  master.ign  metadata.json  worker.ign
 ----
 
-At this point, you can use the Ignition config files as input to the ISO or PXE bare
+Now you can use the Ignition config files as input to the ISO or PXE bare
 metal installation procedures to install {op-system-first} systems.
 
 [id="installation-user-infra-machines-advanced_retaindisk_{context}"]
 === Retaining existing partitions
 For an ISO installation, you can add options to the `coreos-installer`
 that causes the installer to maintain one or more existing partitions.
-For a PXE installation, you can APPEND coreos.inst options to preserve partitions.
+For a PXE installation, you can APPEND `coreos.inst` options to preserve partitions.
 
 Saved partitions might be partitions from an existing {product-title}
-system that has data partitions that you want to keep or partitions
+system that has data partitions that you want to keep, or partitions
 that you just manually created. Here are a few tips:
 
 * Make sure you assign at least the recommended amount of disk space to the
@@ -197,7 +199,7 @@ number or label.
 
 For an ISO installation:
 
-The following example illustrates running the coreos-installer in a way that preserves
+The following example illustrates running `coreos-installer` in a way that preserves
 the sixth (6) partition on the disk:
 
 [source,terminal]