Hello, guys!
I can’t find any info about it outside of mentioning firefox@seoul package.
So the question is simple: I’d like to know what is it and how to use it? 
How does it compare to VBox? What use cases are more suitable for Seoul than for VBox?
And how does it work?
Maybe these are silly questions, but I struggle to find any practical information about it 
Please check out the README of the Seoul sources usable with the Genode framework. It should give you the base idea of Seoul/Vancouver VMM and contains a collection of resources, also how to build/use/develop/test it yourself.
In short and oversimplified: If you care about complexity of the code you have to entrust to serve your needs, then the Seoul VMM is of potential interest to you. If you don’t care, as most users tend to do, VBox will serve you well.
Some pro and cons from my point of view and my daily experience:
Seoul VMM is very light weight, it has less than 40k lines of code, no hard dependencies on external libraries. (well, the usb model requires the qemu-usb library). It is in that sense free-standing and is using the Genode interfaces directly. No libc, no pthreads, no stdcxx, no additional emulations, no global locks, no monitors, one handler thread per vCPU … The complexity is reduced to a minimum to run a VM efficiently.
VBox is a port to Genode, the VMM depends on million lines of code, virtualbox itself, libc, mesa lib and the other libraries I forgot. The amount of threads in the VMM is plenty - compare both VMMs with top-view to get an idea. The complexity is amazing overwhelming. Porting, developing, debugging is no fun at all. I was quite deep involved in VBox4 and VBox5 support, so I know what I’m talking about.
Seoul I can run on AMD (private machines) and Intel (work). VBox6 is not working on AMD when I last tried, so it is not an option.
Seoul runs since years quite efficiently. It scales well with the number of vCPUs used (I run it with 12 vCPUs daily, up to 16 on my AMD desktop). In contrast, more than 4 vCPUs slows down the VM with VBox6 … This now seems to have changed with Vbox7.
When the VM is idle, with Seoul the CPU load is close to not measurable. Vbox6 has a constant load (check it with top-view and msr-gui). So, a notebook consumes unnecessary energy, does not go to deeper sleep states and so on and so on.
VBox supports a wide variety of guests, Linux and of course Windows.
Seoul guest support is restricted, respectively only known to work with Debian stable and several Tinycore versions. I also tried Ubuntu (24.04?) in the past successfully, but decided to stay with Debian.
Seoul has several virtio models, which Linux guests already have built-in support for.
VBox guest additions are sometimes tricky to get up. Having two versions, the built-in of the Linux kernel (not supported by Oracle) and the official ones from Oracle, makes things not easier.
The model support of Seoul is not too bad (ahci, usb, virtio-audio, virtio-input, virtio-fs, virtio-gpu(2D), intel network model, …), but feature-wise VBox wins definitely (+multi-monitor support in guest, +gpu(3d), +clipboard, +uefi support).
So, depending whether you need the extra features actually, Seoul may or may not be an option.
The README above contains references to build and play with Seoul sources yourself. If you miss something, tell me, and I will try to improve it.
On Sculpt OS I have also a subsection in my alex-ab index, e.g. “VMMs - sculpt a VM yourself”. There are several Seoul packages, potentially the first Seoul package may serve as starting point. It will import a Seoul configuration to your recall folder, which you can change yourself. The subsection “Adapter - Block” provide tools, which may become handy in this context.
Thanks a lot @alex-ab ! 
This is a great introduction I was looking for!
Somehow I didn’t see that README
Going to check it now 
This was just the inspiring pep-talk I needed to try again with Seoul! Especially the AMD support, which I need in order to move to the Framework 16.
Your packages work great, but I am having trouble figuring out how to wire things together for my own custom installations. I see the “.cfg” files, but I think I am still missing something. Most importantly, where is the link to the “.vdi” filename? Also, how do you specify the amount of RAM? That sort of thing.
Thanks!
Out of interest, what makes it so tricky to get a guest working?
The seoul packages will ever request a block service (or several, depending on the package). If you want to provide the VM from a VDI file, then you need the vdi_block component (subsection “adapter-block” from my index ) to configure and start beforehand. This component will either import an empty vdi file (called block.vdi) or it will use the one which exists in the configured filesystem (which has to be named block.vdi).
The “file_ro_block” adapter can be used with installation mediums of distributions (e.g. usb bootable mediums) - in case you want to try to install directly from them. Here the seoul-block-2-boot package is handy, e.g.
fs_vdi (target) <-> vdi_block <-> seoul - 1. block connection
fs_tmp (usb/iso hybrid) <-> file_ro_bock <-> seoul - 2. block connection (boot)
Seoul takes a small amount of RAM for itself and the rest it gives to the VM. In the cfg file, you can configure it by the “vmm_memory: 80M” tag. Beside that, by increasing the overall memory of the package, you increase implicitly the memory for the VM, e.g.
runtime | ram: 2450M | caps: 1350 | binary: init
+ requires
...
+ start seoul | ram: 16G
The package gets only 2.5 Gb, but you may increase the numbers, and seoul and the VM will get implicitly more (up to 16G in this example).
I wanted to keep the expectations low, so I mentioned only the distributions I tried personally. Other may work. Well, debugging guests which work mostly or to a large degree, but not ever, or stop working after some time, can become quite time consuming to debug. If you are lucky, and the error manifest immediately, that is the good case to debug. If the error manifest much later, you don’t get the root reason. So, you have to look backwards within the guest, potentially instrument the guest to understand what is ongoing and then conclude what you potentially did wrong in the VMM.
Presumably a simpler OS (such as Haiku for instance) would be easier to port and debug?
This was very helpful info, but I think I’m still missing one piece of the puzzle - I don’t see how you connect to the “.cfg” file.
(Sorry if I’m just being thick-headed!)
@alex-ab - After reading the release notes for 26.08, I was wondering if you could say a few words about “virtio-fs” and “virtio-net”. “virtio-fs” sounds especially interesting.
Okay, let’s have a look at the shortened recipe of the mentioned seoul package, e.g.
runtime ...
+ requires
+ fs recall | writeable: yes
...
+ start fs_rom
+ provides | + service ROM
+ route
+ service File_system | + parent | identity: recall ...
+ start seoul
+ route
+ service ROM | label: config | + child fs_rom | label: vm_seoul_audio.cfg
From the snippet one can see, that the Seoul VMM will request its ‘config’ ROM from the fs_rom component. The config request is re-labeled to another name. The fs_rom will read the file with same name from the recall filesystem and provides it to the Seoul VMM as ROM.
That means, that the configuration is read via the recall path you configured during instantiation on Sculpt OS.
Well, Virtio is a specification for virtual device models. The Virtio file system device, e.g. Virtual I/O Device (VIRTIO) Version 1.4, specifies how a file-system can be established between host and guest based upon the Linux FUSE protocol. I worked on this over a longer period in my spare time and now it is usable to exchange files.
Let’s have a look at the firefox@seoul package, e.g.
runtime ...
+ requires
+ fs shared | writeable: yes
+ start seoul
+ route
+ service File_system | + parent | identity: shared ...
In the Seoul VMM cfg you may see the virtio-fs model enabled for some configurations, e.g.
...
+ virtio_input
+ virtio_gpu
+ virtio_sound
+ virtio_fs | tag: shared
...
The tag name “shared” you can use in your guest VM to mount the file-system, e.g.
mkir tmp
sudo mount -t virtio shared tmp
In principal you may also instantiate virtio_fs multiple times with different tag names, and use those names in the guest to differentiate the file systems.