Đổi kernel không cần reboot: kmorph, multikernel và cuộc đua live update¶

Thay kernel Linux mà máy vẫn chạy, không mất dịch vụ, đang dần thành hiện thực. Năm 2025–2026 có hai hướng cùng dựa trên kexec. Hướng tuần tự (KHO/LUO) đã vào mainline nhờ Google và Amazon. Hướng song song (multikernel) còn nằm ngoài tree. Bài này đi từ một repo nhỏ là kmorph để nhìn ra bức tranh chung. Bài trình bày lần lượt: chi phí của reboot, nền tảng kexec và KHO, hai hướng LUO và multikernel, chi tiết kmorph, so sánh với các cách làm khác, các tranh luận trên LKML, và góc nhìn cho 5G RAN và hệ thống nhúng.

1. Chi phí của reboot kernel¶

Mỗi lần reboot là một lần mất dịch vụ: firmware POST, bootloader, kernel init, rồi toàn bộ user space khởi động lại từ đầu. Trên server, riêng phần firmware đã có thể mất vài phút.

Có hai nhóm người dùng bị ảnh hưởng nhiều nhất:

Cloud provider: mỗi bản vá bảo mật kernel trên host đồng nghĩa với việc phải migrate hoặc tạm dừng hàng chục VM của khách.
Telecom và embedded: một lần kernel panic → watchdog reboot → trạm mất sóng cho đến khi stack khởi động xong và đồng bộ lại.

Các công cụ hiện có chỉ giải quyết được một phần:

Livepatch (kpatch, kGraft): vá từng hàm khi kernel đang chạy. Livepatch phù hợp để sửa CVE, nhưng không nâng được version kernel và không đổi được cấu trúc dữ liệu.
kdump: khi panic thì kexec sang một capture kernel để lấy vmcore. Nó chỉ phục vụ debug, sau đó máy vẫn phải reboot.

Câu hỏi đặt ra: có thể thay cả kernel mà không đi qua firmware, không mất trạng thái, hoặc thậm chí không dừng máy hay không?

2. Nền tảng chung: kexec và KHO¶

Cả hai hướng trong bài đều xây trên kexec. Đây là cơ chế cho phép kernel đang chạy nạp một kernel khác vào RAM rồi nhảy thẳng vào đó, bỏ qua firmware và bootloader.

kexec có từ lâu và được dùng theo hai kiểu:

kexec reboot: khởi động lại nhanh. Bỏ được thời gian firmware, nhưng kernel mới vẫn bắt đầu từ con số 0, mọi trạng thái cũ đều mất.
kdump: một capture kernel được nạp sẵn vào vùng crashkernel=. Khi panic, kernel chính nhảy vào đó để ghi lại bộ nhớ.

Mảnh còn thiếu là cách để kernel cũ trao lại thứ gì đó cho kernel mới. Kexec HandOver (KHO) của Mike Rapoport lấp chỗ trống này và đã được merge vào Linux 6.16. Kernel cũ đánh dấu các trang nhớ cần giữ và mô tả chúng bằng một Flattened Device Tree. Kernel mới đọc device tree này khi boot và không ghi đè lên các trang đó.

KHO chỉ là cơ chế giữ bộ nhớ, chưa phải một giải pháp hoàn chỉnh. Hai hướng dưới đây dùng nó theo hai cách rất khác nhau.

3. Hướng 1 – Live update tuần tự (LUO)¶

Ý tưởng: vẫn kexec từ kernel cũ sang kernel mới như bình thường, nhưng giữ lại những tài nguyên được chọn (bộ nhớ, file descriptor, và về sau là cả device) để workload tiếp tục ngay khi kernel mới lên. Máy vẫn có một khoảng dừng ngắn, nhưng không mất trạng thái.

Live Update Orchestrator (LUO) của Pasha Tatashin (Google) là lớp điều phối nằm trên KHO. LUO đã được merge vào Linux 6.19, và Google đã dùng nó trong production để cập nhật kernel trên host chạy VM (chưa kiểm chứng). Cơ chế chính (tài liệu kernel):

Một daemon trong user space mở /dev/liveupdate và tạo các session có tên.
Daemon đưa vào session những file descriptor cần giữ, ví dụ bộ nhớ memfd/shmem chứa RAM của VM.
Ngay trước kexec, LUO ghi metadata qua KHO. Sau khi kernel mới boot, daemon lấy lại các file descriptor đó và khởi động tiếp workload.

