ข้ามไปยังเนื้อหา
TH
รับ NexCMP ฟรี

การย้ายระบบ · VMware

ย้ายเครื่องเสมือน VMware ไปยัง Apache CloudStack

Apache CloudStack สามารถนำเข้าเครื่องเสมือนจาก VMware vCenter และสามารถแปลงเป็น KVM ได้ตั้งแต่เวอร์ชัน 4.19 เป็นต้นไป แต่การดำเนินการอย่างปลอดภัยยังคงต้องมีการทำรายการตรวจสอบ (inventory), การเตรียม target zone, การทดสอบระบบ และการวางแผนตัดเปลี่ยนระบบ (cutover plan) เป็นรายเครื่อง โดยตลอดระยะเวลา 30 วันทำการของ NexCMP Source วิศวกรผู้เชี่ยวชาญจะร่วมดำเนินงานขั้นตอนนี้กับคุณโดยไม่มีค่าใช้จ่ายเพิ่มเติม

รับ NexCMP ฟรีดูเดโม

รวมอยู่ใน NexCMP Source ($499 จ่ายครั้งเดียว) ไม่รวมอยู่ใน NexCMP Free ทั้งนี้ VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor และ Apache CloudStack เป็นเครื่องหมายการค้าของเจ้าของที่เกี่ยวข้อง NexCMP ดำเนินงานอย่างเป็นอิสระและไม่มีส่วนเกี่ยวข้องหรือได้รับการรับรองจากแบรนด์ดังกล่าว

ปัญหา: การย้ายออกจาก VMware โดยไม่สูญเสียการควบคุม

การย้ายไปยัง Apache CloudStack หมายความว่าเวอร์ชวลแมชชีนทุกเครื่องจะเปลี่ยนแพลตฟอร์ม ทั้งดิสก์ การ์ดเครือข่าย ไดรเวอร์ และมักรวมถึงหมายเลข IP หากดำเนินการอย่างเร่งรีบ อาจส่งผลให้เครื่องบูตไม่ขึ้น ลูกค้าไม่สามารถเข้าถึงได้ หรือไลเซนส์หยุดทำงาน

CloudStack มีเครื่องมือสำหรับการนำเข้าให้ แต่ไม่ได้ตัดสินใจแทนคุณว่าควรย้ายเครื่องใดก่อน จะแมปแต่ละเครือข่ายอย่างไร จะเกิดอะไรขึ้นกับ Windows guests หรือแต่ละเครื่องจะต้องออฟไลน์นานเพียงใด การตัดสินใจเหล่านี้และการทดสอบที่ครอบคลุมคือหัวใจสำคัญของการไมเกรต

หากคุณจำหน่ายเวอร์ชวลแมชชีนให้กับลูกค้า การย้ายระบบยังมีอีกครึ่งหนึ่งที่ต้องจัดการ นั่นคือเครื่องทั้งหมดจะต้องเชื่อมโยงกับลูกค้า แพ็กเกจ และราคาที่ถูกต้องในระบบ Billing ของคุณ NexCMP คือเลเยอร์ระบบ Billing และ Customer Portal บน CloudStack โดยมีวิศวกรผู้เชี่ยวชาญดูแลทั้งสองส่วนอย่างครบวงจร

สิ่งที่ CloudStack รองรับในตัว

