Tag: Nutanix

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