From owner-freebsd-virtualization@freebsd.org Fri Aug 5 15:48:49 2016 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E134BB0858 for ; Fri, 5 Aug 2016 15:48:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 76EA61362 for ; Fri, 5 Aug 2016 15:48:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7299ABB0857; Fri, 5 Aug 2016 15:48:49 +0000 (UTC) Delivered-To: virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7238ABB0856 for ; Fri, 5 Aug 2016 15:48:49 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail.eeeit.de (mail.eeeit.de [37.120.160.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 047C31360; Fri, 5 Aug 2016 15:48:48 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from localhost (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mike@reifenberger.com) by mail.eeeit.de (Postfix) with ESMTPSA id 6870641F5; Fri, 5 Aug 2016 17:48:39 +0200 (CEST) Received: from ppp-62-216-199-84.dynamic.mnet-online.de (ppp-62-216-199-84.dynamic.mnet-online.de [62.216.199.84]) by mail.eeeit.de (Horde Framework) with HTTPS; Fri, 05 Aug 2016 17:48:39 +0200 Date: Fri, 05 Aug 2016 17:48:39 +0200 Message-ID: <20160805174839.Horde.c9blLf_kcl9ZRprZEOdH2Qx@mail.eeeit.de> From: Michael Reifenberger To: Matt Churchyard Cc: Peter Grehan , virtualization@freebsd.org Subject: Re: Bhyve tests and findings References: <20160804132810.Horde.PbxdxEormFX3MwsBMVBoRo7@mail.eeeit.de> <386acc93-afea-9c7e-bcb0-401d1f71fa1f@freebsd.org> <20160804205702.Horde.cclsReqAJZ4gP-yp7ySWYDW@mail.eeeit.de> <282a992c2cd048c9872526d48e2eef14@SERVER.ad.usd-group.com> In-Reply-To: <282a992c2cd048c9872526d48e2eef14@SERVER.ad.usd-group.com> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.22 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, 05 Aug 2016 15:48:49 -0000 Zitat von Matt Churchyard : >> Zitat von Peter Grehan : > >> Hi Mike, >> >>> - Windows 8, 8.1 and 10 installs and runs in graphical mode flawlessly. >> >> Have you had any issues with the XHCI mouse on 8/8.1 ? >> >>> - I was able to graphically Restore/Reconfigure a Acronis >>> Windows-Backup into a Bhyve instance using the Acronis Restore-CD >>> (Converting a BIOS Win8.1 to UEFI Win8.1) >> >> Very nice ! >> >>> - Only vnclient from FreeBSD can connect to the bhyve VNC Server. >>> I havn't found any vncviewer running on Windows which where able to >>> work (tried UltraVNC, RealVNC, ...) >> >> Some VNC clients refuse to connect when only null-auth is advertized >> by the server. There is a patch to bhyve to support VNC password-auth, >> which may fix the issue with these clients. >> > >> Yes, that sounds reasonable. > >>> - in VNC only most basic Keys work most special characters like (*\@) >>> (and of course no german localization) but at least a usual US-kbd >>> would be helpful. >>> (Is there a way to debug the keystrokes or duplicate a localized VNC >>> kbd from some VNC server) >> >> Nothing outside of modifying the source, but it seems useful enough >> to add a parameter for this. >> >>> - For the SAP-Systems it seems that only 4 disks get used when the >>> disk type is virtio-blk. >>> (Is this intentionally or a feature of vm-bhyve? How to provide more >>> disks) >> >> I'll let Matt comment on that. There's no limitation with guests that >> support MSI interrupts for adapters. Unfortunately, Windows guests >> require legacy interrupts for the AHCI controller, which is where the >> restriction originates. >> > >> I'd like to use a 6 disks setup with Centos7. >> Centos7 on XEN PVM has no issue with supporting 6 paravirtulized disks. > >> Thats the config (for vm-bhyve) where only the first 4 disks are >> used for the guest (Centos7): > >> uefi="yes" >> cpu=1 >> memory=2G >> network0_type="virtio-net" >> network0_switch="public" >> disk0_name="root" >> disk0_type="virtio-blk" >> disk0_dev="zvol" >> disk1_name="swap" >> disk1_type="virtio-blk" >> disk1_dev="zvol" >> disk2_name="sapmnt" >> disk2_type="virtio-blk" >> disk2_dev="zvol" >> disk3_name="usrsap" >> disk3_type="virtio-blk" >> disk3_dev="zvol" >> disk4_name="db" >> disk4_type="virtio-blk" >> disk4_dev="zvol" >> disk5_name="log" >> disk5_type="virtio-blk" >> disk5_dev="zvol" >> graphics="yes" >> graphics_port="5903" >> graphics_listen="0.0.0.0" >> graphics_res="1600x900" >> graphics_wait="no" >> xhci_mouse="yes" > > Sorry I didn't actually spot that you were using my vm-bhyve code to > run the guest the first time. > > The UEFI code in vm-bhyve is currently limited to using slots 4/5/6 > for disks so you should only see 3... (I put a CD device on slot 3) > If you look in the /path/to/guest/vm-bhyve.log log file you'll > probably see something like "ending disks as disk2 due to UEFI > limitations". > > I've never been 100% on which guests have the limitation and which > don't, so in UEFI mode I played it safe and just used the 3 slots. > If you run the guest with the grub loader instead of UEFI you should > get all the disks. > > If you want, you can comment out the limitation in the vm-bhyve > source and see if the guest will pick up the extra disks. It's the 4 > lines after the "can't go past slot 6" comment around line 364 of > lib/vm-run. If it works it may be worth me adding a configuration > option to toggle this limit. > Cool! Commenting out: ... # stop at slot 6 on uefi # if [ ${_slot} -ge 7 ]; then # util::log "guest" "${_name}" "ending disks at disk${_num} due to UEFI firmware limitations" # break # fi ... Gives me all disks in Centos7: [ 0.755083] ahci 0000:00:03.0: version 3.0 [ 0.759512] ahci 0000:00:03.0: irq 25 for MSI/MSI-X [ 0.759548] ahci 0000:00:03.0: SSS flag set, parallel bus scan disabled [ 0.759661] ahci 0000:00:03.0: AHCI 0001.0300 32 slots 6 ports 6 Gbps 0x1 impl SATA mode [ 0.759663] ahci 0000:00:03.0: flags: 64bit ncq sntf ilck stag pm led clo pio slum part sxs apst [ 0.767612] scsi host0: ahci [ 0.774675] scsi host1: ahci [ 0.783392] virtio-pci 0000:00:04.0: irq 26 for MSI/MSI-X [ 0.783407] virtio-pci 0000:00:04.0: irq 27 for MSI/MSI-X [ 0.784850] vda: vda1 vda2 vda3 vda4 [ 0.785013] virtio-pci 0000:00:05.0: irq 28 for MSI/MSI-X [ 0.785027] virtio-pci 0000:00:05.0: irq 29 for MSI/MSI-X [ 0.785609] vdb: unknown partition table [ 0.785725] virtio-pci 0000:00:06.0: irq 30 for MSI/MSI-X [ 0.785739] virtio-pci 0000:00:06.0: irq 31 for MSI/MSI-X [ 0.786817] vdc: unknown partition table [ 0.786925] virtio-pci 0000:00:07.0: irq 32 for MSI/MSI-X [ 0.786939] virtio-pci 0000:00:07.0: irq 33 for MSI/MSI-X [ 0.790069] virtio-pci 0000:00:0a.0: irq 34 for MSI/MSI-X [ 0.790083] virtio-pci 0000:00:0a.0: irq 35 for MSI/MSI-X [ 0.790097] virtio-pci 0000:00:0a.0: irq 36 for MSI/MSI-X [ 0.790895] vdd: unknown partition table [ 0.791026] virtio-pci 0000:00:08.0: irq 37 for MSI/MSI-X [ 0.791040] virtio-pci 0000:00:08.0: irq 38 for MSI/MSI-X [ 0.792815] vde: unknown partition table [ 0.792927] virtio-pci 0000:00:09.0: irq 39 for MSI/MSI-X [ 0.792942] virtio-pci 0000:00:09.0: irq 40 for MSI/MSI-X [ 0.795286] vdf: unknown partition table So it seems to work for UEFI / Centos7. Greetings --- Mike Gruß --- Michael Reifenberger