มีสองแนวทางที่ระบุไว้ในเอกสารสำหรับการย้ายจาก VMware แนวทางที่เหมาะสมขึ้นอยู่กับว่าโฮสต์ VMware จะยังคงอยู่ในคลาวด์ของคุณหรือไม่

  • A. แปลงเป็น KVM ด้วย virt-v2v

    สิ่งที่ระบุในเอกสารของ CloudStack
    ตั้งแต่เวอร์ชัน 4.19 เป็นต้นมา ผู้ดูแลระบบสามารถเลือก VMware VM ในดาต้าเซ็นเตอร์ของ vCenter เดิมหรือภายนอก และนำเข้ามายัง KVM คลัสเตอร์ได้ที่เมนู Tools, Import-Export Instances ตัว VM จะถูกส่งออก แปลงด้วย virt-v2v และนำเข้าดิสก์ในรูปแบบ QCOW2 เอกสารเวอร์ชันล่าสุดได้เพิ่มช่องทางการสตรีมข้อมูลผ่าน VDDK ควบคู่กับวิธีเดิมที่ใช้ OVF ส่วนเวอร์ชัน 4.22 ได้เพิ่มการแปลงข้อมูลไปยัง storage pool โดยตรง และเวอร์ชัน 4.22.1 เพิ่มการเลือก guest OS ตาม guest OS ต้นทาง
    ข้อจำกัดที่ระบุไว้ในเอกสาร
    virt-v2v ไม่ได้ติดตั้งมาพร้อมกับ CloudStack agent และต้องติดตั้งลงในแต่ละ KVM โฮสต์ มิฉะนั้นการแปลงจะล้มเหลว ความสำเร็จในการแปลงไม่ได้การันตีและขึ้นอยู่กับ guest OS และระบบไฟล์ เอกสารจึงแนะนำให้ทดสอบก่อนนำไปใช้งานจริงบนโพรดักชัน ทั้งนี้ VM ที่นำเข้ามาจะได้ประเภท guest OS เริ่มต้นเป็น CentOS 4.5 (32-bit) ในเวอร์ชัน 4.19 และต้องแก้ไขในภายหลัง

    Source: Apache CloudStack — การนำเข้า VMware VMs เข้าสู่ KVM · เข้าถึงเมื่อ 2026-10-19

  • B. นำเข้าแบบ In-place (unmanaged instances)

    สิ่งที่ระบุในเอกสารของ CloudStack
    สำหรับ vSphere คลัสเตอร์ที่มีโฮสต์เป็นส่วนหนึ่งของ CloudStack อยู่แล้ว คำสั่ง listUnmanagedInstances จะแสดงรายการ VM และคำสั่ง importUnmanagedInstance จะนำ VM เข้ามาอยู่ภายใต้การจัดการของ CloudStack การแสดงรายการ unmanaged VMware instances เริ่มมีในเวอร์ชัน 4.14 การยกเลิกการจัดการเริ่มใน 4.15 และการนำเข้าผ่าน UI เริ่มใน 4.16
    ข้อจำกัดที่ระบุไว้ในเอกสาร
    เครือข่ายปลายทางจะต้องมีอยู่แล้วใน CloudStack และต้องเพิ่มสตอเรจเป็น primary storage แล้ว ดิสก์ข้อมูลต้องได้รับการแมปเข้ากับ disk offerings ทั้งนี้หากมีประเภทคอนโทรลเลอร์ของดิสก์หรือประเภท NIC ปะปนกันจะทำให้เกิดข้อผิดพลาด สำหรับ VM ที่กำลังทำงานอยู่จะสามารถนำเข้าได้ก็ต่อเมื่อ network VLAN และ compute offering ตรงกันเท่านั้น มิฉะนั้นจะต้องหยุดการทำงานของเครื่องก่อน

    Source: Apache CloudStack — เกี่ยวกับ Import Export Instances · เข้าถึงเมื่อ 2026-10-19

แนวทาง A ใช้เมื่อปลายทางเป็น KVM เอกสารของ NexCMP ระบุว่า KVM คือไฮเปอร์ไวเซอร์ที่ผ่านการทดสอบแล้ว ดังนั้นเราจึงวางแผนใช้แนวทาง A เว้นแต่การออกแบบของคุณจะคงโฮสต์ VMware ไว้ภายใต้ CloudStack โปรดตรวจสอบเวอร์ชัน CloudStack ที่คุณใช้งาน เนื่องจากเอกสารข้างต้นระบุถึงพฤติกรรมการทำงานที่แตกต่างกันระหว่างเวอร์ชัน 4.19 และเวอร์ชันล่าสุด