Các bước tiếp theo trong năm 2026, tính đến thời điểm viết vẫn đang review:

VFIO-PCI: giữ device file qua live update. Bản v5 (7/2026) đã thử nghiệm device tiếp tục DMA trong lúc kexec.
IOMMU/iommufd: giữ bảng dịch địa chỉ và domain của IOMMU (v3, 6/2026).
Caretaker cho VM: RFC (4/2026) đề xuất một chương trình bare-metal tối giản giữ vCPU tiếp tục chạy trong lúc host kernel kexec. Chương trình này không có kernel đứng sau và không gọi syscall nào.

Điểm mạnh của hướng này là nằm sẵn trong mainline và có Google, Amazon, NVIDIA cùng đóng góp (chưa kiểm chứng). Điểm yếu là máy vẫn có một khoảng "đóng băng", và nó không giúp gì khi kernel panic: khi đó không còn ai để chuẩn bị handover.

4. Hướng 2 – Multikernel song song¶

Ý tưởng: không tắt kernel cũ rồi mới bật kernel mới. Thay vào đó, cho nhiều kernel chạy cùng lúc trên một máy. Mỗi kernel sở hữu riêng một phần CPU, RAM và PCI device, chạy native, không có hypervisor.

Người khởi xướng là Cong Wang, maintainer subsystem traffic control từ 2017, trước đây làm ở ByteDance, Twitter và Red Hat (chưa kiểm chứng). Cong Wang lập công ty Multikernel Technologies. Các mốc chính:

Thời gian	Mốc
25/8/2026	Phát hành công khai đầu tiên: mklinux v7.0-mk2 (fork Linux 7.0, x86-64)
10/2025	RFC v2 (16 patch): chuyển sang `kexec_file_load()`, dùng KHO để truyền device tree, thêm messaging qua ngắt liên CPU (inter-processor interrupt, IPI)
9/2025	RFC v1 (7 patch) gửi lên LKML

Cơ chế của mklinux:

Một host kernel nắm pool CPU, RAM và PCI device, rồi chia pool thành các instance.
Instance được khai báo bằng device tree ghi vào /sys/fs/multikernel/. Device tree overlay chuyển tài nguyên giữa pool và instance đang chạy mà không cần reboot.
Kernel con được boot vào instance bằng kexec_file_load() ở chế độ multikernel. Các kernel giao tiếp với nhau qua IPI và vsock.
So với VM: không có VM exit, không có bảng trang hai tầng, không có device model. So với container: các instance không dùng chung kernel, nên lock, panic hay exploit trong một kernel không lan sang kernel khác.

Quanh fork kernel này, org multikernel có thêm kerf (quản lý nhiều kernel instance trên một host), daxfs (filesystem cho bộ nhớ chia sẻ giữa các kernel và CXL), và kmorph. Công ty cũng bán sẵn sản phẩm thương mại dựa trên nền này, gồm sandbox cho AI agent và LiveUpdate.

Về upstream, chưa có dấu hiệu multikernel sẽ sớm vào mainline. Phần 7 nói rõ hơn về các phản biện.

Khác biệt cốt lõi: LUO chỉ có một kernel tại mỗi thời điểm, còn multikernel luôn có một kernel thứ hai đang chạy sẵn để nhận máy.

5. kmorph và cơ chế tiếp quản kernel¶

kmorph đem multikernel vào đúng bài toán của bài này. Một kernel dự phòng (successor) được boot sẵn bên cạnh kernel đang chạy máy (predecessor), rồi tiếp quản toàn bộ CPU, RAM và device của predecessor.

5.1 Tổng quan¶

kmorph (Apache-2.0) tiếp quản theo hai kiểu:

Khi crash: predecessor panic hoặc treo, successor nhận ra sự im lặng và chạy tiếp máy. README ước tính khoảng 1 giây từ lúc phát hiện đến khi successor chạy.
Khi được yêu cầu: kmorph upgrade trao máy cho successor chạy kernel mới, tức nâng cấp kernel không reboot.

Sau khi tiếp quản, successor trở thành kernel chính và có thể arm successor của riêng nó. Nhờ vậy máy có thể đi qua nhiều thế hệ kernel: generation-1, generation-2, v.v.

