VWannabe

Category: Nutanix

  • Migrating Virtualized Workloads to Nutanix AHV: A Phased Approach That Works in Production

    Migrating Virtualized Workloads to Nutanix AHV: A Phased Approach That Works in Production


    Every VMware to Nutanix AHV migration project comes with the same fundamental tension: you want to move workloads to a better platform without disrupting the people who depend on those workloads every day. The good news is that Nutanix Move, when paired with a well defined phased methodology, handles that tension well. This post walks through how we approach these engagements at ePlus, covering the migration mechanics, database specific considerations, and the operational steps that close out each phase cleanly.

    How Nutanix Move Works


    Nutanix Move is a cross hypervisor mobility tool that automates VM migrations from VMware ESXi, Hyper-V, or public cloud sources to Nutanix AHV. The core model is straightforward: Seed, Sync, Cutover.

    1. Discovery: Connect Move to the source environment (vCenter, standalone ESXi, or Hyper-V) and the target Nutanix cluster. Move inventories the VMs and validates compatibility before anything touches production data.
    2. Data Seeding: Move creates a placeholder VM on the AHV side and begins copying virtual disks from the source. This initial seed runs in the background while the source VM stays live.
    3. Changed Block Tracking (CBT): After the initial copy, Move uses CBT to replicate only blocks that have changed since the last sync. This keeps the replication delta small and the eventual cutover window short.

    Why Daytime Replication Is Safe

    A common concern when planning migrations is whether running replication during business hours will hurt production performance. In practice, it does not, and here is why.

    Non Disruptive Snapshots
    Move uses native snapshot mechanisms (VMware CBT, for example) to read source data. The VM stays powered on and users experience no interruption.    		Network Throttling
    Move supports bandwidth throttling on migration traffic so replication does not compete with production traffic on shared links during peak hours.
    Background Operation
    The seeding phase is a background task. End users are fully isolated from the process because their application is still running on the source hypervisor.    		Incremental Efficiency
    After the initial seed, subsequent syncs only move changed blocks, so the bandwidth consumption of ongoing replication is a fraction of the initial transfer.

    The Cutover Process

    The cutover is the only step that involves any downtime, and even that window is typically measured in minutes per VM. The sequence is deterministic and should be documented in the project plan before any work begins.

    1. Final Sync: Move performs one last incremental sync to capture the most recent changed blocks.
    2. Graceful Shutdown: The source VM is powered off cleanly, not forcefully terminated.
    3. Final Delta: A final incremental pass captures any blocks written during the shutdown sequence.
    4. Activation: Move installs the required VirtIO drivers for AHV, optionally reconfigures IP addressing, and powers the VM on within the Nutanix cluster.

    Practical Note
    For most general purpose VMs, the combined downtime from final sync through power on on AHV is under five minutes. Database VMs with large in flight transactions may take slightly longer depending on the final delta size.

    Rollback Strategy

    One of the most important things to communicate to stakeholders before a cutover is that rollback is not a complex recovery procedure. It is simply reversing a power state.

    Because Move does not delete or modify the source VM during cutover (it only powers it off and disconnects its network interface), the path back to the original state requires no data restoration. If a migrated VM does not perform as expected on AHV, the steps are:

    1. Power off the VM on the Nutanix AHV side.
    2. Reconnect the network interface on the source VM.
    3. Power on the source VM in the original environment.

    The source disks remain completely untouched throughout the process, so this rollback takes seconds rather than hours. It also means stakeholder sign off on a cutover carries much lower risk than it would in a traditional migration approach.

    Special Migration Scenarios

    Not every VM is a candidate for a straightforward Move migration. A few categories require a different approach:

    • Legacy Operating Systems: Windows Server 2003 and older Linux kernels with unsupported kernel versions are explicitly unsupported by modern versions of Nutanix Move and the standard AHV VirtIO driver set. These workloads cannot use the standard Move migration path and require an alternative approach such as a cold clone, a bare metal backup restoration, or an application level migration to a newly provisioned VM.
    • Physical Hardware Pass through: VMs with PCI pass through devices or Raw Device Mappings (RDMs) require manual reconfiguration on the target side.
    • Shared Disk Clustering: Certain older Oracle RAC or MSCS configurations that rely on shared SCSI bus emulation need architectural review before migration.

    For these cases, the alternatives range from a manual cold clone, to an application level migration, to a fresh OS installation with data restoration from backup. The right path depends on the workload, and that decision should be made during technical discovery before the project schedule is finalized.

    Database Migration Methodology

    Databases deserve a separate treatment because the consequences of a failed migration, or even a migration that succeeds but lands on a poorly configured target, are higher than for stateless application servers. We cover both Microsoft SQL Server and Oracle here.

    Storage Architecture for Database VMs

    Nutanix gives database workloads two primary storage paths: native vDisks and Nutanix Volume Groups.

    • Native vDisks are the default for AHV VMs and are simple to manage through Prism. Starting with AOS 6.x, the Autonomous Extent Store (AES) improved local sharding for native vDisks, so they are no longer as constrained as they were in earlier releases. That said, a single CVM still serves as the primary I/O path for a given vDisk, which means very high throughput workloads can reach a performance ceiling at the CVM level.
    • Nutanix Volume Groups (VG) are collections of vDisks presented as block devices. For AHV, VGs can be direct attached, appearing as native SCSI devices to the guest OS. When Volume Group Load Balancing (VGLB) is enabled, the system shards vDisks across all CVMs, removing the single CVM I/O path and allowing the database to draw on the aggregate throughput of the entire cluster’s Stargate processes.

    iSER Support: For the highest performance requirements, Nutanix supports iSER (iSCSI Extensions for RDMA), which bypasses the TCP/IP stack entirely to reduce latency and CPU overhead between the guest and the CVM. This is worth evaluating for latency sensitive OLTP workloads.

    AHV Specific Tuning for Databases

    Several AHV configuration decisions have a direct and measurable impact on database performance.

    • vCPU to pCPU Ratio: For production databases, size assuming 1 vCPU equals 1 physical core, not one hyperthreaded thread. Oversubscription introduces CPU Ready Time, which is particularly harmful to latency sensitive query workloads. Target below 5% CPU Ready.
    • Memory Reservations: Reserve 100% of assigned VM memory for SQL Server and Oracle VMs. AHV memory reclamation through ballooning or swapping can cause significant and hard to diagnose latency spikes in database workloads.
    • Huge Pages: AHV uses 2 MB Huge Pages to reduce Translation Lookaside Buffer (TLB) pressure. Ensure the guest OS is configured to use large page allocations to take advantage of this.
    • vNUMA: For VMs larger than a single physical socket, enable vNUMA and match the virtual topology to the physical hardware. This allows the database engine to schedule threads and memory access with NUMA awareness. Disable CPU hot add, as enabling it disables vNUMA and can cause performance degradation of up to 30%.

    AOS Features That Matter for Databases

    Data Locality
    AOS stores a VM’s data on the same physical node where the VM runs. Read I/O is served locally without network traversal, which reduces database read latency materially.    		AHV Turbo (Frodo I/O Path)
    Bypasses traditional QEMU emulation with a multi-queue I/O path that scales with the number of vCPUs, delivering higher I/O capacity and lower CPU overhead for storage intensive workloads.
    Nutanix Blockstore
    A block management system that moves device interactions into user space, eliminating context switching and kernel driver overhead for data disks.    		VGLB for OLAP
    Volume Group Load Balancing distributes I/O across all CVMs in the cluster. Critical for high throughput OLAP and reporting workloads that can saturate a single CVM.

    Microsoft SQL Server Migration Options

    There are three viable paths for SQL Server migrations, and the right choice depends on the deployment type and the acceptable downtime window.

    • Nutanix Move: The simplest path for standalone instances. Move handles disk conversion to AHV RAW format, VirtIO driver injection, and IP configuration. Best suited for standalone instances where a brief cutover window is acceptable.
    • Always On Availability Groups: Build a new SQL VM on AHV, join it to the existing Windows Server Failover Cluster (WSFC), and add it as a new secondary AG replica. Once synchronized, perform a planned manual failover to promote the Nutanix based node, then decommission the old nodes. This approach reduces cutover risk for business critical SQL workloads and can achieve near zero application downtime.
    • Backup and Restore: Take a full backup of the source database, restore it on a pre staged SQL VM on AHV using WITH NORECOVERY, and during the cutover window take a tail log backup, restore it with WITH RECOVERY, and redirect applications to the new instance.

    Oracle Migration Options

    • Nutanix Move: Recommended for migrating the Oracle VM as is from vSphere to AHV when the VM itself is in Move’s compatibility matrix. Move handles VirtIO driver injection automatically.
    • RMAN Active Duplication: Use Oracle Recovery Manager to perform an active duplication from the source to a new Oracle VM on AHV. The source database remains online until the final switchover, minimizing the downtime window.
    • Data Guard: Set up a physical standby on the Nutanix cluster, synchronize it via RMAN, and then perform a Data Guard switchover to promote the Nutanix instance to primary. This is the lowest risk option for Oracle databases with strict RPO/RTO requirements.
    • Oracle RAC with Nutanix Volumes: For RAC deployments, Nutanix Volumes provide the shared block storage required by clusterware. Volume Groups should be attached via iSCSI and configured with SCSI-3 Persistent Reservations.

    SQL Server Best Practices on AHV

    These configurations should be treated as baseline for any production SQL Server on Nutanix, whether migrated or newly deployed.

    Storage Layout

    • Use at least four vDisks to distribute data files, log files, TempDB, and the OS independently.
    • Format all data and log volumes with a 64 KB NTFS allocation unit size.
    • Do not use Windows Dynamic Disks or in guest volume managers. Add vDisks directly to the VM instead.
    • Keep OS, SQL binaries, user database data, logs, and TempDB on separate volumes.

    Instance Level Tuning

    • Instant File Initialization (IFI): Grant the SQL Server service account the “Perform Volume Maintenance Tasks” privilege to enable IFI. This eliminates zero initialization overhead during data file creation and auto growth events. IFI applies only to data files (.mdf and .ndf). Log files (.ldf) are always zero initialized regardless of this setting. Starting with SQL Server 2016, IFI can also be enabled directly from the installation wizard.
    • Lock Pages in Memory (LPIM): Enable LPIM to prevent Windows from paging the SQL Server buffer pool to disk. Max Server Memory must be set correctly before enabling LPIM to avoid starving the guest OS.
    • Max Server Memory: For mid to large VMs, leave 6 to 8 GB for the OS. For VMs under 32 GB of RAM, 4 GB is often sufficient. A practical formula: reserve 10% of total RAM for the OS, with a ceiling of around 8 GB unless SSIS or SSRS also run on the same instance.
    • MAXDOP: Set MAXDOP to the number of logical cores within a single vNUMA node. For SQL Server 2016 and later, the updated guidance is to use either 8 or the number of cores per NUMA node, whichever is smaller.
    • Cost Threshold for Parallelism (CTFP): Increase from the default of 5 to at least 50. OLTP workloads land at 50. Hybrid environments sometimes use a value in the 25 to 50 range.
    • TempDB: Match the number of data files to the logical processor count when that count is 8 or fewer. Start at 8 data files when the logical processor count exceeds 8. Only increase beyond 8 (in increments of 4) if PAGELATCH_UP or PAGELATCH_SH waits confirm actual contention.

    SQL Server Baseline Configuration Summary

    SettingRecommended BaselineReason
    IFIEnabledEliminates zero initialization overhead for data files during creation and auto growth.
    LPIMEnabledPrevents Windows from reclaiming the SQL Server buffer pool. Requires Max Server Memory to be set first.
    Max Server MemoryTotal RAM minus 4 to 8 GB (or 10% of total RAM)Prevents SQL Server from starving the guest OS.
    MAXDOP8 or cores per NUMA node, whichever is smallerKeeps parallel query execution within a single NUMA domain.
    CTFP50 (or 25 to 50 for hybrid workloads)Prevents low cost queries from triggering parallelism on modern multi core hardware.
    TempDBMatch logical processor count up to 8; increase by 4 only when contention is confirmedReduces allocation contention. All files must be equally sized with identical growth settings.

    Oracle Best Practices on AHV

    Oracle on Nutanix AHV benefits from the same platform level advantages as any other workload, but the database engine has enough specific tuning requirements that it warrants its own treatment.

    Memory Allocation: SGA and PGA

    Reserve approximately 10 percent of the total VM memory for the guest OS and file cache. Of the remaining 90 percent, allocate 80 percent to the System Global Area (SGA) and the remaining 20 percent to the Program Global Area (PGA). Memory reservations should be set to 100% of the assigned VM memory. Memory overcommit is not recommended for Oracle workloads.

    Storage Layout and Disk Groups

    NDB provisions multiple vDisks spread across ASM disk groups to maximize throughput across the Distributed Storage Fabric. The two primary disk groups are DATADG for database data files and RECODG for redo logs and archive files. For Oracle RAC, a third disk group CRSDG is required for Grid Infrastructure and clusterware files.

    Disk GroupSmall or Medium (500 GB and under)Large (501 GB and above)
    CRSDG (RAC only)3 vDisks3 vDisks
    DATADG4 vDisks8 vDisks
    RECODG2 vDisks4 vDisks

    ASM Configuration Options

    Nutanix supports ASMFD (ASM Filter Driver), ASMLIB, and udev rules for ASM disk mappings. ASMFD is the preferred method on modern Linux distributions. All ASM disks should be placed on vDisks in an AOS storage container with inline compression enabled and deduplication disabled.

    Network Design for Oracle RAC

    Oracle RAC requires a public network for client connections and a private interconnect for cache fusion on separate VLANs. Mixing them on the same VLAN introduces the risk of cache fusion traffic competing with client traffic. When using NDB to provision Oracle RAC, NDB manages IP address assignment across public, private, and virtual (scan and VIP) network types.

    RAC and Nutanix Volumes: Oracle RAC requires shared storage for the CRSDG disk group. On AHV, this is provided through Nutanix Volume Groups attached via iSCSI with SCSI-3 Persistent Reservations enabled. This is a prerequisite for RAC clusterware to function correctly.

    Oracle Patching with NDB

    NDB uses an out of place patching model for Oracle. Rather than patching a running Oracle home directly, the process involves provisioning a new database VM from an existing software profile, manually applying the patch set to that VM, and then creating a new software profile version from the patched VM. Once published, that version becomes available to all Oracle VMs managed by NDB. Patching can be performed in either a rolling or non rolling fashion for Oracle RAC environments.

    Time Machine Backup and Recovery for Oracle

    NDB Time Machine creates application consistent snapshots of Oracle databases along with copies of transaction log files. An SLA attached to the time machine controls snapshot frequency and retention. Point in time recovery is available as long as both a base snapshot and the covering transaction logs exist for the target timestamp. NDB restores the vDisks from the appropriate snapshot and then applies log files forward to bring the database to a consistent state.

    Decommissioning Protocol

    The migration is not complete when the VM powers on successfully on AHV. A structured decommissioning process ensures the legacy environment is cleaned up safely.

    StepActionOwner
    1Source VMs remain powered off with NIC disconnected for a 48 to 72 hour burn in period to prevent IP conflicts.Infrastructure Team
    2Confirm with Application Owners that performance and stability on AHV is acceptable after the burn in period.Project Lead
    3Archive a final backup of the source VM according to the organization’s retention policy before deletion.Backup Admin
    4Remove the VM from the source cluster inventory.Infrastructure Team
    5Update the CMDB or asset tracker to reflect the VM’s new hypervisor and decommission the legacy record.IT Operations

    Technical Discovery Requirements

    The quality of the discovery work done before migration determines how smooth everything else goes. At a minimum, the following information should be gathered before any migration plan is finalized.

    General Infrastructure

    • Specific vSphere version and ESXi build number in use on source hosts
    • Networking configuration: LACP, Jumbo Frames (MTU 9000), or standard configuration
    • IP retention requirement: retain existing IPs after migration or assign new IPs on AHV
    • Guest OS list with versions and BIOS/UEFI boot mode for each VM in scope

    SQL Server Environments

    • SQL Server versions and editions (Standard vs. Enterprise) deployed
    • Deployment type: Standalone, Failover Cluster Instance (FCI), or Always On AG
    • Current vCPU to physical core allocation and whether LPIM is already configured
    • vDisk layout per VM: number of disks, purpose (Data, Log, TempDB), and whether any single large data files exist that should be split
    • Dependencies on MSDTC, Linked Servers, or SQL Agent Jobs that require documentation before cutover

    Oracle Environments

    • Oracle versions in scope and whether instances are Single Instance or RAC
    • Shared storage configuration for RAC: ASM with ASMLib, ASMFD, or udev rules
    • Huge Pages configuration status in the guest OS
    • Existing RMAN backup workflows or Data Guard standbys that can be leveraged
    • Source platform architecture: if any workloads currently run on AIX or Solaris (SPARC), be aware that Nutanix Move is strictly an x86-to-x86 tool and cannot be used for these migrations. AIX and Solaris on SPARC are Big-Endian, while Nutanix AHV runs exclusively on x86-64 (Little-Endian). Cross-endian migrations require a fully manual path using RMAN CONVERT for Oracle or an application level export and restore, and should be scoped separately from the rest of the Move migration plan.

    Migration Constraints

    • Maximum acceptable maintenance window for final cutover
    • Average daily change rate for production databases (drives seeding bandwidth planning)
    • Top 10 application functions or queries to validate Day 1 performance after migration
    • Total allocated versus used storage per database environment, plus expected annual growth
  • Insights from a Nutanix Migration Specialist

    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!”

  • 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.