สิ่งที่จะถูกย้ายและสิ่งที่ต้องให้ความสำคัญ

  • ดิสก์

    ขั้นตอนการทำงาน
    แปลงเป็น QCOW2 และนำเข้าไปยัง primary storage pool ของปลายทาง (แนวทาง A) หรือแมปเข้ากับ disk offerings ของ CloudStack (แนวทาง B)
    ข้อควรระวัง
    ในแนวทาง B ดิสก์จะไม่ถูกปรับขนาดแม้ว่า disk offering จะมีขนาดใหญ่กว่า สตอเรจชั่วคราวระหว่างการแปลงตามแนวทาง A จะใช้ secondary storage เป็นค่าเริ่มต้น โดยจะใช้ primary storage ได้ก็ต่อเมื่อเป็น NFS เท่านั้น

    Source: Apache CloudStack — การนำเข้า VMware VMs เข้าสู่ KVM · เข้าถึงเมื่อ 2026-10-19

  • เครือข่าย

    ขั้นตอนการทำงาน
    เครือข่ายต้องมีอยู่แล้วใน CloudStack ก่อนการนำเข้า โดยมีสคริปต์ค้นหาที่จะแสดงรายการเครือข่าย vCenter ที่มี VM เชื่อมต่ออยู่อย่างน้อยหนึ่งเครื่อง เพื่อให้สามารถสร้างเครือข่ายที่ตรงกันได้
    ข้อควรระวัง
    virt-v2v ไม่สามารถกำหนดค่าคอนฟิกเครือข่ายของ guest ใหม่ หรือเปลี่ยน MAC address ได้ หากซับเน็ตปลายทางแตกต่างจากเดิม จะต้องเข้าไปปรับแต่งที่ตัว guest หลังการแปลง

    Source: libguestfs — คู่มือ virt-v2v · เข้าถึงเมื่อ 2026-10-19

  • Linux guests

    ขั้นตอนการทำงาน
    Linux VM ที่กำลังทำงานอยู่สามารถนำเข้าผ่านแนวทาง A ได้ โดย CloudStack จะทำการโคลนเครื่องก่อนส่งออก ทำให้การแปลงข้อมูลอยู่ในสถานะ crash-consistent
    ข้อควรระวัง
    เอกสารของ CloudStack แนะนำให้ปิดเครื่อง Linux VM ก่อน virt-v2v จะไม่ติดตั้งเคอร์เนลหรือไดรเวอร์ใหม่ และจะแจ้งเตือนหากไม่มีการรองรับ virtio ดังนั้น guest จึงต้องมีเวอร์ชันขั้นต่ำตรงตามข้อกำหนดก่อนเริ่มการแปลง

    Source: libguestfs — คู่มือ virt-v2v · เข้าถึงเมื่อ 2026-10-19

  • Windows guest

    ขั้นตอนการทำงาน
    ต้องทำการปิดเครื่องอย่างสมบูรณ์ (graceful shutdown) ก่อนอิมพอร์ตด้วยเส้นทาง A ไดรเวอร์ virtio จะถูกนำมาจากแพ็กเกจ virtio-win และติดตั้งในการบูตครั้งแรก โดย Windows อาจรีบูต 4 ครั้งขึ้นไปหลังจากการบูตครั้งแรก
    ข้อควรระวัง
    Fast Startup หรือการ hibernate จะทำให้ไม่สามารถแปลงระบบได้ และไม่รองรับดิสก์ระบบที่อยู่บน Dynamic Disk การอิมพอร์ต Windows จำเป็นต้องมีไดรเวอร์ virtio บนโฮสต์ที่ทำการแปลง

    Source: libguestfs — คู่มือ virt-v2v · เข้าถึงเมื่อ 2026-10-19

  • VMware Tools

    ขั้นตอนการทำงาน
    virt-v2v จะพยายามลบ VMware Tools ออก
    ข้อควรระวัง
    คู่มือระบุว่าการลบอาจทำงานได้ไม่สมบูรณ์บน Windows ซึ่งอาจจำเป็นต้องลบ Tools ด้วยวิธีอื่น

    Source: libguestfs — คู่มือ virt-v2v · เข้าถึงเมื่อ 2026-10-19

  • ประเภท Guest OS

    ขั้นตอนการทำงาน
    VM ที่อิมพอร์ตเข้ามาจะได้รับประเภท Guest OS ค่าเริ่มต้น
    ข้อควรระวัง
    ในเวอร์ชัน 4.19 จะเป็น CentOS 4.5 (32-bit) และต้องเปลี่ยนด้วยตนเอง ส่วนเวอร์ชัน 4.22.1 สามารถแมปจาก Guest OS ต้นทางได้หากมีการกำหนดค่าการแมปไว้

    Source: Apache CloudStack — การนำเข้า VMware VMs เข้าสู่ KVM · เข้าถึงเมื่อ 2026-10-19

  • ระบบเรียกเก็บเงินและลูกค้า

    ขั้นตอนการทำงาน
    แผน ราคา และบัญชีลูกค้าจะได้รับการตั้งค่าใน NexCMP และเครื่องที่ย้ายข้อมูลแต่ละเครื่องจะถูกเชื่อมโยงไปยังลูกค้าที่ถูกต้อง
    ข้อควรระวัง
    ตกลงร่วมกันในสัปดาห์ที่ 1 สำหรับเวอร์ชัน CloudStack ของคุณ ทั้งนี้เป็นงานของ NexCMP ไม่ใช่ฟีเจอร์ของ CloudStack

