possible to compile uhyve as unikernel?

[lonnietc]

Hello,

Right now, it seems that uhyve is used to test unikernel builds, but I need a single instance virtualization application that is compiled with a unikernel.

I am working on a project and would like to compile bhyve or xhyve which are C/C++, or possibly uhyve (Rust) to be build with the unikernel as well.

Can this be accomplished?

[stlankes]

You want to combine both and run it bare-metal on the hardware?

[lonnietc]

Actually, I would just like to take one of them and compile it to run on bare metal.

In this way, it will be similar to a Type-1 virtualization platform. This system will be running within a hypervisor that I have to allow a user to boot an Unikernel or OS platform that may be in an ISO, for example.

[stlankes]

Hm, this does currently not work. It would be a great feature. I will think about it.

[jounathaen]

Hmm. I don't think this is in the scope of uhyve. The aim of uhyve is IMHO only to make developement and execution of a unikernel simple, not to provide a feature-rich virtualization platform. There are other hypervisors which are better suited for this.

I'd rather change rusty-hermit, so that it could run on a bare-metal hypervisor like ZEN.

[lonnietc]

Hi All, Thanks for the feedback on this relative to uhyve. Actually, a new type of hypervisor which has an ultra small footprint utilizing a unikernel for the VMM while specifically for unikernel applications is exactly what I am working on developing in my project. The existing hypervisors are great for what they do, but my target groups are a bit different. Cheers

…

On Tue, Aug 11, 2020 at 7:39 AM Jonathan Klimt ***@***.***> wrote: Hmm. I don't think this is in the scope of uhyve. The aim of uhyve is IMHO only to make developement and execution of a unikernel simple, not to provide a feature-rich virtualization platform. There are other hypervisors which are better suited for this. I'd rather change rusty-hermit, so that it could run on a bare-metal hypervisor like ZEN. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#30 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUOZIUFY3TAPSOR7YXBAVDSAEUWLANCNFSM4P2MG27A> .

[stlankes]

I totally agree. I like the idea.

[jounathaen]

Can this be closed then?

[stlankes]

No, I will think about it...

[daxpedda]

Hi,

I have a question about how to approach running multiple applications on the same server. In my scenario I would just compile all applications into a single unikernel image and use that, but I wish to seperate them to make sure that one application crashing doesn't crash the entire server.

Considering that we are in a unikernel and processes don't exist, my first thought was to use uhyve to host multiple seperate hermit unikernels, which would prevent one application (now each application is it's own unikernel) to crash the whole server.

The issue is that running uhyve requires me to again put an OS on the server, I believe if uhyve could be compiled as a unikernel, I could just run uhyve directly on the hardware, requiring no underlying OS, and uhyve can then spawn unikernels that are isolated from each other.

Potentially if there was a way to "catch" crashes in code, I wouldn't even need separate unikernels or uhyve. But I suppose thats not possible, because crashes like segfaults don't cause stack unwinding to reach the "catch" instruction?

[jschwe]

@daxpedda Uhyve is a type-2 Hypervisor and requires KVM (i.e. Linux), so uhyve can't be "compiled as a unikernel".
From your description, it looks like you might want a type-1 Hypervisor (e.g. Xen). Rusty-hermit doesn't offer Xen support, but there are definitely some options out there that do support Xen.

[daxpedda]

I may have misunderstood this issue, I believed it was about potentially making Uhyve a type-1 Hypervisor.

[jschwe]

Ah, sorry, your right, this seems to be exactly what this feature request is. Since the issue was old, I only looked at your post when replying.
Still, I'd say that this happening anytime in the near future is highly unlikely, so I'd recommend looking at other alternatives like Xen or ACRN.

Potentially if there was a way to "catch" crashes in code, I wouldn't even need separate unikernels or uhyve. But I suppose that's > not possible, because crashes like segfaults don't cause stack unwinding to reach the "catch" instruction?

Unwinding is only available on the major Tier 1 targets windows, linux and mac OS anyway. Rusty-hermit always aborts on a panic.
From your description, I'm also not really sure why you want to use unikernels. To me, it sounds like running a bare-metal Linux, with your applications as processes or containers, would fit your needs. Linux can be configured to be quite small.

[daxpedda]

Unwinding is only available on the major Tier 1 targets windows, linux and mac OS anyway. Rusty-hermit always aborts on a panic.

I didn't realize that, is unwinding a possible goal for HermitCore?

To me, it sounds like running a bare-metal Linux, with your applications as processes or containers, would fit your needs. Linux can be configured to be quite small.

This is indeed the current approach we took and it does work out just fine.

[jschwe]

Unwinding is only available on the major Tier 1 targets windows, linux and mac OS anyway. Rusty-hermit always aborts on a panic.

I didn't realize that, is unwinding a possible goal for HermitCore?

That would of course be awesome, but according to Alex Crichton:

In general a panic=unwind strategy requires so much compiler support that's basically impossible to implement a custom unwinding panic strategy.In that sense only targets officially supported by rustc (likely tier 1) and shipped with binaries will support unwinding panic [...]

[daxpedda]

Considering this comment was left before rust-lang/rust#74682, I think this can be done now by contributing to backtrace-rs.
If you look in the issue tracker/PR's, already a couple of contributions were made for non-tier 1 targets.

What do you think? (this may be off-topic at this point, if what I'm saying is correct, maybe we should open a tracking issue, if HermitCode is indeed interested in this feature)

[jschwe]

As far as I can see, backtrace-rs is only for printing customized backtraces, but it's not a replacement for panic_unwind.
To catch an unwind (which is not even always possible), the target must have an implementation in the panic_unwind crate (compiler internal).
Hermit actually has an implementation (at src/hermit.rs), however, it simply aborts, so it's functionally the same as panic_abort.

I also suspect that for most applications, that want to use a unikernel, panic_unwind is not that interesting, since it adds a certain overhead (mostly with respect to compile-time and executable size).

Since this is pretty far offtopic now, feel free to open an issue at libhermit-rs if you wish to continue this discussion.