Re: two mysteries

[Yasha Karant]

On 01/26/2016 09:41 PM, jdow wrote:

On 2016-01-26 05:17, Tom H wrote:

On Tue, Jan 26, 2016 at 10:12 AM, David Sommerseth
 wrote:

On 26/01/16 08:13, Yasha Karant wrote:


As neither VMware player nor VirtualBox seem capable of providing a MS
Win guest with any form of Internet access to an 802.11 connection 
from

the host (in both cases, the claim from a MS Win 7 Pro guest is that
there is no networking hardware, despite being shown by the guest as
existing), it is possible that the "native" (ships with) vm
functionality of EL 7 may address this issue.


So you want the guest to have full control over the wireless network
adapter?  That is possible, but only through a hypervisor ... and these
days, unless the adapter supports PCI SR-IOV [1], you need to disable
the interface (unload all drivers, unconfigure it) and allow your guest
to access the PCI interface directly (so called PCI passthrough).

With PCI SR-IOV support (this requires hardware support), you can
actually split a physical PCI device also supporting SR-IOV into
multiple "virtual functions" (VF) which results in more PCI devices
appearing on your bare-metal host and you can then grant a VM access to
this VF based PCI device.  For network cards, that also includes a
separate MAC address per VF.

[1] 

But the downside, from your perspective, all this requires a 
hypervisor.


IIRC, Yasha's issue with 802.11 is that he cannot bridge a wifi NIC (I
pointed out in Oct/Nov that it's because the kernel prevents it).


Have you gone into /dev and made the appropriate permissions change on 
the device?


{o.o}

Obviously, there is some point I am missing:

The physical 802.11 device has an instantiated driver interface wlp61s0 
on the machine in question.


bash-4.2$ ls -a /dev/wl*
ls: cannot access /dev/wl*: No such file or directory
bash-4.2$ ls /dev | grep -a wl
bash-4.2$
bash-4.2$ locate wlp61s0
/home/ykarant/.gkrellm2/data/net/wlp61s0
/var/lib/NetworkManager/dhclient-568cb7e6-daa1-4768-b13e-0ac4d3d61864-wlp61s0.lease
/var/lib/NetworkManager/dhclient-646c0914-6eff-4c67-ad42-330f130e6f8c-wlp61s0.lease
/var/lib/NetworkManager/dhclient-6ece21f4-61c7-47a1-bc0f-85b36632da7e-wlp61s0.lease
/var/lib/NetworkManager/dhclient-76d98a93-e645-4da2-b190-e2de2e2b9333-wlp61s0.lease
/var/lib/NetworkManager/dhclient-8811aaa3-40a9-43f7-b1d5-7d00f3e0c4fc-wlp61s0.lease
/var/lib/NetworkManager/dhclient-b31e96c6-392c-4c73-a6a5-8532908a0e44-wlp61s0.lease
/var/lib/NetworkManager/dhclient-ba0ab7fc-e666-4969-86d9-7e343ea8f722-wlp61s0.lease
/var/lib/NetworkManager/dhclient-c806cddf-1d8b-46da-a2a8-40bcf7e9956e-wlp61s0.lease
/var/lib/NetworkManager/dhclient-ef685b95-88bf-4a0d-acea-837443a026c0-wlp61s0.lease
/var/lib/NetworkManager/dhclient-wlp61s0.conf

Re: two mysteries

[jdow]

On 2016-01-26 05:17, Tom H wrote:

On Tue, Jan 26, 2016 at 10:12 AM, David Sommerseth
 wrote:

On 26/01/16 08:13, Yasha Karant wrote:


As neither VMware player nor VirtualBox seem capable of providing a MS
Win guest with any form of Internet access to an 802.11 connection from
the host (in both cases, the claim from a MS Win 7 Pro guest is that
there is no networking hardware, despite being shown by the guest as
existing), it is possible that the "native" (ships with) vm
functionality of EL 7 may address this issue.


So you want the guest to have full control over the wireless network
adapter?  That is possible, but only through a hypervisor ... and these
days, unless the adapter supports PCI SR-IOV [1], you need to disable
the interface (unload all drivers, unconfigure it) and allow your guest
to access the PCI interface directly (so called PCI passthrough).

With PCI SR-IOV support (this requires hardware support), you can
actually split a physical PCI device also supporting SR-IOV into
multiple "virtual functions" (VF) which results in more PCI devices
appearing on your bare-metal host and you can then grant a VM access to
this VF based PCI device.  For network cards, that also includes a
separate MAC address per VF.

[1] 

