Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Mar 2015 13:38:22 -0600
From:      Scott Furry <scott.wl.furry@gmail.com>
To:        Juergen Lock <nox@jelal.kn-bremen.de>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: qemu-devel usage
Message-ID:  <54FF482E.2070807@gmail.com>
In-Reply-To: <201503071805.t27I5HoV056581@enceladus10.kn-bremen.de>
References:  <201503071805.t27I5HoV056581@enceladus10.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On 07/03/2015 11:05, Juergen Lock wrote:
> In article <54F64BBC.4060502@gmail.com> you write:
>> I didn't have to go to this extreme when I setup qemu networking on a
>> linux box. However, new OS. :)
>>
>>  From my original setup files for qemu, I had used the -enable-kvm and
>> -cpu host flags (see 2 below). Qemu on BSD just didn't want to accept
>> "host" as a cpu option. The reference did point out how the flag worked,
>> something I didn't realize. However, it would be really good to have the
>> "host" flag to pass along the cpu accelerators to the VM without having
>> to call them individually. Is anyone working on this?
Just to amend this observation...I wouldn't worry about this ATM.
"-cpu host" hides a lot of details about settings in qemu. When moving 
over to another VM tool, those hidden settings/unknown defaults become 
painful to manage.
>> Is the -enable-kvm flag mentioned earlier still required here?
>   A little bit of history:  qemu started as jit-only (software
> emulation), then came kqemu, then kqemu was replaced by kvm.
> However, the FreeBSD kvm kernel bits port was never finished so
> recent qemu versions (qemu-devel, qemu-sbruno) are stuck with jit
> again which means for x86-on-x86 virtualization you're better off
> with bhyve or vbox, they're simply faster,
I've since managed to convert images over to vdi's. Tweaking the 
settings for host params 
was...amusing?...entertaining?...challenging?...painful! (see comment 
above). Even with the links you gave to the handbook, I ended up on the 
Oracle site to learn there was a gui that could be used to manage 
things. And here I was dreading the idea of text file setup's. The gui 
has some painful quirks but is usable.

Learning "what is a sane default" can be a determent to a steep learning 
curve. And I'm shaking my head at the foolishness. You can call a file 
by name, but must clean by UUID. And VBox doesn't provide a "UUID from 
name search" mechanism. I ended up modifying my original images 
"cleaning/backup" script to pull the UUID from a VBoxManager call. 
Speaking of entertaining...

The blurring and cross-usage of qemu, kqemu and KVM made searching 
difficult. But the little history you provided makes reading through 
search results suddenly more CLEARER!
Thank you.

> The main use of the qemu ports on FreeBSD is for testing/emulating
> other than the host arch
 From the available ports - got it. Having used qemu on other OS's. I 
was hoping to just pickup and carry on with existing files. Lovely 
thought on my part. Not possible practically. The move to VBox was 
inevitable it appears.

Overall, I have my Win7 and BSD emulations working in VBox. I'm good.

Juergen. Thanks for the details and the response!

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54FF482E.2070807>