ย้ายออกจาก VMware: ทางเลือกหลังเปลี่ยน License

หลัง Broadcom ซื้อ VMware เสร็จในเดือนพฤศจิกายน 2023 VMware เลิกขาย perpetual license (license แบบซื้อขาด) และให้ต่อสัญญาเป็น subscription ซึ่งส่วนใหญ่อยู่ในชุด VMware Cloud Foundation (VCF) หรือ VMware vSphere Foundation (VVF)

ทางเลือกมีสี่ทาง: ต่อสัญญาและลดขนาด ย้าย VM ไป Proxmox VE หรือ OpenStack บน hardware เดิม ย้ายขึ้น public cloud รวมถึง region ในไทย หรือผสมกันทีละระลอก ทางที่เหมาะขึ้นกับว่าระบบผูกกับ VMware ลึกแค่ไหน

พื้นฐานของการย้ายขึ้น cloud เช่น 5R และการประเมินค่าใช้จ่าย อยู่ในคู่มือ Cloud Migration

Broadcom เปลี่ยนอะไรใน license ของ VMware?

เปลี่ยนจากการขาย license แบบซื้อขาดพร้อมค่าบริการรายปี ไปเป็น subscription ที่รวมผลิตภัณฑ์เป็นชุด บทความใน VMware Cloud Foundation blog (22 มกราคม 2024) ระบุว่าการเปลี่ยนนี้ประกาศเมื่อ 11 ธันวาคม 2023 ผลิตภัณฑ์ที่เกี่ยวข้องอยู่ในสถานะ End of Availability (หยุดจำหน่าย) เมื่อขายแยกชิ้น และครอบคลุมทุกรูปแบบ license ทั้ง perpetual, Support & Subscription (SnS) และ SaaS

สามเรื่องที่กระทบการตัดสินใจต่อสัญญาโดยตรง:

• สัญญาเดิมยังได้ support จนหมดอายุ: บทความเดียวกันระบุว่า VMware ยังให้ support ตลอดอายุสัญญาเดิม ผลิตภัณฑ์ที่เลิกขายแยกชิ้นบางรายการยังใช้ได้ในฐานะส่วนหนึ่งของ VCF หรือ VVF และเมื่อต่อสัญญาให้ตกลงกับผู้ขายว่าจะย้ายไปชุดใด
• ชุดที่ขายเปลี่ยนไป: VMware Japan blog (8 กุมภาพันธ์ 2024) ซึ่งแปลจากประกาศภาษาอังกฤษ อธิบายว่าในเวลานั้น (ก.พ. 2024) มี VCF สำหรับองค์กรขนาดใหญ่ VVF สำหรับลูกค้าขนาดกลางถึงเล็ก และ vSphere Standard กับ vSphere Essentials Plus สำหรับการใช้งานที่จำกัดกว่า ส่วนเสริมเช่น storage และการกู้คืนจากภัยพิบัติขายเป็น add-on รายการชุดที่ขายเปลี่ยนได้หลังจากนั้น ให้ขอรายการ SKU ที่ขายอยู่จากผู้ขาย
• นับตาม core: Broadcom KB 313548 ระบุว่า subscription ของ VCF และ VVF นับตาม physical core โดยต้องนับขั้นต่ำ 16 core ต่อ CPU หนึ่งตัว CPU ที่มี 8 core จึงนับเป็น 16 core ส่วน vSAN นับตามความจุเป็น TiB

VMware Japan blog ข้างต้นระบุว่าเลิกขาย perpetual license และไม่รับต่อ SnS ของ perpetual license ตั้งแต่ 4 กุมภาพันธ์ 2024 และหมายเหตุว่าวันที่มีผลแตกต่างกันได้ จึงควรยืนยันเงื่อนไขของสัญญาคุณกับผู้ขาย และถามด้วยว่าผู้ขายรายเดิมยังต่อสัญญาให้ได้หรือไม่ บทความนี้ไม่กล่าวถึงราคา เพราะราคาขึ้นกับจำนวน core และสัญญาของแต่ละองค์กร

สถานะ ณ 2026-11-09

ถ้าไม่ต่อสัญญา VMware ระบบจะหยุดทำงานไหม?

สำหรับ perpetual license ระบบไม่หยุด Broadcom KB 429208 ระบุว่าเมื่อ SnS ของ perpetual license หมด ESXi และ vCenter ยังทำงานตามปกติ VM ที่เปิดอยู่ยังทำงาน feature ที่ได้ license ไว้ยังใช้ได้ และไม่มีกลไกปิดระบบอัตโนมัติ

ตาม VMware Japan blog (8 ก.พ. 2024) SnS ของ perpetual license ต่ออายุแบบเดิมไม่ได้แล้วตั้งแต่ 4 ก.พ. 2024 การต่อสัญญาจึงหมายถึงซื้อ subscription ส่วนองค์กรที่ใช้ subscription อยู่แล้ว ให้ตรวจเงื่อนไขเมื่อสิ้นสุดอายุ subscription กับผู้ขาย

สิ่งที่หายไปคือการดาวน์โหลด patch, security update และเวอร์ชันใหม่จาก Broadcom Support Portal ซึ่งจำกัดเฉพาะ account ที่มี SnS และการเปิด support request กับ Broadcom ระบบจึงเดินต่อได้ แต่เมื่อมีช่องโหว่ใหม่จะไม่มีทางแก้จากผู้ผลิต ช่วงหลังหมด SnS จึงเหมาะเป็นช่วงย้ายออกที่มีเส้นตาย ไม่ใช่สถานะที่ใช้ระยะยาว

ถ้ายังใช้ vSphere 7 อยู่ ไม่ว่าจะมีสัญญาแบบใด ก็ไม่ได้ patch สำหรับเวอร์ชันนั้นแล้วหลัง 2 ตุลาคม 2025 (KB 415405 และ VMware blog 31 มี.ค. 2025 ที่ระบุว่าหลังวันนั้นจะไม่ได้รับ product support, security patch และ update) แนวทางดูแลระบบที่หมด support ระหว่างรอย้ายอยู่ในดูแลระบบเก่าให้ปลอดภัย

ทางเลือกหลัง VMware เปลี่ยน license มีอะไรบ้าง?

มีสี่ทางหลัก และองค์กรส่วนใหญ่ใช้มากกว่าหนึ่งทางกับระบบต่างกลุ่ม

1. ต่อสัญญาและลดขนาด: ต่อ subscription สำหรับ host ที่จำเป็นจริง เพราะค่าใช้จ่ายนับตาม core การลดจำนวน host หรือรวม VM ให้อยู่บนเครื่องน้อยลงจึงมีผลโดยตรง เหมาะเมื่อระบบผูกกับ vSAN, NSX หรือเครื่องมือของ VMware มาก และต้องการเวลาวางแผนย้าย
2. ย้าย VM ไป hypervisor อื่นบน hardware เดิม: ตัวเลือกที่ใช้ KVM คือ Proxmox VE สำหรับทีมเดียวที่ดูแล VM ชุดหนึ่ง และ OpenStack ซึ่ง เอกสาร Nova ระบุว่าใช้ KVM เป็น hypervisor ค่าเริ่มต้น เหมาะเมื่อหลายทีมต้องสร้างเครื่องเองผ่าน API ความต่างระหว่าง OpenStack กับ VMware อธิบายไว้ในหน้า OpenStack ทางเลือกอื่นในตลาดมีเช่น Microsoft Hyper-V และ Nutanix AHV ซึ่งบทความนี้ไม่ได้เปรียบเทียบ
3. ย้ายขึ้น public cloud: เลิกดูแล hardware เอง และเลือก region ในไทยได้ถ้าต้องการให้ข้อมูลอยู่ในประเทศ เช่น Huawei Cloud AP-Bangkok หรือ AWS Asia Pacific (Thailand) ตารางผู้ให้บริการที่มี region ในไทยอยู่ในคู่มือ Cloud Migration
4. ผสมและย้ายทีละระลอก: คง VMware cluster ขนาดเล็กไว้สำหรับระบบที่ย้ายยาก แล้วย้ายส่วนที่เหลือเป็นระลอก ช่วยกระจายความเสี่ยงและงบประมาณ แต่ต้องดูแลสองแพลตฟอร์มในช่วงนั้น