แผนการดำเนินงานรายสัปดาห์

เป็นไปตามรูปแบบทั่วไปและปรับตามกรณีของคุณ ระยะเวลาทำงานต่อเนื่อง 30 วันทำการคิดเป็นเวลาประมาณ 6 สัปดาห์ตามปฏิทิน

  1. สัปดาห์ที่ 1 — สำรวจข้อมูลระบบและการตัดสินใจ

    ด้วยสิทธิ์การเข้าถึง vCenter แบบอ่านอย่างเดียว เราจะทำรายการ VM ทั้งหมด: Guest OS, ดิสก์, การ์ดเครือข่าย, VLAN, สแนปช็อต, สถานะการทำงาน และความเกี่ยวข้องกันของแต่ละระบบ เราจะเลือกเส้นทาง A หรือ B กำหนดรอบการย้าย และระบุเครื่องที่ต้องดูแลเป็นพิเศษ เช่น Windows guest, เครื่องที่มีดิสก์ขนาดใหญ่ และระบบที่มีไลเซนส์แบบผูกคงที่

  2. สัปดาห์ที่ 2 — จัดเตรียมระบบปลายทาง

    โซน CloudStack จะได้รับการตรวจสอบหรือจัดสร้างขึ้น: โฮสต์ KVM, สตอเรจ และเครือข่ายที่ตรงกับของ VMware เราจะติดตั้ง virt-v2v บนโฮสต์ KVM (และ nbdkit บนโฮสต์ Ubuntu) เตรียมไดรเวอร์ virtio สำหรับ Windows และเปิดเส้นทางเครือข่ายระหว่างโฮสต์ที่ทำการแปลงกับ vCenter และ ESXi หากคุณให้บริการขายเครื่อง NexCMP จะได้รับการติดตั้งและเชื่อมต่อกับ CloudStack ภายในสัปดาห์เดียวกันนี้

  3. สัปดาห์ที่ 3 — โครงการนำร่อง

    เครื่องที่ไม่ใช่ระบบวิกฤตจำนวน 2-3 เครื่อง (ประเภทละหนึ่งเครื่องตาม Guest ที่คุณมี) จะเข้าสู่กระบวนการย้ายจริง เราจะตรวจสอบว่าเครื่องสามารถบูตได้ ใช้งานเครือข่ายได้ และมีไดรเวอร์ที่ถูกต้อง ตั้งค่าประเภท Guest OS ตลอดจนวัดระยะเวลาที่เครื่องต้องออฟไลน์ ผลลัพธ์ที่ได้จะนำมาใช้กำหนดกรอบเวลาสำหรับรอบการย้ายข้อมูล

  4. สัปดาห์ที่ 4 และ 5 — ดำเนินการย้ายระบบเป็นรอบ

    การย้ายเครื่องจะดำเนินการเป็นกลุ่มตามเวลาที่คุณตกลงไว้ แต่ละกลุ่มจะได้รับการตรวจสอบก่อนเริ่มกลุ่มถัดไป และเครื่อง VMware เดิมจะถูกปิดไว้แต่ยังคงเก็บรักษาไว้เพื่อให้คุณสามารถย้อนกลับได้ หากคุณให้บริการขายเครื่อง บัญชีลูกค้า แผน และราคาจะได้รับการตั้งค่าใน NexCMP ไปพร้อมกัน และระบบเรียกเก็บเงินจะทำงานควบคู่กันไปก่อนที่คุณจะสลับระบบจริง

  5. สัปดาห์ที่ 6 — ตัดถ่ายระบบขั้นสุดท้ายและการส่งมอบงาน

    เครื่องชุดสุดท้ายจะถูกย้าย วันที่เรียกเก็บเงินจะถูกสลับหากคุณให้บริการขาย และดำเนินการปรับเปลี่ยนค่า DNS เราจะจัดทำเอกสารขั้นตอนการทำงานทั้งหมด ทบทวนการเสริมความปลอดภัย (hardening) และระบบแบ็กอัป พร้อมทั้งคอยสนับสนุนการย้ายระบบจนครบกำหนด 30 วันทำการ

