vmm(4) status?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

vmm(4) status?

Christian Weisgerber
I was wondering about the status of OpenBSD's vmm(4) hypervisor.
Is it ready for some limited use, say, testing a port in an i386
VM on an amd64 host?

(TL;DR: nope.)

There's little information, so I decided to give it a try after
reading the various vmm(4), vm.conf(5), vmd(8), vmctl(8), virtio(4),
etc. man pages.

First, you need to build a kernel with vmm(4).  It is not enabled
in GENERIC yet.  You also need an up-to-date /dev since vmd opens
/dev/vmm and /dev/tap0.

Next: Start vmd, create a disk image (can you use a raw partition
instead?), spin up a VM with an amd64 bsd.rd kernel I had at hand.

# /etc/rc.d/vmd -f start
# vmctl create /home/bardioc.img -s 4G
# vmctl start -c -k /bsd.rd -m 1G -d /home/bardioc.img -i 1

Something's happening!  There's a copyright message.  And that's
it...  I was about to give up when the bsd.rd kernel continued,
successfully booted, and allowed to drop me into a (S)hell.

Observation: vmd completely hogs one CPU core even if the guest
isn't doing anything.

Next step: networking.  As expected, a vio0 interface showed up
inside the VM, but the man pages don't explain how to connect this
to the outside.  Since I had noticed that vmd opens tap0, I created
a bridge on the host and added tap0 and a real interface.  I don't
know if that's the intended way, but after manually configuring an
IP address on vio0, I could ping other machines from the guest. \o/

ping also showed that time was running three times slower in the
VM than on the outside.  Uh-oh.

I deleted the inet configuration from vio0 and started the installer.
I got as far as the network configuration, when the guest kernel
died with an UVM error--and my patience along with it.

So, yeah, interesting but not useful yet.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: vmm(4) status?

Reyk Floeter-2
On Wed, Jan 20, 2016 at 05:44:36PM +0100, Christian Weisgerber wrote:

> I was wondering about the status of OpenBSD's vmm(4) hypervisor.
> Is it ready for some limited use, say, testing a port in an i386
> VM on an amd64 host?
>
> (TL;DR: nope.)
>
> There's little information, so I decided to give it a try after
> reading the various vmm(4), vm.conf(5), vmd(8), vmctl(8), virtio(4),
> etc. man pages.
>
> First, you need to build a kernel with vmm(4).  It is not enabled
> in GENERIC yet.  You also need an up-to-date /dev since vmd opens
> /dev/vmm and /dev/tap0.
>
> Next: Start vmd, create a disk image (can you use a raw partition
> instead?), spin up a VM with an amd64 bsd.rd kernel I had at hand.
>
> # /etc/rc.d/vmd -f start
> # vmctl create /home/bardioc.img -s 4G
> # vmctl start -c -k /bsd.rd -m 1G -d /home/bardioc.img -i 1
>
> Something's happening!  There's a copyright message.  And that's
> it...  I was about to give up when the bsd.rd kernel continued,
> successfully booted, and allowed to drop me into a (S)hell.
>
> Observation: vmd completely hogs one CPU core even if the guest
> isn't doing anything.
>
> Next step: networking.  As expected, a vio0 interface showed up
> inside the VM, but the man pages don't explain how to connect this
> to the outside.  Since I had noticed that vmd opens tap0, I created
> a bridge on the host and added tap0 and a real interface.  I don't
> know if that's the intended way, but after manually configuring an
> IP address on vio0, I could ping other machines from the guest. \o/
>
> ping also showed that time was running three times slower in the
> VM than on the outside.  Uh-oh.
>
> I deleted the inet configuration from vio0 and started the installer.
> I got as far as the network configuration, when the guest kernel
> died with an UVM error--and my patience along with it.
>
> So, yeah, interesting but not useful yet.
>

It is not enabled in GENERIC, so obviously not ready yet :)

The CPU usage, time and networking issues are know and should go away
after mlarkin@ finished implementing proper interrupt handling.

On the userland side, the networking configuration will be changed to
a slightly different approach, but I kind of suspended this until the
previous issue is solved.

But, in fact, I already use vmm for some things, like installing
images that I upload to EC2 :) So it is partially useful, at least for
me.

Thanks for feedback & testing!

Reyk

Reply | Threaded
Open this post in threaded view
|

Re: vmm(4) status?

Christian Weisgerber
In reply to this post by Christian Weisgerber
On 2016-01-20, Christian Weisgerber <[hidden email]> wrote:

> So, yeah, interesting but not useful yet.

That came across all wrong.

I already sent some words in private, but I would like to publicly
apologize to Mike, too.  What I wrote was dismissive of his work
in a way that was entirely uncalled for.  I failed to consider how
this would make feel the people doing the actual work.  And I should
have done more research and in particular asked the people involved
before taking this to a public mailing list.

I'm very sorry.

----

Regarding the question in the subject line:
vmm(4) is still under construction and not yet enabled FOR A REASON.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: vmm(4) status?

Peter Nicolai Mathias Hansteen
In reply to this post by Reyk Floeter-2
On Wed, Jan 20, 2016 at 06:20:48PM +0100, Reyk Floeter wrote:
 
> It is not enabled in GENERIC, so obviously not ready yet :)
>
> The CPU usage, time and networking issues are know and should go away
> after mlarkin@ finished implementing proper interrupt handling.
>
> On the userland side, the networking configuration will be changed to
> a slightly different approach, but I kind of suspended this until the
> previous issue is solved.

for the terminally curious among us, do you have a ballpark figure for when
it comes back in GENERIC? (as in, pre- or post-5.9?)

- P
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.