Năm công cụ chuyển VM từ VMware sang OpenStack

Sau khi Broadcom mua lại VMware, nhiều đội hạ tầng bắt đầu tính đường sang OpenStack. Phần khó không phải dựng cụm OpenStack, mà là đưa hàng trăm VM đang chạy sang đó với thời gian dừng chấp nhận được và không mất dữ liệu. Bài này so năm công cụ chuyển đổi, hai mã nguồn mở và ba thương mại, trên bốn tiêu chí: thời gian dừng VM, chi phí, mức tự động hóa và nhóm VM phù hợp.

Chuyển nguội hay chuyển ấm

Hai cách chuyển quyết định thời gian dừng của VM:

• Chuyển nguội (cold): tắt VM trên VMware, sao chép toàn bộ đĩa, bật VM ở OpenStack. VM dừng trong suốt thời gian sao chép. Đĩa càng lớn, dừng càng lâu.
• Chuyển ấm (warm): sao chép đĩa khi VM vẫn chạy, lặp lại để đồng bộ phần thay đổi. Đến lúc cutover mới tắt VM, đồng bộ lần cuối và bật ở OpenStack. VM chỉ dừng trong bước cuối.

Ở lớp dưới, mọi công cụ đều đọc đĩa VMDK, đổi driver trong guest sang virtio để chạy trên KVM, rồi tạo volume và VM trên OpenStack. Khác biệt là có sao chép khi VM đang chạy hay không, tự động hóa đến đâu, và tính tiền thế nào.

virt-v2v: chuyển nguội, không mất phí

virt-v2v thuộc dự án libguestfs, do Red Hat duy trì, có sẵn trong Red Hat Enterprise Linux và Debian/Ubuntu. Nó chuyển VM từ VMware ESXi, Xen và một số hypervisor khác sang KVM, hỗ trợ guest Linux lẫn Windows, và là nền của nhiều công cụ khác trong bài.

Với đích là OpenStack, theo tài liệu libguestfs, virt-v2v phải chạy bên trong một VM trên chính cụm đích, gọi là conversion appliance. Kết quả là các Cinder volume, mỗi đĩa của VM gốc thành một volume. Việc tạo VM từ volume là bước bạn làm sau đó bằng openstack server create --volume.

Giới hạn cần biết:

• VM nguồn phải tắt sạch trước khi chuyển. Guest đang chạy hoặc khởi động lại trong lúc chuyển có thể làm hỏng filesystem. Với đĩa lớn, thời gian dừng tính bằng giờ.
• Chỉ hỗ trợ x86_64, không hỗ trợ IBM Z, POWER hay ARM.
• Thao tác thủ công. Mỗi VM là một lệnh với nhiều tham số về nguồn, đích và volume type. Hợp với người đã quen Linux.

virt-v2v hợp với VM nhỏ, VM không quan trọng, hoặc hệ thống có cửa sổ bảo trì vài giờ. Không mất phí nên nó thường được chọn cho đợt pilot đầu tiên.

MigrateKit: chuyển ấm bằng mã nguồn mở

MigrateKit là công cụ dòng lệnh do VEXXHOST, một nhà vận hành OpenStack, mở mã nguồn theo giấy phép Apache-2.0. Nó giải quyết đúng điểm yếu của virt-v2v: thời gian dừng. Quá trình chia làm hai pha:

1. Pha sao chép (migrate): chạy khi VM vẫn hoạt động trên VMware. Lần đầu sao chép toàn bộ đĩa; các lần sau chỉ sao chép phần thay đổi nhờ change tracking trên đĩa VM. Lặp lại được bao nhiêu lần tùy ý.
2. Pha cutover (cutover): kiểm tra tài nguyên đích đã có (flavor, Neutron port, network mapping), đồng bộ lần cuối, tắt VM trên VMware, rồi tạo VM trên OpenStack. Bên trong, MigrateKit chạy virt-v2v ở chế độ in-place lên đĩa đích để đổi driver.

Điều kiện triển khai, theo README của dự án: nguồn phải là VMware có API endpoint (vCenter hoặc ESXi), không phải file VMDK rời; phải tự tải VMware Virtual Disk Development Kit (VDDK) từ trang VMware, cần tài khoản developer và chấp nhận EULA; tài khoản vCenter cần đủ quyền, trong đó có quyền tắt VM.

Giới hạn MigrateKit chỉ có CLI, không có giao diện đồ họa. Chuyển hàng loạt phải tự dựng bằng script bao ngoài. Đổi lại, cách chạy minh bạch: mỗi VM là hai lệnh, dễ kiểm tra và dễ đưa vào runbook.

MigrateKit hợp với đội có kỹ sư Linux, muốn chuyển ấm mà không trả phí license, và chấp nhận tự lo phần điều phối.

Coriolis: quy mô lớn, có rollback

Coriolis của Cloudbase Solutions là công cụ thương mại cho chuyển đổi quy mô lớn, hỗ trợ nhiều chiều giữa VMware, Hyper-V, OpenStack, AWS, Azure và các nền tảng khác. Nó không cần cài agent hay đăng nhập vào guest.

Điểm mạnh so với hai công cụ mã nguồn mở:

• Replica chạy nền: VM nguồn được sao chép khi vẫn chạy, đặt lịch tự động được. Theo Cloudbase, việc này không ảnh hưởng tới VM, với điều kiện hạ tầng nguồn hỗ trợ live snapshot.
• Tự động hóa cho hàng nghìn VM, chuyển theo lô.
• Rollback khi lần chuyển gặp sự cố.

Giới hạn: Coriolis chỉ mở mã nguồn một phần, phần còn lại cần license tính theo mỗi VM được chuyển, nên với số lượng VM lớn đây là khoản đáng kể. Nó cũng cần cấu hình tích hợp với cả nguồn và đích trước khi bắt đầu, không hợp với đợt thử nhanh.