เป็นเพียงโครงร่างเบื้องต้นเท่านั้น แผนการจริงจะสรุปในสัปดาห์ที่ 1 และข้อผูกพันตามกรอบเวลาเพียงอย่างเดียวในข้อเสนอนี้คือ 30 วันทำการ

ความเสี่ยงและวิธีที่เราใช้ลดความเสี่ยง

การย้ายระบบทุกครั้งมีความเสี่ยง และเราไม่ได้รับประกัน zero downtime นี่คือสิ่งที่อาจเกิดขึ้นได้และวิธีที่เราใช้จัดการ

  • Downtime ต่อเครื่อง

    เครื่อง Windows ไม่สามารถแปลงระบบขณะทำงานอยู่ได้ ส่วนเครื่อง Linux ที่กำลังทำงานอยู่จะถูกแปลงในสถานะ crash-consistent โดย CloudStack ไม่ได้ระบุระยะเวลาที่ใช้ในการแปลง เราจึงทำการวัดผลในโครงการนำร่อง และตกลงกรอบเวลาการหยุดทำงานต่อกลุ่มเครื่อง

  • การแปลงระบบไม่สำเร็จ

    CloudStack ระบุว่าไม่สามารถรับประกันความสำเร็จได้และขึ้นอยู่กับตัว guest เราจะทดสอบ guest แต่ละประเภทในโครงการนำร่องก่อนเริ่มแต่ละรอบ และเครื่องเดิมจะคงไว้โดยไม่มีการแตะต้องจนกว่าเครื่องใหม่จะผ่านการตรวจสอบ

  • ไดรเวอร์และ VMware Tools

    เครื่อง Windows จะได้รับไดรเวอร์ virtio ระหว่างการแปลง ส่วนเครื่อง Linux ต้องมีการรองรับ virtio ไว้ล่วงหน้า และ VMware Tools อาจจำเป็นต้องลบออกด้วยตนเอง โดยรายการเหล่านี้จะได้รับการตรวจสอบสำหรับ guest แต่ละระบบในโครงการนำร่อง

  • ที่อยู่ IP, MAC address และ DNS

    Guest จะยังคงใช้ MAC address เดิมและการกำหนดค่าเครือข่ายของตนเอง ดังนั้นหากซับเน็ตปลายทางแตกต่างไป จะต้องแก้ไขการตั้งค่าภายใน guest เราจะทำรายการที่อยู่ทั้งหมดในสัปดาห์ที่ 1 ปรับลดค่า DNS TTL ล่วงหน้าก่อนการตัดถ่ายระบบ และแจ้งลูกค้าของคุณล่วงหน้า

  • ไลเซนส์ซอฟต์แวร์บน Guest

    Windows และซอฟต์แวร์เชิงพาณิชย์ภายในเครื่องอาจมีสัญญาอนุญาตผูกอยู่กับแพลตฟอร์มเดิม เราจะจัดทำรายการเหล่านี้ไว้ในคลัง เพื่อให้คุณสามารถตรวจสอบข้อกำหนดกับผู้ให้บริการแต่ละรายก่อนดำเนินการย้าย

  • การแปลงระบบที่หยุดชะงัก

    CloudStack ระบุว่าการรีสตาร์ต management server ระหว่างการย้ายข้อมูลจะทำให้กระบวนการหยุดชะงัก และต้องเริ่มการนำเข้าใหม่อีกครั้ง เราจึงจัดตารางแต่ละรอบ (waves) ให้เลี่ยงช่วงเวลาซ่อมบำรุง และหลีกเลี่ยงการรีสตาร์ตในขณะที่รอบนั้นกำลังทำงานอยู่

  • การสลับระบบคิดเงินและการย้อนกลับ

    หากคุณจำหน่ายเครื่องเหล่านี้ วันที่เริ่มย้ายระบบคิดเงินจะกำหนดร่วมกับคุณ และทั้งสองระบบจะทำงานควบคู่กันไปก่อน เครื่องต้นฉบับบน VMware จะถูกเก็บรักษาไว้จนกว่าคุณจะเห็นพ้องว่าการย้ายข้อมูลเสร็จสมบูรณ์ เพื่อให้ทุกฝ่ายมีแนวทางย้อนกลับได้เสมอ

หน้าที่และความรับผิดชอบ

  • สิทธิ์การเข้าถึง vCenter แบบอ่านอย่างเดียว (Read-only) และรายชื่อเครื่องที่คุณเห็นว่ามีความสำคัญอย่างยิ่ง

    สิ่งที่ผู้เชี่ยวชาญจะดำเนินการ
    จัดทำรายการ VM ทั้งหมดและวางแผนรอบการย้ายข้อมูล

  • สิทธิ์การเข้าถึงสภาพแวดล้อม CloudStack และโฮสต์ KVM หรือฮาร์ดแวร์สำหรับสร้างระบบดังกล่าว

    สิ่งที่ผู้เชี่ยวชาญจะดำเนินการ
    จัดเตรียม zone เครือข่าย และโฮสต์สำหรับการแปลงระบบ

  • แพ็กเกจ VDDK และ virtio ตามแนวทางที่คุณเลือก ในกรณีที่ผู้ให้บริการกำหนดให้คุณต้องดาวน์โหลดด้วยตนเอง

    สิ่งที่ผู้เชี่ยวชาญจะดำเนินการ
    ติดตั้งและทดสอบแพ็กเกจเหล่านั้นบนโฮสต์สำหรับการแปลงระบบ

  • ช่วงเวลาหยุดให้บริการที่ตกลงร่วมกัน และการแจ้งเตือนไปยังลูกค้าของคุณ

    สิ่งที่ผู้เชี่ยวชาญจะดำเนินการ
    ดำเนินโครงการนำร่อง (pilot) และรอบการย้ายข้อมูล รวมถึงตรวจสอบทุกเครื่องหลังจากดำเนินการเสร็จสิ้น

  • การตัดสินใจเรื่องการกำหนดราคาของคุณ หากคุณจำหน่ายเครื่องเหล่านี้

    สิ่งที่ผู้เชี่ยวชาญจะดำเนินการ
    ตั้งค่าแพ็กเกจ ลูกค้า และระบบคิดเงินใน NexCMP พร้อมทั้งดูแลช่วงเวลาที่ระบบทำงานควบคู่กัน

สิ่งที่คุณจะได้รับภายใน 30 วันทำการ

