VWannabe

Blog

  • 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

  • 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

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

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

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

  • CCNA DevNet Study Guide – Part 1

    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

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

    Screenshot 2019-06-19 11.28.47

    5. Click the Add User or Group button to add the service account.

  • Vembu now supports Hyper-V Cluster

    Logo_01

    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

    high-availability-with-v4.0

    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/#

  • vCenter 6.7 upgrade walkthrough

    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.

    vCSA-768x528

     

     

  • Vembu

    Vembu

    Logo_01

    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:

    Download the following Whitepapers for Free: