Date: Fri, 05 Aug 2016 17:48:39 +0200 From: Michael Reifenberger <mike@reifenberger.com> To: Matt Churchyard <matt.churchyard@userve.net> Cc: Peter Grehan <grehan@freebsd.org>, virtualization@freebsd.org Subject: Re: Bhyve tests and findings Message-ID: <20160805174839.Horde.c9blLf_kcl9ZRprZEOdH2Qx@mail.eeeit.de> In-Reply-To: <282a992c2cd048c9872526d48e2eef14@SERVER.ad.usd-group.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Zitat von Matt Churchyard <matt.churchyard@userve.net>:
>> Zitat von Peter Grehan <grehan@freebsd.org>:
>
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160805174839.Horde.c9blLf_kcl9ZRprZEOdH2Qx>