abstract cloud-hypervisor module

.cargo/config.toml

@@ -2,4 +2,12 @@
 # but this only works on the target machine, so we have it commented out at the moment.
 # You can also set the target-cpu to do cross compilation if you know the exact micro architecture of the target machine.
 [build]
-#rustflags = ["-C", "target-cpu=native"]
+#rustflags = ["-C", "target-cpu=native"]
+
+# Cross-build aliases. These select compilation targets without changing the
+# host toolchain used to run Cargo on the development machine.
+[alias]
+build-linux-x86_64 = "build --target x86_64-unknown-linux-gnu"
+build-linux-x86_64-release = "build --release --target x86_64-unknown-linux-gnu"
+build-linux-rva23 = "build --target riscv64a23-unknown-linux-gnu"
+build-linux-rva23-release = "build --release --target riscv64a23-unknown-linux-gnu"

docs/fixtures/manifest/storage-backed.json

@@ -5,7 +5,7 @@
     "metadata": { "name": "storage-backed", "labels": {}, "annotations": {} },
     "compute": { "vcpus": 2, "max_vcpus": 4, "memory_bytes": 4294967296 },
     "storage": [
-      { "id": "root", "uri": "rbd://vms/root", "boot": true },
+      { "id": "root", "uri": "rbd://vms/root" },
       { "id": "data", "volume_id": "01J00000000000000000000002" }
     ],
     "networks": [],

docs/manifest.md

@@ -28,9 +28,11 @@ Odorobo should provision. It contains:
 - `metadata`: stable name, labels, and annotations.
 - `compute`: boot vCPUs, optional scaling ceiling, and memory in bytes.
 - `storage`: ordered storage attachments. An attachment references either a storage URI or a
-  provisioned volume ID; `boot` identifies the boot attachment. The control plane owns
-  attachment identity and ordering; the provider driver/storage transform resolves the
-  URI or volume ID to a node-local device path.
+  provisioned volume ID. The array order is the attachment order and preferred disk boot
+  order: the first attachment is the preferred boot disk, followed by later attachments.
+  Cloud Hypervisor has no per-disk boot index, so providers must preserve this order when
+  translating the manifest. The control plane owns attachment identity and ordering; the
+  provider driver/storage transform resolves the URI or volume ID to a node-local device path.
 - `networks`: stable network IDs and optional guest MAC addresses. The control plane owns
   the attachment identity and requested MAC; the provider networking transform resolves
   the network to a host interface or tap device.
@@ -58,8 +60,8 @@ A manifest must use a supported `api_version`, have a non-empty metadata name,
 non-zero vCPUs and memory, and satisfy these relationships:
 
 - `max_vcpus` must be at least `vcpus`.
-- Every storage attachment must have a non-empty ID and exactly one usable source (URI or volume reference), and
-  a boot storage attachment cannot be read-only. At most one storage attachment may be marked as boot.
+- Every storage attachment must have a non-empty ID and exactly one usable source (URI or volume reference).
+  Storage order must be preserved when attachments are translated to the provider.
 - Affinity requirements within a rule are OR-ed; rules are combined according to
   their strictness, and `inverse` negates a rule's result. `lt` and `gt` comparisons require exactly one
   finite numeric value.
@@ -86,6 +88,16 @@ Representative JSON fixtures are in [`fixtures/manifest`](fixtures/manifest):
 - [`cloud-init.json`](fixtures/manifest/cloud-init.json)
 - [`vsock.json`](fixtures/manifest/vsock.json)
 
+For example, storage attachments are listed in preferred disk boot order. Here `root` is
+presented before `data`:
+
+```json
+"storage": [
+  { "id": "root", "uri": "rbd://vms/root" },
+  { "id": "data", "volume_id": "01J00000000000000000000002" }
+]
+```
+
 For example:
 
 ```json

odorobo/src/actors/agent_actor.rs

@@ -1,6 +1,7 @@
 use crate::{
     ch_driver::actor::VMActor,
     config::Config,
+    manifest::VmManifest,
     messages::{
         Ping, Pong,
         agent::{AgentStatus, GetAgentStatus},
@@ -12,7 +13,7 @@ use crate::{
         },
     },
     networking::actor::NetworkAgentActor,
-    types::{ObjectMetadata, VirtualMachine},
+    types::ObjectMetadata,
     utils::actor_names::{NETWORK, VM, vm_actor_id},
 };
 use ahash::AHashMap;
@@ -28,7 +29,7 @@ use kameo::error::PanicError;
 
 pub struct VMCacheData {
     actor_ref: ActorRef<VMActor>,
-    config: VirtualMachine,
+    config: VmManifest,
 }
 
 #[derive(RemoteActor)]
@@ -152,7 +153,7 @@ impl Message<MigrateVMReceive> for AgentActor {
             vmid,
             VMCacheData {
                 actor_ref: actor_ref.clone(),
-                config: VirtualMachine::default(),
+                config: msg.config.clone(),
             },
         );
 
@@ -304,14 +305,14 @@ impl Message<GetAgentStatus> for AgentActor {
         let vcpus_used_by_vms = self
             .vms
             .values()
-            .map(|vm| vm.config.data.vcpus)
+            .map(|vm| vm.config.desired.compute.vcpus)
             .reduce(u32::saturating_add)
             .unwrap_or(0);
 
         let ram_used_by_vms = self
             .vms
             .values()
-            .map(|vm| vm.config.data.memory.as_u64())
+            .map(|vm| vm.config.desired.compute.memory_bytes)
             .reduce(u64::saturating_add)
             .unwrap_or(0);