But the downside, from your perspective, all this requires a hypervisor.


IIRC, Yasha's issue with 802.11 is that he cannot bridge a wifi NIC (I
pointed out in Oct/Nov that it's because the kernel prevents it).


Have you gone into /dev and made the appropriate permissions change on the 
device?

{o.o}

Posted for testing: Scientific Linux 7.2 x86_64 Release Candidate

[Pat Riehecky]

Scientific Linux 7.2 x86_64 Release Candidate - Jan 26, 2016

== Information ==

If no critical bugs are reported by Feb 2, 2016 this will become the 
official release of Scientific Linux 7.2


NOTE: Please review the SL Release Notes along with
The Upstream Vendor's Release Notes:

http://ftp.scientificlinux.org/linux/scientific/7.2/x86_64/release-notes/

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/index.html

There is a great deal of information within those documents not listed here.

Send comments/issues/test reports to:
scientific-linux-de...@listserv.fnal.gov

== Media ==
You can find the release media at:
http://ftp.scientificlinux.org/linux/scientific/7.2/x86_64/iso/

Alternatively the livecd-iso-to-disk utility is able to convert
this to USB successfully. A USB device of sufficient size is
required.

Alternatively you can utilize the dd command to write the
raw image to a USB device.

http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_how_to_make_a_bootable_usb_installer

== SL Specific Updates ==
.External Repos
With SL 7.2, yum-conf files pointing to non-base SL (such as EPEL, ELRepo,
SL-Extras, SL-SoftwareCollections, ZFS) have moved to a central location.
Since these repos are not specific to individual releases of SL, the
separate location will allow for easier adding and removing of these 
resources

for any SL7 system.
To load a resource, such as EPEL:
`yum install yum-conf-repos` followed by `yum install yum-conf-epel`.

.Install Media Updates
The install media now features the yum-fastest-mirror plugin.
The yum-fastest-mirror plugin should locate a quickly responding
mirror for network installs.

.Scientific Linux Contexts
SL 7.2 includes initial support for Scientific Linux Contexts which
should allow for ease of creating local customization for specific
computing needs.
For more information on Scientific Linux Contexts:
http://ftp.scientificlinux.org/linux/scientific/7/contexts/README.html

.OpenAFS
With SL 7.2 OpenAFS has been updated to version 1.6.16 the latest 
upstream stable.


.Yum behavior update
Backported patch from upstream for yum fs-vars, per BZ#1281593
Now yum vars set in /etc/yum/vars will be checked even in an
alternate yum-root.
Thanks for the bug report Lincoln Bryant!

.IPA customizations
The IPA packages have been customized to remove the upstream links to 
their support services.


.Build Fixes
The curl and mariadb packages were modified to ensure their unit tests 
for date validation worked after Oct 2015


== Known Bugs ==



== UEFI Secure Boot ==
The status of UEFI Secure Boot for Scientific Linux is noted in detail at:

http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_about_uefi_secure_boot

Booting SL7 with Secure Boot enabled works but requires a manual step.
This is because the "shim" has not been signed by the UEFI CA.
Instructions are included within the SL7 Release Notes.

Re: two mysteries

[Tom H]

On Tue, Jan 26, 2016 at 10:12 AM, David Sommerseth
 wrote:
> On 26/01/16 08:13, Yasha Karant wrote:
>>
>> As neither VMware player nor VirtualBox seem capable of providing a MS
>> Win guest with any form of Internet access to an 802.11 connection from
>> the host (in both cases, the claim from a MS Win 7 Pro guest is that
>> there is no networking hardware, despite being shown by the guest as
>> existing), it is possible that the "native" (ships with) vm
>> functionality of EL 7 may address this issue.
>
> So you want the guest to have full control over the wireless network
> adapter?  That is possible, but only through a hypervisor ... and these
> days, unless the adapter supports PCI SR-IOV [1], you need to disable
> the interface (unload all drivers, unconfigure it) and allow your guest
> to access the PCI interface directly (so called PCI passthrough).
>
> With PCI SR-IOV support (this requires hardware support), you can
> actually split a physical PCI device also supporting SR-IOV into
> multiple "virtual functions" (VF) which results in more PCI devices
> appearing on your bare-metal host and you can then grant a VM access to
> this VF based PCI device.  For network cards, that also includes a
> separate MAC address per VF.
>
> [1] 
>
> But the downside, from your perspective, all this requires a hypervisor.

IIRC, Yasha's issue with 802.11 is that he cannot bridge a wifi NIC (I
pointed out in Oct/Nov that it's because the kernel prevents it).

