From owner-freebsd-virtualization@FreeBSD.ORG Fri Feb 28 07:15:46 2014 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4358DA87 for ; Fri, 28 Feb 2014 07:15:46 +0000 (UTC) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 04F4118B7 for ; Fri, 28 Feb 2014 07:15:45 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id D2D58121CD; Fri, 28 Feb 2014 17:08:49 +1000 (EST) Received: from Peters-MacBook-Pro.local (c-67-161-27-37.hsd1.ca.comcast.net [67.161.27.37]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BSE35158 (AUTH peterg@ptree32.com.au); Fri, 28 Feb 2014 17:08:49 +1000 Message-ID: <531035FD.4030704@freebsd.org> Date: Thu, 27 Feb 2014 23:08:45 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Rudy (bulk)" Subject: Re: lazy bhyve doesn't boot until I conenct to console References: <5310346B.4000001@monkeybrains.net> In-Reply-To: <5310346B.4000001@monkeybrains.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 07:15:46 -0000 Hi Rudy, > I'm seeing something odd... I am running this command: > > bhyve -c 4 -m 2048M -H -P -A -s 0:0,hostbridge -s 1:0,lpc -s > 2,virtio-net,tap1 -s 3,virtio-blk,/dev/zvol/data/vm1 -l com1,/dev/nmdm1A > vm1 > but I the VM is being lazy... A number of people have reported this, and looking at it, I think it's a bug in bhyve. nmdm attempts to simulate modem control (not quite correctly - run back-back cu's to see some of the behaviour), but also bhyve doesn't open the device non-blocking. This results in the open() syscall waiting for simulated carrier-detect to arrive, which doesn't happen until the other end of the nmdm is opened. A fix should be showing up shortly. later, Peter.