Coriolis hợp với môi trường nhiều nền tảng, cần nhà cung cấp đứng sau và rollback có sẵn.

Hystax Acura và Trilio: hai lựa chọn thương mại khác

Hystax Acura tự động hóa toàn bộ quy trình: phát hiện VM, sao chép nền, rồi chuyển. Nó dùng đồng bộ gia tăng để VM chạy trong phần lớn quá trình, có rollback tích hợp, hỗ trợ nhiều hypervisor và cloud đích, trong đó có OpenStack. Giới hạn là chi phí license cao, nên thường chỉ hợp với số lượng VM hạn chế, và môi trường phức tạp có thể cần tùy chỉnh thêm.

Trilio tích hợp thẳng vào Horizon, dashboard của OpenStack. Người dùng lập migration plan và chọn một trong ba kiểu:

Kiểu chuyển	Cách làm	Dùng khi
Cold	Tắt VM, sao chép toàn bộ	VM không quan trọng, chấp nhận dừng lâu
Dry run	Sao chép dữ liệu, không động tới VM đang chạy	Kiểm thử kế hoạch trước khi chuyển thật
Warm	Sao chép gia tăng khi VM vẫn chạy, dừng ngắn lúc cutover	VM cần thời gian dừng ngắn

Trilio tự ánh xạ CPU, RAM và đĩa sang flavor OpenStack, và ánh xạ network cùng datastore của VMware sang bên tương đương, kể cả Ceph.

Lưu ý Theo tài liệu Trilio, hai giới hạn thường gặp: với VM Windows, các đĩa không phải đĩa hệ thống có thể ở trạng thái offline sau khi chuyển và phải vào guest bật lại thủ công; và kernel mặc định trong GRUB không được đổi, nên VM giữ nguyên kernel đang cấu hình dù đã cài kernel mới hơn. Giới hạn thứ hai thừa hưởng từ virt-v2v, nên cũng đúng với mọi công cụ dùng virt-v2v bên dưới.

Trilio hợp với đội đã dùng Trilio để backup OpenStack, hoặc muốn thao tác từ Horizon thay vì CLI.

Bảng so sánh

Công cụ	Thời gian dừng VM	Dung lượng phù hợp	Độ phức tạp vận hành	Mã nguồn mở	Chi phí
virt-v2v	Trung bình đến dài, VM tắt suốt lúc sao chép	Nhỏ đến trung bình	Cao, thao tác thủ công	Có	Không
MigrateKit	Gần như bằng không, chỉ dừng lúc cutover	Lớn	Thấp, nhưng chỉ có CLI	Có, Apache-2.0	Không
Coriolis	Tối thiểu, replica chạy nền	Lớn	Thấp đến trung bình, cần thiết lập trước	Một phần	License theo VM
Hystax Acura	Tối thiểu, đồng bộ gia tăng	Lớn	Thấp, tự động toàn bộ	Không	License, cao
Trilio	Tùy kiểu: cold, warm, dry run	Trung bình đến lớn	Trung bình	Không	License

Cột “độ phức tạp” nói về công sức vận hành công cụ, không phải độ khó của chính VM. Một VM Windows nhiều đĩa dữ liệu khó như nhau ở mọi công cụ.

Chọn công cụ theo nhóm VM

Một hệ thống vài trăm VM gần như luôn cần hơn một công cụ. Phân nhóm VM theo thời gian dừng cho phép và dung lượng đĩa, rồi gán công cụ cho từng nhóm:

• Không trạng thái hoặc có cửa sổ bảo trì dài (web tier, batch, môi trường test): virt-v2v. Không mất phí, hợp cho đợt pilot.
• Có trạng thái, đĩa lớn, dừng được vài phút (database, file server, ứng dụng nội bộ chạy 24/7): MigrateKit nếu đội quen CLI và muốn giữ chi phí bằng không; Trilio nếu muốn lập kế hoạch trên Horizon.
• Hàng trăm đến hàng nghìn VM, nhiều nền tảng nguồn, cần rollback có sẵn: Coriolis hoặc Hystax Acura. Tính license trên tổng số VM trước khi quyết định.
• Yêu cầu đặc biệt (kernel cũ, kiến trúc không phải x86_64): kiểm thử riêng trước, vì giới hạn của virt-v2v áp dụng cho hầu hết công cụ.

Giới hạn của bài Nhận xét về chi phí và độ phức tạp lấy từ tài liệu công khai của từng nhà cung cấp, không từ một đợt đo trên cùng một tập VM. Thời gian dừng thực tế phụ thuộc tốc độ đọc từ datastore VMware, băng thông sang OpenStack và tốc độ ghi của Ceph. Đo trên nhóm pilot trước khi cam kết cửa sổ bảo trì.

Việc cần làm trước khi chọn

Dù chọn công cụ nào, bốn việc sau cần xong trước:

1. Xuất danh sách VM từ vCenter (RVTools là đủ), kèm dung lượng đĩa, hệ điều hành và giờ cao điểm của từng VM.
2. Xác định thời gian dừng cho phép của từng nhóm VM, có xác nhận của bộ phận nghiệp vụ.
3. Chuẩn bị tài khoản vCenter với quyền tối thiểu cho công cụ; nếu dùng MigrateKit hoặc công cụ dựa trên VDDK, tải sẵn VDDK.
4. Chạy pilot trên vài VM của mỗi nhóm, đo thời gian sao chép và cutover thật, rồi mới chốt công cụ và lịch cho từng đợt.

Phần phân nhóm VM và lộ trình năm bước, với hai môi trường chạy song song đến khi host ESXi cuối cùng được chuyển, nằm ở trang giải pháp thoát VMware.