Re: two mysteries

[David Sommerseth]

On 26/01/16 08:13, Yasha Karant wrote:
> On 01/25/2016 04:30 PM, David Sommerseth wrote:
[...snip...]
>> But  KVM is the core hypervior.  It is in fact just a kernel
>> module which
>> you can load at any time on systems with CPUs supporting hardware
>> virtualization (VT-d or similar, most modern Intel, AMD and IBM Power 7/8
>> supports KVM).
>>
>> libvirt is the management backend, which provides a generic API. 
>> libvirt can
>> be used against other hypervisors as well, such as Xen, but probably more
>> often used with KVM.
>>
>> qemu-kvm is the KVM virtual machine process.  Each qemu-kvm process is
>> started
>> per VM.  You seldom start these processes manually, but they are
>> kicked off by
>> libvirt.
>>
>> virt-manager is a management GUI front-end.  And virsh is a console based
>> management tool.  Both connects to the libvirt API.
>>
>> Further, you can also download an oVirt Live image and boot that on a
>> bare-metal or virtual machine.  oVirt can then connect to libvirt and
>> provide
>> an even more feature rich management tool.
>>
>> virt-manager and oVirt can also connect to several systems running
>> libvirt
>> simultaneously, so you can manage more hypervisors from a single
>> front-end.
>> And there are probably even more front-ends, like "Boxes" (not really
>> tried it).
>>
>> I dunno much about vmware stuff, so I will refrain to comment that.  But
>> VirtualBox is also two-fold.  My experience with VirtualBox is now
>> quite old
>> (5-6 years ago).  You can start VirtualBox guests without a kernel
>> support
>> module loaded, which would work on most hardware.  But performance was
>> not too
>> good at all.  If you got the init.d script to build the kernel module,
>> you
>> could get quite acceptable performance.  However, I see VirtualBox
>> more like a
>> single package which gives you both hypervisor and management tool in
>> a single
>> software package.
>>
>> Even though VirtualBox is more a "single unit" and KVM/Qemu/libvirt
>> consists
>> of more components ... you normally don't notice that when you start
>> VMs via
>> the management tools.
>>
> Thank you for your detailed exposition.  My primary concern is that I do
> *NOT* want a hypervisor actually controlling the physical hardware; we
> have enough security vulnerabilities with a "hardened" supervisor such
> as EL 7.  

You can run virtual machines without a hypervisor.  But, that will not
give you a good performance in general.  Running in this mode is often
called 'emulation'.  So the hardware a computer needs, is emulated by
software in user space, without anything running in kernel space at all.
 You can do this also with libvirt and qemu too, but then you use 'qemu'
and not 'qemu-kvm'.

As a related side-track.  Running with a hypervisor can only allow
guests to be of the same CPU family as the bare-metal host.  With
emulation, the CPU seen on the inside of the guest can be whatever the
emulator supports.  With emulation you can run powerpc, mips or even
s/390 based environments - but it is slow compared to bare-metal
performance - as everything you do is emulated.

Likewise with VirtualBox, it goes into emulated mode when it does not
have the kernel module (vbox.ko? don't recall right now).  This also
provides a much poorer performance.

I do not know enough about vmware, but their early products did run on
hardware before hardware had any virtualization features at all.  But I
suspect they also needed some kind of kernel module to provide a decent
performance.  Once the bare-metal hardware got virtualization support,
you still need the kernel module - but now the module takes advantage of
the hardware capabilities in addition, increasing the performance even more.

So to simplify it a bit: Qemu, VirtualBox and vmware (I suspect) needs a
kernel module to provide decent performance, and these modules
instruments the kernel with at least hypervisor-like capabilities.

> My secondary issue is the actual human clock execution time in
> the VM as contrasted with the same OS/environment running on the
> physical hardware.  I have found that current production releases of
> VirtualBox and VMware (e.g., VMware player) provide acceptable
> performance, although the USB interface on VMware now does seem better
> than VirtualBox that evidently still has issues (one of the mysteries).

And this is what the hypervisor does.  It provides a channel from the
hardware on the bare-metal to the guest VM.

And to get an acceptable human clock execution time inside a virtual
guest OS, you will need a hypervisor.  So you have most likely been
running both wmware and virtualbox with the kernel support modules.
Otherwise you would not get such a good performance.

> As neither VMware player nor VirtualBox seem capable of providing a MS
> Win guest with any form of Internet access to an 802.11 connection from
> the host (in both cases, the claim from a MS Win 7 Pro guest is that
> there is no networking hardware, despite being shown by t