search

hermit-os / uhyve

A specialized hypervisor for Hermit.
Apache License 2.0
251 stars 29 forks source link

possible to compile uhyve as unikernel? #30

Open lonnietc opened 3 years ago

lonnietc commented 3 years ago

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 commented 3 years ago

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

lonnietc commented 3 years ago

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 commented 3 years ago

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

jounathaen commented 3 years ago

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 commented 3 years ago

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 notifications@github.com 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 https://github.com/hermitcore/uhyve/issues/30#issuecomment-671894480, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUOZIUFY3TAPSOR7YXBAVDSAEUWLANCNFSM4P2MG27A .

stlankes commented 3 years ago

I totally agree. I like the idea.

jounathaen commented 3 years ago

Can this be closed then?

stlankes commented 3 years ago

No, I will think about it...

daxpedda commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

jschwe commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Considering this comment was left before https://github.com/rust-lang/rust/pull/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 commented 3 years ago

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.