Di chuyển · VMware
Di chuyển máy ảo VMware sang Apache CloudStack
Apache CloudStack có thể import máy ảo từ VMware vCenter và hỗ trợ chuyển đổi sang KVM từ phiên bản 4.19. Để thực hiện an toàn, bạn vẫn cần lập bản kiểm kê, chuẩn bị zone đích, chạy thử nghiệm và lập kế hoạch chuyển đổi cho từng máy. Trong 30 ngày làm việc của gói NexCMP Source, một kỹ sư chuyên gia sẽ đồng hành thực hiện công việc đó cùng bạn mà không tính thêm phụ phí.
Bao gồm trong NexCMP Source ($499 một lần), không kèm trong NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor và Apache CloudStack là thương hiệu của các chủ sở hữu tương ứng. NexCMP độc lập và không liên kết hay được chứng thực bởi các bên này.
Vấn đề: rời khỏi VMware mà không mất quyền kiểm soát
Chuyển sang Apache CloudStack đồng nghĩa với việc mọi máy ảo đều thay đổi nền tảng: ổ đĩa, card mạng, driver và thường là cả địa chỉ mạng. Nếu thực hiện vội vàng, đây là lúc máy ảo không khởi động được, khách hàng mất quyền truy cập hoặc license ngừng hoạt động.
CloudStack cung cấp các công cụ import, nhưng không thể quyết định thay bạn máy nào chuyển trước, từng network được map ra sao, điều gì xảy ra với các guest Windows, hay mỗi máy sẽ offline bao lâu. Những quyết định đó, cùng quy trình kiểm thử đi kèm, chính là bản chất của quá trình migration.
Nếu bạn bán máy ảo cho khách hàng, quá trình chuyển đổi còn một nửa còn lại: các máy ảo phải được gắn đúng với khách hàng, gói dịch vụ và mức giá trong hệ thống billing của bạn. NexCMP chính là lớp billing và portal khách hàng đặt trên CloudStack, và cùng một kỹ sư sẽ phụ trách cả hai phần việc này.
Những gì bản thân CloudStack hỗ trợ
Có hai phương án được tài liệu hóa để chuyển từ VMware. Phương án phù hợp phụ thuộc vào việc các host VMware có tiếp tục nằm trong cloud của bạn hay không.
A. Chuyển đổi sang KVM bằng virt-v2v
- Tài liệu CloudStack mô tả
- Từ phiên bản 4.19, quản trị viên có thể chọn một VM VMware trong datacenter vCenter hiện có hoặc bên ngoài và import vào cụm KVM, tại mục Tools, Import-Export Instances. VM được export, chuyển đổi bằng virt-v2v và các ổ đĩa được import dưới dạng QCOW2. Tài liệu mới nhất bổ sung thêm phương thức streaming dựa trên VDDK bên cạnh phương thức dựa trên OVF; phiên bản 4.22 bổ sung khả năng chuyển đổi trực tiếp vào storage pool và phiên bản 4.22.1 cho phép chọn guest OS dựa trên guest OS nguồn.
- Giới hạn nêu trong tài liệu
- virt-v2v không được cài đặt sẵn bởi CloudStack agent mà phải được cài đặt trên từng host KVM, nếu không quá trình chuyển đổi sẽ thất bại. Khả năng thành công không được đảm bảo tuyệt đối và phụ thuộc vào guest OS cũng như file system, vì vậy tài liệu khuyến nghị nên kiểm thử trước khi đưa vào môi trường production. VM sau khi import sẽ nhận loại guest OS mặc định là CentOS 4.5 (32-bit) ở bản 4.19 và cần được chỉnh sửa lại sau đó.
Source: Apache CloudStack — Import máy ảo VMware vào KVM · truy cập ngày 2026-10-19
B. Import tại chỗ (unmanaged instances)
- Tài liệu CloudStack mô tả
- Với các cụm vSphere có host đã nằm trong CloudStack, listUnmanagedInstances sẽ liệt kê các VM và importUnmanagedInstance sẽ đưa chúng vào diện quản lý của CloudStack. Tính năng liệt kê VMware instances chưa quản lý bắt đầu từ bản 4.14, hủy quản lý từ bản 4.15 và import trên giao diện UI từ bản 4.16.
- Giới hạn nêu trong tài liệu
- Network đích phải tồn tại sẵn trong CloudStack, và storage phải được thêm dưới dạng primary storage. Các ổ data disk phải được map với disk offering tương ứng; việc dùng lẫn lộn các loại controller đĩa hoặc loại NIC sẽ gây lỗi. Một VM đang chạy chỉ có thể được import nếu network VLAN và compute offering khớp hoàn toàn; nếu không, VM phải được tắt trước.
Source: Apache CloudStack — Giới thiệu về Import Export Instances · truy cập ngày 2026-10-19
Phương án A áp dụng khi đích đến là KVM. Tài liệu của NexCMP xác định KVM là hypervisor đã được kiểm thử, vì vậy chúng tôi lên kế hoạch theo phương án A trừ khi thiết kế của bạn giữ lại các host VMware dưới sự quản lý của CloudStack. Hãy kiểm tra phiên bản CloudStack bạn đang chạy: các trang tài liệu ở trên mô tả hành vi khác nhau giữa bản 4.19 và bản phát hành mới nhất.
Những gì được di chuyển và những điểm cần lưu ý
Ổ đĩa
- Quá trình diễn ra
- Được chuyển đổi sang QCOW2 và import vào primary storage pool đích (phương án A), hoặc được map với các disk offering của CloudStack (phương án B).
- Lưu ý
- Trong phương án B, ổ đĩa sẽ không được thay đổi kích thước nếu disk offering có dung lượng lớn hơn. Dung lượng lưu trữ tạm thời trong quá trình chuyển đổi ở phương án A mặc định là secondary storage; primary storage chỉ có thể được dùng làm nơi lưu tạm nếu là NFS.
Source: Apache CloudStack — Import máy ảo VMware vào KVM · truy cập ngày 2026-10-19
Mạng
- Quá trình diễn ra
- Các mạng phải tồn tại sẵn trong CloudStack trước khi import. Một script discovery sẽ liệt kê các mạng vCenter đang có ít nhất một VM kết nối, giúp bạn tạo các mạng tương ứng.
- Lưu ý
- virt-v2v không thể cấu hình lại network của máy guest hoặc thay đổi địa chỉ MAC của nó. Nếu subnet đích khác biệt, máy guest sẽ cần được cấu hình lại sau khi chuyển đổi.
Source: libguestfs — Hướng dẫn sử dụng virt-v2v · truy cập ngày 2026-10-19
Guest Linux
- Quá trình diễn ra
- Một VM Linux đang chạy có thể được import theo phương án A: CloudStack sẽ clone VM trước khi export, do đó nó được chuyển đổi ở trạng thái crash-consistent.
- Lưu ý
- Tài liệu CloudStack khuyến nghị tắt nguồn VM Linux trước. virt-v2v không cài đặt kernel hoặc driver mới, đồng thời sẽ cảnh báo nếu thiếu hỗ trợ virtio, vì vậy guest OS phải đáp ứng các phiên bản tối thiểu trước khi chuyển đổi.
Source: libguestfs — Hướng dẫn sử dụng virt-v2v · truy cập ngày 2026-10-19
Guest Windows
- Quá trình diễn ra
- Phải được tắt đúng cách (graceful shutdown) trước khi import theo phương án A. Driver virtio được lấy từ gói virtio-win và cài đặt trong lần khởi động đầu tiên; Windows có thể khởi động lại từ bốn lần trở lên sau lần khởi động đầu tiên.
- Lưu ý
- Tính năng Fast Startup hoặc chế độ ngủ đông (hibernation) sẽ ngăn cản quá trình chuyển đổi, và ổ đĩa hệ thống trên Dynamic Disk không được hỗ trợ. Việc import Windows yêu cầu phải có driver virtio trên host chuyển đổi.
Source: libguestfs — Hướng dẫn sử dụng virt-v2v · truy cập ngày 2026-10-19
VMware Tools
- Quá trình diễn ra
- virt-v2v sẽ thử gỡ bỏ VMware Tools.
- Lưu ý
- Tài liệu hướng dẫn lưu ý rằng việc gỡ bỏ không hoạt động ổn định trên Windows, nơi VMware Tools có thể phải được gỡ bỏ bằng phương pháp khác.
Source: libguestfs — Hướng dẫn sử dụng virt-v2v · truy cập ngày 2026-10-19
Loại guest OS
- Quá trình diễn ra
- VM sau khi import sẽ nhận loại guest OS mặc định.
- Lưu ý
- Trên 4.19, mặc định là CentOS 4.5 (32-bit) và phải thay đổi thủ công; phiên bản 4.22.1 có thể tự ánh xạ từ guest OS nguồn nếu tồn tại cấu hình mapping.
Source: Apache CloudStack — Import máy ảo VMware vào KVM · truy cập ngày 2026-10-19
Billing và khách hàng
- Quá trình diễn ra
- Các gói dịch vụ, giá cước và tài khoản khách hàng được thiết lập trong NexCMP, và mỗi máy được di chuyển sẽ được gán cho đúng khách hàng.
- Lưu ý
- Được thống nhất vào tuần 1 cho phiên bản CloudStack của bạn. Đây là công việc của NexCMP, không phải tính năng của CloudStack.
Kế hoạch chi tiết theo từng tuần
Kế hoạch điển hình, được điều chỉnh theo trường hợp của bạn. 30 ngày làm việc liên tục tương đương khoảng sáu tuần dương lịch.
Tuần 1 — Khảo sát và ra quyết định
Với quyền truy cập chỉ đọc vào vCenter, chúng tôi sẽ liệt kê mọi VM: guest OS, ổ đĩa, card mạng, VLAN, Snapshots, trạng thái nguồn và các mối phụ thuộc. Chúng tôi chọn phương án A hoặc B, xác định các đợt di chuyển và ghi chú các máy cần lưu ý đặc biệt, chẳng hạn như guest Windows, ổ đĩa dung lượng lớn và bất kỳ hệ thống nào dùng license cố định.
Tuần 2 — Dựng hệ thống đích
Zone CloudStack được kiểm tra hoặc khởi tạo: KVM host, storage, mạng khớp với hệ thống VMware. Chúng tôi cài đặt virt-v2v trên các KVM host (và nbdkit trên Ubuntu host), chuẩn bị driver virtio cho Windows, đồng thời mở các luồng mạng giữa conversion host với vCenter và ESXi. Nếu bạn bán máy ảo, NexCMP sẽ được cài đặt và kết nối với CloudStack ngay trong tuần này.
Tuần 3 — Pilot
Một vài máy không trọng yếu, đại diện cho từng loại guest của bạn, sẽ trải qua quy trình chuyển đổi thực tế. Chúng tôi kiểm tra khả năng khởi động, kết nối mạng và driver chuẩn xác, cấu hình loại guest OS, đồng thời đo lường thời gian offline của từng máy. Kết quả này sẽ định hình khung thời gian cho các đợt tiếp theo.
Tuần 4 và 5 — Các đợt chuyển đổi
Các máy được di chuyển theo nhóm vào các khung thời gian bạn đã đồng ý. Mỗi nhóm đều được kiểm tra kỹ trước khi bắt đầu nhóm tiếp theo, và các máy VMware gốc vẫn được tắt nguồn nhưng giữ nguyên để bạn có thể quay lại. Nếu bạn bán máy ảo, khách hàng, gói dịch vụ và giá cước sẽ được thiết lập song song trong NexCMP, và hệ thống billing sẽ chạy song song trước khi bạn chuyển đổi.
Tuần 6 — Cutover hoàn tất và bàn giao
Các máy cuối cùng được di chuyển, ngày tính billing được chuyển đổi nếu bạn bán máy ảo, và các cập nhật DNS được thực hiện. Chúng tôi lập tài liệu chi tiết quy trình đã triển khai, rà soát hardening và Backups, đồng thời luôn sẵn sàng hỗ trợ cho quá trình chuyển đổi cho đến khi kết thúc 30 ngày làm việc.
Chỉ là khung tham khảo. Kế hoạch thực tế sẽ được xác định từ tuần 1, và cam kết duy nhất về thời gian trong đề xuất là 30 ngày làm việc.
Rủi ro và cách chúng tôi giảm thiểu
Không có quá trình migration nào là không có rủi ro, và chúng tôi không cam kết zero downtime. Dưới đây là những sự cố có thể xảy ra và cách chúng tôi xử lý.
Downtime của từng máy
Máy Windows không thể chuyển đổi khi đang chạy, và máy Linux đang chạy chỉ được chuyển đổi ở trạng thái crash-consistent. CloudStack không nêu rõ quá trình chuyển đổi mất bao lâu. Chúng tôi đo lường việc này trong giai đoạn pilot, sau đó thống nhất khung thời gian dừng dịch vụ cho từng nhóm máy.
Quá trình chuyển đổi không thành công
CloudStack nêu rõ rằng tỷ lệ thành công không được đảm bảo tuyệt đối và phụ thuộc vào từng guest. Chúng tôi kiểm thử từng loại guest trong giai đoạn pilot trước bất kỳ đợt chuyển đổi nào, và máy gốc vẫn được giữ nguyên vẹn cho đến khi máy mới đã được kiểm tra xong.
Driver và VMware Tools
Máy Windows nhận driver virtio trong quá trình chuyển đổi, máy Linux cần hỗ trợ virtio từ trước, và VMware Tools có thể cần phải gỡ bỏ thủ công. Những điểm này đều được kiểm tra trên từng guest trong giai đoạn pilot.
Địa chỉ IP, địa chỉ MAC và DNS
Các guest giữ nguyên địa chỉ MAC và cấu hình mạng riêng của mình, vì vậy subnet đích khác biệt sẽ đòi hỏi thay đổi bên trong guest. Chúng tôi lập danh sách mọi địa chỉ trong tuần 1, hạ thấp DNS TTL trước thời điểm cutover và thông báo trước cho khách hàng của bạn.
License phần mềm trên guest
Windows và các phần mềm thương mại bên trong máy ảo có thể bị ràng buộc bản quyền với nền tảng cũ. Chúng tôi sẽ liệt kê chúng trong danh mục kiểm kê để bạn có thể xác nhận lại các điều khoản với từng nhà cung cấp trước khi di chuyển.
Quá trình chuyển đổi bị gián đoạn
CloudStack lưu ý rằng việc khởi động lại các management server trong quá trình di chuyển sẽ làm gián đoạn tiến trình và việc import phải thực hiện lại từ đầu. Chúng tôi lên lịch các đợt di chuyển tránh các kỳ bảo trì và tránh khởi động lại khi một đợt đang diễn ra.
Chuyển đổi billing và phương án rollback
Nếu bạn bán các máy ảo, ngày chuyển đổi billing sẽ được thống nhất cùng bạn và cả hai hệ thống sẽ chạy song song trước. Các máy VMware gốc vẫn được giữ lại cho đến khi bạn xác nhận việc di chuyển đã hoàn tất, đảm bảo mọi nhóm đều có phương án quay lại.
Phân chia công việc
Quyền truy cập vCenter ở chế độ read-only và danh sách các máy ảo bạn đánh giá là trọng yếu
- Chuyên gia thực hiện
- Kiểm kê toàn bộ VM và lập kế hoạch cho các đợt di chuyển
Quyền truy cập vào môi trường CloudStack và các host KVM, hoặc phần cứng để triển khai chúng
- Chuyên gia thực hiện
- Chuẩn bị zone, mạng và các host chuyển đổi
Các gói VDDK và virtio cần thiết theo phương án đã chọn, trong trường hợp nhà cung cấp yêu cầu bạn phải tự tải xuống
- Chuyên gia thực hiện
- Cài đặt và kiểm thử chúng trên các host chuyển đổi
Khung thời gian downtime đã thống nhất và thông báo gửi đến khách hàng của bạn
- Chuyên gia thực hiện
- Triển khai thử nghiệm và các đợt di chuyển, sau đó kiểm tra lại từng máy ảo
Quyết định về biểu giá của bạn, nếu bạn bán các máy ảo
- Chuyên gia thực hiện
- Thiết lập gói dịch vụ, khách hàng và billing trong NexCMP rồi vận hành giai đoạn chạy song song
Những gì bạn nhận được trong 30 ngày làm việc
Dịch vụ di chuyển là một phần của gói nâng cấp NexCMP Source: chi phí một lần $499 bao gồm toàn bộ mã nguồn (Rust server, portal và admin Vue, Go node agent, CLI, build scripts), quyền chỉnh sửa và build phiên bản riêng không giới hạn, 12 tháng nhận các bản phát hành mã nguồn mới, toàn bộ ứng dụng và 30 ngày làm việc liên tục cùng một kỹ sư chuyên gia.
Trong 30 ngày làm việc đó, chuyên gia sẽ hỗ trợ bạn di chuyển từ VMware sang Apache CloudStack mà không tính thêm phí. Ngoài ra hoặc thay vào đó, thời gian này cũng có thể dùng để di chuyển từ WHMCS hay hệ thống khác, hoặc để thiết lập toàn diện từ A đến Z và build các ứng dụng của bạn. Thời gian bắt đầu tính khi bạn bắt đầu làm việc cùng chuyên gia và được hiển thị trên trang license của bạn. Hỗ trợ di chuyển kéo dài trong suốt 30 ngày này.
NexCMP Free không bao gồm dịch vụ này. Gói Free được miễn phí một năm với đầy đủ các module và không có hỗ trợ kỹ thuật, chỉ sửa lỗi mã nguồn, và gia hạn ở mức $99 mỗi năm.
VMware sang CloudStack — các câu hỏi thường gặp
Chi phí là bao nhiêu?
Dịch vụ này có bao gồm trong NexCMP Free không?
Những phiên bản CloudStack và VMware nào được hỗ trợ?
Các máy ảo của tôi có bị downtime không?
Có phải mọi VM đều có thể chuyển đổi được không?
Tôi có phải giữ lại VMware sau đó không?
Tôi cần cung cấp những gì?
Nguồn tham khảo và ghi chú
Các thông tin kỹ thuật được dẫn từ tài liệu chính thức của Apache CloudStack và hướng dẫn virt-v2v. Tài liệu có thể thay đổi giữa các phiên bản, vì vậy vui lòng kiểm tra phiên bản bạn đang chạy. Tuyên bố về 4.19 trích từ tài liệu 4.19, bắt đầu trang VMware-to-KVM với cụm từ 'As of CS 4.19'. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor và Apache CloudStack là thương hiệu của các chủ sở hữu tương ứng. NexCMP độc lập và không liên kết hay được chứng thực bởi họ.
Rời VMware với kỹ sư đồng hành cùng bạn
Nâng cấp lên NexCMP Source với giá $499 và bắt đầu 30 ngày làm việc của bạn, hoặc liên hệ [email protected] trước để trao đổi về môi trường hiện tại.
Cập nhật lần cuối: