Why OpenHarmony don't have a traditional dedicated hypervisor or virtualisation framework API like Android, iOS & Windows etc.?
Let me show you why
OpenHarmony does not currently feature a dedicated hypervisor API in the traditional sense. However, it does support virtualization concepts and has been designed to enable resource sharing and isolation across different devices and applications. The architecture allows for a modular approach, which can facilitate the development of virtualized environments.
OpenHarmony currently lacks a dedicated hypervisor API for several reasons:
Target Use Cases: OpenHarmony is designed primarily for IoT and embedded devices, where the need for full virtualization is less critical compared to traditional computing environments. The platform uses Distributed Virtual Framework, where stationary as well as mobile devices will form a distributed virtual bus as communication channel. On top of this, the bus of the connected devices resources form a so called super device with an augmented resource pool. As a resort at App stack level by app developers, apps can make use of this resource pool through an API.
Resource Constraints: Many devices that OpenHarmony targets have limited hardware resources. Implementing a hypervisor could introduce overhead that isn't suitable for these low-resource environments.
Focus on Lightweight Architecture: OpenHarmony emphasizes a lightweight and efficient architecture to ensure smooth performance on various devices. A hypervisor might complicate this design.
Ecosystem Priorities: The focus has been on creating a unified experience across devices and fostering an ecosystem rather than developing complex virtualization features.
Development Stage: OpenHarmony is still evolving. Future versions may include more advanced features as the platform matures and as user needs become clearer.
Fuchsia, Google's open-source operating system, does not include a traditional hypervisor like those found in other operating systems (e.g., VMware or KVM). Instead, it uses a microkernel architecture called Zircon, which provides a minimal set of services and allows for a more modular design.
While Fuchsia doesn't have a dedicated hypervisor, it can support virtualization and can run applications in isolated environments, leveraging its architecture. This design allows for efficient resource management and enhances security, as applications can be run in separate user spaces.
OpenHarmony does have some support for virtualization concepts, primarily through its architecture that allows for resource management and isolation. While it doesn't feature a full-fledged hypervisor or dedicated virtualization API, it can facilitate certain virtualized environments, particularly in IoT contexts.
The focus is more on lightweight, efficient resource sharing among devices rather than traditional virtualization used in servers or desktops. This design aims to optimize performance on the constrained hardware typical of many IoT devices.
developers can utilize cloud implementation streams or other cloud-based services to run virtualized environments or manage virtual machines. Since OpenHarmony itself doesn't provide a dedicated hypervisor or robust virtualization capabilities, leveraging cloud infrastructure is a common approach for handling more complex virtualization needs.
This allows developers to take advantage of the cloud's scalability and resource management while maintaining the lightweight and efficient design that OpenHarmony targets for IoT devices.
OpenHarmony can run applications in isolated environments, similar to Fuchsia, but it does not support running multiple virtual machines in the traditional sense, as it lacks a dedicated hypervisor.
For more complex virtualization needs, such as running multiple VMs, developers typically need to rely on cloud solutions or external virtualization platforms. OpenHarmony is designed primarily for IoT and embedded systems, focusing on lightweight and efficient operation rather than full virtualization capabilities.
traditional VMs are not actually banned, they don't work in fact with this IoT distributed virtual OS-hardware architecture. Virtualisation with QEMU cutout use is possible alongside more appropriate cloud-phone solution with Virtual Machines inside for streaming with best performance as possible.