ควรเลือกทางไหน: ตารางตามสถานการณ์

เริ่มจากสถานการณ์ที่ตรงกับระบบของคุณมากที่สุด แล้วตรวจเหตุผลในคอลัมน์ขวากับข้อมูลจากการสำรวจในหัวข้อถัดไป

ก่อนตัดสินใจต้องสำรวจอะไรในระบบ VMware?

ต้องรู้ว่ามี VM อะไรบ้าง แต่ละตัวผูกกับอะไรของ VMware และติดเงื่อนไข license ใด ข้อมูลชุดนี้ใช้ทั้งขอใบเสนอราคาต่อสัญญาและเลือกปลายทาง จึงควรทำก่อนเจรจากับผู้ขาย

Checklist สำรวจระบบ

• สัญญาและเวอร์ชัน: วันหมด SnS ของแต่ละ license เวอร์ชัน ESXi และ vCenter ของแต่ละ cluster
• Hardware: จำนวน host จำนวน CPU และ core ต่อ CPU ของแต่ละเครื่อง (ใช้คำนวณขั้นต่ำ 16 core ต่อ CPU) และวันหมดประกัน
• รายการ VM: ชื่อ OS และเวอร์ชัน จำนวน vCPU, RAM และขนาด disk ระบบงานที่ VM นั้นรองรับ และเจ้าของระบบ
• Firmware และความปลอดภัย: VM ใดบูตแบบ BIOS หรือ UEFI ใดมี vTPM (TPM เสมือนของ VM ที่ BitLocker ใช้เก็บกุญแจ) หรือ disk เข้ารหัส และเก็บ BitLocker recovery key ไว้ครบหรือไม่
• Snapshot: VM ที่ยังมี snapshot ค้าง เพราะทำให้ importer ช้าลงและบางวิธีแปลงใช้ไม่ได้
• Storage: VM ใดอยู่บน vSAN, datastore ใดมีชื่อที่มีอักขระพิเศษ และ VM ใดต่อ storage ภายนอกหรือ disk ที่แชร์ระหว่างเครื่อง
• Network: ใช้ NSX หรือไม่ ใช้ส่วนใด เช่น segment, firewall หรือ load balancer และ VM ใดใช้ IP แบบ static หรือ DHCP reservation ที่ผูกกับ MAC
• เครื่องมือที่ต่อกับ vCenter: ซอฟต์แวร์ backup, monitoring, disaster recovery และ automation ที่เชื่อมผ่าน vCenter ต้องตรวจกับผู้ขายแต่ละรายว่ารองรับปลายทางใหม่หรือไม่
• Appliance ของผู้ขาย: ระบบที่ส่งมาเป็น OVA และผู้ขายรองรับเฉพาะบน VMware
• License ของ OS และฐานข้อมูล: แนวทางของ Microsoft สำหรับ Windows Server 2025 ระบุว่าการนับตาม core ต้องนับทุก physical core ของเครื่อง ขั้นต่ำ 8 core ต่อ CPU และ 16 core ต่อเครื่อง Standard ให้สิทธิ์ 2 OSE (สภาพแวดล้อม OS แบบ physical หรือ virtual) ส่วน Datacenter ไม่จำกัด และการนับตาม VM ต้องมี subscription หรือ Software Assurance ที่ยังมีผล ย้าย VM ไป host ใหม่จึงต้องนับใหม่ตาม host ปลายทาง ส่วน SQL Server และ Oracle Database ให้ตรวจเงื่อนไขกับผู้ขายหรือที่ปรึกษาด้าน license ก่อนย้าย host
• ความสัมพันธ์ระหว่างระบบ: VM ใดต้องย้ายพร้อมกัน เช่น แอปกับฐานข้อมูลที่ latency ต่ำต้องอยู่ใกล้กัน

ปลายทางแต่ละแบบใช้อะไรแทน vSAN และ NSX?

ปลายทางทุกแบบแทนส่วน hypervisor ได้ แต่ส่วน storage, network และเครื่องมือรอบ vCenter ต้องออกแบบใหม่ และบางอย่างไม่มีของที่ทำงานเหมือนกันทุกจุด

• Storage แทน vSAN: Proxmox VE รัน Ceph บน node เดียวกับ hypervisor ได้ (hyper-converged) โดยต้องมีอย่างน้อยสามเครื่องที่ควรสเปกเหมือนกัน และ Proxmox แนะนำเครือข่ายอย่างน้อย 10 Gbps สำหรับ Ceph โดยเฉพาะ ถ้าเครื่องเดิมมี network น้อยกว่านี้ต้องรวมไว้ในงบ
• Network แทน NSX: SDN (Software-Defined Network) ของ Proxmox VE รองรับ zone แบบ Simple, VLAN, QinQ, VXLAN และ EVPN และติดตั้งเป็นค่าเริ่มต้นตั้งแต่ 8.1 แต่ IPAM/DHCP และการ routing ที่ซับซ้อนผ่าน FRRouting ยังเป็น tech preview (ฟีเจอร์ทดลองที่ผู้ผลิตยังไม่รับรองสำหรับใช้งานจริง) จึงแทน NSX ได้บางส่วน ไม่ใช่ทั้งหมด ถ้าใช้ firewall หรือ load balancer ของ NSX ต้องวางทางแทนแยก
• OpenStack: แยก compute, network และ storage เป็นบริการของตัวเอง ทีมต้องดูแลหลายบริการกว่า รายละเอียดอยู่ในหน้า OpenStack
• Public cloud: network และ storage เป็นบริการของผู้ให้บริการ ต้อง map VLAN และ firewall เดิมเป็นโครงสร้าง network ของ cloud นั้น และตรวจว่าเครื่องมือ backup เดิมรองรับหรือต้องเปลี่ยน
• vTPM: Proxmox ระบุว่าย้ายสถานะ vTPM จาก VMware ไม่ได้ VM ที่ใช้ BitLocker จึงต้องเตรียม recovery key ไว้ก่อนย้าย

แปลง VM จาก VMware (V2V) ทำอย่างไร?

ใช้เครื่องมือของปลายทางเป็นหลัก ได้แก่ import wizard ของ Proxmox VE, virt-v2v สำหรับ KVM และ OpenStack และบริการย้าย server ของผู้ให้บริการ cloud ทุกวิธีต้องหยุด VM ต้นทางในช่วงใดช่วงหนึ่ง จึงควรวางช่วงหยุดระบบของแต่ละ VM ไว้ในแผนเสมอ

Proxmox VE: import wizard

ตามหน้า Migrate to Proxmox VE importer ต้องใช้ Proxmox VE 8 ขึ้นไป (wizard สำหรับ ESXi มีตั้งแต่ 8.2) รองรับต้นทางเป็น ESXi และไฟล์ OVA/OVF ทำงานเป็น storage plugin ที่ต่อเข้า ESXi และอ่านค่าส่วนใหญ่ของ VM มาแปลงเป็นค่าของ Proxmox ข้อควรรู้:

• ต่อเข้า ESXi host โดยตรง เอกสารระบุว่า import ผ่าน vCenter ทำให้ช้าลงมาก
• ต้องปิด VM ฝั่ง VMware ก่อน import
• ใช้ไม่ได้กับ disk บน vSAN (ย้าย disk ไป storage อื่นก่อน) และ disk ที่เข้ารหัส (ถอด encryption policy ก่อน) VM ที่มี snapshot จะช้าลง และชื่อ datastore ที่มีอักขระพิเศษเช่น + อาจล้มเหลว
• ถ้าย้ายพร้อมกันหลายเครื่อง เอกสารแนะนำให้ import ไม่เกินสี่ disk พร้อมกัน
• live import ให้ VM เริ่มทำงานบน Proxmox ขณะที่ disk ยังคัดลอกอยู่เบื้องหลัง แต่ถ้า import ล้มเหลว ข้อมูลที่เขียนหลังเริ่ม import จะหายทั้งหมด

ถ้าใช้ wizard ไม่ได้ เอกสารเดียวกันมีทางอื่น คือ export เป็น OVF ด้วย ovftool ของ VMware แล้ว import ด้วยคำสั่งแรก หรือ import disk ทีละลูกด้วยคำสั่งที่สอง (disk จะเข้ามาเป็น unused disk ให้ต่อเข้า VM เอง)

qm importovf <vmid> <name>.ovf <storage>
qm disk import <vmid> <file>.vmdk <storage>

KVM และ OpenStack: virt-v2v

virt-v2v ของโครงการ libguestfs แปลง guest ทีละเครื่องจาก hypervisor อื่นให้รันบน KVM ปลายทางได้ทั้ง KVM ที่จัดการด้วย libvirt, OpenStack, oVirt และ KubeVirt (ยังเป็นโหมดทดลองตามเอกสาร) โดยคัดลอกจากต้นทางและไม่แก้ VM ต้นทาง ระหว่างแปลงจะติดตั้ง virtio driver และพยายามถอด VMware Tools

• วิธีอ่านจาก VMware: เอกสาร input ระบุว่า VDDK มักเร็วและยืดหยุ่นที่สุด ผ่าน vCenter ด้วย HTTPS ช้าที่สุด และการอ่านผ่าน SSH ใช้กับ VM ที่มี snapshot ไม่ได้
• ส่งเข้า OpenStack: ตามเอกสาร output -o openstack สร้าง Cinder volume หนึ่งลูกต่อหนึ่ง disk และต้องรัน virt-v2v ใน VM ที่อยู่บน OpenStack ปลายทาง (conversion appliance) ส่วน -o glance เป็นทางเก่าที่ไม่แนะนำ
• ข้อจำกัด: guest ต้องปิดเครื่องอย่างสมบูรณ์ ถ้ารันอยู่ระหว่างแปลง filesystem จะเสีย ใช้กับ Windows ที่เปิด Fast Startup หรือ hibernate ไม่ได้ ไม่รองรับ system disk ของ Windows ที่เป็น Dynamic Disk และไม่ปรับค่า network ของ guest ให้ การถอด VMware Tools บน Windows มักไม่สำเร็จ ควรถอดเองก่อนแปลง

Public cloud: บริการย้าย server

ผู้ให้บริการ cloud มีบริการย้าย server ของตัวเอง ตัวอย่างคือ Huawei Cloud Server Migration Service (SMS) ซึ่งย้าย server x86 ทั้งเครื่องจริงและ VM ไปเป็น ECS ขั้นตอนคือติดตั้ง SMS-Agent บนเครื่องต้นทาง เลือกหรือสร้าง ECS ปลายทาง ทำ full replication แล้วซิงก์ข้อมูลส่วนเพิ่มจนถึงวันสลับระบบ

ข้อจำกัดของ SMS ที่ต้องตรวจกับรายการ VM คือ ย้ายเครื่องที่ใช้ RAID, OS ที่เข้ารหัสเช่น BitLocker, cluster, shared file system, เครื่องที่มีหลาย OS, nested LVM และ storage ภายนอกไม่ได้ และย้ายเฉพาะ disk ที่ mount และใช้งานอยู่ ให้ตรวจด้วยว่าบริการเปิดใน region ที่เลือก

Checklist แปลง VM: driver, boot mode และเครือข่าย

ปัญหาหลังแปลงส่วนใหญ่มาจาก driver, firmware และ network รายการนี้รวมข้อควรระวังจากเอกสารของ Proxmox และ libguestfs

• ถอด VMware Tools ก่อน: Proxmox แนะนำให้ถอด guest tools ของ hypervisor เดิม และ virt-v2v ถอดบน Windows ไม่สำเร็จในหลายกรณี
• ติดตั้ง VirtIO driver: บน Linux ให้แน่ใจว่า virtio driver อยู่ใน initramfs ก่อนย้าย บน Windows ใช้ virtio-win ISO ถ้ายังไม่มี driver ให้บูต Windows จาก disk แบบ SATA หรือ IDE ก่อน แล้วจึงเปลี่ยนเป็น VirtIO SCSI
• ตั้ง firmware ให้ตรง: VM แบบ BIOS ใช้ SeaBIOS แบบ UEFI ใช้ OVMF พร้อม EFI disk บาง OS ต้องเพิ่ม boot entry เอง
• จดค่า network: ชื่อ network adapter มักเปลี่ยนหลังย้าย และ MAC address เปลี่ยน ให้ปรับ DHCP reservation หรือกำหนด MAC เอง บน Windows ที่ตั้ง static IP พิจารณาลบค่าเดิมก่อนย้ายแล้วตั้งใหม่ที่ปลายทาง
• เตรียม recovery key: สถานะ vTPM ย้ายไม่ได้ เก็บ BitLocker recovery key ของทุกเครื่องที่เข้ารหัสไว้ก่อน
• ลบ snapshot: รวม snapshot ก่อนย้ายเพื่อให้ import เร็วขึ้นและใช้วิธีแปลงได้ครบ
• ปิด Fast Startup และ hibernate ของ Windows: แล้วปิดเครื่องแบบ shutdown ปกติ

ย้ายเป็นระลอกพร้อมทางถอยกลับอย่างไร?

ย้ายจากระบบนำร่องไปสู่ระลอกที่ใหญ่ขึ้น โดยทุกระลอกมีทางถอยกลับที่ทดสอบแล้ว ทางถอยของงาน V2V ง่ายกว่าการย้ายแอปทั่วไป เพราะ VM ต้นทางยังอยู่ แต่มีเงื่อนไขที่ห้ามพลาด

1. นำร่อง: เลือก VM ที่ไม่สำคัญแต่ครอบคลุมแบบที่มีในระบบ เช่น Linux และ Windows, BIOS และ UEFI แปลง ทดสอบ และจดเวลาที่ใช้ต่อ VM เพื่อใช้วางแผนระลอกถัดไป
2. แบ่งระลอกตามกลุ่มที่พึ่งพากัน: VM ที่ต้องทำงานด้วยกันย้ายในระลอกเดียวกัน และตกลงช่วงหยุดระบบของแต่ละระลอกกับเจ้าของระบบ
3. สลับระบบในช่วงเวลาที่วางไว้: ปิด VM ต้นทาง แปลง เปิดที่ปลายทาง แล้วตรวจตามหัวข้อถัดไป
4. ถอยกลับเมื่อไม่ผ่าน: ปิด VM ปลายทาง แล้วเปิด VM ต้นทางกลับมา ห้ามเปิดทั้งสองฝั่งพร้อมกันเพราะ Proxmox เตือนว่าทำให้ disk เสีย และถ้าใช้ live import แล้วล้มเหลว ให้ถือว่าข้อมูลที่เขียนระหว่างนั้นหายและกลับไปใช้ต้นทาง
5. เก็บ VM ต้นทางไว้แบบปิดเครื่อง: ไม่ลบจนกว่าปลายทางผ่านช่วงใช้งานจริงตามที่ตกลง และกู้คืนจาก backup ของแพลตฟอร์มใหม่ได้แล้ว

เกณฑ์ตัดสินใจ go/no-go การซ้อม และการสื่อสารกับผู้ใช้ในวัน cutover อธิบายไว้ในหัวข้อ cutover ของคู่มือ Cloud Migration

หลังแปลง VM แล้วต้องทดสอบอะไร?

ทดสอบให้ครบทั้งระดับเครื่องและระดับระบบงานก่อนประกาศว่าระลอกนั้นเสร็จ

• บูตด้วย firmware ที่ถูกต้อง และ disk กับ network ใช้ driver VirtIO แล้ว
• ชื่อ network adapter, IP, DNS และ default gateway ถูกต้อง และเครื่องอื่นเรียกเข้ามาได้
• แอปและฐานข้อมูลทำงานตาม health check หรือรายการทดสอบที่เจ้าของระบบกำหนด
• ประสิทธิภาพเทียบกับค่าที่วัดไว้ก่อนย้าย เช่น เวลาตอบสนองและ I/O ของ disk
• สถานะ activation ของ Windows และ license ของซอฟต์แวร์ที่ผูกกับ hardware
• backup บนแพลตฟอร์มใหม่ทำงาน และกู้คืนได้จริงอย่างน้อยหนึ่งครั้ง
• monitoring และ log ส่งจากเครื่องใหม่ครบ และเลิกเฝ้าเครื่องต้นทางที่ปิดแล้ว

องค์กรที่มีข้อกำหนดข้อมูลและหน่วยงานรัฐต้องดูอะไรเพิ่ม?

ถ้าย้ายไป hypervisor ใหม่บน hardware เดิม ที่ตั้งข้อมูลไม่เปลี่ยน แต่ถ้าย้ายขึ้น public cloud ต้องตรวจว่าข้อมูลแต่ละชั้นไปอยู่ที่ใดได้ ข้อกำหนดเรื่องที่ตั้งข้อมูลของภาคการเงินและภาครัฐ พร้อมตาราง region ในไทย อยู่ในคู่มือ Cloud Migration ให้ตรวจด้วยว่า backup และ log ของปลายทางใหม่เก็บไว้ที่ใด

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

UNIXDEV ช่วยย้ายออกจาก VMware ได้อย่างไร?

UNIXDEV ย้าย VM ออกจาก VMware ไปยัง OpenStack หรือ KVM, Proxmox VE และ public cloud เช่น Huawei Cloud งานเริ่มจากสำรวจระบบตาม checklist ข้างต้น เปรียบเทียบทางเลือกกับข้อมูลจริงของคุณ ทำระบบนำร่อง แล้วย้ายทีละระลอกพร้อมแผนถอยกลับ ดูรายละเอียดงาน cloud ที่หน้า Cloud Services และความสามารถด้าน OpenStack, Huawei Cloud และ Linux หลังย้ายแล้ว ดูแลระบบต่อได้ผ่าน DevOps & SRE Managed Services ตามขอบเขตที่ตกลง

แหล่งอ้างอิงและอ่านต่อ

• U.S. SEC — Broadcom Inc. Form 8-K filings (22 November 2023)
• VMware blog — End of Availability of Perpetual Licensing and SaaS Services (22 January 2024) · Broadcom KB 309138
• VMware Japan blog — VMware by Broadcom business transformation (8 February 2024)
• VMware blog — License changes and upgrade paths with VCF and VVF (23 April 2024)
• Broadcom KB 313548 — Counting cores · KB 429208 — Perpetual license after SnS expiry
• Broadcom KB 415405 — End of general support for vSphere 7.0 · KB 459135 — vSphere 8.0
• VMware blog — Reminder: vSphere 7 to reach end of service October 2, 2025 (31 March 2025)
• Proxmox VE wiki — Migrate to Proxmox VE · Proxmox VE 8.2 press release · Windows VirtIO Drivers
• Proxmox VE wiki — Deploy Hyper-Converged Ceph Cluster · Software-Defined Network
• libguestfs — virt-v2v · input from VMware · output to OpenStack
• OpenStack Nova — KVM
• Huawei Cloud — SMS best practice · SMS constraints · Regions and endpoints (OBS)
• AWS — Regions
• Microsoft — Windows Server 2025 licensing guidance
• บทความที่เกี่ยวข้อง: Cloud Migration ในไทย เริ่มยังไงและประเมินค่าใช้จ่ายจากอะไร
• บทความที่เกี่ยวข้อง: TOR ย้ายระบบขึ้น Cloud ภาครัฐ ควรระบุอะไรบ้าง
• บทความที่เกี่ยวข้อง: ปรับระบบเก่าสู่ Cloud-Native
• บทความที่เกี่ยวข้อง: วางโครงสร้าง VPS และ Cloud สำหรับแอปที่กำลังเติบโต
• บทความทั้งหมดในหมวด Cloud และการย้ายระบบ

เงื่อนไข license และสัญญาให้ยืนยันกับผู้ขายของคุณ บทความนี้ไม่ใช่คำแนะนำทางกฎหมาย

ตรวจข้อมูล ณ วันที่ 2026-11-09

วิธีจัดทำ: อ้างอิงจากเอกสารต้นทางข้างต้น ตรวจโดยทีม UNIXDEV