บริการย้ายระบบรวมอยู่ในแพ็กเกจอัปเกรด NexCMP Source แบบชำระครั้งเดียว $499 ซึ่งครอบคลุมซอร์สโค้ดทั้งหมด (เซิร์ฟเวอร์ Rust, พอร์ทัลและส่วนแอดมิน Vue, เอเจนต์โหนด Go, CLI, สคริปต์บิลด์) สิทธิ์ในการปรับแต่งและบิลด์เวอร์ชันของคุณเองได้ไม่จำกัด ซอร์สโค้ดเวอร์ชันใหม่เป็นเวลา 12 เดือน แอปทั้งหมด และการทำงานร่วมกับวิศวกรผู้เชี่ยวชาญอย่างต่อเนื่องเป็นเวลา 30 วันทำการ

ภายใน 30 วันทำการดังกล่าว ผู้เชี่ยวชาญจะช่วยคุณย้ายระบบจาก VMware ไปยัง Apache CloudStack โดยไม่มีค่าใช้จ่ายเพิ่มเติม นอกจากนี้ คุณยังสามารถใช้เวลาดังกล่าวในการย้ายระบบจาก WHMCS หรือระบบอื่น หรือเพื่อตั้งค่าระบบแบบครบวงจรตั้งแต่เริ่มต้นจนจบและบิลด์แอปของคุณได้ด้วยเช่นกัน เวลานับถอยหลังจะเริ่มขึ้นเมื่อคุณเริ่มทำงานร่วมกับผู้เชี่ยวชาญและจะแสดงบนหน้ารายละเอียดใบอนุญาตของคุณ บริการสนับสนุนสำหรับการย้ายระบบจะมีผลตลอด 30 วันนี้เช่นเดียวกัน

NexCMP Free ไม่ครอบคลุมบริการนี้ โดย Free ใช้งานได้ฟรี 1 ปีพร้อมโมดูลทั้งหมด และไม่มีบริการสนับสนุนทางเทคนิค มีเพียงการแก้ไขข้อผิดพลาดของซอร์สโค้ดเท่านั้น และต่ออายุในราคา $99 ต่อปี

VMware to CloudStack — คำถามที่พบบ่อย

มีค่าใช้จ่ายเท่าไร?
การย้ายระบบเป็นส่วนหนึ่งของการอัปเกรด NexCMP Source โดยมีค่าบริการครั้งเดียว $499 ราคานี้รวมซอร์สโค้ด การอัปเดตเวอร์ชันซอร์สโค้ดใหม่ 12 เดือน แอปทั้งหมด และการทำงานร่วมกับวิศวกรผู้เชี่ยวชาญ 30 วันทำการ ข้อเสนอนี้ไม่มีค่าบริการรายชั่วโมง
บริการนี้รวมอยู่ใน NexCMP Free หรือไม่?
ไม่ บริการย้ายระบบมาพร้อมกับ NexCMP Source เท่านั้น ส่วน NexCMP Free มีโมดูลทั้งหมดให้ใช้งานได้ 1 ปี แต่ไม่มีบริการสนับสนุนทางเทคนิค มีเพียงการแก้ไขข้อผิดพลาดของซอร์สโค้ด และต่ออายุในราคา $99 ต่อปี
รองรับ CloudStack และ VMware เวอร์ชันใดบ้าง
เอกสารของ CloudStack ระบุว่าการแปลงระบบจาก VMware เป็น KVM สามารถใช้งานได้ตั้งแต่เวอร์ชัน 4.19 ขึ้นไป และไม่ได้ระบุว่ารองรับ vSphere เวอร์ชันใดบ้าง โดยหน้าเอกสารล่าสุดแนะนำให้ใช้ VDDK 8 สำหรับสภาพแวดล้อม vSphere 7 และ 8 ทั้งนี้เอกสารของ NexCMP ระบุเวอร์ชัน 4.23 ว่าเป็นรุ่น CloudStack ที่ผ่านการทดสอบแล้ว โปรดตรวจสอบเวอร์ชันที่คุณใช้งานอยู่ โดยเราจะยืนยันเวอร์ชันทั้งสองในสัปดาห์ที่ 1
เครื่องเวอร์ชวลแมชชีนจะมีช่วงเวลาหยุดทำงาน (downtime) หรือไม่
มี แต่ละเครื่องจะออฟไลน์ไปช่วงระยะเวลาหนึ่ง และเราไม่ได้รับประกันการไม่มี downtime เครื่อง Windows จะต้องถูกปิดการทำงานอย่างสมบูรณ์ก่อนทำการนำเข้า ส่วนเครื่อง Linux ที่กำลังทำงานอยู่สามารถนำเข้าได้แต่จะถูกแปลงในสถานะ crash-consistent ดังนั้นเราจึงมักปิดเครื่องก่อนเสมอ โดยโครงการนำร่องจะวัดเวลาที่ใช้และกำหนดกรอบเวลาที่แน่นอน
สามารถแปลง VM ได้ทุกเครื่องหรือไม่
ไม่เสมอไป CloudStack ระบุว่าไม่สามารถรับประกันความสำเร็จได้ และขึ้นอยู่กับ guest OS รวมถึงระบบไฟล์ ในบางกรณีของ Windows เช่น ดิสก์ระบบที่อยู่บน Dynamic Disk หรือการเปิดใช้ Fast Startup จะถูกระบุว่าเป็นอุปสรรคโดย virt-v2v ด้วยเหตุนี้เราจึงทดสอบ guest แต่ละประเภทก่อนเริ่มรอบการย้ายข้อมูลจริง
หลังจากนั้นฉันยังต้องคง VMware ไว้อยู่หรือไม่
ไม่จำเป็นสำหรับเครื่องที่ย้ายระบบเสร็จแล้ว เราจะปิดเครื่องต้นฉบับไว้จนกว่าคุณจะเห็นพ้องว่าการย้ายข้อมูลเสร็จสมบูรณ์ จากนั้นคุณสามารถตัดสินใจว่าจะปลดระวางเครื่องเหล่านั้นเมื่อใด ส่วนเรื่องสัญญาอนุญาตของสภาพแวดล้อม VMware นั้นเป็นข้อตกลงระหว่างคุณกับผู้ให้บริการดังกล่าว
คุณต้องเตรียมอะไรบ้าง?
สิทธิ์การเข้าถึง vCenter แบบอ่านอย่างเดียว (Read-only), สิทธิ์เข้าถึงสภาพแวดล้อม CloudStack และ KVM hosts, กรอบเวลาหยุดการทำงานของระบบ (stop windows) ตามที่คุณตกลงไว้ และผู้ที่สามารถตอบคำถามเกี่ยวกับเครื่องได้ ในกรณีที่เวนเดอร์กำหนดให้คุณต้องดาวน์โหลดแพ็กเกจอย่าง VDDK ด้วยตนเอง คุณจะเป็นผู้จัดเตรียมสิ่งนั้น

แหล่งข้อมูลและหมายเหตุ

ข้อความทางเทคนิคอ้างอิงจากเอกสารทางการของ Apache CloudStack และคู่มือ virt-v2v เนื้อหาเอกสารอาจมีการเปลี่ยนแปลงในแต่ละเวอร์ชัน โปรดตรวจสอบเวอร์ชันที่คุณใช้งานอยู่ ข้อมูลเวอร์ชัน 4.19 มาจากเอกสารเวอร์ชัน 4.19 ซึ่งขึ้นต้นหน้า VMware-to-KVM ด้วยคำว่า 'As of CS 4.19' ทั้งนี้ VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor และ Apache CloudStack เป็นเครื่องหมายการค้าของเจ้าของที่เกี่ยวข้อง NexCMP เป็นอิสระและไม่มีส่วนเกี่ยวข้องหรือได้รับการรับรองจากองค์กรดังกล่าว

ย้ายออกจาก VMware โดยมีวิศวกรคอยดูแลเคียงข้างคุณ

อัปเกรดเป็น NexCMP Source ในราคา $499 และเริ่มต้นระยะเวลาดำเนินงาน 30 วันทำการของคุณ หรือสอบถาม [email protected] เกี่ยวกับสภาพแวดล้อมระบบของคุณก่อนได้

รับ NexCMP ฟรีติดต่อฝ่ายขายดูเดโม

อัปเดตล่าสุด: