[{"content":"1. Background: Service Startup Failures After Windows Password Rotation In enterprise and public cloud infrastructure environments, security compliance standards (such as vulnerability audits or periodic password rotation policies) require updating the Windows Server local Administrator password or migrating to dedicated administrative accounts.\nHowever, immediately following a password change on a Windows host running Veeam Backup \u0026amp; Replication (VBR), administrators frequently encounter critical operational disruptions:\nThe Veeam Backup \u0026amp; Replication Console fails to launch, hanging or rejecting logon requests. Windows Event Viewer logs Event ID 7000 / 7038 (The service did not start due to a logon failure). Attempting to start the services manually via services.msc returns Error 1069. [Windows Service Error] Error 1069: The service did not start due to a logon failure. This occurs because Veeam core components—such as the backup engine, catalog service, and broker—are configured during initial setup to run under the context of the administrative user. When the account password is changed in Windows without updating the service properties, all dependent Veeam services fail to authenticate and halt immediately.\n2. Preliminary Check: Impacted Veeam Services A standard Veeam Backup \u0026amp; Replication installation registers more than ten background services. The key services requiring updated logon credentials include:\nService Name Display Name Purpose VeeamBackupSvc Veeam Backup Service Core engine orchestrating backup, replication, and scheduling VeeamBrokerSvc Veeam Broker Service Communication broker and infrastructure configuration cache VeeamCatalogSvc Veeam Guest Catalog Service Guest OS file indexation and search service VeeamCloudSvc Veeam Cloud Connect Service Cloud repository and tenant management service VeeamEnterpriseManagerSvc Veeam Backup Enterprise Manager Web management interface and centralized reporting VeeamRESTSvc Veeam Backup Server RESTful API Service REST API endpoint for automation workflows [Figure 1] Veeam services list and context menu in Windows Services Manager (services.msc)\n3. Step-by-Step Remediation Procedure Step 1. Close Open Veeam Console Instances Ensure all active instances of Veeam.Backup.Shell.exe are closed to prevent session locks.\nStep 2. Open Windows Services Manager Press Win + R, enter services.msc, and run it with administrative privileges.\nStep 3. Access Veeam Service Properties Locate the Veeam services, right-click each target service, and select Properties.\nStep 4. Update Credentials on the Log On Tab Switch to the Log On tab. Under This account, verify the target user (e.g., .\\veeam-admin or DOMAIN\\Account). Enter the new Password and confirm it in Confirm password. Click Apply. A system pop-up will confirm: \u0026ldquo;The account has been granted the Log On As A Service right.\u0026rdquo; Click OK to commit the settings. [Figure 2] Updating credentials under the Log On tab in Service Properties\n[Field Note: Browsing for Users]\nIf changing the account name or selecting a domain object, use the Browse... button to select the target location and click Check Names before saving.\n[Figure 3] Specifying the service account in the Windows Select User dialog\nStep 5. Batch Update All Dependent Veeam Services Repeat Steps 3 and 4 across all Veeam services configured with domain or local user logon accounts.\nNote: Default Windows services running under Local System or Network Service do not require credential updates.\nStep 6. Start and Validate Services Right-click the updated services and select Start. Verify that all Veeam services show a Running status without error. [Figure 4] All Veeam services running normally following credential updates\n4. Final Verification: Console Access and Job Status Once all background services are active:\nLaunch Veeam Backup \u0026amp; Replication Console from the start menu or desktop. Sign in using the updated credentials. Check the status bar at the bottom to verify the connected session (Logged in: .\\veeam-admin). Confirm that the Backup Jobs inventory and infrastructure repositories populate correctly. [Figure 5] Successful console login and healthy backup job list\n5. Engineering Best Practices Dedicated Service Accounts (gMSA / Non-Expiring Svc Account):\nUsing a personal administrator account for background service execution creates an unnecessary point of failure during password expiration cycles. Configure a dedicated, non-interactive service account or gMSA where supported.\nSchedule Password Changes During Maintenance Windows:\nNever modify service account credentials while active backup or replication jobs are running, as interrupted data streams can leave lock files on backup repositories. Always execute credential updates during designated maintenance windows.\n","permalink":"https://cknotes.kr/en/posts/veeam-windows-password-change-service-logon-fix/","summary":"\u003ch2 id=\"1-background-service-startup-failures-after-windows-password-rotation\"\u003e1. Background: Service Startup Failures After Windows Password Rotation\u003c/h2\u003e\n\u003cp\u003eIn enterprise and public cloud infrastructure environments, security compliance standards (such as vulnerability audits or periodic password rotation policies) require updating the Windows Server local \u003ccode\u003eAdministrator\u003c/code\u003e password or migrating to dedicated administrative accounts.\u003c/p\u003e\n\u003cp\u003eHowever, immediately following a password change on a Windows host running \u003cstrong\u003eVeeam Backup \u0026amp; Replication (VBR)\u003c/strong\u003e, administrators frequently encounter critical operational disruptions:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe \u003cstrong\u003eVeeam Backup \u0026amp; Replication Console\u003c/strong\u003e fails to launch, hanging or rejecting logon requests.\u003c/li\u003e\n\u003cli\u003eWindows Event Viewer logs \u003cstrong\u003eEvent ID 7000 / 7038 (The service did not start due to a logon failure)\u003c/strong\u003e.\u003c/li\u003e\n\u003cli\u003eAttempting to start the services manually via \u003ccode\u003eservices.msc\u003c/code\u003e returns \u003cstrong\u003eError 1069\u003c/strong\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e[Windows Service Error]\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eError 1069: The service did not start due to a logon failure.\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eThis occurs because Veeam core components—such as the backup engine, catalog service, and broker—are configured during initial setup to run under the context of the administrative user. When the account password is changed in Windows without updating the service properties, all dependent Veeam services fail to authenticate and halt immediately.\u003c/p\u003e","title":"[Veeam] Updating Service Logon Credentials after Windows Server Password Change"},{"content":"Following the deployment of KVM-based HPE VM Essentials (VME) and HPE SimpliVity HCI, integrating Veeam Backup \u0026amp; Replication for image-level backups and disaster recovery verification drills is a critical operational procedure to ensure enterprise service continuity.\nHowever, when performing full image restores for multi-disk virtual machines (VMs with two or more virtual disks, such as separate OS and data volumes), administrators may encounter an unexpected restore blockage caused by disk index collisions.\nThis article details the root cause of the Veeam VirtIO disk matching failure in HPE VME and demonstrates how to unlock the hidden Cloud Advanced Options in VME Manager to reassign unique VirtIO bus indexes.\n1. Symptoms \u0026amp; Veeam Restore Session Error Log During a scheduled restore verification drill of a multi-disk VM backed up from HPE VME, the Veeam Full VM Restore workflow stalled and returned the following infrastructure API error:\nIn the Morpheus external infrastructure API response, the affected VM (vm-name) has two Virtio disks (id 11 and id 15) but both disks are reported with the same index value (index=0) and no diskLabel is provided. This makes disk identification ambiguous and may cause the restore workflow to fail disk-to-disk matching, resulting in the error: “Failed to match the original disk 15 to any disk of the restored VM.” Analysis of the Failure Morpheus-Driven API Layer: HPE VME Manager utilizes the Morpheus orchestration engine beneath its cloud management API layer. Duplicate Disk Indexing (index=0): The API reported both attached VirtIO disks (id 11 and id 15) with the identical index value 0 and without distinct disk labels. Ambiguous Disk Matching: Because Veeam\u0026rsquo;s restore engine requires deterministic 1:1 disk mapping between source backup definitions and target VM volumes, the duplicate index rendered disk 15 unmatchable, aborting the restore. 2. Inspecting VME Manager: Duplicate Mount Points (VIRTIO 0:0) Navigating to the affected VM\u0026rsquo;s storage configuration within the HPE VME Manager console revealed the direct root cause:\n(Figure: Both virtual disks vda and vdb assigned the exact same MOUNT POINT: VIRTIO 0:0)\nDisk 0 (vda): Storage Controller VirtIO Block / Mount Point VIRTIO 0:0 Disk 2 (vdb): Storage Controller VirtIO Block / Mount Point VIRTIO 0:0 Even though Linux recognizes the block devices sequentially at the kernel level (vda, vdb), both disks were pinned to controller index VIRTIO 0:0 at the hypervisor configuration layer. For Veeam, which relies on strict hypervisor API metadata rather than in-guest device naming, this duplicate bus position creates an unresolvable collision.\n3. The Solution: Unlocking Hidden VirtIO Bus Options in Cloud Settings When attempting to fix the issue directly via Reconfigure Server on the VM, the dropdown menu for changing the VirtIO mount point is initially greyed out or completely unavailable under default platform settings.\nTo make the VirtIO bus numbering editable, administrators must first enable disk and storage type selection policies at the parent Cloud configuration level.\nStep 1. Enable Cloud Advanced Options Navigate to the infrastructure cloud settings within the HPE VME console: Infrastructure \u0026gt; Clouds \u0026gt; Select your SimpliVity Cloud \u0026gt; Edit\nExpand the Advanced Options dropdown near the bottom of the page, check the following options, and save:\n(Figure: Enabling DISK TYPE SELECTION and STORAGE TYPE SELECTION under Cloud Advanced Options)\n[x] ENABLE DISK TYPE SELECTION [x] ENABLE STORAGE TYPE SELECTION [x] ENABLE NETWORK INTERFACE TYPE SELECTION 4. Reconfiguring the Server: Reassigning VirtIO Numbering (VIRTIO 0:1) With the cloud-level policies saved, return to the VM instance management view: Select VM \u0026gt; Actions \u0026gt; Reconfigure Server\nUnder the VOLUMES section, the controller type and mount point dropdowns are now fully exposed and interactive.\n(Figure: Selecting a distinct mount point such as VIRTIO 0:1 for the secondary disk)\nRoot OS Disk (vda): Maintain the primary mount point VIRTIO 0:0. Secondary Data Disk (vdb): Open the dropdown and select an unused, unique index such as VIRTIO 0:1. Click Reconfigure at the bottom right to apply changes. Once applied, the storage table will show vda mapped to VIRTIO 0:0 and vdb mapped to VIRTIO 0:1.\n5. Verification \u0026amp; Successful Veeam Restore With unique VirtIO bus addresses assigned, verify the operational loop:\nInitiate New Veeam Backup: The VME API correctly presents index=0 and index=1 for the respective disks in its infrastructure payload. Execute Full VM Restore: Veeam\u0026rsquo;s restore engine achieves seamless 1:1 disk matching for both volumes. The error Failed to match the original disk 15 to any disk of the restored VM is completely eliminated, and the restore finishes successfully. 6. Key Takeaways \u0026amp; Best Practices Always audit disk bus layouts on multi-disk templates:\nIn KVM/QEMU-based virtualization platforms, multi-disk instances created from certain legacy templates or quick provisioning steps can inadvertently share controller positions (0:0). Even if guest OS boots normally, third-party backup and replication tools will choke at the API layer. Explore parent cloud policies when options are missing:\nHPE VME streamlines cloud operations by concealing lower-level hardware controls by default. Whenever granular disk, NIC, or bus controller options appear locked, inspect the parent Cloud \u0026gt; Advanced Options configuration. ","permalink":"https://cknotes.kr/en/posts/vme-veeam-duplicate-virtio-disk-restore-fix/","summary":"\u003cp\u003eFollowing the deployment of KVM-based \u003cstrong\u003eHPE VM Essentials (VME) and HPE SimpliVity HCI\u003c/strong\u003e, integrating \u003cstrong\u003eVeeam Backup \u0026amp; Replication\u003c/strong\u003e for image-level backups and disaster recovery verification drills is a critical operational procedure to ensure enterprise service continuity.\u003c/p\u003e\n\u003cp\u003eHowever, when performing full image restores for \u003cstrong\u003emulti-disk virtual machines\u003c/strong\u003e (VMs with two or more virtual disks, such as separate OS and data volumes), administrators may encounter an unexpected restore blockage caused by disk index collisions.\u003c/p\u003e","title":"[HPE VME] Resolving Veeam Restore Failure: Duplicate VirtIO Disk Index (index=0)"},{"content":"In response to evolving VMware enterprise licensing models, many IT organizations are actively evaluating migration to KVM-based HPE VM Essentials (VME) and HPE SimpliVity HCI architectures, as well as establishing cross-hypervisor disaster recovery (DR) capabilities.\nWhile intra-hypervisor migrations typically rely on online continuous replication across high-speed links, operating across isolated sites with a mere 10Mbps network bandwidth makes real-time network streaming physically impractical. Migrating a multi-gigabyte virtual machine over 10Mbps would require dozens of hours.\nIn such constrained field conditions, the most dependable operational strategy is physically copying raw Veeam backup data files (.vbk) and metadata files (.vbm) to external storage, mounting them at the target datacenter, and performing an offline V2V (Virtual-to-Virtual) restore.\nThis guide details the complete production procedure of importing VMware vSphere Windows 10 backup files into a target Veeam infrastructure and restoring the VM to an HPE VME cluster in just 18 minutes, complete with automated VirtIO driver injection and verified driver cleanups.\nProduction Recovery Environment Summary Metric Source Infrastructure Target Infrastructure Hypervisor VMware vSphere (ESXi) HPE SimpliVity with HPE VME (KVM-based HVM) Backup Platform Veeam Backup \u0026amp; Replication v11 Veeam Backup \u0026amp; Replication (VME Worker Architecture) Backup Format Full Backup Data (.vbk) + Backup Metadata (.vbm) Local repository transfer followed by Import Backup Network Link Extreme 10Mbps WAN bottleneck (Physical copy mandatory) High-speed 10G/25G internal datacenter fabric Target Guest OS Windows 10 Pro (VMware Tools installed) Clean boot backed by KVM Red Hat VirtIO drivers 1. 10Mbps Bandwidth Bottleneck and Physical Backup File Relocation Constrained by a 10Mbps network link, achieving a near-zero Recovery Point Objective (RPO) via online replication is impossible due to transmission lag.\nConsequently, the operational protocol prioritized physical relocation: copying the primary full backup data file (*.vbk) along with the indispensable backup metadata file (*.vbm) directly onto high-capacity external storage, then transferring them straight to the target repository.\nTechnical Rationale: Why the Metadata File (.vbm) is Critical Copying the tiny (several KB) .vbm (Veeam Backup Metadata) file alongside the massive multi-gigabyte .vbk data file is the crucial operational technique here:\nImporting .vbk Alone: Without the metadata file, the target Veeam instance must parse and deep-scan the entire physical .vbk archive block-by-block to rebuild its catalog and disk headers, introducing substantial pre-restore delays. Importing .vbk + .vbm in Tandem: The .vbm file stores complete structural information, including VM hardware specifications, virtual disk geometries, and restore point chain definitions. Even in an isolated network completely disconnected from the original backup database, target Veeam v13 registers the backup chain instantaneously upon clicking Import Backup, enabling zero-delay restoration. 2. Veeam Restore Session: VirtIO Driver Injection Mechanics Once the imported backup chain was registered, a Full VM Restore targeting the HPE VME (SimpliVity) cluster was initiated. Below is the operational transcript recorded during the live restore session.\n(Figure: Veeam Restore session transcript detailing KVM worker allocation, disk recreation, VirtIO driver injection, and final elapsed duration)\nRecovery Time Objective (RTO) Metrics Session Start: 40:27 PM Session Finish: 58:32 PM Net Restore Duration: 18 minutes 5 seconds Had this workload been transferred over the 10Mbps link, replication would have exceeded half a day. Restoring directly from local physical media achieved full instance provisioning in under 18 minutes (RTO satisfied).\nSolving the V2V Challenge: Automated VirtIO Driver Injection Migrating from VMware ESXi to KVM-based HPE VME presents an immediate storage controller architectural mismatch:\nVMware: LSI Logic SAS or VMware Paravirtual (PVSCSI) controllers KVM (VME): High-performance VirtIO SCSI controller Powering on a converted disk without pre-loaded storage drivers triggers a catastrophic Blue Screen of Death (BSOD 0x7B: Inaccessible Boot Device).\nVeeam circumvents this hurdle by deploying a dedicated KVM worker appliance (veeam-worker01), which mounts the offline Windows virtual disk and directly injects storage and networking drivers into the registry and driver store:\nVirtIO driver injection required (0:00:50) VirtIO driver injection finished (0:06:12) In approximately 6 minutes, Red Hat KVM VirtIO storage and network drivers were fully injected into the offline system image, ensuring immediate storage recognition upon initial boot.\n3. HPE VME Manager: HVM Instance Provisioning and Power-On Following Veeam\u0026rsquo;s restore finalization, the newly instantiated workload appears within the HPE VM Essentials (VME) Manager administrative interface.\n(Figure: HVM instance automatically provisioned under veeam-custom-service-plan running normally in HPE VME console)\nInstance Status: Running Virtualization Type: HVM (Hardware-assisted Virtual Machine on KVM) Service Plan: veeam-custom-service-plan (Mapped automatically via Veeam API matching original VM hardware sizing) Lifecycle History: Provision: 17 minutes 32 seconds (Disk synthesis and conversion via Veeam worker) Startup: 2 minutes 33 seconds (Hypervisor-level instance initial power-on) Post-Provision Operations: Instantaneous completion The native integration between Veeam and VME bypassed manual VM shell configuration, translating original vCPU, vRAM, and disk specifications seamlessly into the VME cluster.\n4. Guest OS Verification: Device Manager and Clean Driver Handshake True recovery success is validated from within the guest OS by confirming device driver bindings and the absence of hypervisor software conflicts. Connecting to the restored instance via the VME web console revealed pristine operating health.\n(Figure: Verified Red Hat VirtIO Ethernet and QEMU SCSI disk controllers, physical Intel Xeon Gold CPU model passthrough, and clean removal of VMware Tools)\nKey operational checks within Windows 10 Device Manager and App Settings confirmed:\nFlawless Red Hat VirtIO Driver Operation: Network Adapter: Running on Red Hat VirtIO Ethernet Adapter. Disk Drive: Operating via QEMU QEMU HARDDISK SCSI Disk Device. No yellow warning exclamations or unrecognized peripheral devices. Physical SimpliVity Host CPU Binding: Processor inventory correctly identifies the physical host Intel Xeon Gold 6542Y processors, ensuring optimal hardware instruction set execution. Clean VMware Tools Demarcation: Verifying Settings \u0026gt; Apps \u0026gt; Installed apps confirmed that legacy VMware Tools services were cleanly deactivated without driver-level conflicts. The desktop environment loaded smoothly without display flickering, service hang-ups, or residual background daemon errors commonly encountered during hypervisor transitions. 5. Key Takeaways \u0026amp; Operational Conclusion In low-bandwidth environments (10Mbps), physical backup relocation remains king:\nInsisting on network replication across narrow WANs risks missing critical disaster recovery windows. For structured cutovers or air-gapped recovery, transferring full backup data (.vbk) and metadata (.vbm) files directly into a target repository provides the safest, most deterministic restoration path. Pre-flight driver injection is non-negotiable for V2V transitions:\nPreventing 0x7B boot loops between VMware and KVM requires verified offline injection mechanisms. Utilizing Veeam\u0026rsquo;s automated VirtIO injection guarantees bootable system images within a single 18-minute window. Post-restore guest verification routine:\nAlways verify Device Manager controllers and confirm that legacy hypervisor tools (such as VMware Tools) do not cause silent driver collisions on the new KVM stack. ","permalink":"https://cknotes.kr/en/posts/veeam-vmware-to-hpe-vme-restore-guide/","summary":"\u003cp\u003eIn response to evolving VMware enterprise licensing models, many IT organizations are actively evaluating migration to KVM-based \u003cstrong\u003eHPE VM Essentials (VME) and HPE SimpliVity HCI\u003c/strong\u003e architectures, as well as establishing cross-hypervisor disaster recovery (DR) capabilities.\u003c/p\u003e\n\u003cp\u003eWhile intra-hypervisor migrations typically rely on online continuous replication across high-speed links, operating across isolated sites with \u003cstrong\u003ea mere 10Mbps network bandwidth\u003c/strong\u003e makes real-time network streaming physically impractical. Migrating a multi-gigabyte virtual machine over 10Mbps would require dozens of hours.\u003c/p\u003e","title":"[HPE VME] Cross-Hypervisor Restore from VMware VBK in 18 Minutes"},{"content":"Driving an Audi or Volkswagen vehicle over several years often introduces a minor yet frustrating issue during refueling visits: the rubber tether connecting the fuel filler cap to the fuel door snaps.\nOnce the strap breaks, there is no secure place to hang the cap while fueling. Leaving it balanced precariously on the pump handle or letting it dangle against the car paintwork risks cosmetic scratches and dropping the cap.\nOfficial dealer service centers do not supply the rubber tether as an individual spare part. Instead, they quote an entire fuel cap assembly replacement, incurring substantial costs of approximately $50 to $100 including labor.\nHowever, using a $10 aftermarket replacement rubber ring and a utility knife, the tether can be replaced cleanly in under five minutes without risking body panel damage. This guide details the practical replacement procedure and crucial precautions applicable to Audi A3, A4, A6, and Volkswagen Golf and Tiguan platforms sharing identical fuel cap architectures.\nJob Overview \u0026amp; Requirements Item Details Applicable Models Audi A3 (Shared platform with VW Golf, Passat, Tiguan, Audi A4, A6) Required Part Aftermarket fuel cap tether strap ring (Curved profile option) Tools Needed Utility knife, work gloves (No trim pry tools or screwdrivers needed) Working Time Approximately 5 minutes Difficulty Level Low (Straightforward cutting and push-fit elastic engagement) 1. Root Cause of Tether Failure and Replacement Part Preparation (Figure: Rubber tether snapped from repeated bending fatigue and natural aging over 10+ years of ownership)\nThe root cause here has nothing to do with fuel vapor leaks or seal failure within the cap itself. Over more than a decade of daily driving, opening and closing the fuel cap hundreds of times subjected the rubber tether to continuous bending and twisting fatigue. Combined with exposure to seasonal outdoor temperature fluctuations, the elastomer naturally hardened over the years until reaching its fatigue threshold and snapping. Because the cap\u0026rsquo;s internal pressure valve and sealing gasket remain in perfect condition, replacing only the tether strap completely resolves the problem.\n(Figure: Molded replacement part integrating cap mounting ring, tether cord, and door retaining eyelet)\nThe aftermarket replacement part features an integrated design comprising the circular cap mounting ring, flexible connecting tether, and mounting eyelet for the vehicle-side pin.\nThe material exhibits resilient elasticity and thickness comparable to OEM specifications, ensuring reliable long-term durability. When sourcing the part, select the appropriate profile (Curved vs. Straight) corresponding to your specific vehicle model (the curved variant applies to the Audi A3).\n2. Critical Safety Rule: Do Not Pry Out the Vehicle-Side Retaining Pin (Figure: Plastic retaining pin bracket mounted directly on the vehicle fuel door housing)\nBefore beginning work, one crucial physical precaution must be observed.\nOnline guides often mistakenly advise prying out the plastic retaining pin on the fuel door using trim tools or flathead screwdrivers. On older vehicles, this plastic bracket is already embrittled. Applying leveraged force risks snapping the pin or cracking the fuel door housing bracket itself, necessitating an expensive full fuel door assembly replacement.\nLeave the vehicle-side pin intact. Simply slice away the degraded residual rubber and push the new elastic tether over the pin head.\n3. Slicing Residual Rubber and Removing the Old Cap Ring (Figure: Carefully slicing away the severed rubber stub without scratching the plastic pin)\nUsing a utility knife, carefully score and slice the remaining rubber nub clinging to the fuel door retaining pin. Lightly cut along the rubber sleeve without scoring the underlying plastic pin head, allowing the old piece to slide off cleanly.\n(Figure: Slicing the worn plastic retaining ring seated in the fuel cap body groove)\nNext, remove the original ring encircling the fuel cap body. The ring is firmly seated in the perimeter groove and cannot easily be stripped by hand. Slice cleanly through the ring cross-section with the utility knife; once the continuous loop is broken, tension releases and the ring pulls away effortlessly.\n4. Inspecting the Tapered Groove and Installing the New Ring (Figure: Beveled taper profile within the fuel cap seating channel)\nInspecting the bare fuel cap body reveals that the seating groove is not a rectangular channel, but rather features an inward taper.\n(Figure: Matching internal bevel profile on the replacement ring and installation alignment)\nThe replacement ring is molded with an internal bevel specifically matching this cap taper.\nVerify the slope orientation, seat one side into the cap groove, and work around the perimeter pressing firmly with your thumbs. Thanks to the elastic properties of the rubber, the ring snaps smoothly into the channel without requiring external tools.\n5. Verifying Alignment and Attaching to the Vehicle-Side Pin (Figure: Temporarily threading the cap to verify tether trajectory and twist-free alignment)\nWith the ring installed on the cap, thread the fuel cap partially into the filler neck. This step verifies that the tether cord aligns naturally with the fuel door pin without twisting or excessive tension when the cap is closed.\n(Figure: Snapping the replacement tether eyelet securely over the fuel door retaining pin)\nOnce orientation is confirmed, position the eyelet hole at the tip of the tether over the vehicle-side pin head and press inward with your thumb. The pliable elastomer stretches over the pin flange and seats firmly behind it. This eliminates any need to dislodge or stress the body bracket.\n6. Functional Verification and Cost Comparison (Figure: Fuel cap suspended securely beside the filler neck without contacting vehicle paintwork)\nOpen the fuel cap and release it to check clearance. The cap hangs securely at a safe distance from the fender panel, eliminating the risk of accidental drops or surface paint blemishes.\nDealer Assembly Replacement vs. DIY Tether Repair Evaluation Metric Dealer Service (Full Assembly) Aftermarket DIY Tether Repair Repair Method Complete fuel cap assembly replacement 1:1 replacement of severed tether strap Total Cost ~$50 – $100 (Parts + Labor) ~$10 (Replacement part) Duration Service appointment booking and shop wait 5 minutes (Immediate on-site repair) Body Damage Risk Potential bracket breakage if pried Retaining pin untouched (0% risk) Operational Result OEM standard retention Identical retention functionality restored 7. Field Engineering Takeaways Never forcefully pry the vehicle-side pin:\nBreaking the mounting bracket expands a 5-minute fix into a major repair requiring full fuel door assembly replacement. Always slice the old rubber and push-fit the replacement. Cold weather tip:\nIn cold climates, rubber elastomers stiffen. Soak the new ring in warm water for 1 to 2 minutes or apply a drop of soapy water before fitting to facilitate smooth installation. Platform compatibility across VAG vehicles:\nThis procedure applies across numerous Volkswagen Auto Group (VAG) vehicles sharing the MQB and MLB platforms, including Audi A3, A4, A6, Q3, Q5, and Volkswagen Golf Mk7, Passat, and Tiguan. ","permalink":"https://cknotes.kr/en/posts/2026-10-08-audi-a3-fuel-cap-strap-replacement/","summary":"\u003cp\u003eDriving an Audi or Volkswagen vehicle over several years often introduces a minor yet frustrating issue during refueling visits: the rubber tether connecting the fuel filler cap to the fuel door snaps.\u003c/p\u003e\n\u003cp\u003eOnce the strap breaks, there is no secure place to hang the cap while fueling. Leaving it balanced precariously on the pump handle or letting it dangle against the car paintwork risks cosmetic scratches and dropping the cap.\u003c/p\u003e","title":"[Lifestyle] Audi A3 Fuel Cap Broken Tether Strap 5-Minute DIY Replacement"},{"content":"1. Overview: Core Principles of HPE Alletra 9000 Firmware Upgrades Serving enterprise mission-critical workloads, HPE Alletra 9060 (built on the Alletra 9000 / Primera architecture) storage arrays support online, non-disruptive firmware upgrades across dual or quad-controller nodes.\nThe paramount prerequisite for any Alletra 9000 OS upgrade is the advance preparation of the latest Upgrade Tool (UT). Before executing the main OS firmware update, the matching Upgrade Tool package must be loaded into the storage array. This ensures accurate pre-upgrade readiness checks, scripts validation, and seamless rolling controller reboot sequences.\nThis guide walks through the complete upgrade procedure from OS 9.6.5 to OS 9.6.30 (Extended Support Release) on an active HPE Alletra 9060 system, highlighting critical field engineering verification checkpoints.\n2. Pre-Upgrade Preparation \u0026amp; Package Acquisition 2.1. Downloading Required Packages Firmware binaries and tooling for HPE Alletra 9000 and Primera arrays are sourced through the official licensing portal:\nLog in to the HPE Enterprise License Portal (My HPE Software Center). Navigate to Software ➔ Input your contract SAID or array identifier. Download the following components: Latest Upgrade Tool Package: Upgrade Tool 80 (build 260625) or newer. Target OS Firmware Package: HPE Alletra 9000 OS 9.6.30.xx (tar/iso archive). 2.2. Pre-Flight Verification Checklist Host Multipath Redundancy: Ensure redundant active I/O paths across all 15+ connected host initiators before initiating rolling controller reboots. Array Hardware \u0026amp; Alert Status: Verify all controller nodes, power modules, and drive enclosures show healthy status with zero active unacknowledged alerts (New alerts: 0). Note on Remote Copy \u0026amp; Schedules: In modern HPE Alletra/Primera OS architectures, Remote Copy sessions and internal schedule windows are engineered for non-disruptive rolling failovers. Unless explicitly mandated by a specific Release Note or Customer Advisory, manual suspension of replication or backup schedules is not required. 3. Step-by-Step Non-Disruptive Upgrade Procedure Step 1. Initial Dashboard \u0026amp; Health Inspection Log in to the web console and inspect system alerts (New alerts: 0), usable capacity, and online host connectivity. Under System ➔ Software, confirm the baseline firmware version (9.6.5) and array model specifications.\nFigure 1. Pre-upgrade Dashboard - Health status, capacity metrics, and active hosts\nFigure 2. System Overview - Baseline firmware version (9.6.5) and hardware summary\nStep 2. Loading Upgrade Tool and OS 9.6.30 Update Packages From the right-hand Actions menu, click Load an update package . Upload the downloadedUpgrade Tool (UT 80) and OS 9.6.30 package to the array.\nFigure 3. Load an update package - Selecting and uploading firmware packages\nStep 3. Pre-Upgrade Readiness Checks \u0026amp; Warning Acknowledgment Prior to initiating the live upgrade, the system executes automated Readiness Checks to evaluate overall cluster safety and prerequisite compliance.\nPort Topology Warning Review and Acknowledgment The readiness scan may report a warning on Check Port Topology Consistency. This occurs due to planned fabric topology differences across target ports (0:3:1, 0:3:2, 1:3:1, 1:3:2). Confirm that this matches your planned SAN configuration.\nFigure 4. Pre-upgrade Readiness Checks - Detailed review of port topology consistency warning\nAfter confirming all primary readiness checks (PD/Chunklets, LD State, IOCTLs, Host Path Consistency) show Passed, open the Ignore checks dialog, review the prompt, and select Yes, ignore to pass pre-checks and proceed.\nFigure 5. Pre-upgrade Readiness Checks - Physical disks, logical disks, and host paths verified passed\nFigure 6. Ignore checks dialog - Acknowledging warning to proceed\nStep 4. Executing the Non-Disruptive Rolling Node Upgrade Once pre-checks are cleared, start the upgrade. The automated Upgrade Tool 80 engine executes pre-update scripts and installs the base OS filesystem onto the secondary partition.\nFigure 7. OS update in progress - Upgrade Tool 80 executing pre-update scripts\nNode 0 Upgrade \u0026amp; Reboot Sequence After base filesystem staging, Node 0 leaves the cluster (11:13:20) to perform a full reboot into the new OS (9.6.30). Host I/O seamlessly paths through active Node 1. Once rebooted, Node 0 automatically rejoins the cluster (11:22:13).\nFigure 8. Node 0 OS update - Cluster exit, reboot into 9.6.30, and successful rejoin\n💡 Field Engineering Note (Management Failover):\nWhen the active master controller node reboots, the web management session fails over to the peer node. An overlay modal (Update in progress 16%) may briefly appear. Do not refresh or close the browser; the session recovers automatically.\nFigure 9. Management console failover progress dialog during node reboot\nStep 5. Node 1 Rolling Upgrade \u0026amp; Web UI Reconnection With Node 0 confirmed healthy and resynchronized, Node 1 leaves the cluster to reboot into OS 9.6.30 (11:27:32).\nReconnecting to the web management UI during the Node 1 reboot reveals the main Software view displaying an active **Maintenance Mode **notification banner and the overall installation progress (Installing HPE Alletra 9000 9.6.30: 69%).\nFigure 10. Web UI reconnection during Node 1 reboot - Installation progress (69%) and maintenance mode banner\nOnce Node 1 finishes rebooting and rejoins the cluster (11:35:16), both nodes are synchronized at 9.6.30, and the automated post-upgrade validation phase commences (11:41:23).\nFigure 11. Node 1 OS update - Reboot, cluster rejoin, and post-upgrade initiation\nStep 6. Post-Upgrade Verification \u0026amp; Final Version Confirmation The system purges deprecated staging packages (OS-9.6.20.6). Review the final prompt in the Continue update software dialog and click Yes, continue (11:49:45 No issues reported).\nFigure 12. Continue update software - Post-upgrade confirmation dialog\nFigure 13. Post-upgrade completion - Verification log reporting no issues\nIn the Software console, verify that Current version: 9.6.30 is displayed with You're all up to date. Maintenance mode clears automatically, concluding the non-disruptive update.\nFigure 14. Final Software view - OS 9.6.30 verified active and system fully healthy\n4. Key Engineering Takeaways Dimension Critical Focus Item Field Engineering Recommendation Upgrade Tool (UT) Version Compatibility Always stage the latest Upgrade Tool release prior to running the main OS update. Software Acquisition Official Licensing Portal Source binaries from the HPE Enterprise License Portal under valid support entitlements (SAID). High Availability Host Multipathing Ensure all host initiators maintain redundant active paths before initiating rolling reboots. Warning Handling Port Topology Nuances Investigate all readiness check warnings; acknowledge only verified, deliberate fabric configurations. 5. Summary \u0026amp; Technical Support Advisory Upgrading an HPE Alletra 9060 array to OS 9.6.30 delivers critical security patches and enterprise controller stability. Supported by rigorous pre-checks and the proper Upgrade Tool, the upgrade proceeds with 100% online availability.\n⚠️ Field Support Notice:\nHPE Alletra 9000 storage arrays manage tier-1 mission-critical enterprise data. If you require architecture validation, fabric topology review, or tailored firmware guidance, always consult HPE Pointnext Services or authorized partner engineers.\n","permalink":"https://cknotes.kr/en/posts/hpe-alletra-9060-os-upgrade-guide/","summary":"\u003ch2 id=\"1-overview-core-principles-of-hpe-alletra-9000-firmware-upgrades\"\u003e1. Overview: Core Principles of HPE Alletra 9000 Firmware Upgrades\u003c/h2\u003e\n\u003cp\u003eServing enterprise mission-critical workloads, \u003cstrong\u003eHPE Alletra 9060 (built on the Alletra 9000 / Primera architecture)\u003c/strong\u003e storage arrays support online, non-disruptive firmware upgrades across dual or quad-controller nodes.\u003c/p\u003e\n\u003cp\u003eThe paramount prerequisite for any Alletra 9000 OS upgrade is the advance preparation of the \u003cstrong\u003elatest Upgrade Tool (UT)\u003c/strong\u003e. Before executing the main OS firmware update, the matching Upgrade Tool package must be loaded into the storage array. This ensures accurate pre-upgrade readiness checks, scripts validation, and seamless rolling controller reboot sequences.\u003c/p\u003e","title":"[HPE Alletra 9060] OS 9.6.30 Non-Disruptive Upgrade Procedure"},{"content":"1. Overview: Major UI Overhaul in ArcusOS 10.6.0 With the release of OS version 10.6.0 (ArcusOS) for the HPE Alletra Storage MP B10K (B10120) all-NVMe modular storage system, Hewlett Packard Enterprise introduced a major transformation of its on-premises web management console.\nDeparting from the legacy dark-grey single-level sidebar interface utilized up through version 10.5.x, OS 10.6.0 introduces a modern, cloud-native white card theme combined with an expandable multi-tier tree navigation structure.\nThis field guide provides an exhaustive review of the updated interface, comparing key menu workflows, hardware diagnostic screens, and central security configuration options from an enterprise engineering perspective.\n2. Comparing UI Architecture: 10.5.x vs. 10.6.0 Feature / Dimension Legacy UI (OS 10.5.50 \u0026amp; Prior) New UI (OS 10.6.0) Field Engineering Advantage Theme \u0026amp; Aesthetic Dark-grey monochrome sidebar Clean, card-based white layout Greatly improved readability; unified GreenLake cloud look-and-feel Left Navigation Icon-only single-tier menu Multi-tier collapsible text-labeled tree Instant 1-click navigation directly to Drives, Ports, and sub-components Top Branding Minimal generic logo glyph HPE Logo with full model identifier Immediate visual identification across multi-array data center deployments Port / Switch Access Nested within deep hardware tabs Dedicated Ports and Switches items Rapid verification of SAN fabric link speed and port health Integrated Settings Dispersed configuration tabs Consolidated Settings tree Unified management for Ransomware Detection, Volume Retention, and Telemetry Side-by-Side System Dashboard Comparison Figure 1. [Pre-Upgrade] Legacy dark sidebar System dashboard in OS 10.5.50\nFigure 2. [Post-Upgrade] Modern white tree-navigation System dashboard in OS 10.6.0\n3. Comprehensive Breakdown of the 6 Core Menus 3.1. Dashboard (System Health, Capacity \u0026amp; Performance) The default landing view delivers immediate visibility into operational health, storage allocation, and real-time throughput metrics via three primary card widgets.\nHealth: Displays active alerts along with real-time status glyphs for Storage, Protection, System, Call Home, and Data Services Cloud Console (DSCC). Usable Capacity: Visualizes total vs. available capacity via a clean donut chart, differentiating between Private/Shared usage, snapshots, system overhead, and unallocated blocks. Performance: Tracks online connected hosts alongside live trend graphs for IOPS, bandwidth, and I/O latency. Figure 3. Main Dashboard - Real-time metrics for Health, Usable Capacity, and Performance\n3.2. Storage (Block Volumes, Host Sets \u0026amp; VMware Integration) The central operational workspace for provisioning and managing all block storage objects, host definitions, and migrations.\nBLOCK: Virtual volume sets, Volumes, Host sets, Hosts VMWARE: VMware storage containers integration PEER MOTION: Online non-disruptive migration orchestration from older 3PAR or Primera arrays Quick actions: One-click shortcuts to create host sets, provision volume sets, or launch tutorials Figure 4. Storage Menu Overview - Block volumes, host groups, and Quick Action cards\nVirtual Volume Sets \u0026amp; Volumes Management Enables immediate inspection of provisioning ratios, capacity allocation, and protection policies across logical volume groups (e.g., VMware ESXi datastores).\nFigure 5. Virtual Volume Sets Detail - Volume group membership and export status\nHost Sets \u0026amp; Connected Host Infrastructure Provides structured visibility into clustered server groups (Host sets) and individual host nodes, ensuring all SAN paths report Normal status.\nFigure 6. Host Sets View - Host server clustering and path health verification\n3.3. Protection (Data Replication \u0026amp; Application Protection) Consolidates remote replication sessions, HPE StoreOnce backup integrations, and application-aware protection policies into a card-based view.\nREPLICATION: Replication partners and remote target systems BACKUP SYSTEMS: Direct integration with HPE StoreOnce appliances APPLICATION PROTECTION: Policy management for VMware Datastores, VMs, VM protection groups, and Microsoft SQL Server databases Figure 7. Protection Menu Overview - Remote replication, backup targets, and application protection\n3.4. System (Hardware Chassis, Controllers \u0026amp; Physical Components) Dedicated to physical infrastructure health, hardware diagnostics, and low-level component telemetry.\nSystem Details Presents hardware specifications (HPE Alletra Storage MP B10120), operational OS version (10.6.0), system uptime, hardware encryption capability, and hardware summary counts (2 Controllers, 1 Enclosure, 8 Drives, 8 FC Ports).\nFigure 8. System Details View - Model specs, OS 10.6.0 operational status, and license summary\nSystem Software (OS Firmware \u0026amp; Lifecycle Policies) Displays running OS version (10.6.0) alongside configured cloud staging policies (Software Update Policy) managed directly from the local array or GreenLake.\nFigure 9. System Software View - Firmware version tracking and automatic staging policies\nEnclosure Chassis \u0026amp; Controllers Interactive graphical schematic representing enclosure bay locations, power supplies, Chassis Discovery Modules (CDM), and dual active-active controller nodes (Node 0 Master / Node 1).\nFigure 10. Enclosure Details - Rear chassis module layout and dual-controller operational status\nDrives \u0026amp; Ports Provides individual status cards for all 8 NVMe SSD drives (Slots 1:1 through 1:8, 3.84TB each) and 8 high-speed FC front-end host ports.\nFigure 11. System Drives View - Health and capacity state of 8 all-NVMe SSD drives\n3.5. Settings (Unified Configuration, Network \u0026amp; Security) A central administration hub uniting system parameters, networking, identity, and certificates.\nIntegrated Settings Categories: System, Telemetry, Users, Domains, LDAP configuration, Contacts, VMware vCenter, HPE VM Essentials, Network services, Array certificates, and Trusted certificates. Figure 12. Settings Overview - Centralized management for networking, users, and security certificates\nSettings ▶ System (Management Network \u0026amp; Data Security Policies) Configures management IPv4 addresses, subnet masks, default gateways, and DNS servers, while centrally defining Volume Retention periods and Ransomware Detection sensitivity levels.\nFigure 13. Settings-System View - Management network IP configuration and ransomware protection\nSettings ▶ Telemetry (Call Home \u0026amp; Data Services Cloud Console) Monitors outbound Call Home connectivity for proactive automated hardware dispatch, alongside active cloud binding status for HPE GreenLake Data Services Cloud Console (DSCC).\nFigure 14. Settings-Telemetry View - Call Home and DSCC cloud telemetry status\nSettings ▶ Contacts (Support Notification Directory) Maintains registered customer administrator contact cards and technical support escalation directories.\nFigure 15. Settings-Contacts View - Administrator notification profile management\n3.6. Reports \u0026amp; Activities (Reporting \u0026amp; Task Execution Auditing) Reports (Real-Time Performance \u0026amp; Capacity Analytics) Enables engineers to instantly generate custom performance reports (Create report) capturing CPU, memory, IOPS, and latency across custom time intervals.\nFigure 16. Reports View - Real-time custom metric reporting and template loading\nActivities (Alerts, Tasks \u0026amp; Schedules) Provides unified auditing across real-time hardware alerts (Alerts), active and historical background operations such as firmware upgrades or volume creations (Tasks), and scheduled jobs (Schedules).\nFigure 17. Activities View - Real-time system alerts, background task history, and maintenance schedules\n4. Field Engineering Summary \u0026amp; Operational Impact Streamlined Navigation Workflows:\nThe persistent multi-level text tree on the left reduces menu navigation overhead, allowing engineers to transition between volume troubleshooting and physical port diagnostics in a single click.\nImmediate Fabric Port \u0026amp; Switch Visibility:\nSAN zoning and physical link verification no longer require digging through deep hardware sub-menus; Ports and Switches are readily accessible from the root navigation tree.\nCentralized Data Security Governance:\nUnifying Volume Retention and Ransomware Detection within Settings ➔ System ensures enterprise compliance policies are verified with minimal friction.\n5. Technical Support Guidance The ArcusOS 10.6.0 web console represents a substantial visual and operational leap for HPE Alletra Storage MP B10K systems, delivering cloud-like responsiveness in an on-premises deployment.\n⚠️ Field Engineering Support Advisory:\nHPE Alletra Storage MP systems host tier-1 mission-critical business data. If you encounter complex SAN design requirements, unresolved pre-upgrade readiness warnings, or complex replication configurations, always engage certified HPE Pointnext Services or authorized partner engineers for verified deployment assistance.\n","permalink":"https://cknotes.kr/en/posts/hpe-alletra-mp-b10k-new-ui-guide/","summary":"\u003ch2 id=\"1-overview-major-ui-overhaul-in-arcusos-1060\"\u003e1. Overview: Major UI Overhaul in ArcusOS 10.6.0\u003c/h2\u003e\n\u003cp\u003eWith the release of \u003cstrong\u003eOS version 10.6.0 (ArcusOS)\u003c/strong\u003e for the \u003cstrong\u003eHPE Alletra Storage MP B10K (B10120)\u003c/strong\u003e all-NVMe modular storage system, Hewlett Packard Enterprise introduced a major transformation of its on-premises web management console.\u003c/p\u003e\n\u003cp\u003eDeparting from the legacy dark-grey single-level sidebar interface utilized up through version 10.5.x, OS 10.6.0 introduces a \u003cstrong\u003emodern, cloud-native white card theme combined with an expandable multi-tier tree navigation structure\u003c/strong\u003e.\u003c/p\u003e","title":"[HPE Alletra MP B10K] ArcusOS 10.6.0 New UI Hands-on Guide"},{"content":"1. Background: Alletra MP 10.6.0 Upgrade \u0026amp; New Web UI Overhaul On an enterprise production HPE Alletra Storage MP (B10K / B10120) system, we executed a firmware upgrade to OS version 10.6.0 to enhance platform stability and support the latest storage capabilities.\nThe 10.6.0 release brings not only underlying performance and reliability improvements but also a complete visual overhaul of the local on-premises management console from the legacy dark sidebar into a clean, modern white tree-based navigation UI.\nIf the storage array is connected to the internet (HPE Cloud Connect), the 10.6.0 firmware package is automatically staged (pre-downloaded) onto the system. In air-gapped environments, administrators can easily upload the package manually via the local console web UI.\n2. Environment \u0026amp; Prerequisites Item Specification / Details Field Rationale Target Storage HPE Alletra Storage MP B10120 2-Node Active-Active Enterprise Block Storage Current OS Version OS 10.5.50 Existing operational firmware version Target OS Version OS 10.6.0 (ArcusOS) Recommended release with new UI and stability fixes Package Delivery Online Staged / Manual Load Package Automatically pre-staged via internet connectivity Mandatory Pre-check System Readiness Checks Must achieve 100% Passed status prior to upgrade Estimated Duration Approx. 60 – 90 minutes Includes sequential node reboots and CDM firmware writing 3. Step-by-Step Practical Upgrade Procedure Step 1. Inspect Current OS Version and System Dashboard Health Before starting, log into the local web management console and navigate to System ➔ Dashboard to verify the active OS version (10.5.50) and confirm healthy operational status (OK) for controllers, enclosure chassis, and drive IOMs.\nStep 1. Pre-upgrade System Dashboard inspection verifying running OS version 10.5.50\nStep 2. Access Software Menu and Verify Staged 10.6.0 Firmware Package Navigate to System ➔ Software from the left-hand navigation bar.\nWhen connected to the internet, the recommended 10.5.60 and latest 10.6.0 packages appear automatically under the Staged updates list ready for deployment.\n💡 For Air-Gapped (Offline) Environments:\nClick Load an update package at the top right to manually upload the pre-downloaded firmware ISO package (e.g., OS-10.6.0.xx.iso) directly via your web browser.\nStep 2-1. Software menu displaying automatically staged 10.6.0 firmware update packages\nStep 2-2. Load an update package interface for air-gapped manual file uploads\nStep 3. ★ Mandatory Pre-Upgrade Step: Verify System Readiness Checks This is the most crucial verification step before executing the upgrade.\nClick the View readiness checks link adjacent to the 10.6.0 staged entry to review the automated integrity scan.\nKey Pre-check Validations: Check System Status \u0026amp; Restart system logger: Passed Ensure Node Disk Free Space: Validates adequate internal capacity Verify Host Connectivity: Validates active SAN host multipathing paths Check VV \u0026amp; Check VLUNs: Validates volume and LUN mapping integrity Ensure all check categories display a green Passed status before proceeding.\nStep 3. System readiness checks summary - 100% Passed validation across all system, host, and volume components\nStep 4. Initiate Update Software and Select 10.6.0 Package With readiness checks confirmed, click the Update software action button.\nIn the package selection dialog, select **HPE GreenLake for Block Storage 10.6.0**and click Install.\nStep 4. Selecting HPE GreenLake for Block Storage 10.6.0 package and initiating Install\nStep 5. Background OS Firmware Upgrade Task Activation Upon execution, a top notification banner displays Starting installation of HPE GreenLake for Block Storage 10.6.0, and the background Activities upgrade session starts.\nStep 5. Confirmation banner indicating 10.6.0 installation startup and background task activation\nStep 6. Non-Disruptive OS Upgrade \u0026amp; Automatic Transition to New UI Alletra MP executes a non-disruptive upgrade by sequentially failing over and upgrading controller nodes without interrupting host I/O.\nPre-update checks: Final system sanity checks. Node software \u0026amp; firmware writing: Flashing software and firmware onto Node 0 and Node 1. Sequential node reboot: Node 0 reboots and restores health ➔ Node 1 reboots. Version switch \u0026amp; console daemon restart: An Update in progress dialog appears during web management service reinitialization. Component firmware \u0026amp; New UI Overhaul:\nAs version switching finalizes, the management console automatically refreshes into the new modern white tree-based UI, while disk drives and CDM (Chassis Discovery Module) component firmwares complete in the background. Step 6-1. OS update in progress - Initializing pre-update checks\nStep 6-2. 36% Progress - Sequential node reboot and failover handling\nStep 6-3. 44% Progress - System version switch and web console refresh dialog\nStep 6-4. 96% Progress - Automatic transition to new white UI and CDM component firmware updating\nStep 7. Verify OS Upgrade Completion Once all stages complete, the OS update successful screen appears confirming HPE Alletra Storage 10.6.0 update completed successfully across all stages.\nStep 7. OS update successful - All upgrade items marked Completed\nStep 8. Final Dashboard Verification in the New UI (OS 10.6.0) Navigate to System ➔ Details / Software in the new interface to verify overall system operational status:\nOS version: Successfully updated to 10.6.0. Hardware health: All green checkmarks (OK) for Enclosure chassis, Controllers, Drive IOMs, Drives, Ports, and Switches. New Navigation Structure: Clean, intuitive organization across Storage, Protection, System, Settings, and Reports. Step 8. Final System Dashboard in the new white UI verifying operational OS version 10.6.0\n4. 🚨 Troubleshooting \u0026amp; Field Precautions Precaution 1: Handling Warnings or Failures in Readiness Checks Root Cause: Severed multipath links, ongoing background backup jobs, or insufficient node free space. Resolution : Never check Ignore pre-installation warnings to force an install. Resolve the underlying issue first, run Re-run checks, andonly proceed when all checks achieve Passed status. Precaution 2: Temporary Web Console Freezing at 44% Version Switch Symptom: The browser may appear unresponsive or show the updating popup for 1–2 minutes during node reboots. Resolution: This is normal behavior during web service daemon restarts. Do not close or spam-refresh the browser; the page will automatically refresh into the new white UI once complete. Precaution 3: When In-House Execution is Difficult (Mandatory Recommendation for HPE Engineer Support) **Recommendation **: HPE Alletra Storage MP powers critical enterprise tier-1 workloads. If your in-house team is unfamiliar with the process, if persistent warnings in Readiness Checks cannot be resolved internally, or if executing offline manual package updates,do not attempt to force the upgrade alone. Strongly request on-site or remote assistance from certified HPE Pointnext Services or authorized partner engineers to ensure zero data disruption. 5. Verification Checklist OS Version: Navigate to System ➔ Software and confirm OS version: 10.6.0. Component Health: Verify all 2-node controllers, chassis, IOMs, power, and fan modules report OK. Host Multipathing: Confirm uninterrupted I/O and active FC/iSCSI paths from connecting host servers. 6. Field Engineering Best Practices Leverage Automatic Staging:\nAlletra MP\u0026rsquo;s cloud-connected architecture eliminates manual binary hunting when internet access is available, enabling safe one-click staging. Adapting to the 10.6.0 UI:\nSub-menus like Details, Software, Controllers, and Ports are now cleanly nested under System, making daily operational inspections significantly faster. 7. Summary Core Upgrade Workflow: Check 10.5.50 Dashboard ➜ Verify Staged 10.6.0 Package ➜ Validate 100% Passed on System Readiness Checks (Mandatory) ➜ Execute Update software ➜ Non-disruptive Node Reboots \u0026amp; New White UI Transition ➜ Final Verification on 10.6.0. With rigorous pre-checks, the entire upgrade completes seamlessly in about an hour. 📢 Coming Up Next:\nIn this guide, we focused on the step-by-step 10.6.0 OS upgrade procedure. In the next article, we will dive deep into the completely redesigned white tree-navigation Web UI of OS 10.6.0—exploring new dashboard widgets, updated menu workflows, and enhanced volume/port management features! Stay tuned!\n","permalink":"https://cknotes.kr/en/posts/hpe-alletra-mp-b10k-os-upgrade-guide/","summary":"\u003ch2 id=\"1-background-alletra-mp-1060-upgrade--new-web-ui-overhaul\"\u003e1. Background: Alletra MP 10.6.0 Upgrade \u0026amp; New Web UI Overhaul\u003c/h2\u003e\n\u003cp\u003eOn an enterprise production \u003cstrong\u003eHPE Alletra Storage MP (B10K / B10120)\u003c/strong\u003e system, we executed a firmware upgrade to \u003cstrong\u003eOS version 10.6.0\u003c/strong\u003e to enhance platform stability and support the latest storage capabilities.\u003c/p\u003e\n\u003cp\u003eThe 10.6.0 release brings not only underlying performance and reliability improvements but also \u003cstrong\u003ea complete visual overhaul of the local on-premises management console from the legacy dark sidebar into a clean, modern white tree-based navigation UI\u003c/strong\u003e.\u003c/p\u003e","title":"[HPE Alletra MP B10K] OS 10.6.0 Non-Disruptive Upgrade Guide"},{"content":"1. Background: Why Did the Switch Front Panel Light Up Amber in a Cold Server Room? During on-site data center maintenance, it is common to observe the SYS/ENV status LED on the front panel of Cisco MDS 9148T (HPE SN6620C) storage switches illuminated in amber (orange), even when the server room ambient temperature is kept at a cool 18–20°C.\nWhen running show environment to inspect internal sensor readings, the temperatures show 32°C (Normal). Despite normal operating conditions, a sensor polling mechanism bug in NX-OS 9.2.2 (such as CSCwo09244) erroneously triggers a threshold warning and illuminates the cosmetic amber warning light.\nIn this guide, we cover the root cause analysis of the false temperature sensor Amber LED issue, the permanent resolution via the recommended 9.4.5 upgrade , andhow to configure the switch Timezone to eliminate log timestamp confusion during incidents.\n2. Environment \u0026amp; Prerequisites Item Specification / Details Field Rationale Target Switch Cisco MDS 9148T / HPE SN6620C 32G Enterprise FC SAN Switch Affected Version Cisco NX-OS 9.2(2) Known cosmetic temp sensor polling bug Resolved Version Cisco NX-OS 9.4(5) Fixes sensor polling and platform monitoring bugs Configured Timezone Timezone (KST, UTC+9) Synchronized log timestamp analysis 3. Step-by-Step Resolution and Configuration Procedure Pre-upgrade switch front panel LED and status inspection\nStep 1. Inspect Temperature Sensor \u0026amp; Environmental Health When the front Amber LED is lit, perform an initial check to determine whether it is a hardware failure or a software bug.\n# Detailed check of environmental sensors and temperature info show environment temperature If all sensors report OK and temperatures are within the Normal operating range, yet the Amber LED remains lit, you can confirm it is the NX-OS 9.2.2 sensor polling bug.\nPost-upgrade verification showing normal green LED and show environment sensor validation\nStep 2. Permanently Fix Sensor Bug via 9.4.5 OS Upgrade To resolve the sensor polling bug, upgrade the switch OS to the recommended release NX-OS 9.4(5).\nOnce the upgrade is complete and the switch reboots, the platform monitoring daemon re-initializes, clearing the amber alarm and restoring the front panel LED to normal Green.\nConfiguring Timezone (KST, UTC+9) using clock timezone command\nStep 3. Configure Switch Timezone If the switch remains in default UTC (Coordinated Universal Time), cross-referencing switch logs with server and storage logs during incident troubleshooting creates a time gap that complicates root cause analysis.\n# Enter global configuration mode switch# configure terminal # Set Timezone (e.g., KST UTC+9) switch(config)# clock timezone KST 9 0 # Verify clock setting switch(config)# show clock (Field Rationale: Matching storage SAN switch log timestamps with standard operating time reduces troubleshooting duration by half)\nStep 4. Save Running Configuration Save the running configuration to startup configuration so the timezone setting persists across reboots.\n# Save configuration switch# copy running-config startup-config 4. 🚨 Troubleshooting Notes (Field Realities) Issue 1: Temperature is Normal (32°C) but Front SYS/ENV LED Remains Amber Symptom: show environment reports all statuses as Normal, but front panel SYS/ENV LED stays amber. Root Cause: NX-OS 9.2.2 IOSlice temp sensor polling retry logic bug (%PLATFORM-4-MOD_TEMPFAIL cosmetic malfunction). Resolution: Software reset commands (clear environment history) do not fix the issue permanently. Upgrading to NX-OS 9.4(5) completely resolves the issue, restoring the LED to 100% normal Green. 5. Verification Checklist Physical Front LED Verification: Verify that SYS, ENV, and FAN LEDs on the front panel have changed from Amber to Normal Green. Sensor Health Verification: show environment # Output: Power, Fan, Temp all report OK / Normal Timezone Verification: show clock # Example output: 15:35:12.123 KST Sun Sep 27 2026 6. Field Engineering Best Practices Distinguishing Hardware Faults from Software Bugs:\nDo not immediately request hardware RMA replacement when the front Amber LED is lit. Always run show environment first. If sensor temperatures are in the normal 30°C range, it is a firmware sensor polling bug solvable via OS upgrade. Configure Timezone During Initial Commissioning:\nMissing timezone configuration leads to confusion during FC port flapping or link error analysis. Always establish the habit of running clock timezone KST 9 0 during initial setup. 7. Summary Core Takeaways: NX-OS 9.2.2 false temperature Amber LED issue is permanently resolved by upgrading to 9.4(5). Configure standard timezone using clock timezone KST 9 0. Persist settings with copy running-config startup-config. ","permalink":"https://cknotes.kr/en/posts/cisco-mds-temp-sensor-amber-led-fix-and-kst-timezone/","summary":"\u003ch2 id=\"1-background-why-did-the-switch-front-panel-light-up-amber-in-a-cold-server-room\"\u003e1. Background: Why Did the Switch Front Panel Light Up Amber in a Cold Server Room?\u003c/h2\u003e\n\u003cp\u003eDuring on-site data center maintenance, it is common to observe the \u003cstrong\u003eSYS/ENV status LED on the front panel of Cisco MDS 9148T (HPE SN6620C) storage switches illuminated in amber (orange)\u003c/strong\u003e, even when the server room ambient temperature is kept at a cool 18–20°C.\u003c/p\u003e\n\u003cp\u003eWhen running \u003ccode\u003eshow environment\u003c/code\u003e to inspect internal sensor readings, the temperatures show \u003ccode\u003e32°C (Normal)\u003c/code\u003e. Despite normal operating conditions, a sensor polling mechanism bug in NX-OS 9.2.2 (such as CSCwo09244) erroneously triggers a threshold warning and illuminates the cosmetic amber warning light.\u003c/p\u003e","title":"[Cisco MDS] Fixing Temp Sensor Amber LED \u0026 Timezone Setup"},{"content":"1. Background: Why NX-OS 9.4.5 Upgrade Was Necessary In an enterprise customer environment running HPE SN6620C (Cisco MDS 9148T-based) 32Gb FC SAN switches, a firmware upgrade was requested to improve system stability.\nThe legacy 9.2.2 release had known issues such as environmental sensor polling false positives (e.g., Amber LED triggers) and potential BIOS timeout risks during ISSU. Consequently, we chose NX-OS 9.4(5), designated as the Recommended Release by both HPE and Cisco official advisories.\nBecause the data center was an isolated air-gapped network, external Internet access was blocked. We deployed Rebex Tiny SFTP/SCP Server on the engineer laptop to transfer firmware images directly via local management ports.\n2. Environment \u0026amp; Prerequisites Item Specification / Details Field Rationale Target Switch HPE SN6620C (Cisco MDS 9148T OEM) 32Gbps Fibre Channel (FC) SAN Switch Current NX-OS Version 9.2(2) Existing operational release Target NX-OS Version 9.4(5) HPE/Cisco Recommended Release File Transfer Protocol SCP (Secure Copy Protocol) Laptop ↔ Switch Management Port direct connection SCP Server Utility Rebex Tiny SFTP/SCP Server Lightweight portable SCP server without installation Firmware Files m9000-pkg2.9.4.5.bin, m9000-kickstart-pkg2.9.4.5.bin System OS \u0026amp; Kickstart binary packages 3. Step-by-Step Practical Upgrade Procedure Step 1. Check Current OS Version and Switch Status Before starting the upgrade, connect to the switch CLI and verify current running versions (show version) and module/port health (show module).\n# Check current OS version and system info show version # Verify module status and port operational health show module Step 1. Connect to Switch CLI and Verify Current 9.2.2 Version\nStep 2. Download and Configure Rebex Tiny SCP Server Set up Rebex Tiny SFTP/SCP Server, a lightweight portable tool optimized for air-gapped field operations.\nDownload the portable executable and place it on the engineer laptop. Launch the utility, configure User/Password (e.g., scpuser / P@ssw0rd), and specify the directory containing the firmware binaries as theRoot Directory. Click Start Server to immediately bind and activate the SCP listener. Step 2-1. Download Rebex Tiny SFTP/SCP Server Portable\nStep 2-2. Rebex SFTP/SCP Server Main Window\nStep 2-3. Rebex User Account and Firmware Folder Configuration\nStep 2-4. Click Start Server to Activate SCP Service\nStep 3. Transfer Firmware File via copy Command Execute the copy scp: command on the switch CLI to pull the firmware binaries (m9000-pkg2.9.4.5.bin, m9000-kickstart-pkg2.9.4.5.bin) from the laptop to the local bootflash: area.\n# Transfer firmware from laptop (SCP server) to bootflash: (System \u0026amp; Kickstart) copy scp://scpuser@192.168.1.100/m9000-pkg2.9.4.5.bin bootflash: vrf management copy scp://scpuser@192.168.1.100/m9000-kickstart-pkg2.9.4.5.bin bootflash: vrf management Step 3. Transfer Firmware to Switch bootflash using copy scp command\nStep 4. Install Firmware and Run Pre-Upgrade Impact Checks via install all Once the file transfer is complete, run install all specifying both system and kickstart images to perform image integrity checks, compatibility analysis, and flash the new OS.\n# Start 9.4.5 OS firmware upgrade (Specify both System and Kickstart) install all system bootflash:m9000-pkg2.9.4.5.bin kickstart bootflash:m9000-kickstart-pkg2.9.4.5.bin During installation, the system verifies image checksums, applies patches across supervisor and controller modules, and performs an automatic reboot.\nStep 4-1. Initiate Firmware Installation via install all Command\nStep 4-2. Automatic Pre-Upgrade Compatibility \u0026amp; Impact Analysis\nStep 4-3. Firmware Upgrade \u0026amp; Module Patch Writing in Progress\nStep 5. Verify Successful Boot and NX-OS 9.4.5 Application After the switch reboots, reconnect via CLI and verify that the target version (NX-OS 9.4.5) is active and running.\n# Verify new OS version show version Step 5. Verify Normal Kernel/OS Boot and NX-OS 9.4.5 Upgrade Completion\nStep 6. Clean Up bootflash Storage using delete Command After completing the upgrade, delete the uploaded firmware binaries to prevent bootflash space exhaustion.\n# Check bootflash directory space dir bootflash: # Remove uploaded 9.4.5 System and Kickstart binaries to free disk space delete bootflash:m9000-pkg2.9.4.5.bin delete bootflash:m9000-kickstart-pkg2.9.4.5.bin # Verify reclaimed free space dir bootflash: Step 6. Clean Up bootflash using delete Command Post-Upgrade\n4. 🚨 Troubleshooting Notes (Field Realities) Issue 1: Host key verification failed during SCP Transfer Error Message: error: ssh connect failed / Host key verification failed Root Cause: Cipher algorithm mismatch between the switch SSH client and laptop Rebex SCP server. Resolution: # Explicitly allow key-exchange algorithm on switch CLI switch(config)# ip ssh client algorithm key-exchange dh-group14-sha1 5. Verification Checklist OS Version: show version ➔ Confirm system: version 9.4(5). SAN Port States: show interface fc1/1-48 status ➔ All operational FC ports remain Online. bootflash Capacity: dir bootflash: ➔ Confirm reclaimed storage after delete. 6. Field Engineering Best Practices Always Clean Up bootflash:\nMDS switch bootflash has finite capacity. Leaving large binary packages will cause disk full errors during subsequent maintenance or core dump generation. 7. Summary Core Workflow: Version Check (show version) ➜ Rebex SCP Setup ➜ Transfer (copy scp:) ➜ Upgrade (install all) ➜ Verification ➜ Clean Up (delete). Storage Management via bootflash Cleanup: To prevent future system issues and disk full errors during subsequent operations, always delete uploaded installer files using the delete command after upgrading. ","permalink":"https://cknotes.kr/en/posts/hpe-sn6620c-firmware-upgrade-guide/","summary":"\u003ch2 id=\"1-background-why-nx-os-945-upgrade-was-necessary\"\u003e1. Background: Why NX-OS 9.4.5 Upgrade Was Necessary\u003c/h2\u003e\n\u003cp\u003eIn an enterprise customer environment running HPE SN6620C (Cisco MDS 9148T-based) 32Gb FC SAN switches, a firmware upgrade was requested to improve system stability.\u003c/p\u003e\n\u003cp\u003eThe legacy 9.2.2 release had known issues such as environmental sensor polling false positives (e.g., Amber LED triggers) and potential BIOS timeout risks during ISSU. Consequently, we chose \u003cstrong\u003eNX-OS 9.4(5)\u003c/strong\u003e, designated as the \u003cstrong\u003eRecommended Release\u003c/strong\u003e by both HPE and Cisco official advisories.\u003c/p\u003e","title":"[HPE SN6620C] Cisco NX-OS 9.4.5 Firmware Upgrade Guide"},{"content":"While official vendor manuals exist, this guide is a real-world field record documenting the OS upgrade process using the new HPE Alletra 6000 UI. For engineers and administrators, the lack of step-by-step UI screenshots can make firmware upgrades intimidating. This guide provides clear visual walkthroughs from preparation to troubleshooting.\n📌 Task Overview Current OS Version: 6.1.2.500 Target OS Version: 6.1.3.300 Estimated Duration: ~ 2 hours (Includes image download, sequential node reboots, and patch application) 1. Firmware Image Preparation (Internet vs. Local) HPE Alletra supports two methods for preparing OS update files. Choose based on your environment:\nDirect Internet Download: If the storage array has external internet connectivity (e.g., connected to HPE InfoSight), you can check and download the latest version directly from the UI. Local File Upload: For air-gapped environments or manual version staging, upload the pre-downloaded firmware image file from your local PC via the browser. Alletra New UI Main Dashboard\n2. Step-by-Step Upgrade Process Step 1. Accessing the Software Menu Log in with administrator credentials and navigate to the Software section from the main menu. You can view the currently installed version (6.1.2.500) and available update actions.\nSoftware Management Menu Interface\nStep 2. Downloading \u0026amp; Uploading Firmware Proceed based on your selected method:\nDirect Internet Download: Clicking the \u0026lsquo;Download\u0026rsquo; button displays a list of available downloadable OS versions. Local Upload: Click the \u0026lsquo;Browse\u0026rsquo; button to select the pre-downloaded firmware file (.iso/.img) from your local PC. Available Downloadable OS Versions Window Displayed Upon Clicking Download\nClicking the \u0026lsquo;Browse\u0026rsquo; Button to Select Local Firmware File for Upload\nFirmware Image File Upload Progress Screen\nDirect Internet Download \u0026amp; Image Application Progress Screen\nStep 3. Pre-check Routine \u0026amp; Update Button Activation Once the file is staged, the system automatically runs a pre-check routine. (Screenshot missing). Once all system and volume health checks pass (Passed), the previously greyed-out Update button becomes active.\nStep 4. Clicking Update \u0026amp; EULA License Agreement Clicking the activated Update button opens the final End User License Agreement (EULA) popup dialog. Review and accept the EULA terms.\nEULA License Agreement Dialog Displayed After Clicking Update\nStep 5. Initiating OS \u0026amp; Firmware Update \u0026amp; Monitoring Upon accepting the EULA, controller nodes reboot sequentially to apply the new OS and component firmware patches. The UI displays real-time percentage (%) progress.\nOS Update In-Progress Screen\nStep 6. Completion \u0026amp; Version Verification After all nodes finish rebooting and patch application completes, return to the main dashboard to verify the target version (6.1.3.300).\nFinal OS Version (6.1.3.300) Verification\n💡 Note: During the OS upgrade process, hardware component FW (firmware) updates are automatically performed if necessary.\n🚨 [Caution] Local Upload Troubleshooting Story Sharing a critical mistake experienced during local file staging:\nInitially, for an air-gapped setup, the 2.5 GB firmware file was being downloaded on a local work PC. Due to large file size, the download took time. Out of urgency, an incomplete temporary file (a .part file) was uploaded to the Alletra UI without verifying completeness.\nNaturally, the UI threw a file corruption / checksum error and halted the upload process.\nFortunately, the storage system had external internet access. Pivoting immediately to direct internet download from within the Alletra UI allowed the download of the 2.5 GB file in ~30 minutes, saving the task.\nAlways double-check that local file downloads are 100% complete before uploading. A simple rule, but easily overlooked under field pressure!\nVisualizing actual UI screenshots makes field work significantly smoother. Task completed successfully!\n","permalink":"https://cknotes.kr/en/posts/hpe-alletra-6000-firmware-upgrade-guide/","summary":"\u003cp\u003eWhile official vendor manuals exist, this guide is a real-world field record documenting the OS upgrade process using the new HPE Alletra 6000 UI. For engineers and administrators, the lack of step-by-step UI screenshots can make firmware upgrades intimidating. This guide provides clear visual walkthroughs from preparation to troubleshooting.\u003c/p\u003e\n\u003ch3 id=\"-task-overview\"\u003e📌 Task Overview\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eCurrent OS Version\u003c/strong\u003e: 6.1.2.500\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTarget OS Version\u003c/strong\u003e: 6.1.3.300\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEstimated Duration\u003c/strong\u003e: ~ 2 hours (Includes image download, sequential node reboots, and patch application)\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch3 id=\"1-firmware-image-preparation-internet-vs-local\"\u003e1. Firmware Image Preparation (Internet vs. Local)\u003c/h3\u003e\n\u003cp\u003eHPE Alletra supports two methods for preparing OS update files. Choose based on your environment:\u003c/p\u003e","title":"[HPE Alletra 6000] OS Firmware Upgrade Hands-on Guide"},{"content":"When production database or application servers running RHEL, Rocky Linux, CentOS (7 ~ 9), or Ubuntu (20.04 ~ 24.04 LTS) reach 90%+ disk utilization, scheduling emergency maintenance downtime is rarely an acceptable option. In modern virtualization (VMware, KVM, Nutanix, SimpliVity) and cloud infrastructures, performing 100% online, non-disruptive storage expansion is an essential skill for system engineers.\nHere is the battle-tested standard operating procedure for triggering a kernel SCSI bus rescan, extending LVM physical/logical volumes, and expanding filesystems (XFS vs EXT4) without unmounting.\n1. The 4-Step Process flowchart LR A[\u0026#34;1. Expand VM/Storage Disk\u0026#34;] --\u0026gt; B[\u0026#34;2. Trigger OS SCSI Bus Rescan\u0026#34;] B --\u0026gt; C[\u0026#34;3. Extend LVM (pvresize / lvextend)\u0026#34;] C --\u0026gt; D[\u0026#34;4. Grow Filesystem (xfs_growfs / resize2fs)\u0026#34;] 2. Step 1: Trigger SCSI Bus Rescan in Linux Kernel After increasing disk size in your hypervisor or SAN storage (e.g., 100GB to 200GB), the Linux kernel does not automatically notice the change. You can trigger a rescan without rebooting:\n# Verify disk name lsblk # Trigger rescan on specific disk (e.g. /dev/sdb) echo 1 \u0026gt; /sys/class/block/sdb/device/rescan To rescan all SCSI hosts at once:\nfor host in /sys/class/scsi_host/host*/scan; do echo \u0026#34;- - -\u0026#34; \u0026gt; ${host}; done Check dmesg and lsblk to verify the new capacity:\ndmesg | tail -n 15 lsblk /dev/sdb 3. Step 2: Resize Partition Table (If Partitioned) If the entire raw disk was formatted directly as an LVM Physical Volume (pvcreate /dev/sdb), skip to Step 3.\nIf partitioned (/dev/sdb1), grow the partition using growpart:\n# Install growpart if not already present # RHEL/Rocky: yum install -y cloud-utils-growpart # Ubuntu: apt install -y cloud-guest-utils # Expand partition 1 on /dev/sdb growpart /dev/sdb 1 4. Step 3: Extend LVM Physical \u0026amp; Logical Volumes 1) Update Physical Volume (PV) pvresize /dev/sdb # (or pvresize /dev/sdb1 if using a partition) # Verify new Free Space pvs vgs 2) Extend Logical Volume (LV) # Add 50GB lvextend -L +50G /dev/mapper/vg_data-lv_data # Or allocate 100% of remaining free space in Volume Group (most common) lvextend -l +100%FREE /dev/mapper/vg_data-lv_data 5. Step 4: Online Filesystem Growth (XFS vs EXT4) Identify your filesystem type:\ndf -Th /data For XFS (Default on RHEL / Rocky / CentOS): Specify the mount point directory:\nxfs_growfs /data ⚠️ Important Field Note : XFS supports online expansion seamlessly, butcannot be shrunk. Never over-allocate if you expect to reduce storage later.\nFor EXT4 (Default on Ubuntu / Debian): Specify the logical volume block device path:\nresize2fs /dev/mapper/vg_data-lv_data 6. Verification Confirm the new usable capacity:\ndf -h /data The available storage updates immediately without zero impact on active I/O workloads.\n","permalink":"https://cknotes.kr/en/posts/linux-online-lvm-disk-expansion-guide/","summary":"\u003cp\u003eWhen production database or application servers running RHEL, Rocky Linux, CentOS (7 ~ 9), or Ubuntu (20.04 ~ 24.04 LTS) reach 90%+ disk utilization, scheduling emergency maintenance downtime is rarely an acceptable option. In modern virtualization (VMware, KVM, Nutanix, SimpliVity) and cloud infrastructures, performing \u003cstrong\u003e100% online, non-disruptive storage expansion\u003c/strong\u003e is an essential skill for system engineers.\u003c/p\u003e\n\u003cp\u003eHere is the battle-tested standard operating procedure for triggering a kernel SCSI bus rescan, extending LVM physical/logical volumes, and expanding filesystems (XFS vs EXT4) without unmounting.\u003c/p\u003e","title":"[Linux Guide] Online Disk Expansion Without Reboot \u0026 LVM Resizing"},{"content":"After completing the deployment of an HPE SimpliVity 6.2.0 and VME (VM Essentials) cluster, the next operational milestone is provisioning workload virtual machines (VMs, Instances) and installing target guest operating systems (Linux, Windows Server).\nIn VM Essentials, deploying virtual machines from scratch requires registering OS installation ISO media in the Virtual Image Library. To ensure high-capacity ISO files are stably retained and universally accessible across all cluster nodes, an NFS file share storage backend must be pre-integrated into VME Manager.\nThis guide details the complete operational procedure—from registering the management server\u0026rsquo;s NFS export folder as a VME image store to uploading OS installation ISO files and verifying their backend directory paths. It also covers practical workarounds for browser upload timeouts on large ISO files and essential NFS export permission considerations.\n1. End-to-End Workflow Registering virtual images into VME Manager involves four sequential phases: backend verification, file share attachment, ISO upload, and storage path validation.\nflowchart TD Step1[\u0026#34;Phase 1: Verify NFS Server Export\u0026lt;br/\u0026gt;(Host CLI: exportfs -v)\u0026#34;] --\u0026gt; Step2 Step2[\u0026#34;Phase 2: Attach NFS File Share in VME Manager\u0026lt;br/\u0026gt;(Infrastructure \u0026gt; Storage \u0026gt; File Shares \u0026gt; NFSv3)\u0026#34;] --\u0026gt; Step3 Step3[\u0026#34;Phase 3: Register ISO in Virtual Images Library\u0026lt;br/\u0026gt;(Library \u0026gt; Virtual Images \u0026gt; + Add \u0026gt; ISO)\u0026#34;] --\u0026gt; Step4 Step4[\u0026#34;Phase 4: Confirm Upload \u0026amp; Storage Hierarchy\u0026lt;br/\u0026gt;(Inspect morpheus-virtual-images path)\u0026#34;] 2. Essential Prerequisites \u0026amp; Verification Review these three prerequisites before initiating uploads to avoid provisioning roadblocks:\nEnable \u0026lsquo;Default Virtual Image Store\u0026rsquo;\nWhen configuring an NFS file share in VME Manager, always check Default Virtual Image Store. This flag designates the share as the default repository bucket for virtual images, ensuring cluster nodes can reference the images during VM provisioning without path resolution errors. NFS Export Permissions (no_root_squash)\nVME Manager service daemons require write permissions to create subdirectories and stream multi-gigabyte ISO files. Ensure the host /etc/exports includes rw,no_root_squash,no_subtree_check. Internal Directory Structure of VME Images\nVME does not dump uploaded ISO files into the root of /nfs. Instead, it stores them within an isolated directory hierarchy: /nfs/morpheus-virtual-images/\u0026lt;NumericID\u0026gt;/\u0026lt;filename.iso\u0026gt;. 3. Step-by-Step ISO Registration Guide Step 01. Verify NFS Server Export Status (CLI) Verify that the NFS service on the management server (Ubuntu BaseOS) is actively exporting the target directory (/nfs):\n# Verify active NFS exports root@vmemgr:/home/vmeadmin# exportfs -v Confirm that the output includes proper export options such as /nfs \u0026lt;world\u0026gt;(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash).\nStep 02. Navigate to Storage File Shares Menu Log into the VM Essentials Manager console (https://\u0026lt;VME_Manager_IP\u0026gt;):\nNavigate to [Infrastructure] -\u0026gt; [Storage]. Select the File Shares tab. Click the **[+ Add]**dropdown on the right and select NFSv3. Step 03. Configure New File Share Parameters In the New File Share modal, enter the configuration parameters:\nNAME: Identifier for the share (e.g., nfs) HOST: IP address of the NFS host (management server IP) EXPORT: Export directory path (e.g., /nfs) Checkbox Options: [✔] Active: Checked [ ] Default Backup Target: Unchecked [ ] Default Deployment Archive Target: Unchecked [✔] Default Virtual Image Store: Required Click [Save Changes] at the bottom right. Step 04. Confirm File Share Attachment Upon returning to the File Shares view, the registered NFS share will be listed:\nNAME: nfs TYPE: Nfs PATH: \u0026lt;NFS_Server_IP\u0026gt;:/nfs Step 05. Open Virtual Images Library To upload the ISO file:\nNavigate to [Library] -\u0026gt; [Virtual Images]. Click the top-right [+ Add] dropdown and select ISO. Step 06. Specify Virtual Image Metadata \u0026amp; Storage Bucket In the Upload Virtual Image modal, enter the image properties:\nNAME: Display name for VM provisioning (e.g., Ubuntu 22.04 or Windows Server 2022) OS: Target operating system family (e.g., ubuntu 22.04 64-bit) MIN MEMORY: Default 0 MB STORAGE BUCKET: Select the nfs share created in Step 03 IMAGE ID SOURCE: Select the ● File radio button Step 07. Upload Image File and Configure Virtualization Flags Scroll down to upload the media file and confirm compatibility flags:\nFile Upload: Click [Add File] or drag and drop the ISO image (e.g., ubuntu-22.04.5-live-server-amd64.iso). Wait until the upload progress reaches 100%. Advanced Settings: [✔] VirtIO Drivers Loaded?: Checked for modern Linux distributions (verify VirtIO injection for Windows) [✔] VM Tools Installed?: Checked Specify UEFI, Secure Boot, or vTPM flags based on OS requirements. Click [Save Changes]. Step 08. Verify Image Active Status in Library Once uploaded, the new ISO image appears in the Virtual Images table:\nTYPE: ISO NAME: Ubuntu PLATFORM: ubuntu 22.04 64-bit SIZE: Actual file size (e.g., 2.0 GiB) SOURCE: Uploaded STATUS: Active Step 09. Verify Storage Directory Structure Inspect the backend NFS filesystem path:\nNavigate to [Infrastructure] -\u0026gt; [Storage] -\u0026gt; [File Shares] -\u0026gt; nfs. The file browser confirms the path: nfs / morpheus-virtual-images / 19 / ubuntu-22.04.5-live-server-amd64.iso\nVME cleanly assigns a dedicated numeric ID subdirectory to maintain structured isolation. 4. Attaching the ISO to Virtual Machines With the image registered, attach it to guest instances during provisioning:\nNavigate to [Provisioning] -\u0026gt; [Instances] -\u0026gt; [+ Add]. Select instance technology (KVM or HVM). In the storage phase, map the CD ROM drive to Ubuntu (ISO). Power on the VM to boot directly from the media and proceed with installation. 5. Field Troubleshooting: Upload Timeouts and Permissions [!WARNING] Browser Disconnect During Large ISO Uploads (5GB+)\nCause: Short client body timeout configurations on ingress proxies or load balancers. Resolution: Instead of browser-based uploads, copy the file directly to /nfs via SCP on the management host. In the VME image registration dialog, select ● URL/PATH (file:///nfs/...) to index the local file instantly without network streaming delays. [!WARNING] Virtual Image Status Displays \u0026lsquo;Error\u0026rsquo; or \u0026lsquo;Failed\u0026rsquo;\nCause: Insufficient capacity on the NFS volume or permission denial when creating morpheus-virtual-images. Resolution: Check available disk capacity with df -h /nfs and verify write permissions on the directory (chmod -R 775 /nfs). 6. Summary Configuring the ISO library in HPE VME bridges foundational cluster deployment with active workload provisioning.\nEnsuring that the NFS share has Default Virtual Image Store enabled and no_root_squash configured eliminates common permission and discovery issues, providing a seamless foundation for ongoing VM deployments.\n","permalink":"https://cknotes.kr/en/posts/simplivity-vme-iso-image-upload-guide/","summary":"\u003cp\u003eAfter completing the deployment of an HPE SimpliVity 6.2.0 and VME (VM Essentials) cluster, the next operational milestone is provisioning workload virtual machines (VMs, Instances) and installing target guest operating systems (Linux, Windows Server).\u003c/p\u003e\n\u003cp\u003eIn VM Essentials, deploying virtual machines from scratch requires registering OS installation ISO media in the Virtual Image Library. To ensure high-capacity ISO files are stably retained and universally accessible across all cluster nodes, an NFS file share storage backend must be pre-integrated into VME Manager.\u003c/p\u003e","title":"[HPE VME] ISO Image Registration \u0026 NFS Storage Integration Guide"},{"content":"After initial deployment of an HPE SimpliVity HVM or VME (VM Essentials) cluster, only the default Management network is configured. Putting production workload virtual machines (VMs) into service requires adding dedicated data networks or tenant VLANs.\nThe deployment workflow consists of two primary stages: creating a network bond interface at the physical host layer (via HPE VM Console TUI), and then mapping it as an Open vSwitch (OVS) network router within the VME Manager web console to attach to VMs.\nThis guide outlines the standard operating procedure from TUI host bonding to VME router mapping and VM vNIC provisioning. It also highlights a crucial field design practice—why you should always encapsulate single physical links in a bond interface—as well as practical troubleshooting steps for lingering OVS ghost port errors.\n1. End-to-End Workflow Adding an external network to HVM hosts and attaching it to VMs is cleanly separated between the physical host and virtualization management layers.\nflowchart TD subgraph HostLevel[\u0026#34;Layer 1: Physical Host Level (HPE VM Console TUI)\u0026#34;] A1[\u0026#34;Access HPE VM Console\u0026lt;br/\u0026gt;(Configure Network)\u0026#34;] --\u0026gt; A2[\u0026#34;Select Device Type: bond(0) \u0026amp; Add\u0026#34;] A2 --\u0026gt; A3[\u0026#34;Specify Bond Device ID\u0026lt;br/\u0026gt;(e.g., net-10g)\u0026#34;] A3 --\u0026gt; A4[\u0026#34;Select Member Physical Interface\u0026lt;br/\u0026gt;(e.g., eno2)\u0026#34;] A4 --\u0026gt; A5[\u0026#34;Set Bonding Mode\u0026lt;br/\u0026gt;(active-backup, etc.)\u0026#34;] A5 --\u0026gt; A6[\u0026#34;Save \u0026amp; Apply Netplan\u0026lt;br/\u0026gt;(Netplan changes applied)\u0026#34;] end subgraph VMELevel[\u0026#34;Layer 2: Management Web Console (VME Manager Web GUI)\u0026#34;] B1[\u0026#34;Navigate to Infrastructure \u0026gt; Network \u0026gt; Routers\u0026#34;] --\u0026gt; B2[\u0026#34;Click + Add to create Network Router\u0026#34;] B2 --\u0026gt; B3[\u0026#34;Map GROUP / CLOUD / NAME / CLUSTER /\u0026lt;br/\u0026gt;Host Bridge \u0026amp; Network Interface\u0026#34;] B3 --\u0026gt; B4[\u0026#34;Verify Router Status\u0026lt;br/\u0026gt;(STATUS: OK, OVS Bridge Domain)\u0026#34;] B4 --\u0026gt; B5[\u0026#34;Instance Reconfigure\u0026lt;br/\u0026gt;(Attach new network net-10g)\u0026#34;] end HostLevel --\u0026gt; VMELevel 2. Field Design Practice: Why Single NIC Environments Still Require Bonding During physical rollouts, upstream switch ports may not yet be provisioned, or rack cabling delays might require bringing up services with only a single physical link (e.g., eno2).\nA common pitfall in this situation is configuring the interface directly as a raw ethernet device and attaching it straight to the OVS bridge.\n[!WARNING] Drawback of Direct Single Ethernet Devices\nWhen the secondary switch port becomes available later and you want to implement high-availability (HA) teaming, you will have to tear down and rebuild the existing OVS bridge and all attached VM network mappings. This inevitably causes unnecessary service downtime for production workloads.\nKey Operational Reasons to Use bond (active-backup) for Single Links Zero-Downtime HA Scalability\nEven with a single cable, creating a bond (Device ID: net-10g, Mode: active-backup, Interface: eno2) establishes an extensible logical abstraction. When the secondary link (eno3) is patched later, you simply add eno3 to the bond members without touching the OVS bridge or restarting VMs. Configuration Immutability in VME Manager\nVME Manager binds to the higher-level logical device (net-10g). Physical NIC additions, swaps, or driver adjustments beneath the bond remain transparent to VME router bindings and VM vNIC configurations. Operational Consistency\nStandardizing all host network devices under consistent bond naming conventions (e.g., bond0, net-10g) simplifies long-term maintenance, documentation, and automation playbooks. [!TIP] Regardless of whether you currently have one or two cables connected, configuring host interfaces as a bond in active-backup mode is the enterprise standard.\n3. [Part 1] HPE VM Console (TUI) Host Network Bonding Configuration Connect to the HVM host console (via iLO Remote Console or physical KVM) to configure bonding using the text-based HPE VM Console.\nStep 01. Enter Configure Network Menu On the HPE VM Console home screen, select \u0026lt;Configure Network\u0026gt; using arrow keys and press Enter.\nStep 02. Select bond(0) Device Type and \u0026lt;Add\u0026gt; From the Device Type dropdown, select bond(0) and select \u0026lt;Add\u0026gt;.\nStep 03. Specify Bond Device ID In the Add Device modal, confirm that Device Type is bond, enter the desired Device ID (e.g., net-10g), and click \u0026lt;Continue\u0026gt;.\nStep 04. Select Member Physical Interfaces Under the Bond tab in Edit Device, navigate to [ ] interfaces, select the physical interface (e.g., eno2) with the Space bar, and click \u0026lt;Done\u0026gt;.\n(※ Even in single link scenarios, select just eno2 and proceed.)\nStep 05. Configure Bonding Mode In the Edit parameters screen, select the bonding operation mode:\nFor standard active-passive redundancy or single NIC deployments, select mode: active-backup. If upstream switches have pre-configured LACP trunks, select 802.3ad. Click \u0026lt;Done\u0026gt; when finished. Step 06. Save Netplan Configuration Return to Configure Network and click \u0026lt;Save\u0026gt;. Confirm with \u0026lt;Yes\u0026gt; when prompted that Netplan changes may cause a disconnect.\nStep 07. Verify Netplan Applied Successfully Once Linux network configuration completes, Netplan changes applied is displayed. Click \u0026lt;OK\u0026gt; to exit the console.\n4. [Part 2] VME Manager Web Console: Router Registration \u0026amp; VM Attachment With net-10g active at the host OS layer, register it as a logical router in VME Manager and attach it to virtual instances.\nStep 08. Navigate to Network \u0026gt; Routers and Click + Add Log into VME Manager (https://\u0026lt;VME_Manager_IP\u0026gt;), navigate to [Infrastructure] -\u0026gt; [Network] -\u0026gt; [Routers], and click the green [+ Add] button.\nStep 09. Configure Router Parameters \u0026amp; Interface Mapping In the ADD NETWORK ROUTER modal, enter the configuration details:\nGROUP: Target management group (e.g., vme-grp) CLOUD: Connected cloud environment (e.g., vme-cloud) NAME: Identifier for the router (e.g., 10g-net) CLUSTER: Target HVM cluster (e.g., prod-cluster) HOST BRIDGE: Name for the OVS bridge (e.g., 10g-net) NETWORK INTERFACE: Select the bond interface created in Part 1 (e.g., net-10 or test dummy0). [!CAUTION] Avoid OVS Bridge Name Collisions\nDo not use names of existing bridges on the host (such as the default management bridge mgmt). Duplicate bridge names will cause router provisioning to fail.\nStep 10. Verify Router Status Once provisioned, the new router appears in the Routers list:\nSTATUS: Green checkmark (Active/OK) NAME: Assigned router name (net-10g) ROUTER TYPE: OVS Bridge Domain GROUP: Correct management group binding Step 11. Attach Network to Virtual Machine Attach the new network to your workload instances:\nNavigate to [Provisioning] -\u0026gt; [Instances] and select the target VM. In the instance details view, click Reconfigure from the top-right action menu. In the NETWORKS section, click the + button. Select net-10g from the network dropdown and configure IP addressing (DHCP or Static). Click [Reconfigure] to dynamically attach the virtual NIC. 5. Network Separation Considerations for SimpliVity HVM Clusters Unlike standalone HVM nodes, HPE SimpliVity 6.2.0 (HVM) clusters require strict physical isolation between workload traffic and storage backbones.\n+-----------------------------------------------------------------------+ | HPE SimpliVity Physical Node | | | | [ Dedicated 10G/25G PCIe NIC ] ---\u0026gt; SimpliVity OVC Storage Controller| | - Storage Network (MTU 9000, VLAN 151) : Real-time block replication| | - Federation Network (MTU 9000, VLAN 153) : Cluster metadata | | * Workload VM traffic is strictly prohibited on these links! | | | | [ Onboard LOM / Extra PCIe NIC (eno1–eno4) ] --\u0026gt; OVS Bond (net-10g) | | - Production Workload VM Application Traffic | +-----------------------------------------------------------------------+ Isolate OVC Storage \u0026amp; Federation Interfaces\nOmniStack Virtual Controllers (OVC) use dedicated 10GbE interfaces (ens21f0np0, ens21f1np1) with jumbo frames (MTU 9000) for real-time deduplication and synchronous mirroring. Never share OVC storage interfaces with VM workloads. Use separate onboard LOM ports (eno1–eno4) or dedicated workload PCIe NICs. Maintain Identical Bridge Topology Across All Cluster Nodes\nTo ensure seamless VM live migrations (vMotion), create identical bond names and OVS bridge configurations across every host in the cluster. 6. Field Troubleshooting: Clearing OVS Ghost Ports If a virtual machine crashes or is deleted improperly, orphaned virtual interfaces (ghost ports) may linger inside the Open vSwitch database, generating errors.\nRunning ovs-vsctl show on the host CLI may display:\nroot@vmemgr:/home/vmeadmin# ovs-vsctl show 4ea92630-835f-4664-83bc-01936dc54090 Bridge mgmt fail_mode: standalone Port eno2 Interface eno2 Port vnet17 Interface vnet17 error: \u0026#34;could not open network device vnet17 (No such device)\u0026#34; Port vnet2 Interface vnet2 error: \u0026#34;could not open network device vnet2 (No such device)\u0026#34; Port vnet3 Interface vnet3 error: \u0026#34;could not open network device vnet3 (No such device)\u0026#34; Port mgmt Interface mgmt type: internal You can cleanly resolve this by manually pruning the stale ports from the bridge:\n# Delete orphaned vnet ports sudo ovs-vsctl del-port mgmt vnet17 sudo ovs-vsctl del-port mgmt vnet2 sudo ovs-vsctl del-port mgmt vnet3 # Verify OVS status ovs-vsctl show After removal, ovs-vsctl show will reflect a clean bridge state containing only active ports (eno2, mgmt).\n7. Summary Network provisioning in HPE VME and SimpliVity clusters hinges on standard host-level bonding paired with flexible VME OVS router abstraction.\nThe workflow is straightforward, but adhering to two core practices—bonding even single links from day one andstrictly isolating storage backbone fabrics—ensures reliable long-term operations and non-disruptive capacity expansion.\n","permalink":"https://cknotes.kr/en/posts/simplivity-vme-network-add-bonding-guide/","summary":"\u003cp\u003eAfter initial deployment of an HPE SimpliVity HVM or VME (VM Essentials) cluster, only the default Management network is configured. Putting production workload virtual machines (VMs) into service requires adding dedicated data networks or tenant VLANs.\u003c/p\u003e\n\u003cp\u003eThe deployment workflow consists of two primary stages: creating a network bond interface at the physical host layer (via HPE VM Console TUI), and then mapping it as an Open vSwitch (OVS) network router within the VME Manager web console to attach to VMs.\u003c/p\u003e","title":"[HPE VME] HVM Network Addition \u0026 Bonding Guide"},{"content":"Working with IT infrastructure systems for many years creates a habit of analyzing every decision—even personal vehicle choices—through the lens of cost-to-benefit ratios and risk management.\nRecently, as I began looking for a car to handle daily commuting and client visits, Hyundai\u0026rsquo;s hydrogen fuel cell vehicle, the NEXO, entered my shortlist.\nWhile the upcoming 2nd-generation The All-New NEXO—featuring bold boxy SUV styling and modern pixel lighting derived from the INITIUM concept—looks appealing, evaluating the purchase methods brings a classic dilemma:\n\u0026ldquo;Paying full sticker price (actual purchase price around 38 to 40 million KRW after subsidies) means facing steep hydrogen EV depreciation over 3 years\u0026hellip; Should I pick up a 1st-generation used NEXO that has already dropped to roughly 15 million KRW? Or opt for Hyundai\u0026rsquo;s guaranteed residual buyback program on the new generation to cap the downside?\u0026rdquo;\nHere is a realistic look at the numbers and trade-offs when calculated across a 3-year ownership horizon.\n1. Realistic fact in everyday life: “If you ride for 3 years anyway, 10 to 20 million won will disappear.” When buying a car, whether new or used, there are things you miss by simply looking at the ‘vehicle price’. It is Depreciation (money that disappears over time).\nReality of 3-year depreciation of new car (The All New Nexo): Even if a new car is released at an actual purchase price of 40 million won with local government subsidies, the used car price will drop to about 20 to 23 million won after 3 to 4 years due to the steep depreciation unique to hydrogen cars. 👉 In other words, the net loss that just \u0026rsquo;evaporates\u0026rsquo; from my bank account through depreciation over 3 years is about 17 to 20 million won.\nMarket price reality for 1st generation used Nexo: Currently, the market price for the 2019-2021 model year 1st generation Nexo accident-free used car at Encana K Car is approximately 14 to 17 million won. 👉 Surprisingly, the money you pay to buy an entire 1st generation used Nexo is almost the same as the depreciation loss lost when you drive the new car, The All New Nexo, for 3 years! In the end, the essence of this concern is a matter of choice:\u0026ldquo;If 15 to 20 million won will come out of my pocket over 3 years anyway, what will I gain with that cost and what risks will I avoid?\u0026rdquo;\n2. Concern 1: New ‘The All New Nexo’ + Burden Reduction Program This is an option to protect yourself from the hydrogen car depreciation bomb while riding the all-new 2nd generation The All New Nexo.\n💡 Key benefits in everyday life: “Get rid of worries about depreciation and breakdown” Hyundai Motor Company\u0026rsquo;s \u0026lsquo;burden down program\u0026rsquo; applies a deferred installment payment method for a low initial cost, and the financial company definitely guarantees the residual value of the used car (approximately 55 to 60%) upon maturity after three years.\nFrom the perspective of a car owner who drives the car on a daily basis, the advantages of this method are quite clear:\nConveniently pay for depreciation that will disappear in monthly installments: You can take the depreciation loss of 15 to 20 million won, which will disappear in the air over three years, by breaking it down into low monthly payments of 200,000 to 300,000 won. Zero stress due to plummeting used car prices: Even if the price of hydrogen cars bottoms out after three years, if you return the car to a financial company (buy-back), the contract will be completed without loss. Convenience and repair costs of \u0026lsquo;0 won\u0026rsquo; for the latest new cars: Improved 3rd generation high durability fuel cell stack (improved winter startability and durability) Generous driving range of over 650km and 3.6kW V2L support indoors and outdoors, useful for outdoor camping/vehicle camping The latest ccNC wireless navigation and driving assistance system 10-year, 160,000 km free warranty for new vehicles throughout the 3-year driving period ➔ No need to worry about repair costs 3. Concern 2: Direct purchase of the ‘1st generation used Nexo’, the best value for money This is a method of purchasing a used 1st generation Nexo, which has already reached the bottom of its price range, for around 15 million won.\n👍 Advantage: Even in the worst case, the amount of money you can lose is limited (Max Loss limited) Even if I buy it for 15 million won, drive it for 3 years, and the used market price drops to 5 million won, or in the worst case scenario, scrap the car, the maximum amount I can lose is capped at 15 million won. You can enjoy the spacious space of a luxury SUV priced at 70 million won at the time and abundant options such as adaptive cruise, remote smart parking, and ventilated seats at the used Avante price. The sweet maintenance cost benefits of hydrogen cars, such as a 50% discount on highway tolls, half-price public parking, and an annual automobile tax of 130,000 won, are 100% the same as new cars. ⚠️ Realistic worry: The pressure of the looming warranty expiration Used items priced at 15 million won are usually 4 to 6 years old and have an accumulated mileage of 60,000 to 100,000 km. Hyundai Motor Company’s free warranty for hydrogen-specific parts is **10 years / 160,000 km **. In other words,only half of the warranty remains. If, by any chance, a defect occurs in the fuel cell stack after the warranty period ends, the replacement estimate alone will cost more than 40 million won, so the fact that I may have to give up the car is weighing on my heart. 4. Real-World Cost and Risk Comparison Table Assuming you\u0026rsquo;ll keep the car for three years, we\u0026rsquo;ve compared the two options side by side in a table:\nFeature / Metric Direct Purchase: 1st Gen Used NEXO (2019–2021) The All-New NEXO + Guaranteed Buyback (New) **Estimated 3-year extinction cost ** **Vehicle depreciation loss of approximately 7 to 10 million won ** Total payment (depreciation amount) over 3 years: approximately 12 to 18 million won **Initial lump sum burden ** **Approximately 14 to 17 million won **(Lump sum expenditure) Advance fee ranges from 0 won to several million won (preservation of lump sum) **Vehicle Productivity ** 1st generation model / V2L not supported / Previous generation info 2nd generation full change (3rd generation stack, V2L, ccNC) **Stack Remaining Guarantee ** Remaining 4 to 5 years / Remaining 60,000 to 90,000 km New car 10-year/160,000 km full warranty (0 won repair fee) **Certain failure risk ** **Caution required **(Stack cannot be replaced after warranty ends) No worries (100% free care within the warranty period) **Disposal after 3 years ** Sell ​​directly to a used car dealer (market price supervised) Clearly completed with guaranteed residual value upon return 5. Conclusion: What are my selection criteria in everyday life? In the end, once you acknowledge the reality that around 10 to 20 million won worth of money will disappear due to depreciation over the course of three years, the criteria for selection become simpler than you think:\n🎯 Those who are suitable for the 1st generation used Nexo \u0026ldquo;I want to achieve the best cost-effectiveness by reducing even the depreciation costs that will last for three years as much as possible!\u0026rdquo; Those whose annual mileage is less than 10,000 km, so they don’t have to worry about the 160,000 km warranty expiring even if they drive for a few more years. A practical person who wants to ride frugally at around 15 million won and then recover the residual value (5 to 8 million won) 🎯 Those who are suited for The All New Nexo + a stress-free program \u0026ldquo;Anyway, if I drive for 3 years, the money will be lost by 15 million won in depreciation, but I would rather drive the latest new car comfortably without worrying about breakdowns!\u0026rdquo; Those who want to enjoy camping/car camping V2L electric utilization, stylish second-generation boxy design, and the latest cutting-edge driving assistance People who want to coolly return the 1st generation stack and move on to the next car after 3 years without worrying about durability or the stress of selling a used car later Choosing and maintaining a car in daily life always seems to be both exciting and agonizing. Which choice are you more attracted to: \u0026lsquo;A 15 million won used 1st generation Nexo\u0026rsquo; or \u0026lsquo;The All New Nexo\u0026rsquo;, which you can enjoy by paying the depreciation over 3 years in installments? 😊\n","permalink":"https://cknotes.kr/en/posts/nexo-used-vs-smart-down/","summary":"\u003cp\u003eWorking with IT infrastructure systems for many years creates a habit of analyzing every decision—even personal vehicle choices—through the lens of cost-to-benefit ratios and risk management.\u003c/p\u003e\n\u003cp\u003eRecently, as I began looking for a car to handle daily commuting and client visits, Hyundai\u0026rsquo;s hydrogen fuel cell vehicle, the NEXO, entered my shortlist.\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"The All-New NEXO, running on coastal roads\" loading=\"lazy\" src=\"/posts/nexo-used-vs-smart-down/images/the_all_new_nexo.jpg\"\u003e\u003c/p\u003e\n\u003cp\u003eWhile the upcoming 2nd-generation \u003cstrong\u003eThe All-New NEXO\u003c/strong\u003e—featuring bold boxy SUV styling and modern pixel lighting derived from the INITIUM concept—looks appealing, evaluating the purchase methods brings a classic dilemma:\u003c/p\u003e","title":"[Lifestyle] 'The All-New NEXO Buyback' vs. '1st Gen Used NEXO'"},{"content":"Operating Cisco MDS SAN switches—the storage fabric backbone in enterprise datacenters—requires real-time telemetry into hardware component health (fans, power supplies, thermal sensors), FC port link state, and fabric zoning events via an integrated Network Management System (NMS: Zabbix, PRTG, Nagios).\nA frequent misconfiguration in production is executing snmp-server enable traps globally. Indiscriminately enabling every trap floods the monitoring collectors with low-severity debug notifications, triggering trap storms and elevating switch CPU utilization.\nEnterprise best practice dictates selectively activating only high-impact MIB trap categories.\nThis guide outlines the standard configuration sequence for SNMP v2c (Community, Host), selective MIB trap enablement, running configuration persistence, and official Cisco MIB dependencies for NMS ingestion.\n1. Example of pre-preparation and setting parameters The basic parameters of the practical and field application environment are defined as follows:\nitem Example settings explanation Equipment Model Cisco MDS 9148S SAN Fabric Switch **SNMP Version ** v2c The most widely used standard SNMP version in practice **Community String ** SDS (example) For security reasons, use the organization standard name instead of the default public **Access Rights ** ro (Read-Only) Read-only permission for NMS collection **NMS Monitoring Server IP ** 192.168.100.10 Monitoring server IP to receive trap events **Trap listening port ** UDP 162 Standard SNMP Trap Port 2. Basic SNMP environment settings (Community \u0026amp; Host Trap) First, connect to the MDS switch using a terminal console or SSH and enter global configuration mode (config terminal).\n2.1. Execute command # 전역 설정 모드 진입 conf t # 1. SNMP Community String 생성 및 Read-Only(ro) 권한 부여 snmp-server community SDS ro # 2. NMS 모니터링 서버로 SNMP Trap 전송 설정 (버전 v2c) snmp-server host 192.168.100.10 traps version 2c SDS 2.2. terminal run screen [!TIP] Community Security Recommendations \u0026gt; Community for monitoring purposes must be set toro (Read-Only). If set to rw (Read-Write), there is a risk of the switch settings being arbitrarily changed from outside through SNMP vulnerability.\n3. Individual activation of major MIB notifications based on Reference Guide Based on the list of important MIBs in the source and official reference guides, only notifications that should never be missed in practice are individually activated.\n3.1. Hardware and entity management (related to ENTITY-MIB) This is an essential setting to immediately detect physical failures such as physical components of the switch chassis, power supply unit (PSU), and cooling fan tray.\n# 물리적 엔티티 및 센서(온도, 전압 등) 상태 변경 알림 snmp-server enable traps entity # 현장 교체 가능 유닛(FRU: 파워서플라이, 팬 등) 장애/탈착 알림 snmp-server enable traps entity fru 3.2. Interface state management (related to IF-MIB) Detects changes in the Link Up / Down status of FC (Fibre Channel) ports connected to server HBA or storage ports.\n# FC 포트 링크 상태 변경 알림 (기본적으로 IETF extended 알림 활성화) snmp-server enable traps link Note: You can optionally refine the notification type by adding the snmp-server enable traps link cisco or ietf options.\n3.3. Hardware and Interface Notifications Terminal Screen 3.4. Fabric and virtual SAN management (related to CISCO-DM, FCNS, ZONE MIB) Real-time monitoring of FC domain, name server, and zone configuration changes, which are core functions unique to SAN switches. This is a key notification that catches storage path loss or unauthorized zone changes.\n# FC 도메인 관리 알림 (도메인 ID 변경, 리컨피규레이션 등) snmp-server enable traps fcdomain # 네임 서버(FCNS) 알림 (신규 서버 포트 플러그인 / 로그인 해제 감지) snmp-server enable traps fcns # 존(Zone) 구성 및 활성 Zoneset 변경 알림 snmp-server enable traps zone 3.5. Security and system management (related to AAA, SNMPv2-MIB) Detects communication problems with the switch login authentication server or unauthorized access attempts through an incorrect community.\n# AAA 서버(TACACS+ / RADIUS) 연동 및 인증 알림 snmp-server enable traps aaa # SNMP 인증 실패(잘못된 커뮤니티 접근 등) 알림 snmp-server enable traps snmp authentication 3.6. Fabric and Security Notification Terminal Screen 4. Permanent saving and verification of settings (Save \u0026amp; Verification) Since Cisco MDS switches are NX-OS based, the current running memory configuration (running-config) must be saved as the startup configuration (startup-config) in NVRAM to preserve the configuration across reboots.\n4.1. Save Config # 설정 모드 종료 end # NVRAM 영구 저장 copy running-config startup-config 4.2. Configuration verification command (Verification) Verify that the community and host traps are registered properly:\n# 1. 등록된 SNMP Community 확인 show snmp community # 2. 등록된 Trap 수신 호스트(NMS) 확인 show snmp host # 3. 활성화된 Trap 항목 전체 확인 show snmp trap 4.3. Save and Verify Terminal Screen 5. Required MIB file information for NMS server For the NMS monitoring server (Zabbix, PRTG, etc.) to parse the OID numbers (e.g. .1.3.6.1.4.1.9...) received from the MDS switch into human-readable names (ciscoMds..., entPhysicalDescr), Cisco MIB files must be registered in the MIB directory of the NMS server.\n5.1. Required MIB file list The six MIB files below are key files for interpreting the notifications set in this post:\nSNMPv2-SMI.my: SNMPv2 structure definition base MIB SNMPv2-MIB.my: System basic information and authentication trap MIB RFC1213-MIB.my: MIB-II standard management MIB IF-MIB.my: Interface (FC port) status and traffic MIB CISCO-SMI.my: Cisco-specific Enterprise OID root definition MIB ENTITY-MIB.my: Physical entity management MIB such as chassis, slots, power, and fans. 5.2. Cisco official MIB download path You can download the MIB files for the MDS 9000 Series for free directly from Cisco\u0026rsquo;s official GitHub repository:\n🔗 Go to Cisco MIB official GitHub repository: 👉 https://github.com/cisco/cisco-mibs/tree/main/supportlists/mds9000\n[!NOTE] NMS MIB Loading Order Tips Since there is a dependency relationship when compiling a MIB file or importing it to NMS, you must first load the root definition files SNMPv2-SMI.my and CISCO-SMI.my and then load the lower MIBs (ENTITY-MIB.my, IF-MIB.my, etc.) to prevent parsing errors.\n6. Summary and practical tips at a glance step key commands main purpose Basic settings snmp-server community \u0026lt;string\u0026gt; ro and host \u0026lt;IP\u0026gt; traps Polling collection permission and NMS trap transmission route designation Hardware Monitoring snmp-server enable traps entity / entity fru Immediate detection of fan, power (PSU), and temperature sensor failures Port Monitoring snmp-server enable traps link FC Port Link Down/Up Failure Detection Fabric Watch snmp-server enable traps fcdomain / fcns / zone SAN fabric and zone change detection Security Surveillance snmp-server enable traps aaa / snmp authentication Unauthorized access and authentication failure detection save copy running-config startup-config Retain settings across reboots Selectively configuring SNMP trap categories—focusing on physical chassis health, FC link state, and fabric mutations—protects switch management planes from trap storm overhead while ensuring rapid detection of critical storage infrastructure outages.\n","permalink":"https://cknotes.kr/en/posts/cisco-mds-snmp-setup-guide/","summary":"\u003cp\u003eOperating Cisco MDS SAN switches—the storage fabric backbone in enterprise datacenters—requires real-time telemetry into hardware component health (fans, power supplies, thermal sensors), FC port link state, and fabric zoning events via an integrated Network Management System (NMS: Zabbix, PRTG, Nagios).\u003c/p\u003e\n\u003cp\u003eA frequent misconfiguration in production is executing \u003ccode\u003esnmp-server enable traps\u003c/code\u003e globally. Indiscriminately enabling every trap floods the monitoring collectors with low-severity debug notifications, triggering trap storms and elevating switch CPU utilization.\u003c/p\u003e","title":"[Cisco MDS] SAN Switch SNMP v2c \u0026 Key Traps Setup"},{"content":" 📌 Local LLM on My PC: Ollama Practical Series\nPart 1. What is Ollama, a Local AI Running Free on My PC? (Concepts \u0026amp; Features)\u0026gt; -Part 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u0026gt; -[Current Post] Part 3. Ollama Practical Applications: Terminal Chat, WebUI, and REST API In Parts 1 and 2, we covered the architectural advantages of local LLMs in air-gapped environments and walked through installing Ollama on Windows 11 to run lightweight models in the terminal.\nThis final part focuses on practical integrations for daily engineering workflows.\nWe explore CLI management commands and shortcuts, setting up a desktop GUI client (Chatbox), configuring network bindings (OLLAMA_HOST) for remote access from secondary laptops, and integrating the engine into automation scripts via Python and REST APIs.\n1. Local AI Integration Architecture Ollama operates not merely as a terminal utility, but as a local REST API daemon (http://localhost:11434). This architecture allows straightforward integration across multiple client interfaces:\nflowchart TD subgraph Core[\u0026#34;Ollama Local Backend Core (Windows 11)\u0026#34;] Engine[\u0026#34;Ollama Daemon Engine\u0026lt;br/\u0026gt;(Port: 11434)\u0026#34;] Models[\u0026#34;Local LLM Weights\u0026lt;br/\u0026gt;(Gemma, Llama, Qwen)\u0026#34;] Engine \u0026lt;--\u0026gt; Models end subgraph Client[\u0026#34;Client Interfaces\u0026#34;] CLI[\u0026#34;1. Terminal Interface\u0026lt;br/\u0026gt;(PowerShell / CMD CLI)\u0026#34;] WebUI[\u0026#34;2. Desktop / Web GUI Client\u0026lt;br/\u0026gt;(Chatbox / Remote LAN Access)\u0026#34;] Code[\u0026#34;3. Automation \u0026amp; Scripts\u0026lt;br/\u0026gt;(Python / curl / REST API)\u0026#34;] end CLI \u0026lt;--\u0026gt;|\u0026#34;Standard I/O\u0026#34;| Engine WebUI \u0026lt;--\u0026gt;|\u0026#34;HTTP REST API\u0026#34;| Engine Code \u0026lt;--\u0026gt;|\u0026#34;OpenAI-Compatible API\u0026#34;| Engine 2. Key terminal commands \u0026amp; tips for CLI power users These are practical commands that efficiently manage models and improve conversation quality in a terminal (PowerShell) environment.\n📋 Model life cycle management commands (ollama list \u0026amp; ollama rm) # 1. 로컬에 다운로드된 모델 목록 및 용량 확인 ollama list # 2. 현재 메모리(VRAM/RAM)에 상주하여 구동 중인 모델 확인 ollama ps # 3. 모델을 즉시 실행하지 않고 백그라운드로 다운로드만 받아두기 ollama pull llama3.2:3b # 4. 안 쓰는 모델을 삭제하여 디스크 용량 확보하기 ollama rm gemma2:2b 💡 Useful shortcut commands inside the interactive prompt (\u0026gt;\u0026gt;\u0026gt;) When you enter conversational mode with ollama run \u0026lt;model name\u0026gt;, you can control the session with the slash (/) command in the prompt window:\n**/?**or /help: Check the list of available shortcut commands. /show info: Check parameter size, context length, and architecture details of the current local model. /clear: Clear the previous conversation context (history) and start with a new topic. /set system \u0026quot;...\u0026quot;: Assign a specific role (persona) to AI \u0026gt;\u0026gt;\u0026gt; /set system \u0026#34;너는 16년 차 시니어 리눅스 시스템 엔지니어 사수야. 모든 답변은 실무 위주 쉘 스크립트와 명령어 예시로 간결하게 설명해.\u0026#34; /save \u0026lt;my_model_name\u0026gt;: Permanently save the system prompts you set and create your own custom AI model! \u0026gt;\u0026gt;\u0026gt; /save my-linux-mentor (You can then immediately call your dedicated shooter with ollama run my-linux-mentor in the terminal)\n/bye: End conversation and return to shell 3. As convenient as ChatGPT! Integrating GUI client (Chatbox) The terminal black screen (CLI) is light and fast, but a graphic screen operated with a mouse is much more convenient for viewing long source code or classifying and managing previous conversation history.\nThe most recommended free tool for regular Windows 11 users is Chatbox. Integrates in just one minute with a single Windows-specific app installation file, without complicated Docker settings.\n🛠️ How to set up and connect Chatbox in 1 minute Chatbox Download : Download theDownload for Windows installation file from the official website (https://chatboxai.app/) and install it. Open the settings window : After running the Chatbox, click the[Settings] icon in the bottom left. Select AI model provider: Model Provider : SelectOllama API Host: Maintain the default value of http://localhost:11434 (however, when connecting from another PC, refer to the tips below) Model: Select the local model you have installed (e.g. gemma2:2b, llama3.2:3b, etc.) Start a conversation: Now you can conveniently enjoy code highlighting, one-click code copy, Markdown table rendering, and conversation history saving features in the exact same beautiful UI as ChatGPT, all for free! 4. 💡 Special tip: How to use Ollama on one PC and connect to it from “another PC”! \u0026ldquo;I work on a light sub-laptop in the living room or conference room. Is it not possible to remotely connect to Ollama on the main PC in my room (or a high-performance in-house server) and use it?\u0026rdquo;\nOf course you can, and that\u0026rsquo;s one of Ollama\u0026rsquo;s strongest appeals! Heavy AI model calculations are handled by the high-performance main PC, and on a light laptop (another PC) with a low battery, you can conveniently ask questions and receive answers** remotely by simply turning on Chatbox.\nflowchart LR subgraph HostPC[\u0026#34;1. Ollama 구동 메인 PC (데스크톱 / 서버)\u0026#34;] OllamaServer[\u0026#34;Ollama 엔진 (0.0.0.0:11434)\u0026lt;br/\u0026gt;GPU / RAM 모델 추론 전담\u0026#34;] end subgraph ClientPC[\u0026#34;2. 다른 PC (경량 노트북 / 서브 PC)\u0026#34;] ChatboxApp[\u0026#34;Chatbox GUI 클라이언트 앱\u0026lt;br/\u0026gt;API Host: http://192.168.0.50:11434\u0026#34;] end ChatboxApp \u0026lt;--\u0026gt;|\u0026#34;사내망 / 홈 Wi-Fi 로컬 네트워크 통신\u0026#34;| OllamaServer 🛠️ Super simple 2-step setup method for connecting to another PC Step 1: Allow external access on the main PC where Ollama is installed By default, Ollama is locked down to only receive requests from itself (127.0.0.1) for security reasons. Open an environment variable to allow access from other PCs on your corporate or home Wi-Fi network:\nWin + R ➔ Enter sysdm.cpl (System Properties) ➔ Click [Advanced] ➔ [Environment Variables] Click [New]: Variable Name :OLLAMA_HOST Variable value :0.0.0.0 (All local IP connections allowed) Right-click the Ollama icon in the taskbar system tray, quit with Quit Ollama, and run it again. (If the Windows Firewall notification window appears, click ‘Allow access’) Check the internal IP address of your main PC (type ipconfig in PowerShell ➔ e.g. 192.168.0.50). Step 2: Just change the address in the Chatbox on another PC (sub-laptop)! There is absolutely no need to install Ollama or a heavy model on a lightweight sub-notebook (another PC). Install only the Chatbox app. In the Chatbox settings window, enter the API Host address ashttp://192.168.0.50:11434 (IP of the main PC) instead of http://localhost:11434. Now, on your sub-laptop, you can freely connect to the powerful AI engine of your main PC remotely and chat like ChatGPT, without fan noise or battery consumption! 5. Connect AI to my automation script (API \u0026amp; Python) Another powerful weapon of Ollama is that it can be used as an ‘intelligent module’ in my business automation pipeline by linking with programming languages.\n① Directly call API with curl in Windows PowerShell You can immediately receive a JSON response in one line from a Windows terminal without a separate development environment:\ncurl.exe http://localhost:11434/api/generate -d \u0026#39;{ \u0026#34;model\u0026#34;: \u0026#34;gemma2:2b\u0026#34;, \u0026#34;prompt\u0026#34;: \u0026#34;리눅스 디스크 용량 확인 명령어만 한 줄로 알려줘\u0026#34;, \u0026#34;stream\u0026#34;: false }\u0026#39; ② Integrate with the Python official library (only 5 lines of code) You can create a chatbot very easily by installing the Ollama dedicated package in a Python environment:\npip install ollama import ollama # Call local Ollama model response = ollama.chat( model=\u0026#39;gemma2:2b\u0026#39;, messages=[ {\u0026#39;role\u0026#39;: \u0026#39;system\u0026#39;, \u0026#39;content\u0026#39;: \u0026#39;You are an infrastructure engineering assistant.\u0026#39;}, {\u0026#39;role\u0026#39;: \u0026#39;user\u0026#39;, \u0026#39;content\u0026#39;: \u0026#39;Provide an Nginx reverse proxy configuration example.\u0026#39;} ] ) # Print response print(response[\u0026#39;message\u0026#39;][\u0026#39;content\u0026#39;]) ③ OpenAI-Compatible API Endpoint (/v1) Ollama provides built-in compatibility with the OpenAI API specification (http://localhost:11434/v1).\nExisting scripts or IDE extensions (such as Continue for VS Code) can point to http://localhost:11434/v1 to switch to local models seamlessly without incurring cloud API costs.\n6. Practical Field Engineering Scenarios Here are three common patterns for leveraging local LLMs during infrastructure operations:\n🎯 Scenario 1: Parsing Confidential Error Logs When troubleshooting in a client\u0026rsquo;s data center, pasting logs containing internal IP addresses or system parameters into external cloud AI services violates security policies. Feeding the raw log snippet directly to local Ollama with a prompt like \u0026ldquo;Analyze the root cause of the fatal error in this log and suggest remediation commands\u0026rdquo; yields structured troubleshooting guidance within seconds without data leaving the machine.\n🎯 Scenario 2: Generating Automation Scripts \u0026ldquo;Write a PowerShell PowerCLI script to retrieve uptime and CPU utilization for VMware ESXi hosts.\u0026rdquo; \u0026ldquo;Create a Bash script that locates log files older than 30 days, compresses them with gzip, and moves them to a backup archive directory.\u0026rdquo;\nDescribing the intended logic produces syntactically correct boilerplate scripts ready for field testing. 🎯 Scenario 3: Air-Gapped Technical Reference When working inside isolated server rooms without internet access, local models serve as an immediate technical reference for unfamiliar regex syntax, switch VLAN trunk configurations, or Linux kernel parameter definitions (sysctl.conf).\n7. Summary: Concluding the 3-Part Ollama Series Across this three-part series, we explored deploying and leveraging the open-source Ollama engine on local workstations:\n[Part 1. Concepts and Features]: Data privacy, air-gap utility, and why compact 2B–3B parameter models fit standard business laptops. [Part 2. Windows 11 Installation \u0026amp; Setup]: Step-by-step installer deployment, model pulling, and interactive CLI verification. [Part 3. Practical Applications]: CLI management, Chatbox GUI integration, remote access configuration, and Python/REST API automation. Local LLMs provide infrastructure engineers with a secure, highly responsive copilot that functions independently of external internet access. Integrating these tools into your daily workflow enhances productivity while maintaining compliance with strict security requirements.\n🔗 Series Navigation Previous Step Next Step ⬅️ Part 2. Windows 11 Ollama Installation \u0026amp; Setup Series Complete ","permalink":"https://cknotes.kr/en/posts/ollama-03-cli-webui-api/","summary":"\u003cblockquote\u003e\n\u003cp\u003e📌 \u003cstrong\u003eLocal LLM on My PC: Ollama Practical Series\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ca href=\"../ollama-01-local-llm-intro/\"\u003ePart 1. What is Ollama, a Local AI Running Free on My PC? (Concepts \u0026amp; Features)\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e\u003ca href=\"../ollama-02-windows-install-guide/\"\u003ePart 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e[Current Post] \u003ca href=\"/en/\"\u003ePart 3. Ollama Practical Applications: Terminal Chat, WebUI, and REST API\u003c/a\u003e\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cp\u003eIn Parts 1 and 2, we covered the architectural advantages of local LLMs in air-gapped environments and walked through installing Ollama on Windows 11 to run lightweight models in the terminal.\u003c/p\u003e","title":"[Ollama] Part 3. CLI Advanced Tips to WebUI \u0026 API Integration"},{"content":"This blog (CK notes , hereinafter referred to as the \u0026lsquo;Site\u0026rsquo;) values the privacy of its visitors and complies with applicable privacy regulations andGoogle Publisher Policies for advertising and analytics services.\nThis Site does not collect Personally Identifiable Information (PII) without prior consent. The transparent handling of cookies by third-party services such as Google AdSense and Google Analytics is detailed below.\n1. Information Collected and Method of Collection This Site collects minimal information necessary for communication and site operation:\nInquiries and Feedback: Items Collected: Name (or nickname), email address, message contents. Collection Method: Directly provided by the visitor upon submitting an email inquiry. Automatically Generated Information: Items Collected: IP address, browser type and operating system (OS), visit date and time, pageview statistics, and cookies. Collection Method: Automatically logged by web servers and analytics engines (Google Analytics/AdSense) upon visiting the Site. 2. Google Advertising and Cookie Policy (Google AdSense) To support server maintenance and high-quality engineering content creation, this Site may display advertisements via Google AdSense.\nIn accordance with Google Publisher Policies:\nThird-Party Cookies: Third-party vendors, including Google, use cookies to serve ads based on a user\u0026rsquo;s prior visits to this Site or other websites. Purpose of Advertising Cookies: Cookies enable Google and its partners to deliver personalized ads to visitors based on browsing history across the web. Opting Out of Personalized Advertising: Visitors may opt out of personalized advertising by visiting: 🔗 Google Ads Settings You may also opt out of third-party personalized advertising cookies via: 🔗 AboutAds.info Choices 🔗 Network Advertising Initiative (NAI) Opt-Out 3. Google Analytics This Site uses Google Analytics to understand readership trends and improve content quality.\nGoogle Analytics collects non-personally identifiable metrics (Client ID, session duration, referral paths, device specs). All collected data is processed anonymously. If you prefer not to share analytics data, you can install Google\u0026rsquo;s official browser add-on: 🔗 Google Analytics Opt-out Browser Add-on 4. Managing and Rejecting Cookies Cookies are small text files stored on your local drive by your web browser. You retain full control over cookie permissions in browser settings:\nGoogle Chrome: Settings ➔ Privacy and security ➔ Third-party cookies ➔ Block third-party cookies Microsoft Edge: Settings ➔ Cookies and site permissions ➔ Manage and delete cookies and site data Apple Safari: Settings ➔ Privacy ➔ Block all cookies (Note: Completely blocking cookies may affect certain interactive site features.)\n5. Retention and Disposal of Information Retention Period: Personal information collected via email inquiries is permanently destroyed immediately after resolving the inquiry. Disposal Method: Electronic records are permanently purged using unrecoverable technical methods. 6. Third-Party Data Sharing This Site does not provide personal information to external third parties, except where required by law or official legal process.\n7. Contact Information For inquiries, deletion requests, or feedback regarding privacy practices, please reach out via:\n👤 Administrator: CK (Blog Admin) 📧 Contact Email: nrj.adm@gmail.com 8. Policy Updates This Privacy Policy may be updated to reflect changes in legal guidelines or Google service terms. Any updates will be announced promptly on this page.\nEffective Date: September 5, 2026 Last Modified: September 9, 2026 ","permalink":"https://cknotes.kr/en/privacy/","summary":"CK notes Privacy Policy, Google AdSense cookie guidelines, and contact information.","title":"Privacy Policy"},{"content":" 📌 Local LLM on My PC: Ollama Practical Series\nPart 1. What is Ollama, a Local AI Running Free on My PC? (Concepts \u0026amp; Features)\u0026gt; -[Current Post] Part 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u0026gt; -Part 3. Ollama Practical Applications: Terminal Chat, WebUI, and REST API Following the foundational concepts discussed in Part 1 regarding why air-gapped environments benefit from local LLMs and why 2B–3B parameter models are best suited for standard business laptops, this guide walks through the hands-on deployment process.\nWe will cover installing Ollama via the Windows installer, verifying the background tray service, pulling and launching a lightweight model from the terminal, configuring model storage paths to save C-drive capacity, and transferring models offline to isolated data center sites.\n1. Practical Installation Workflow The end-to-end setup workflow is outlined below:\nflowchart TD Step1[\u0026#34;Step 1: Download Installer\u0026lt;br/\u0026gt;(OllamaSetup.exe)\u0026#34;] --\u0026gt; Step2[\u0026#34;Step 2: Run Windows Installer\u0026lt;br/\u0026gt;(One-click deployment)\u0026#34;] Step2 --\u0026gt; Step3[\u0026#34;Step 3: Verify Background Service\u0026lt;br/\u0026gt;(System tray icon \u0026amp; port 11434)\u0026#34;] Step3 --\u0026gt; Step4[\u0026#34;Step 4: Launch Terminal (CLI)\u0026lt;br/\u0026gt;(Check ollama commands \u0026amp; model selection)\u0026#34;] Step4 --\u0026gt; Step5[\u0026#34;Step 5: Pull Model\u0026lt;br/\u0026gt;(Layer download \u0026amp; digest verification)\u0026#34;] Step5 --\u0026gt; Step6[\u0026#34;Step 6: Real-time Terminal Chat\u0026lt;br/\u0026gt;(Prompt response verification)\u0026#34;] 2. Step 1: Download Ollama Windows 11 installation file Open your web browser and go to the Ollama official download page: 🌐 Official Download Link: https://ollama.com/download/windows Click the Download for Windows button in the center of the screen. Once the download is complete, a OllamaSetup.exe installation file will be created in the download folder. 3. Step 2: Run the installer and complete the installation. Double-click the downloaded OllamaSetup.exe file to run it. When the Installation Wizard window appears, click the Install button. File decompression and service registration will proceed automatically (takes approximately 10 to 20 seconds). Once installation is complete, the Ollama icon appears in the Windows 11 system tray (notification area), indicating that the background service is running. 💡 Default installation paths:\nApplication binary: C:\\Users\\\u0026lt;user account\u0026gt;\\AppData\\Local\\Programs\\Ollama Downloaded models: C:\\Users\\\u0026lt;user account\u0026gt;\\.ollama\\models Ollama automatically starts as a background service on system boot, listening on default local port 11434 (http://localhost:11434). 4. Step 3: Service Initialization and Account Setup Ollama runs in the background automatically upon installation or system startup.\nIf desired, you can sign in with your Ollama account (optional; downloading models and executing local inference works completely without authentication).\n5. Step 4: Verify Installation and Explore Models in CLI Right-click the Windows Start button and open Terminal orPowerShell.\nType ollama and press Enter to display the supported command-line options (serve, create, show, run, stop, pull, push, list, ps, rm).\nSelect a lightweight model suited for your hardware. For standard business laptops with 16 GB of system RAM, compact 2B–3B parameter models such as gemma2:2b or llama3.2:3b provide optimal performance with minimal memory overhead (~2 GB).\n6. Step 5: Pull and Launch the Model (ollama run) Execute the following command in PowerShell to pull and initialize the model:\n# Run recommended lightweight model for laptops ollama run gemma2:2b Ollama automatically retrieves the model layers from the official registry:\nManifest retrieval and layer download: Real-time progress and transfer speed: The transfer status for each layer is displayed via progress bars. Digest verification and completion: Once downloaded, sha256 digests are verified, concluding with a success message. 7. Step 6: Interactive Terminal Prompt Once initialization completes, the terminal switches to an interactive \u0026gt;\u0026gt;\u0026gt; prompt. Enter a prompt to test model inference:\n🛠️ Practical Engineering Prompt Test \u0026gt;\u0026gt;\u0026gt; Write a find command in Linux that finds files larger than 100MB and sorts them in descending order by size. Even on standard laptops relying solely on integrated Intel/AMD CPU graphics, responses stream smoothly at around 25 tokens per second.\n🚪 Exiting the Session To exit the interactive session and return to PowerShell:\nType /bye and press Enter Or press Ctrl + D (Ctrl + C or /bye in PowerShell) 8. Practical Tips (Windows 11 Environment) 💡 Tip 1: Moving Model Storage to Another Drive As you pull multiple models, system drive space may diminish. You can relocate the storage path to another partition (such as D:\\) using environment variables:\nPress Win + R, enter sysdm.cpl, and hit Enter. Navigate to Advanced ➔ clickEnvironment Variables. Under System or User variables, click New: Variable name: OLLAMA_MODELS Variable value: D:\\ollama\\models (or your target path) Right-click the Ollama tray icon, select Quit Ollama, and relaunch. Subsequent models will download to the new path. 💡 Tip 2: Deploying Models to Air-Gapped Data Centers When heading to an isolated site without external internet access:\nPull all necessary models on an internet-connected PC beforehand (ollama run gemma2:2b, etc.). Copy the entire C:\\Users\\\u0026lt;account\u0026gt;\\.ollama\\models directory to an external drive. On the air-gapped target machine, install Ollama and place the copied models directory into the user profile folder. Local inference will operate immediately without network access. 9. Summary Installing Ollama on Windows 11 provides a self-contained local AI environment that delivers fast technical assistance without sending a single byte over external networks.\nIf C-drive storage is limited, configuring the OLLAMA_MODELS environment variable enables flexible storage management across secondary drives. In addition, pre-downloaded model weights can be packaged and transferred to offline air-gapped data centers with minimal effort.\nIn Part 3: Ollama Practical Applications: Terminal Chat, WebUI, and REST API, we will explore connecting a browser-based WebUI and calling the local inference engine via Python REST APIs.\n🔗 Series Navigation Previous Step Next Step ⬅️ Part 1. Ollama Concepts and Architecture Overview Part 3. Ollama Practical Applications: WebUI \u0026amp; API Integration ➡️ ","permalink":"https://cknotes.kr/en/posts/ollama-02-windows-install-guide/","summary":"\u003cblockquote\u003e\n\u003cp\u003e📌 \u003cstrong\u003eLocal LLM on My PC: Ollama Practical Series\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e\u003ca href=\"../ollama-01-local-llm-intro/\"\u003ePart 1. What is Ollama, a Local AI Running Free on My PC? (Concepts \u0026amp; Features)\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e[Current Post] \u003ca href=\"/en/\"\u003ePart 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e\u003ca href=\"../ollama-03-cli-webui-api/\"\u003ePart 3. Ollama Practical Applications: Terminal Chat, WebUI, and REST API\u003c/a\u003e\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cp\u003eFollowing the foundational concepts discussed in Part 1 regarding why air-gapped environments benefit from local LLMs and why 2B–3B parameter models are best suited for standard business laptops, this guide walks through the hands-on deployment process.\u003c/p\u003e","title":"[Ollama] Part 2. Windows 11 Installation \u0026 First Model Setup Guide"},{"content":" 📌 Local LLM on Personal Workstation: Practical Series Table of Contents\n[Current Post] Part 1. What is Ollama, a Local AI Running Free on Your PC? (Concepts \u0026amp; Features)\u0026gt; -Part 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u0026gt; -Part 3. Practical Usage: From CLI Mastery to WebUI \u0026amp; API Integration Generative AI has become integral to software engineering workflows, but datacenter field operations present unique constraints. High-security enterprise environments—including financial transaction centers, defense installations, power plants, and public infrastructure—operate in air-gapped isolation with zero outbound internet connectivity.\nIn these environments, cloud-based assistants (ChatGPT, Claude) are inaccessible, and piping proprietary infrastructure configurations, error logs, or routing policies to external endpoints violates core security compliance mandates.\nOllama addresses this constraint by executing optimized open-source large language models locally and offline on commodity laptop hardware.\nThis article reviews the architecture of Ollama, technical contrasts with SaaS AI models, air-gap engineering utility, and lightweight model options well suited for standard corporate laptops.\n1. What is Ollama? Ollama is a free open source tool that allows you to install and run the latest powerful open source large language models (LLMs), including Meta\u0026rsquo;s Llama 3.2, Google\u0026rsquo;s latest lightweight model (Gemma lineup), Qwen, and DeepSeek, on your personal PC or laptop with just one line of commands.\n🌐 Ollama Official Website: https://ollama.com/ 📚 Official model repository (library): https://ollama.com/library 🐙 Official GitHub repository: https://github.com/ollama/ollama In the past, to run an AI model on a local PC, you had to go through complex processes such as creating a Python virtual environment (venv), C++ compilation (llama.cpp), matching the CUDA driver version, and manually downloading the quantization GGUF file.\nHowever, Ollama has greatly simplified all these complex backend engineering processes, just like dealing with a \u0026lsquo;Docker\u0026rsquo; container:\nWith just one command line (ollama run gemma2:2b or ollama run llama3.2:3b), everything from model download to weight memory loading to interactive CLI prompt is completed in one step. It resides as a Windows background service and basically opens REST API (default port: http://localhost:11434), so it is very flexible in linking with Web UI (web interface) and other in-house programs. 2. Cloud AI vs Local AI (Ollama) Architecture Comparison The difference in data flow between cloud-based AI (ChatGPT, Claude) and Ollama\u0026rsquo;s local operation is shown in the diagram below.\nflowchart TD subgraph CloudAI[\u0026#34;1. Cloud AI Architecture (ChatGPT / Claude)\u0026#34;] User1[\u0026#34;User Workstation\u0026#34;] --\u0026gt;|\u0026#34;WAN Transfer (Data Leak Risk)\u0026#34;| CloudServer[\u0026#34;External Cloud Server\u0026#34;] CloudServer --\u0026gt;|\u0026#34;Token Metering \u0026amp; Response\u0026#34;| User1 end subgraph LocalAI[\u0026#34;2. Local AI Architecture (Ollama)\u0026#34;] User2[\u0026#34;User Laptop\u0026#34;] --\u0026gt;|\u0026#34;Local Loopback (127.0.0.1:11434)\u0026#34;| OllamaEngine[\u0026#34;Internal Ollama Engine\u0026#34;] OllamaEngine --\u0026gt;|\u0026#34;System RAM / VRAM Compute\u0026#34;| LocalModels[\u0026#34;Locally Stored Models (Gemma, Llama)\u0026#34;] LocalModels --\u0026gt;|\u0026#34;Air-gapped Instant Response\u0026#34;| User2 end Dimension Cloud AI (ChatGPT / Claude) Local AI (Ollama) **Data Security ** Transmission to external server (risk of leakage of company secrets) Not a single byte leaves my laptop (100% safe) **Internet Connection ** Internet connection required (will not work if communication is not possible) Full support for air-gap closed networks with 0% internet blocking **Cost ** Monthly subscription fee ($20+) or per API token Completely free (only uses laptop battery and hardware resources) **Speed/Latency ** External server traffic and network delays occur Instant streaming output based on local memory **Model Selection ** Forced dependency on service provider policies Freely replace any open source model (Gemma, Llama, etc.) of your choice 3. Key Reasons Why Engineers Rely on Local LLMs ① A Lifesaver in Air-Gapped Closed Networks When working on infrastructure at sites disconnected from the Internet, such as customer computer rooms, financial IDCs, and government offices, it is often difficult to encounter obstacles such as writing complex shell scripts, analyzing unfamiliar error logs, or creating firewall iptables rules. Having a lightweight model preloaded in Ollama turns your laptop into an offline mentor that responds immediately to queries.\n② 100% Safe Data Privacy (Zero Data Leakage) You can safely parse and summarize customer hostnames, internal private IPs, account setup scripts, and system dump logs entirely inside your laptop without pasting them into external AI services.\n③ Unlimited Free Inquiries You can analyze thousands of lines of log files over and over again without paying API token fees or monthly subscriptions.\n4. Model Selection Guide for Standard Laptops Which model should you choose for \u0026ldquo;a standard business laptop without an expensive discrete GPU\u0026rdquo;?\nflowchart LR Prompt[\u0026#34;Engineer Query\u0026#34;] --\u0026gt; MemCheck{\u0026#34;Laptop Hardware Tier\u0026#34;} MemCheck --\u0026gt;|\u0026#34;Standard Laptop (Integrated GPU / 16GB RAM)\u0026#34;| sLLM[\u0026#34;2B – 3B Compact Models Recommended\u0026lt;br/\u0026gt;(gemma-2:2b, llama3.2:3b)\u0026lt;br/\u0026gt;Fast CPU inference\u0026#34;] MemCheck --\u0026gt;|\u0026#34;Performance Laptop (Dedicated GPU 8GB+ VRAM)\u0026#34;| LLM8B[\u0026#34;7B – 9B Standard Models\u0026lt;br/\u0026gt;(gemma-2:9b, llama3.1:8b)\u0026#34;] 💡 General Laptop Highly Recommended: 2B – 3B Small Language Models (sLLM) Google gemma-2:2b (Capacity: ~1.6 GB) Meta llama3.2:3b (or ultralight llama3.2:1b) (Capacity: ~2.0 GB) Alibaba qwen2.5:3b (Coding and multilingual specialization) 🤔 Why Are 2B – 3B Class Models Best Suited for General Laptops? Optimized Memory (RAM) Usage (~2 GB)\nOn a typical Windows 11 laptop (16 GB RAM), the OS and default background apps already use 6 – 8 GB. The 2B – 3B models only take up about 1.5 GB – 2.5 GB of memory when running, so they can reside lightly alongside other work programs without out-of-memory (OOM) errors. Comfortable Speed With Pure CPU Computation Even on laptops without NVIDIA discrete graphics (e.g., Intel Iris Xe or AMD Radeon), CPU execution delivers20 – 30 tokens/sec, exceeding human reading speed. High Capability for Everyday Engineering Tasks\nLatest sLLM models excel at writing Python/Bash scripts, generating regular expressions, validating Linux syntax, and diagnosing error logs. Minimal Battery Consumption and Noise\n7B+ models running on CPU cause cooling fans to spin loudly and drain the battery quickly. 2B – 3B models consume modest power, making them ideal for field trips. 5. Hardware Specification Guide for Windows 11 Laptops Category General Laptop (2B – 3B Models Recommended) High-Performance Laptop (7B – 9B Models) **Operating System ** Windows 11 (64-bit) Windows 11 (64-bit) CPU Intel Core i5/i7 (11th Gen+) or AMD Ryzen 5/7 Intel Core i7/i9 or AMD Ryzen 7/9 **System RAM ** 16 GB (Comfortable multitasking) 32 GB Recommended Graphics (GPU) Intel / AMD Built-in Graphics (Sufficient) NVIDIA RTX 3060 / 4060 Laptop (6 GB – 8 GB VRAM) Storage Space NVMe SSD 20 GB+ free space NVMe SSD 50 GB+ free space 6. Summary Ollama delivers an effective solution for deploying private, locally hosted language models in air-gapped datacenter facilities using standard corporate laptop hardware.\nDeploying optimized 2B – 3B parameter models provides responsive local inference powered solely by system CPU and RAM, enabling reliable technical assistance without risking proprietary data leakage.\nThe next article, Part 2: Windows 11 Ollama Installation \u0026amp; Initial Model Setup, walks through installer deployment, model acquisition, and interactive CLI prompts.\n🔗 Series Navigation Previous Step Next Step Series Start (Current) Part 2. Windows 11 Ollama Installation \u0026amp; First Model Setup ➡️ ","permalink":"https://cknotes.kr/en/posts/ollama-01-local-llm-intro/","summary":"\u003cblockquote\u003e\n\u003cp\u003e📌 \u003cstrong\u003eLocal LLM on Personal Workstation: Practical Series Table of Contents\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e[Current Post] \u003ca href=\"/en/\"\u003ePart 1. What is Ollama, a Local AI Running Free on Your PC? (Concepts \u0026amp; Features)\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e\u003ca href=\"../ollama-02-windows-install-guide/\"\u003ePart 2. Windows 11 Ollama Installation \u0026amp; First Model Setup Guide\u003c/a\u003e\u003c/strong\u003e\u0026gt; -\u003cstrong\u003e\u003ca href=\"../ollama-03-cli-webui-api/\"\u003ePart 3. Practical Usage: From CLI Mastery to WebUI \u0026amp; API Integration\u003c/a\u003e\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003cp\u003eGenerative AI has become integral to software engineering workflows, but datacenter field operations present unique constraints. High-security enterprise environments—including financial transaction centers, defense installations, power plants, and public infrastructure—operate in air-gapped isolation with zero outbound internet connectivity.\u003c/p\u003e","title":"[Ollama] Part 1. Local AI Concepts \u0026 Features Running Free on PC"},{"content":"It is never too late to start documenting everyday moments and vehicle upkeep.\nToday, I am logging the routine engine oil service for my car—a trusted companion that carries me across the country to client sites day in and day out.\nWith frequent nationwide trips, keeping the car in top mechanical shape is essential. In the first half of this year alone, the car went through two oil changes as mileage accumulated rapidly.\nJanuary: First Oil Change of the Year (~234,000 km) On January 9th, as the odometer crossed 234,000 km, I scheduled the first oil change of the year.\n(Photo: MANN filter boxes prepared in advance)\nBefore heading to the garage, I ordered the oil filter and engine air filter online. I chose MANN-FILTER for filtration reliability, paired withZIC engine oil, which has been my go-to choice for years.💡 Note on Filters While MANN filters offer dependable quality, I plan to test other cost-effective OEM alternatives on upcoming services to compare value.\nWith parts in the trunk, I headed to a pre-booked Gongimnara shop.\n(Photo: Mechanic performing the service)\nGongimnara operates on a labor-only model: you supply your own preferred parts and pay standardized, transparent labor fees. For drivers who prefer picking their own fluids and parts while keeping maintenance costs predictable, it is an efficient solution.\n(Photo: Kixx oil on display in the store)\nFor reference, when I looked around the store, there was an oil that matched my car\u0026rsquo;s specifications. When I checked, it was a Kixx product. If you are busy and cannot prepare oil in advance, you may want to use the oil available at the store right away.\n(Photo: 2nd floor lounge where we rested comfortably while waiting for maintenance)\nI left my car and went up to the lounge on the second floor. The waiting area was well-maintained and comfortable, so I was able to rest comfortably until the maintenance was completed.\n**💡 Mechanic’s thorough check and advice After completing the maintenance, the mechanic informed me thatthe drain bolt side of the oil filter cap was worn **. He said that if you continue to ride like this and do not replace the O-ring in time, the O-ring may eventually wear out and cause engine oil leakage.**It is recommended that the entire oil filter cap be replaced the next time. I could have easily missed it, but I was very fortunate to be able to clearly check for hidden factors of deteriorating physical condition with the eagle eye of an expert.\nIn July, replacement cycle and parts repair returned (246,203km) As I was diligently going about my business with my business partner, it was already July 10th! The mileage has increased to about 12,000 km.\n(Photo: Instrument panel proof shot showing 246,203km mileage)\nWhen I saw 246,203km stamped on the dashboard, it was time to replace it again after 6 months. When replacing this July, I did not forget the advice from the mechanic last January and prepared the parts in advance!\n(Photo: New oil filter cap purchased in advance from Naver for about 60,000 won)\nI purchased an oil filter cap through Naver for about 60,000 won. When changing the engine oil this time, I also took this part and replaced it with a new one! I feel reassured that I can ride safely without worrying about oil leaks.\n(Photo: ZIC engine oil was still selected during replacement in July)\nFor this July replacement, we used **ZIC engine oil **just like last January. After emptying out the old oil and replacing it with new ZIC oil,the engine became noticeably quieter and the car felt much smoother. The drive to my next client felt much more refreshing! I am so satisfied with this smooth driving feeling that I will probably replace it with ZIC without hesitation the next time I change engine oil.\nfinish The mileage has exceeded 240,000 kilometers and its age is accumulating, but it is still running strong due to the meticulous management of consumables. There is a sense of pride in taking care of my partner at work, and it kills two birds with one stone as it not only reduces maintenance costs but also prevents accidents or breakdowns (oil leaks, etc.).\nIf you are someone who uses your car as a reliable business partner every day, I highly recommend that you try to manage the condition of your car economically and reliably with the combination of \u0026lsquo;direct purchase of parts + free labor\u0026rsquo; like me!\n","permalink":"https://cknotes.kr/en/posts/2026-08-31-engine-oil-change/","summary":"\u003cp\u003eIt is never too late to start documenting everyday moments and vehicle upkeep.\u003c/p\u003e\n\u003cp\u003eToday, I am logging the routine engine oil service for my car—a trusted companion that carries me across the country to client sites day in and day out.\u003c/p\u003e\n\u003cp\u003eWith frequent nationwide trips, keeping the car in top mechanical shape is essential. In the first half of this year alone, the car went through two oil changes as mileage accumulated rapidly.\u003c/p\u003e","title":"[Lifestyle] Field Workhorse Engine Oil Change (feat. Gongimnara)"},{"content":"With VMware\u0026rsquo;s recent licensing changes, many enterprise data centers are looking closely at lightweight, KVM-based virtualization alternatives. One viable enterprise solution is HPE SimpliVity 6.2.0 powered by HPE VM Essentials (VME).\nIn my 16 years as an infrastructure engineer deploying servers and SAN fabrics, I have found that 90% of HCI deployment failures boil down to two things: sloppy physical/VLAN network segmentation andmisplaced quorum (Arbiter) architecture.\nThis guide condenses the entire deployment lifecycle—from pre-flight network planning to management server staging, node initialization, and automated OVC provisioning via VME Manager—with battle-tested field troubleshooting insights.\n1. 2-Node Network Architecture \u0026amp; Golden Rules A 2-node SimpliVity cluster delivers high availability at a modest footprint. However, if physical links and logical VLANs are not strictly isolated, storage I/O and federation handshakes will collide, leading to split-brain or degraded clusters.\nFive Mandatory Network Segments Segment Bandwidth MTU Purpose \u0026amp; Practical Field Tips 1. iLO Out-of-Band 1 Gbps 1500 Dedicated out-of-band management \u0026amp; remote console (physically isolated switch recommended). 2. Management 1 Gbps / 10 Gbps 1500 Host BaseOS, VME Manager UI, and OVC control communications. **3. Storage ** **10 Gbps / 25 Gbps ** 9000 (Jumbo) [CRITICAL] Real-time node data mirroring. Must enable MTU 9000 end-to-end. 4. Federation 10 Gbps 1500 SimpliVity inter-OVC cluster metadata catalog \u0026amp; synchronization. 5. VM Workload 10 Gbps 1500 Production tenant VM service traffic (isolated customer VLANs). 💡 Field Troubleshooting Note: Jumbo Frame (MTU 9000) Mismatch\nIf you set MTU 9000 on the host interface but forget to enable Jumbo frames on the upstream L2 top-of-rack switch port or SVI, packets will silently drop. If your OVC provisioning stalls at around 70-80%, check your storage switch MTU immediately.\n2. End-to-End Workflow flowchart TD A[\u0026#34;Step 1. Pre-flight Planning \u0026amp; IP Matrix\u0026#34;] --\u0026gt; B[\u0026#34;Step 2. Management Infra (NTP/DNS/NFS)\u0026#34;] B --\u0026gt; C[\u0026#34;Step 3. Deploy VME Manager \u0026amp; Arbiter VM\u0026#34;] C --\u0026gt; D[\u0026#34;Step 4. Node HVM BaseOS \u0026amp; Initial Setup\u0026#34;] D --\u0026gt; E[\u0026#34;Step 5. VME Manager HVM Cluster \u0026amp; OVC Deploy\u0026#34;] E --\u0026gt; F[\u0026#34;Step 6. Federation Sync \u0026amp; CLI Verification\u0026#34;] 3. External Management \u0026amp; Arbiter Quorum Setup In a 2-node cluster, the Arbiter acts as an independent tie-breaker (quorum witness) to prevent split-brain scenarios when network connectivity between nodes degrades.\n⚠️ Golden Rule for Arbiter Placement Never host the Arbiter VM inside the SimpliVity datastore it arbitrates. If a node fails and the Arbiter VM was on that crashed node, the surviving node loses quorum and storage services freeze immediately. Best Practice: Place the Arbiter on an independent 1U standalone management server, or a distinct third-party virtualization host outside the SimpliVity cluster. Strict NTP Time Synchronization Ensure all components (physical hosts, VME Manager, OVCs, Arbiter) sync with a rock-solid NTP source. If clock drift exceeds 5 seconds, TLS certificate handshakes and OVC federation authentication will fail.\n4. Physical Node Setup: HVM BaseOS \u0026amp; Initial Setup After rack mounting and cabling, boot the nodes via iLO Virtual Media to flash HVM 24.04 BaseOS.\niLO Virtual Media: Mount the HVM BaseOS ISO and execute a one-time boot installation. Initial Setup TUI: Log into the host console and run initial_setup. Configure hostname, management IP, default gateway, DNS, and NTP. Verify link status on 10G/25G physical adapters using ethtool before proceeding. 5. VME Manager: HVM Cluster Creation \u0026amp; OVC Auto-Deployment Access the VME Manager web interface (https://\u0026lt;VME-Manager-IP\u0026gt;) to initiate the cluster deployment wizard.\nKey Deployment Wizard Parameters Cluster Type: Select HVM Cluster and provide a descriptive name. Host Selection: Discover and add the two physical nodes configured during initial_setup. SimpliVity Add-on: Select SimpliVity 6.2.0 package. Allocate dedicated OVC Management, Storage, and Federation IPs. Provide the Arbiter IP and root credentials. Automated Provisioning: OVC template rollout, interface binding, Corosync cluster setup, and storage datastore initialization proceed automatically. Once finished, all host and cluster statuses turn green (OK), and the unified resilient storage pool becomes ready in the VME Manager dashboard.\n6. Post-Deployment Verification CLI Cheat Sheet Never rely solely on GUI green checkmarks. Log in via SSH to the OVC and run CLI diagnostic commands to verify cluster health:\n# 1. Overall federation balance and health dsv-balance-show # 2. Node and OVC status check svt-node-show # 3. Verify 2-node Arbiter connection (Must state \u0026#34;Connected\u0026#34;) svt-arbiter-show # 4. Inspect real-time deduplication and storage capacity svt-datastore-show 7. Real-World Field FAQ \u0026amp; Troubleshooting Q1. OVC provisioning freezes around 75% and times out. Cause: Storage network (10G/25G) MTU mismatch or blocked Arbiter ports (TCP 9999). Fix: Run a jumbo ping from the host console to verify MTU integrity: ping -M do -s 8972 \u0026lt;remote_storage_ip\u0026gt; If it fails, audit your upstream switch ports and VLAN MTU settings. Q2. If one node powers down unexpectedly, does storage failover immediately? Answer: If the Arbiter is Connected, failover is instantaneous (0 seconds) with no storage disruption to surviving VMs. For planned maintenance, however, always perform a live migration of workloads to the healthy node first. Wrap-Up HPE SimpliVity with VME offers a reliable enterprise alternative for modern HCI. Adhering to the fundamentals—strict network isolation, end-to-end jumbo frame verification, and external Arbiter placement—guarantees a smooth, error-free deployment on day one.\n","permalink":"https://cknotes.kr/en/posts/simplivity-vme-deployment-guide/","summary":"\u003cp\u003eWith VMware\u0026rsquo;s recent licensing changes, many enterprise data centers are looking closely at lightweight, KVM-based virtualization alternatives. One viable enterprise solution is \u003cstrong\u003eHPE SimpliVity 6.2.0 powered by HPE VM Essentials (VME)\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eIn my 16 years as an infrastructure engineer deploying servers and SAN fabrics, I have found that 90% of HCI deployment failures boil down to two things: \u003cstrong\u003esloppy physical/VLAN network segmentation \u003cstrong\u003eand\u003c/strong\u003emisplaced quorum (Arbiter) architecture\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eThis guide condenses the entire deployment lifecycle—from pre-flight network planning to management server staging, node initialization, and automated OVC provisioning via VME Manager—with battle-tested field troubleshooting insights.\u003c/p\u003e","title":"[SimpliVity \u0026 VME] 2-Node Cluster Deployment Guide A to Z"},{"content":"Hello and welcome to CK notes!\nThis is a personal technical space where an IT systems engineer documents hands-on field experience, infrastructure architecture, troubleshooting case studies, and everyday reflections.\n💡 Why the name \u0026lsquo;CK notes\u0026rsquo;? If you are visiting for the first time, you might have initially thought of the fashion brand (Calvin Klein). 😄\nHowever, CK notes carries a simple yet dedicated meaning:\nCK: The initials of the engineer and author of this blog. notes : RepresentsEngineering Field Notes —the verified technical insights and solutions gathered while diagnosing servers, networks, and virtualization platforms every day. Since entering the IT industry on September 6, 2010, I have spent over16 years building enterprise data centers, managing server and storage infrastructure, and solving critical downtime issues. This space serves as an open, reliable engineering notebook documenting that hard-earned knowledge. 🛠️ Profile \u0026amp; Core Technical Expertise Working as an IT systems and field engineer since September 6, 2010 (16 years of hands-on experience).\nHCI \u0026amp; Virtualization: HPE SimpliVity, HPE VME, VMware vSphere (ESXi, vCenter), KVM Servers \u0026amp; Enterprise Storage: x86 enterprise servers (HPE ProLiant, etc.), SAN Fabric Switches (Cisco MDS, Brocade), Enterprise SAN Storage OS \u0026amp; Infrastructure Services: Linux (RHEL, Rocky, Ubuntu, CentOS), Windows Server, DNS, NTP, NFS, Active Directory Automation \u0026amp; Engineering AI: Bash, PowerShell, Local LLM (Ollama) workflows for enterprise engineering 📂 Blog Focus \u0026amp; Publishing Schedule Mission:\nThis blog rejects generic vendor textbook documentation. Since 2010, I have spent 16 years inside enterprise data centers and server rooms, documenting raw, field-tested troubleshooting logs and deployment notes.\nPublishing Frequency:\nTo prioritize verified depth over quantity, new in-depth articles are published 2 to 4 times a month (bi-weekly schedule).\nCore Categories:\nTech (Field Engineering Notes): Servers, SAN storage, HCI (SimpliVity/VME), KVM, and Linux data center infrastructure troubleshooting. Life \u0026amp; Car: Maintenance, repairs, and DIY logs for the road partner vehicle (Hyundai NEXO, etc.) that powers client on-site visits across the country, alongside everyday reflections away from technology. 📧 Contact Feel free to reach out with technical inquiries, infrastructure architecture discussions, or collaboration inquiries:\nAuthor: CK notes Email: nrj.adm@gmail.com ","permalink":"https://cknotes.kr/en/about/","summary":"Introduction to CK notes blog and the engineer behind it.","title":"About me"},{"content":"Hello! I am CK notes, an IT systems engineer documenting real-world datacenter experience, infrastructure engineering, and everyday life.\nThis first post introduces why I started this blog, the meaning behind \u0026lsquo;CK notes\u0026rsquo;, and the topics I plan to cover.\n💡 Why the name \u0026lsquo;CK notes\u0026rsquo;? When looking at the blog address or title, you might have initially thought of the fashion brand (Calvin Klein). 😄\nHowever, CK notes carries a sincere engineering purpose:\nCK: The initials of my name. notes : Derived fromEngineering Field Notes —the verified technical practices and troubleshooting solutions documented while working directly on enterprise systems. Since starting my IT journey on September 6, 2010, I have spent over16 years building servers, enterprise storage, and virtualization clusters across numerous datacenters. This blog is an accessible, reliable technical notebook preserving that hard-earned knowledge. 🚀 Why I Started This Blog I was never someone who wrote frequently for leisure. However, as an infrastructure engineer, I encounter complex issues and troubleshooting scenarios almost daily. Relying solely on memory felt wasteful, and having a personal reference when similar challenges arise is essential.\nPreviously, I documented these insights in slide decks and internal company wikis. By publishing them online, I hope they become a lifelong engineering archive for myself anda practical guide for fellow engineers working late to solve similar production incidents.\n📂 Topics I Cover Practical IT \u0026amp; Infrastructure Engineering (Tech)\nEnterprise servers (HPE ProLiant, etc.), SAN switches (Cisco MDS, Brocade), and enterprise storage architectures. HCI and virtualization platforms (HPE SimpliVity, HPE VME, VMware vSphere, KVM) deployment and deep dives. Air-gapped engineering workflows and local LLM (Ollama) operations. Hands-on incident investigations and real-world troubleshooting logs. Life \u0026amp; Everyday Experiences (Life)\nDIY automotive maintenance (engine oil, filter changes, and vehicle upkeep). Travel logs and casual thoughts outside the datacenter. 🎯 Looking Forward Rather than a dry, rigid technical manual, I aim to create an approachable space that blends 16 years of practical field engineering with personal experiences.\nI hope CK notes grows step by step into a dependable technical library you can trust whenever challenges arise.\nThank you for visiting, and I look forward to connecting with you!\n","permalink":"https://cknotes.kr/en/posts/hello-ck-log/","summary":"\u003cp\u003eHello! I am \u003cstrong\u003eCK notes\u003c/strong\u003e, an IT systems engineer documenting real-world datacenter experience, infrastructure engineering, and everyday life.\u003c/p\u003e\n\u003cp\u003eThis first post introduces why I started this blog, the meaning behind \u003cstrong\u003e\u0026lsquo;CK notes\u0026rsquo;\u003c/strong\u003e, and the topics I plan to cover.\u003c/p\u003e\n\u003chr\u003e\n\u003ch3 id=\"-why-the-name-ck-notes\"\u003e💡 Why the name \u0026lsquo;CK notes\u0026rsquo;?\u003c/h3\u003e\n\u003cp\u003eWhen looking at the blog address or title, you might have initially thought of the fashion brand (Calvin Klein). 😄\u003c/p\u003e\n\u003cp\u003eHowever, \u003cstrong\u003eCK notes\u003c/strong\u003e carries a sincere engineering purpose:\u003c/p\u003e","title":"Welcome to CK notes: Field Notes of a Systems Engineer"},{"content":"When delivering an HPE SimpliVity with VME (VM Essentials) 2-node cluster to an enterprise customer, you will almost invariably hear the client\u0026rsquo;s IT team request:\n\u0026ldquo;Please just host the Arbiter VM directly on the newly delivered SimpliVity nodes.\u0026rdquo;\nTo an experienced systems engineer, this request highlights two critical architectural and commercial dilemmas.\n1. The Field Dilemmas: Chicken-and-Egg \u0026amp; The Licensing Trap Dilemma 1: The Arbiter Must Exist Before SimpliVity Storage is Created A 2-node SimpliVity cluster requires active network communication with an Arbiter IP before the cluster creation wizard can even begin. If the SimpliVity nodes haven\u0026rsquo;t been initialized and no storage pool exists, where can you run the Arbiter VM? It is a classic chicken-and-egg paradox.\nFurthermore, because the Arbiter acts as an impartial quorum tie-breaker during node communication failures to prevent Split-Brain scenarios , it mustnever reside on the very storage it arbitrates.\nDilemma 2: Creating It in the VME GUI Triggers Costly Licensing The natural location for the Arbiter is the external standalone management host running the VME Manager appliance (which runs on KVM).\nHowever, if an engineer tries to take the easy route by registering this management host into the VME Manager web GUI to deploy the Arbiter VM, the VME licensing engine will immediately count all physical CPU cores on that host toward the paid license entitlement! Purchasing expensive enterprise software licenses just to run a lightweight 2-core tie-breaker VM is unacceptable.\nflowchart TD A[\u0026#34;Customer: \u0026#39;Host Arbiter on new SimpliVity nodes\u0026#39;\u0026#34;] --\u0026gt; B[\u0026#34;Dilemma: Arbiter must precede cluster deployment\u0026#34;] B --\u0026gt; C[\u0026#34;Solution: Host on external VME Manager management server\u0026#34;] C --\u0026gt; D{\u0026#34;Deploy via VME Manager Web GUI?\u0026#34;} D -- \u0026#34;YES\u0026#34; --\u0026gt; E[\u0026#34;❌ Warning: Physical CPU cores billed under VME licenses!\u0026#34;] D -- \u0026#34;NO: Engineer Workaround\u0026#34; --\u0026gt; F[\u0026#34;✅ Native KVM virt-install + VNC: 0 License Cost!\u0026#34;] 2. The 16-Year Engineer\u0026rsquo;s Workaround: KVM CLI + VNC The solution is elegant and zero-cost:\nThe underlying operating system of the VME Manager host is standard Linux KVM with libvirt.\nBy bypassing the VME Manager GUI and creating the VM directly at the host CLI level using virt-install, the Arbiter VM operates completely outside VME licensing scope. We can then attach a lightweight VNC Viewer (virsh vncdisplay) for the initial Ubuntu OS setup, achieving a 100% compliant, independent Arbiter VM at zero software license cost.\n3. Step 1: Stage Ubuntu 22.04 LTS ISO SimpliVity Arbiter officially supports Windows Server or Ubuntu 22.04 LTS. Copy the ISO to the libvirt images folder:\ncp ubuntu-22.04.5-live-server-amd64.iso /var/lib/libvirt/images/ ls -lh /var/lib/libvirt/images/ 4. Step 2: Provision VM via virt-install Create a dedicated VM storage folder and write the provisioning script:\nmkdir -p /var/morpheus/kvm/vms/arbiter vi /root/create_arbiter.sh #!/bin/bash sudo virt-install \\ --name arbiter \\ --ram 4096 \\ --vcpus 2 \\ --cpu host-passthrough \\ --disk path=/var/morpheus/kvm/vms/arbiter/arbiter.qcow2,size=40,format=qcow2,bus=virtio \\ --cdrom /var/lib/libvirt/images/ubuntu-22.04.5-live-server-amd64.iso \\ --network network=Management,model=virtio \\ --graphics vnc,listen=0.0.0.0,password=P@ssw0rd \\ --boot uefi \\ --noautoconsole \\ --autostart Execute the script:\nsh -x /root/create_arbiter.sh 5. Step 3: Connect via VNC for OS Installation Check the assigned VNC display port:\nvirsh vncdisplay arbiter If the output is :1, connect your VNC Client (e.g., MobaXterm or RealVNC) to Management-Host-IP:5901 (Password: P@ssw0rd). Complete the standard Ubuntu server installation with a static Management IP.\n6. Step 4: Configure Autostart \u0026amp; Power On After installation, the VM will power off (shut off). Set it to autostart and boot it:\nvirsh autostart arbiter virsh start arbiter 7. Step 5: Enable Serial Console (ttyS0) for Easy Management Modify /etc/default/grub inside the Arbiter VM to enable direct console access:\nsudo vi /etc/default/grub # Set: GRUB_CMDLINE_LINUX=\u0026#34;console=ttyS0\u0026#34; sudo update-grub Now you can attach directly from the host terminal without VNC:\nvirsh console arbiter # (Press Ctrl + ] to exit) 8. Step 6: Install the HPE SimpliVity Arbiter Package Install the official svtarb deb package:\nsudo dpkg -i ./svtarb_6.0.0.39_amd64.deb sudo systemctl status svtarb Summary Independent Arbiter: Placing the Arbiter on an external management server guarantees quorum integrity and prevents split-brain. Zero License Impact: By utilizing raw KVM CLI (virt-install), you avoid triggering expensive VME CPU core licensing fees. Flawless Deployment: With this pre-configured Arbiter IP in hand, your SimpliVity 2-node cluster deployment will complete without a single quorum hiccup. ","permalink":"https://cknotes.kr/en/posts/hpe-vme-arbiter-vm-creation/","summary":"\u003cp\u003eWhen delivering an HPE SimpliVity with VME (VM Essentials) 2-node cluster to an enterprise customer, you will almost invariably hear the client\u0026rsquo;s IT team request:\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003e\u0026ldquo;Please just host the Arbiter VM directly on the newly delivered SimpliVity nodes.\u0026rdquo;\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eTo an experienced systems engineer, this request highlights \u003cstrong\u003etwo critical architectural and commercial dilemmas\u003c/strong\u003e.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"1-the-field-dilemmas-chicken-and-egg--the-licensing-trap\"\u003e1. The Field Dilemmas: Chicken-and-Egg \u0026amp; The Licensing Trap\u003c/h2\u003e\n\u003ch3 id=\"dilemma-1-the-arbiter-must-exist-before-simplivity-storage-is-created\"\u003eDilemma 1: The Arbiter Must Exist Before SimpliVity Storage is Created\u003c/h3\u003e\n\u003cp\u003eA 2-node SimpliVity cluster requires active network communication with an Arbiter IP before the cluster creation wizard can even begin. If the SimpliVity nodes haven\u0026rsquo;t been initialized and no storage pool exists, where can you run the Arbiter VM? It is a classic \u003cstrong\u003echicken-and-egg paradox\u003c/strong\u003e.\u003c/p\u003e","title":"[SimpliVity \u0026 VME] Deploying Arbiter VM via KVM CLI"},{"content":"1. Overview HPE SimpliVity is a solution that provides integrated computing, storage, and network based on hyperconverged infrastructure (HCI).\nThe storage architecture is based on RAID + RAIN structure andNFS protocol, and VMware-based SimpliVity and VME have similarities and differences.\n2. Storage architecture core composition 1) RAID + RAIN structure RAID (Local): Configure RAID inside each node to prepare for disk failure RAIN (Cluster): Data replication to other nodes in the cluster → Data integrity is guaranteed even when node failures Double protection structure ensures high level of high availability (HA) 2) NFS protocol based data store Use NFS datastore in a VMware ESXi or VME environment OmniStack (based on VMware) or VME software virtualizes local storage to provide a logical pool of storage Virtual machines (VMs) operate reliably through this NFS datastore. 3) Data efficiency Reduce storage space through **Deduplication **+Compression technology Provides built-in backup and recovery functions → Self-DR (disaster recovery) possible without external storage 3. VMware-based SimpliVity vs HPE SimpliVity VME comparison table item SimpliVity on VMware HPE SimpliVity VME Storage Protocol NFS-based NFS-based How data is protected RAID + RAIN + OmniStack Acceleration Card RAID + RAIN (Software Defined) Hardware Dependencies OmniStack Accelerator Card required No additional hardware required, based on standard x86 servers Management Platform VMware vCenter integration VME Manager + Morpheus (can be managed simultaneously with VMware) Scalability Expandable by adding nodes Equally node-based scalability Backup/Restore Built-in features provided Provides the same built-in features Cost Structure VMware License + OmniStack Card Cost Socket-based licensing (up to 70% savings compared to VMware) 4. Additional advantages of VME architecture Hardware simplification: Reduce points of failure and ease maintenance by eliminating OmniStack cards Software-defined approach: Utilizes the latest OS (based on Ubuntu) and open source technology to improve flexibility and update speed IPv6 and modern network support: Optimized for next-generation network environments Management efficiency: Morpheus integration provides a hybrid operating environment that can manage VMware and VME simultaneously Cloud-friendliness: Enhanced on-premises + cloud scalability through HPE GreenLake integration 5. Key takeaways Common features: RAID + RAIN structure, NFS protocol-based datastore, built-in backup/recovery function Difference: VMware-based requires OmniStack card, VME is software-defined for greater simplicity and cost-effectiveness 6. Reference sources HPE SimpliVity official product page HPE VME Release Notes Documentation HPE InfoSight Solutions Guide ","permalink":"https://cknotes.kr/en/posts/hpe-simplivity-vme-storage-architecture/","summary":"\u003ch2 id=\"1-overview\"\u003e1. Overview\u003c/h2\u003e\n\u003cp\u003eHPE SimpliVity is a solution that provides integrated computing, storage, and network based on hyperconverged infrastructure (HCI).\u003c/p\u003e\n\u003cp\u003eThe storage architecture is based on \u003cstrong\u003eRAID + RAIN structure \u003cstrong\u003eand\u003c/strong\u003eNFS protocol\u003c/strong\u003e, and VMware-based SimpliVity and VME have similarities and differences.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"2-storage-architecture-core-composition\"\u003e2. Storage architecture core composition\u003c/h2\u003e\n\u003ch3 id=\"1-raid--rain-structure\"\u003e1) RAID + RAIN structure\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eRAID (Local)\u003c/strong\u003e: Configure RAID inside each node to prepare for disk failure\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRAIN (Cluster)\u003c/strong\u003e: Data replication to other nodes in the cluster → Data integrity is guaranteed even when node failures\u003c/li\u003e\n\u003cli\u003eDouble protection structure ensures high level of \u003cstrong\u003ehigh availability (HA)\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-nfs-protocol-based-data-store\"\u003e2) NFS protocol based data store\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eUse \u003cstrong\u003eNFS datastore\u003c/strong\u003e in a VMware ESXi or VME environment\u003c/li\u003e\n\u003cli\u003eOmniStack (based on VMware) or VME software virtualizes local storage to provide a \u003cstrong\u003elogical pool of storage\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eVirtual machines (VMs) operate reliably through this NFS datastore.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-data-efficiency\"\u003e3) Data efficiency\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eReduce storage space through **Deduplication **+\u003cstrong\u003eCompression\u003c/strong\u003e technology\u003c/li\u003e\n\u003cli\u003eProvides built-in backup and recovery functions → Self-DR (disaster recovery) possible without external storage\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"3-vmware-based-simplivity-vs-hpe-simplivity-vme-comparison-table\"\u003e3. VMware-based SimpliVity vs HPE SimpliVity VME comparison table\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eitem\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eSimpliVity on VMware\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eHPE SimpliVity VME\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eStorage Protocol\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNFS-based\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNFS-based\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eHow data is protected\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRAID + RAIN + OmniStack Acceleration Card\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eRAID + RAIN (Software Defined)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eHardware Dependencies\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eOmniStack Accelerator Card required\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNo additional hardware required, based on standard x86 servers\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eManagement Platform\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVMware vCenter integration\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVME Manager + Morpheus (can be managed simultaneously with VMware)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eScalability\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eExpandable by adding nodes\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEqually node-based scalability\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eBackup/Restore\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eBuilt-in features provided\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eProvides the same built-in features\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eCost Structure\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVMware License + OmniStack Card Cost\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSocket-based licensing (up to 70% savings compared to VMware)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003chr\u003e\n\u003ch2 id=\"4-additional-advantages-of-vme-architecture\"\u003e4. Additional advantages of VME architecture\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eHardware simplification\u003c/strong\u003e: Reduce points of failure and ease maintenance by eliminating OmniStack cards\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSoftware-defined approach\u003c/strong\u003e: Utilizes the latest OS (based on Ubuntu) and open source technology to improve flexibility and update speed\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIPv6 and modern network support\u003c/strong\u003e: Optimized for next-generation network environments\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eManagement efficiency\u003c/strong\u003e: Morpheus integration provides a hybrid operating environment that can manage VMware and VME simultaneously\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCloud-friendliness\u003c/strong\u003e: Enhanced on-premises + cloud scalability through HPE GreenLake integration\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"5-key-takeaways\"\u003e5. Key takeaways\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eCommon features\u003c/strong\u003e: RAID + RAIN structure, NFS protocol-based datastore, built-in backup/recovery function\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDifference\u003c/strong\u003e: VMware-based requires OmniStack card, VME is software-defined for greater simplicity and cost-effectiveness\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"6-reference-sources\"\u003e6. Reference sources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hpe.com/us/en/integrated-systems/simplivity.html\"\u003eHPE SimpliVity official product page\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://support.hpe.com/hpesc/public/docDisplay?docId=a00156081en_us\u0026amp;docLocale=en_US\"\u003eHPE VME Release Notes Documentation\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.hpe.com/us/en/solutions/infosight.html\"\u003eHPE InfoSight Solutions Guide\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"Comparison of HPE SimpliVity VME storage architecture and SimpliVity on VMware"},{"content":"1. Solution Overview HPE SimpliVity VME (Virtual Machine Essentials) is an enterprise virtualization platform based on hyperconverged infrastructure (HCI) that integrates compute, storage, and networking into a unified architecture to reduce operational complexity while delivering high availability and data efficiency.\nBy eliminating the overhead of traditional 3-tier architectures (discrete servers, SAN switches, and external storage arrays), it combines a lightweight KVM-based virtualization layer with the HPE OmniStack Virtual Controller (OVC) to streamline on-premises infrastructure.\n2. Key Architectural Features Inline Deduplication and Compression: Compresses and deduplicates data in real time as writes occur, maximizing usable storage capacity. RAID + RAIN Dual Data Protection: Combines local hardware RAID within each node with network-level data replication across nodes (RAIN) to ensure business continuity during disk or node failures. Built-in Fast Backup and Recovery: Metadata-driven storage-level snapshots allow rapid VM backup and restoration within seconds. Simplified Scale-Out Expansion: Seamlessly scales compute and storage pools linearly simply by adding nodes to the cluster. 3. Deployment Workflow Overview Field deployment progresses from initial network segmentation through management infrastructure setup and node initialization:\nPre-installation Network Design: Separate VLANs for iLO OOB, Management, Storage/Federation, and VM Traffic with MTU 9000 optimization. Management Infrastructure Deployment: BaseOS (HVM) provisioning, core services (NTP/DNS/NFS), and installation of VM Essentials Manager and Arbiter VMs. Node Initial Setup: SimpliVity node firmware updates and initial network parameter configuration. Cluster Creation and OVC Deployment: Establish the HVM cluster and deploy the OmniStack Virtual Controller instances via VME Manager. 💡 Step-by-Step Implementation Guide: For the complete walkthrough with field screenshots, refer to the HPE SimpliVity 6.2.0 Hands-On Deployment Series.\n4. Operations and Management Following deployment, virtual machine lifecycle management, resource monitoring, and datastore expansion are managed centrally through VME Manager (Morpheus).\nIntegration with HPE InfoSight provides predictive analytics to detect potential hardware degradation or storage exhaustion before service disruption occurs.\n5. Summary HPE SimpliVity VME offers a robust, cost-effective alternative to costly external SAN fabrics and increasing hypervisor licensing expenses, delivering enterprise-grade resilience and data efficiency for modern private clouds.\n","permalink":"https://cknotes.kr/en/posts/hpe-simplivity-with-vme-intro/","summary":"\u003ch2 id=\"1-solution-overview\"\u003e1. Solution Overview\u003c/h2\u003e\n\u003cp\u003eHPE SimpliVity VME (Virtual Machine Essentials) is an enterprise virtualization platform based on hyperconverged infrastructure (HCI) that integrates compute, storage, and networking into a unified architecture to reduce operational complexity while delivering high availability and data efficiency.\u003c/p\u003e\n\u003cp\u003eBy eliminating the overhead of traditional 3-tier architectures (discrete servers, SAN switches, and external storage arrays), it combines a lightweight KVM-based virtualization layer with the HPE OmniStack Virtual Controller (OVC) to streamline on-premises infrastructure.\u003c/p\u003e","title":"Introducing HPE SimpliVity With VME"},{"content":"1. Overview VMware has long led the market with its enterprise-class virtualization platform, and HPE VME (HPE Virtual Machine Essentials) is a hyperconverged solution that emphasizes cost-effectiveness and simplicity. The two platforms have differentiated strengths in purpose and functionality.\n2. Key Differences 1) Architecture and underlying technology VMware vSphere: Based on ESXi hypervisor, provides advanced VM management features HPE VME: KVM-based, HPE ProLiant servers + Ubuntu OS, Morpheus platform allows simultaneous management with VMware 2) Management and integration VMware: vCenter-centric management, strong integration with VMware ecosystem (NSX, vSAN) HPE VME: Single management console (VME Manager), HPE GreenLake and Morpheus integration, multi-hypervisor support 3) Cost structure VMware: Core-based licensing → increased costs, policy changes after Broadcom acquisition HPE VME: Socket-based licensing → Simple and predictable, resulting in up to 70% cost savings 4) Functional differences VMware: Provides advanced features such as vMotion, DRS, SR-IOV, etc. HPE VME: Built-in backup/recovery, data deduplication/compression, emphasis on simplicity (NSX-level network automation not supported) 5) Scalability and flexibility VMware: Rich hardware compatibility, enhanced cloud native and container integration HPE VME: Cloud expansion based on HPE GreenLake, enabling rapid deployment 3. Comparison table item VMware vSphere HPE VME (VM Essentials) Hypervisor ESXi KVM-based Management Platform vCenter VME Manager + Morpheus Integrity VMware ecosystem (NSX, vSAN) HPE GreenLake can simultaneously manage VMware License Core-based (increased cost) Socket-based (predictable, cost-saving) Advanced Features vMotion, DRS, SR-IOV, etc. Backup/recovery, deduplication/compression (emphasis on simplicity) Scalability Diverse hardware, cloud native Based on HPE ProLiant, GreenLake scalable Cost Effectiveness relatively high Up to 70% savings possible 4. Key takeaways VMware: Strengths in enterprise-class features and ecosystem integration, but burdened by cost and complexity HPE VME: Simplicity, cost-effectiveness, strength in hybrid management, and coexistence with VMware environments 5. Reference sources HPE Official Site – Introduction to VME VMware vSphere product page HPE VME vs VMware comparison review ","permalink":"https://cknotes.kr/en/posts/vmware-vs-hpe-vme-comparison/","summary":"\u003ch2 id=\"1-overview\"\u003e1. Overview\u003c/h2\u003e\n\u003cp\u003eVMware has long led the market with its enterprise-class virtualization platform, and HPE VME (HPE Virtual Machine Essentials) is a hyperconverged solution that emphasizes cost-effectiveness and simplicity. The two platforms have differentiated strengths in purpose and functionality.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"2-key-differences\"\u003e2. Key Differences\u003c/h2\u003e\n\u003ch3 id=\"1-architecture-and-underlying-technology\"\u003e1) Architecture and underlying technology\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware vSphere\u003c/strong\u003e: Based on ESXi hypervisor, provides advanced VM management features\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: KVM-based, HPE ProLiant servers + Ubuntu OS, Morpheus platform allows simultaneous management with VMware\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"2-management-and-integration\"\u003e2) Management and integration\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware\u003c/strong\u003e: vCenter-centric management, strong integration with VMware ecosystem (NSX, vSAN)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: Single management console (VME Manager), HPE GreenLake and Morpheus integration, multi-hypervisor support\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"3-cost-structure\"\u003e3) Cost structure\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware\u003c/strong\u003e: Core-based licensing → increased costs, policy changes after Broadcom acquisition\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: Socket-based licensing → Simple and predictable, resulting in up to 70% cost savings\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"4-functional-differences\"\u003e4) Functional differences\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware\u003c/strong\u003e: Provides advanced features such as vMotion, DRS, SR-IOV, etc.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: Built-in backup/recovery, data deduplication/compression, emphasis on simplicity (NSX-level network automation not supported)\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"5-scalability-and-flexibility\"\u003e5) Scalability and flexibility\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware\u003c/strong\u003e: Rich hardware compatibility, enhanced cloud native and container integration\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: Cloud expansion based on HPE GreenLake, enabling rapid deployment\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"3-comparison-table\"\u003e3. Comparison table\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eitem\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eVMware vSphere\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eHPE VME (VM Essentials)\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eHypervisor\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eESXi\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eKVM-based\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eManagement Platform\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003evCenter\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVME Manager + Morpheus\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eIntegrity\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eVMware ecosystem (NSX, vSAN)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eHPE GreenLake can simultaneously manage VMware\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eLicense\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eCore-based (increased cost)\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eSocket-based (predictable, cost-saving)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eAdvanced Features\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003evMotion, DRS, SR-IOV, etc.\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eBackup/recovery, deduplication/compression (emphasis on simplicity)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eScalability\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDiverse hardware, cloud native\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eBased on HPE ProLiant, GreenLake scalable\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e\u003cstrong\u003eCost Effectiveness\u003c/strong\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003erelatively high\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eUp to 70% savings possible\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003chr\u003e\n\u003ch2 id=\"4-key-takeaways\"\u003e4. Key takeaways\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eVMware\u003c/strong\u003e: Strengths in enterprise-class features and ecosystem integration, but burdened by cost and complexity\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHPE VME\u003c/strong\u003e: Simplicity, cost-effectiveness, strength in hybrid management, and coexistence with VMware environments\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003ch2 id=\"5-reference-sources\"\u003e5. Reference sources\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.hpe.com\"\u003eHPE Official Site – Introduction to VME\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.vmware.com\"\u003eVMware vSphere product page\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.hpe.com/greenlake/vme\"\u003eHPE VME vs VMware comparison review\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"VMware vs HPE VME comparative analysis"}]