Dự án thay đổi nhanh: 78 commit từ 12/2025 đến 10/11/2026. Riêng trong khoảng 3–5/11/2026, dự án đã thêm kmorph upgrade, tiếp quản IOMMU, hỗ trợ arm64 và standby services. Các bài giới thiệu viết trước thời điểm đó chưa đề cập các tính năng này.

5.2 Kiến trúc¶

kmorph gồm hai chương trình dùng chung file /etc/kmorph/kmorph.conf:

kmorph chạy trên predecessor, với các lệnh image, arm, disarm, status, watch, upgrade.
kmorphd chạy trong initramfs của successor, theo dõi predecessor và thực hiện takeover. Nó được build static với musl.

kmorph không chứa phần kernel nào. Nó chỉ điều phối các interface của kernel multikernel: /sys/fs/multikernel cho pool và instance, kexec_file_load() và reboot() để nạp, boot, dừng và fence, cùng vsock cho heartbeat và các request.

Lệnh kmorph arm thực hiện ba thao tác với kernel:

Create: ghi một overlay để tạo instance với CPU, RAM và device của successor. Overlay kèm theo một host tree mô tả toàn bộ máy: CPU (lấy từ ACPI MADT hoặc device tree), bản đồ RAM (từ /proc/iomem) và danh sách PCI (từ sysfs).
Load: kexec_file_load() ở chế độ multikernel nạp kernel và initramfs. Config và thông tin mạng được ghép vào initramfs ngay trong bộ nhớ.
Exec: lệnh reboot() multikernel boot successor trên các core được chia cho nó.

Khi image đã build sẵn, cả lệnh arm mất khoảng một giây. Mọi thứ successor cần để tiếp quản đều được chốt từ trước khi nó boot. Chỉ thông tin mạng được cập nhật liên tục sau đó.

5.3 Phát hiện predecessor ngừng hoạt động¶

Cơ chế phát hiện dựa vào hành vi mặc định của vsock. kmorphd gọi connect() qua vsock tới predecessor (CID 0), vào một port không ai listen. Kernel còn sống sẽ tự trả về RST mà không cần user space tham gia, và successor nhận được ECONNRESET.

Chỉ có im lặng mới được coi là bằng chứng: một probe chưa được trả lời khi đến lượt probe kế tiếp. Mặc định là probe mỗi 100 ms, và cần 5 lần im lặng liên tiếp, tức khoảng 0,5 giây. Nhờ vậy một predecessor chạy chậm sẽ không bị nhầm là đã chết.

Trạng thái của kmorphd đi theo chuỗi ARMED → SUSPECT → FENCING → FENCED → TAKEN_OVER. Nếu fence thất bại, kmorphd rẽ sang FENCE_FAILED và thử lại. Mỗi lần chuyển trạng thái đều được ghi vào kernel log và /run/kmorph/state.

5.4 Trình tự takeover¶

Detect: 5 probe liên tiếp không được trả lời. Với upgrade, request handover thay cho sự im lặng.
Fence: dừng mọi CPU không thuộc về successor (x86 dùng non-maskable interrupt (NMI) và INIT, arm64 dùng stop IPI và Power State Coordination Interface (PSCI)) và xác nhận từng CPU. Không có fence nửa vời: còn một CPU có thể đang chạy kernel cũ thì takeover không đi tiếp.
Device: mỗi PCI function được adopt trong một transaction riêng và đặt trên một root bus riêng (truy cập config space qua Enhanced Configuration Access Mechanism (ECAM)). Device được reset bằng Function Level Reset (FLR) hoặc chu kỳ power state. Nếu không reset được thì tắt Bus Master Enable, để DMA còn sót lại dừng trước khi RAM được nhận về.
IOMMU: khi mọi function đã yên, successor chuyển từng IOMMU unit sang bảng trang của chính nó.
Mạng: khôi phục tên, MAC, địa chỉ và route cho các NIC vừa adopt. Thông tin này đã được kmorph watch gửi sang từ trước qua rtnetlink. MAC không đổi nên không cần gửi gratuitous ARP.
CPU và RAM: đánh thức các CPU đã fence và hot-add RAM theo granule (4 MB trên x86), hoặc theo memory block 128 MB nếu kernel không hỗ trợ granule.
Dump (tùy chọn): ghi bộ nhớ của predecessor thành vmcore theo định dạng kdump (đọc được bằng crash và makedumpfile) trước khi thu hồi. File đích có thể là một FIFO để stream qua mạng.
Console: mở chương trình login trên cổng serial.

Thứ tự này có chủ đích: dừng CPU trước, dừng DMA sau, và chỉ nhận RAM khi không còn ai có thể ghi vào vùng nhớ đó.

Fence là bước quyết định: nếu còn một CPU chưa dừng, takeover không đi tiếp, nên không bao giờ có hai kernel cùng ghi vào một vùng nhớ.

5.5 User space sau takeover¶

Cần lưu ý: kmorph giữ máy, không giữ tiến trình. Sau takeover, initramfs của successor mount root disk và chạy init của hệ thống. Network, mount và các service được dựng lại như một lần boot, chỉ khác là kernel đã chạy sẵn. Nó bỏ qua được firmware và kernel init, nhưng vẫn mất thời gian khởi động user space.

Để rút ngắn khoảng này, kmorph có standby services. Các systemd unit được liệt kê trong standby sẽ chạy sẵn trong successor ngay từ lúc arm, từ một root filesystem dạng Enhanced Read-Only File System (EROFS) được build từ chính file của host. Khi takeover xong, kmorph-switch dùng pivot_root để chuyển sang root disk thật, và các standby service tiếp tục chạy mà không bị dừng. Điều kiện là service phải khởi động được khi chưa có disk và NIC, và không ghi trạng thái cần lưu lâu dài trước takeover.

Sau đó kmorph.service arm successor cho thế hệ tiếp theo. kmorphd đã chủ động chừa lại một vùng RAM không adopt, để thế hệ sau có đủ bộ nhớ cho pool của nó.

5.6 Nâng cấp kernel bằng `kmorph upgrade`¶

Toàn bộ quy trình chỉ có ba lệnh:

dnf upgrade kernel          # hoặc apt; kernel hook build lại image successor
systemctl restart kmorph    # arm successor chạy kernel mới
kmorph upgrade              # trao máy cho successor

Trước khi trao, kmorph upgrade sync và freeze mọi filesystem ghi được, để successor mount lại mà không có I/O dở dang và không phải replay journal. kmorphd chỉ nhận handover khi probe gần nhất thấy predecessor còn sống, nên handover không thể tranh chấp với một takeover do crash. Nếu sau 10 giây vẫn chưa fence được, lệnh sẽ thaw filesystem và báo lỗi, predecessor tiếp tục chạy máy.

5.7 So với kdump¶

	kdump	kmorph khi crash	kmorph upgrade
Kernel dự phòng	Nạp sẵn nhưng chưa chạy	Đã boot, chạy trên core riêng	Đã boot, chạy kernel mới
Phát hiện	Panic handler gọi kexec	Successor thấy im lặng (~0,5 s)	Request handover
Lấy vmcore	Có	Tùy chọn	Không
Sau đó	Reboot toàn bộ máy	Successor chạy tiếp máy	Successor chạy tiếp máy
Treo cứng (không panic)	Phụ thuộc NMI watchdog	Phát hiện được nếu kernel ngừng trả RST	Không áp dụng

Ý chính: kmorph biến "kernel dự phòng để debug" thành "kernel dự phòng để phục vụ". Successor không cần panic handler của predecessor còn chạy được, vì nó quan sát predecessor từ bên ngoài.

5.8 Giới hạn¶

Phụ thuộc kernel ngoài mainline: kmorph chỉ chạy trên fork multikernel, nên mọi rủi ro của fork đó cũng là rủi ro của kmorph.
User space vẫn khởi động lại, trừ các standby service. Đây không phải zero-downtime cho ứng dụng.
Device được adopt bị hạn chế: mỗi device nằm trên một root bus riêng, không có secondary bus reset, hotplug hay Advanced Error Reporting (AER). Function không hỗ trợ FLR chỉ được làm yên. Device thêm vào sau lần arm sẽ bị bỏ lại nguyên trạng như lúc crash.
NIC phải negotiate lại link sau khi reset, có thể mất từ một giây trở lên.
RAM bị hao hụt ở rìa: một ít bộ nhớ quanh các vùng control và vùng của successor không được nhận về (vài MB với granule 4 MB, khoảng 500 MB trên máy 2 GB nếu dùng block 128 MB).
Không tự re-arm nếu không dùng kmorph.service. Giữa lúc takeover và lúc arm thế hệ mới, máy không có bảo vệ.
Còn rất mới: phần lớn tính năng quan trọng vừa được thêm trong tháng 11/2026 và chưa có release chính thức.

5.9 Câu hỏi mở¶

Treo một phần: heartbeat chỉ kiểm tra được việc kernel còn trả RST. Nếu một CPU bị kẹt lock hoặc user space đứng im, mà đường vsock vẫn sống, thì kmorph sẽ không tiếp quản. Vậy vẫn cần watchdog ở tầng trên, và cần cách để watchdog đó kích hoạt takeover thay vì reboot.
Ranh giới tin cậy: successor đọc toàn bộ RAM của predecessor qua /dev/mem và có quyền fence mọi CPU. Successor cũng là một điểm tấn công có đặc quyền cao nhất trên máy.
Device đang chạy thời gian thực: kmorph reset device để an toàn. Với NIC fronthaul hay card tăng tốc mã sửa lỗi (Forward Error Correction, FEC), reset đồng nghĩa với mất trạng thái, và đây chính là bài toán LUO đang cố giải cho VFIO.
Hội tụ với LUO: nếu multikernel vào mainline, liệu kmorph upgrade có thể dùng LUO session để giữ file descriptor và device qua handover, thay vì khởi động lại user space?

6. So sánh với các cách làm khác¶

Multikernel nằm giữa VM và container: cô lập ở mức kernel như VM, nhưng không có hypervisor như container.

Cách làm	Cơ chế	Cô lập	Đổi kernel	Chuyển giao device	Độ chín
LUO + KHO	kexec tuần tự, giữ FD và bộ nhớ	Một kernel	Có khoảng đóng băng ngắn	VFIO/IOMMU đang review	Mainline 6.19, Google dùng production (chưa kiểm chứng)
Multikernel + kmorph	Nhiều kernel song song, successor tiếp quản	Kernel riêng, không hypervisor	Takeover ~1 s, user space khởi động lại	Reset rồi adopt	Fork ngoài tree, rất mới
Jailhouse, Bao	Phân vùng tĩnh bằng ảo hóa phần cứng	Cell/VM riêng, hypervisor mỏng	Không nhắm tới	Gán cố định	Trưởng thành, dùng nhiều trong embedded
KVM VM	Hypervisor đầy đủ	Mạnh nhất (VM + IOMMU)	Live migration sang host khác	Passthrough hoặc ảo hóa	Rất trưởng thành
Container	Namespace và cgroup	Chung một kernel	Phải reboot host	Không áp dụng	Rất trưởng thành

Ý tưởng multikernel không mới. Barrelfish (ETH Zürich và Microsoft Research, 2009) coi máy là một mạng các core giao tiếp bằng message. Popcorn Linux (Virginia Tech) chạy nhiều instance Linux và cũng dùng kexec để khởi động chúng (chưa kiểm chứng). Trong HPC, IHK/McKernel của RIKEN (dùng trên siêu máy tính Fugaku) chạy một kernel nhẹ cạnh Linux và đẩy các syscall chậm về Linux. Intel mOS và Pisces/Kitten cũng theo hướng tương tự (chưa kiểm chứng).

Cái mới của mklinux là làm việc này ngay trên Linux, với các kernel đều là Linux đầy đủ, và cho phép chuyển tài nguyên giữa chúng lúc đang chạy.

7. Tranh luận và điểm nghẽn¶

RFC multikernel trên LKML nhận nhiều phản biện. Có ba luồng phản biện chính:

Bảo mật: Jarkko Sakkinen cho rằng về mặt bảo mật, multikernel khó thắng được VM kết hợp IOMMU, và yêu cầu có số liệu để chứng minh các tuyên bố. Theo đánh giá của tác giả: khi không có bảng trang tầng hai, một kernel bị chiếm quyền về lý thuyết vẫn có thể map RAM vật lý của kernel khác. Cô lập ở đây chủ yếu chống lỗi, chưa chống được kẻ tấn công.
Trùng với cái đã có: Stefan Hajnoczi (Red Hat) hỏi multikernel khác gì Jailhouse. Cong Wang trả lời rằng Jailhouse vẫn dựa vào ảo hóa phần cứng (VMX, IOMMU), còn multikernel muốn bỏ hẳn hypervisor. Cong Wang cũng lập luận rằng phân vùng tĩnh đi ngược tính co giãn, vốn là lý do container phổ biến hơn VM.
Hướng khác đáng tin hơn: Pasha Tatashin, tác giả LUO, cho biết đã thử cách tiếp cận tương tự khoảng năm năm trước. Theo Pasha Tatashin, giữ VM tiếp tục chạy qua live update mới là con đường đáng tin hơn cho nâng cấp kernel không downtime.

Dù đi hướng nào, điểm nghẽn chung vẫn là device state. CPU và RAM tương đối dễ chuyển giao. Một NIC đang DMA, một IOMMU đang dịch địa chỉ hay một PCI bridge đã được cấu hình thì khó hơn nhiều. kmorph chọn cách an toàn là reset rồi adopt. LUO đang đi con đường khó hơn là giữ nguyên trạng thái. Ở bản patch VFIO đầu năm 2026, device vẫn bị reset về idle khi kexec. Đến bản v5 (7/2026), loạt patch này mới thử nghiệm được DMA liên tục qua live update.

8. Góc nhìn cho 5G RAN và hệ thống nhúng¶

Phần này là đánh giá của tác giả, không phải thông tin từ các dự án.

Tiềm năng. Trên khối xử lý băng gốc (Baseband Unit, BBU) x86, kmorph có thể thay watchdog reboot khi kernel panic. Máy bỏ qua được BIOS POST và kernel init, vốn là phần tốn thời gian lớn trên server. Về lâu dài, multikernel còn gợi ý một kiến trúc mới: kernel riêng cho L1/DPDK, kernel riêng cho vận hành và bảo trì (Operations and Maintenance, O&M) và M-Plane. Khi đó lỗi ở kernel O&M không kéo L1 sập theo.

Vì sao chưa dùng được:

Cell vẫn mất sóng. Sau takeover, NIC fronthaul và card tăng tốc FEC bị reset, ứng dụng L1 phải khởi động lại, và PTP/SyncE phải lock lại. Thời gian mất sóng ngắn hơn reboot, nhưng không phải bằng 0.
Cấu hình RT không tự đi theo. kmorph cố ý bỏ isolcpus, nohz_full và hugepage khỏi command line khi copy sang successor. Sau takeover, kernel mới chưa có cấu hình core cách ly mà L1 cần.
Rủi ro fork kernel. Sản phẩm carrier-grade khó chấp nhận một kernel ngoài mainline, còn chưa có release ổn định.

Nên theo dõi gì:

LUO + VFIO: ứng dụng DPDK dùng vfio-pci chính là đối tượng hưởng lợi khi các patch giữ device với DMA liên tục vào mainline. Đây là con đường thực tế nhất để nâng cấp kernel mà không mất fronthaul.
Ý tưởng Caretaker: một vòng lặp tối giản giữ workload chạy trong lúc kernel đổi. Nó đáng để suy nghĩ cho các vòng xử lý L1 chạy trên core cách ly.
Trên SoC ARM như Zynq UltraScale+ hay LX2160A, OpenAMP/remoteproc và các partitioning hypervisor (Jailhouse, Bao) vẫn là lựa chọn trưởng thành. kmorph đã có code cho arm64, nhưng bản mklinux công khai đầu tiên chỉ hỗ trợ x86-64.

Bước hợp lý là thử kmorph trên một máy x86 trong lab, với workload không phải RT, để đo thời gian takeover và thời gian user space quay lại trên phần cứng thật.

9. Kết luận¶

Theo đánh giá của tác giả, hướng tuần tự (KHO/LUO) đang dẫn trước về mặt upstream: đã nằm trong mainline từ 6.16 và 6.19, có các cloud lớn đứng sau, và đang tiến dần tới việc giữ cả device. Hướng song song (multikernel) đi nhanh hơn về tính năng. kmorph đã làm được failover khi panic và nâng cấp kernel không reboot, nhưng vẫn nằm trên một fork chưa chắc vào được mainline.

Hai hướng không hẳn loại trừ nhau. LUO giải bài toán giữ trạng thái, còn multikernel giải bài toán có sẵn một kernel đang chạy khi kernel kia chết, điều LUO không làm được khi panic. Bên nào giải được bài toán chuyển giao device state trước nhiều khả năng sẽ định hình hướng phát triển chung. Với hệ thống nhúng và telecom, lúc này nên theo dõi và thử nghiệm trong lab, chưa nên đưa vào sản phẩm.

Liên quan¶

Kernel crash dump (kdump): kexec, vùng crashkernel=, capture kernel và phân tích vmcore.
Partitioning Hypervisor: Jailhouse, Xen và cách phân vùng tĩnh trên hệ nhúng.
vRAN trên VM: chạy O-DU trên nền ảo hóa.