Re: two mysteries

[Patrick Mahan]

Sheesh, maybe back in the 4.4 days?  I recommend the following link the gives 
some background as part of the implementation of the DEVFS that occurred back 
in the early 90s.

http://www.usenix.org/legacy/events/bsdcon/full_papers/kamp/kamp_html

Also, see introduction to chapter 14 in the Linux Device Drivers, 2nd Edition 

http://www.xml.com/ldd/chapter/book/ch14.html

Patrick 

Coming to you from deep inside Fortress Mahan

> On Jan 28, 2016, at 2:48 PM, jdow  wrote:
> 
>> On 2016-01-28 14:33, Patrick Mahan wrote:
>>> On 1/27/16 1:23 PM, David Sommerseth wrote:
>>> On 27/01/16 11:13, jdow wrote:
 Fascinating. I made a bad "assumption" about network devices. It seems they
 are created dynamically without any presence in /dev.
>>> 
>>> IIRC, *BSD provides /dev nodes for network devices which the user-space can
>>> use for configuring it and such.  But it's many years since I played with
>>> FreeBSD, so my memory is scarce.
>> 
>> Nope, BSD (FreeBSD, NetBSD, etc) do not show any network devices under /dev. 
>>  And
>> kernel device configuration is done via sysctl commands as opposed to using
>> /sysfs in linux.
>> 
>> Patrick Mahan
> 
> Was that true a decade and a half ago give or take a little?
> 
> {^_^}

Re: two mysteries

[jdow]

On 2016-01-27 13:23, David Sommerseth wrote:

On 27/01/16 11:13, jdow wrote:



Fascinating. I made a bad "assumption" about network devices. It seems they
are created dynamically without any presence in /dev.


IIRC, *BSD provides /dev nodes for network devices which the user-space can
use for configuring it and such.  But it's many years since I played with
FreeBSD, so my memory is scarce.


--
kind regards,

David Sommerseth


That matches my memory of BSD from many years ago. I tried it after getting 
disgusted with RedHat, then Mandrake, then Ubuntu and Mint. I eventually found 
this distro during one of Centos' periods of dying and have lived here 
comfortably for some time now.


Nonetheless, as soon as I need something a little out of the ordinary for 
networking I disable network mangler and hand craft my solutions. Moving to 7 is 
going to be painful. I use a seldom used feature of IPTables to make a nice 
killer firewall that makes repeated attempts to login via SSH with passwords 
cost too much time to guess the password. Can't retry until 2 minutes have 
passed. It's fascinating to see the chains of attempts on SSH when the first one 
got far enough to reject the password and the chain of 200 that followed were 
simply dropped on the floor. I don't see that fun much anymore. Smaller logs are 
easier logs to watch. I moved ssh et al to uncommon pure random number port 
numbers - and left the other protection in place.


{^_^}   Dis broad likes multiple barriers for safety.

Re: two mysteries

[Tom H]

On Wed, Jan 27, 2016 at 5:58 PM, Yasha Karant  wrote:
> On 01/27/2016 07:02 AM, Tom H wrote:
>> On Wed, Jan 27, 2016 at 6:41 AM, jdow  wrote:
>>> On 2016-01-26 05:17, Tom H wrote:

 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?
>>
>> NICs aren't listed under "/dev". They're symlinks under
>> "/sys/class/net/" that point at "/sys/devices/...".
>
> At a previous epoch, both VMware and VirtualBox allowed a MS Win guest to
> "share" the Linux host 802.11 Internet connection, typically through NAT if
> my memory serves. This no longer works evidently because of a change in the
> kernel. Is there any modified driver that can overlay a "virtual" NIC on
> the real 802.11 NIC? Can the kernel be "tricked" by such an overlay? Is
> there a possible alternative (modified, "hacked") kernel that will allow
> this? Is the only alternative to obtain a second 802.11 NIC and then have
> the Linux host not use this hardware but have it used by the virtual machine
> (e.g., MS Win guest)? My laptop has an external "hardware" expansion insert
> slot, and I might be able to find such a 802.11 NIC.

I thought that you weren't able to bridge a wifi NIC with a bridge
(which is normal) but you seem to be unable to use natting (which
isn't).

I don't use SL (or RHEL or CentOS) on my laptop; I use Ubuntu and
Fedora. I'm able to use kvm with and without natting (but without
bridging the wifi NIC).

I've also installed kvm and virtualbox on both my parents' laptops
(running Ubuntu) and I can do the same on both with kvm and
virtualbox. I can even use a bridged setup with virtualbox; it doesn't
use a br or a tap device so its bridging method's non-standard and
hidden.

You're going to be fighting the kernel and udev if you try to use a
usb modem from virtualbox and not from your laptop.

Re: two mysteries

[Yasha Karant]

On 01/27/2016 07:02 AM, Tom H wrote:

On Wed, Jan 27, 2016 at 6:41 AM, jdow  wrote:

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

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?

NICs aren't listed under "/dev". They're symlinks under
"/sys/class/net/" that point at "/sys/devices/...".
At a previous epoch, both VMware and VirtualBox allowed a MS Win guest 
to "share" the Linux host 802.11 Internet connection, typically through 
NAT if my memory serves.  This no longer works evidently because of a 
change in the kernel.  Is there any modified driver that can overlay a 
"virtual" NIC on the real 802.11 NIC?  Can the kernel be "tricked" by 
such an overlay?  Is there a possible alternative (modified, "hacked") 
kernel that will allow this?  Is the only alternative to obtain a second 
802.11 NIC and then have the Linux host not use this hardware but have 
it used by the virtual machine (e.g., MS Win guest)?  My laptop has an 
external "hardware" expansion insert slot, and I might be able to find 
such a 802.11 NIC.


Presumably, a "bare iron" hypervisor controlling the real hardware 
platform and then allocating virtual machines and their environments 
(supervisors), e.g., a SL7 VM and a MS Win VM under the hypervisor, 
would work if the hypervisor time multiplexes the 802.11 NIC between the 
two VMs.  However, one is then forced to a hypervisor controlling the 
hardware (security issues) along with the additional overhead of a full 
time hypervisor.

Re: two mysteries

[Stephen John Smoogen]

On Jan 27, 2016 11:58, "Yasha Karant"  wrote:
>
> On 01/27/2016 07:02 AM, Tom H wrote:
>>
>> On Wed, Jan 27, 2016 at 6:41 AM, jdow  wrote:
>>>
>>> On 2016-01-26 05:17, Tom H wrote:

 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?
>>
>> NICs aren't listed under "/dev". They're symlinks under
>> "/sys/class/net/" that point at "/sys/devices/...".
>
> At a previous epoch, both VMware and VirtualBox allowed a MS Win guest to
"share" the Linux host 802.11 Internet connection, typically through NAT if
my memory serves.  This no longer works evidently because of a change in
the kernel.  Is there any modified driver that can overlay a "virtual" NIC
on the real 802.11 NIC?  Can the kernel be "tricked" by such an overlay?
Is there a possible alternative (modified, "hacked") kernel that will allow
this?  Is the only alternative to obtain a second 802.11 NIC and then have
the Linux host not use this hardware but have it used by the virtual
machine (e.g., MS Win guest)?  My laptop has an external "hardware"
expansion insert slot, and I might be able to find such a 802.11 NIC.
>

>From discussions on other virt lists this only worked by accident and not
very well for a large number of users. Wireless is a beast of hacks on top
of duct tape. Most of the virtual vendors were happy it was removed

> Presumably, a "bare iron" hypervisor controlling the real hardware
platform and then allocating virtual machines and their environments
(supervisors), e.g., a SL7 VM and a MS Win VM under the hypervisor, would
work if the hypervisor time multiplexes the 802.11 NIC between the two
VMs.  However, one is then forced to a hypervisor controlling the hardware
(security issues) along with the additional overhead of a full time
hypervisor.

Re: two mysteries

[David Sommerseth]

On 27/01/16 17:58, Yasha Karant wrote:
> My laptop has an external "hardware" expansion insert slot, and I might be
> able to find such a 802.11 NIC.

USB wireless interfaces should also work, using USB redirection.  But it
depends on your performance needs on the wireless network.  I've done that a
few times with USB Ethernet devices when playing around on odd projects.

The external "hardware" expansion may or may not work, depending on if is
possible to use a PCI Pass-through mode on that interface or not.


--
kind regards,

David Sommerseth

Re: two mysteries

[Lamar Owen]

On 01/27/2016 11:58 AM, Yasha Karant wrote:
At a previous epoch, both VMware and VirtualBox allowed a MS Win guest 
to "share" the Linux host 802.11 Internet connection, typically 
through NAT if my memory serves. ...


Under KVM on my laptop I can use the host's wifi connection through the 
default libvirt NAT networking.  Works great, and as far as the Windows 
VM is concerned there is no difference between a wired and a wireless 
connection, since it is as if it is on the other side of libvirt's NAT 
'router' stack.  Wired or wireless the Windows 7 VM has connectivity, 
using the virtio-provided networking driver.  In the virtual machine 
manager interface, the Virtual Network Interface is set u as 'Virtual 
network 'default' : NAT' and Device Model virtio.  I have an OpenVPN set 
up in the Windows 7 VM that then bridges to the LAN, rather than trying 
to get bridging to work. This way the VM is always on the desired LAN 
even if I am off-campus.  In Windows' Device Manager, the device shows 
up as 'Red Hat VirtIO Ethernet Adapter.'  I did *not* have to do 
anything special to get this working when I installed the VM, but do 
realize that I installed the VM several years ago under CentOS 6 and 
have migrated it over to EL7, so I'm not sure if the installation 
portion of that has changed a lot.


 However, one is then forced to a hypervisor controlling the 
hardware (security issues) along with the additional overhead of a 
full time hypervisor.




KVM is often considered something of a hybrid between a type 1 and type 
2 hypervisor.  But both VMware Player and VirtualBox are type 2 
hypervisors, and QEMU/KVM can be considered type 2.


But the NIC is not being 'shared' in a strict sense; rather, the NIC is 
connected to a virtual switch port of the hypervisor, and the VM's (and 
the host) are connected to other virtual ports.  Cisco has even made a 
business of this for VMware ESX in the form of the Nexus 1000V, and 
there is an open source work-alike called OpenVswitch. In both cases, 
the networking topology is also virtualized, with the phyiscal host's 
ports being connected to virtual ports on the virtualized switches.


Why don't you actually try a Win 7 install on KVM and see what you 
think?  Only you can answer if it will work for you.  It does work, and 
well, for me.

Re: two mysteries

[David Sommerseth]

On 27/01/16 11:13, jdow wrote:
>>
> Fascinating. I made a bad "assumption" about network devices. It seems they
> are created dynamically without any presence in /dev.

IIRC, *BSD provides /dev nodes for network devices which the user-space can
use for configuring it and such.  But it's many years since I played with
FreeBSD, so my memory is scarce.


--
kind regards,

David Sommerseth

Re: two mysteries

[jdow]

On 2016-01-26 22:52, Yasha Karant wrote:

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

Fascinating. I made a bad "assumption" about network devices. It seems they are 
created dynamically without any presence in /dev. So you may want to check the 
/etc/sysconfig/network-scripts files for wireless devices and their permissions 
structures. (Look for files analogous to ifcfg-eth0.) Now, I have seldom used 
network mangler because historically it has blown up in my face too often. By 
now it should be better but You could check in network mangler to see if it 
has a permissions of one sort or another that enable it to be used by other than 
root. There is such for wired ethernet, I believe. That is where I'd look to try 
to unlock this puzzle.


Regarding virtualbox - if it's as finicky to setup as with Windows "good luck". 
Just for grins setting one up in Windows might give you an idea of information 
needed to make it work. The GUI is handy and mostly works. I don't, at this 
time, have a large enough machine dedicated to Linux for experimentation. What I 
have are all little things - mail service for 6-12 accounts with routing is 
basically what they amount to.


{^_^}   Joanne

Re: two mysteries

[Tom H]

On Wed, Jan 27, 2016 at 6:41 AM, jdow  wrote:
> On 2016-01-26 05:17, Tom H wrote:
>>
>> 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?

NICs aren't listed under "/dev". They're symlinks under
"/sys/class/net/" that point at "/sys/devices/...".

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 

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}

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

[Yasha Karant]

On 01/25/2016 04:30 PM, David Sommerseth wrote:

On 25/01/16 19:32, Yasha Karant wrote:

On 01/24/2016 06:06 PM, Lamar Owen wrote:

On 01/23/2016 01:30 PM, Yasha Karant wrote:

Perhaps someone else has experienced what I related below and can comment
-- SL 7x.

1.  ... For 802.3, I prefer to use a manual configuration, not NetworkManager.

For a dynamic connection even with a wired Ethernet you should use the
supported NetworkManager stack, your personal preferences aside.  NM works
and doesn't require munging for a simple DHCP wired connection.


2.  ...Note that I must use MS Win to work with these devices as the
application software for the device in question is *NOT* available for
linux, the device is proprietary (no source code available), and
CrossOver/Wine does not support USB -- forcing the use of a VM running a MS
Win gues

Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB
passthrough works very well with Windows 7 running in a KVM virtual machine
on my laptop.  It just works, and it's already part of SL; why not use it?
Performance is very good in my experience, and I'm running a few pieces of
software in Win 7 for the same reasons as you.  You're also far more likely
to get useful help using KVM, either from the list or from other sources,
such as the Red Hat or Fedora documentation.

 From the KVM site (http://www.linux-kvm.org/page/Management_Tools) that has a
RedHat logo, there is a list of management interfaces, including VMM (Virtual
Machine Manager -- https://virt-manager.org/screenshots/ ) that also appears
to be a Red Hat entity.  Anyone using VMM?  VMM appears to allow a true host
OS (supervisor, not hypervisor) with the VM ("hypervisor") running under the
OS (as with VMWare workstation/player or VirtualBox), thus booting an OS, not
a hypervisor that actually provisions for guest supervisors.  Is this correct?

This was a bit confusing for me (getting late, so probably stupid to reply now).

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.


I hope this gave a broader perspective.


--
kind regards,

David Sommerseth

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.  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).  
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.  Note that older versions 
of VirtualBox with older (pre EL 7) 

Re: two mysteries

[Yasha Karant]

On 01/24/2016 06:06 PM, Lamar Owen wrote:

On 01/23/2016 01:30 PM, Yasha Karant wrote:
Perhaps someone else has experienced what I related below and can 
comment -- SL 7x.


1.  ... For 802.3, I prefer to use a manual configuration, not 
NetworkManager.


For a dynamic connection even with a wired Ethernet you should use the 
supported NetworkManager stack, your personal preferences aside.  NM 
works and doesn't require munging for a simple DHCP wired connection.




2.  ...Note that I must use MS Win to work with these devices as the 
application software for the device in question is *NOT* available 
for linux, the device is proprietary (no source code available), and 
CrossOver/Wine does not support USB -- forcing the use of a VM 
running a MS Win gues


Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB 
passthrough works very well with Windows 7 running in a KVM virtual 
machine on my laptop.  It just works, and it's already part of SL; why 
not use it?  Performance is very good in my experience, and I'm 
running a few pieces of software in Win 7 for the same reasons as 
you.  You're also far more likely to get useful help using KVM, either 
from the list or from other sources, such as the Red Hat or Fedora 
documentation.


From the KVM site (http://www.linux-kvm.org/page/Management_Tools) that 
has a RedHat logo, there is a list of management interfaces, including 
VMM (Virtual Machine Manager -- https://virt-manager.org/screenshots/ ) 
that also appears to be a Red Hat entity.  Anyone using VMM?  VMM 
appears to allow a true host OS (supervisor, not hypervisor) with the VM 
("hypervisor") running under the OS (as with VMWare workstation/player 
or VirtualBox), thus booting an OS, not a hypervisor that actually 
provisions for guest supervisors.  Is this correct?


Yasha Karant
<>

Re: two mysteries

[Michael Duvall]

I have used both VMM and VirtualBox.  Yes, you are correct both KVM/QEMU
(VMM is the GUI) and Virtual Box run on a true host OS and both boot
other guest OSs.  For example, the host OS could be SL7 running a SL6
guest and some other guest such as Windows.  I have run as many as seven
guests concurrently on my laptop; performance was marginal.  The more
RAM the better.

Good Luck,
-- 
Michael Duvall
Systems Analyst, Real-Time
michael.duv...@ccur.com
(954) 973-5395 Office
(954) 531-4538 Mobile
2881 Gateway Drive | Pompano Beach, FL 33069 | www.ccur.com




-Original Message-
From: Yasha Karant <ykar...@csusb.edu>
To: scientific-linux-us...@fnal.gov <scientific-linux-us...@fnal.gov>
Subject: Re: two mysteries
Date: Mon, 25 Jan 2016 13:32:30 -0500

On 01/24/2016 06:06 PM, Lamar Owen wrote:
> On 01/23/2016 01:30 PM, Yasha Karant wrote:
>> Perhaps someone else has experienced what I related below and can 
>> comment -- SL 7x.
>>
>> 1.  ... For 802.3, I prefer to use a manual configuration, not 
>> NetworkManager.
>
> For a dynamic connection even with a wired Ethernet you should use the 
> supported NetworkManager stack, your personal preferences aside.  NM 
> works and doesn't require munging for a simple DHCP wired connection.
>
>>
>> 2.  ...Note that I must use MS Win to work with these devices as the 
>> application software for the device in question is *NOT* available 
>> for linux, the device is proprietary (no source code available), and 
>> CrossOver/Wine does not support USB -- forcing the use of a VM 
>> running a MS Win gues
>
> Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB 
> passthrough works very well with Windows 7 running in a KVM virtual 
> machine on my laptop.  It just works, and it's already part of SL; why 
> not use it?  Performance is very good in my experience, and I'm 
> running a few pieces of software in Win 7 for the same reasons as 
> you.  You're also far more likely to get useful help using KVM, either 
> from the list or from other sources, such as the Red Hat or Fedora 
> documentation.

 From the KVM site (http://www.linux-kvm.org/page/Management_Tools) that 
has a RedHat logo, there is a list of management interfaces, including 
VMM (Virtual Machine Manager -- https://virt-manager.org/screenshots/ ) 
that also appears to be a Red Hat entity.  Anyone using VMM?  VMM 
appears to allow a true host OS (supervisor, not hypervisor) with the VM 
("hypervisor") running under the OS (as with VMWare workstation/player 
or VirtualBox), thus booting an OS, not a hypervisor that actually 
provisions for guest supervisors.  Is this correct?

Yasha Karant

Re: two mysteries

[David Sommerseth]

On 25/01/16 19:32, Yasha Karant wrote:
> On 01/24/2016 06:06 PM, Lamar Owen wrote:
>> On 01/23/2016 01:30 PM, Yasha Karant wrote:
>>> Perhaps someone else has experienced what I related below and can comment
>>> -- SL 7x.
>>>
>>> 1.  ... For 802.3, I prefer to use a manual configuration, not 
>>> NetworkManager.
>>
>> For a dynamic connection even with a wired Ethernet you should use the
>> supported NetworkManager stack, your personal preferences aside.  NM works
>> and doesn't require munging for a simple DHCP wired connection.
>>
>>>
>>> 2.  ...Note that I must use MS Win to work with these devices as the
>>> application software for the device in question is *NOT* available for
>>> linux, the device is proprietary (no source code available), and
>>> CrossOver/Wine does not support USB -- forcing the use of a VM running a MS
>>> Win gues
>>
>> Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB
>> passthrough works very well with Windows 7 running in a KVM virtual machine
>> on my laptop.  It just works, and it's already part of SL; why not use it? 
>> Performance is very good in my experience, and I'm running a few pieces of
>> software in Win 7 for the same reasons as you.  You're also far more likely
>> to get useful help using KVM, either from the list or from other sources,
>> such as the Red Hat or Fedora documentation.
> 
> From the KVM site (http://www.linux-kvm.org/page/Management_Tools) that has a
> RedHat logo, there is a list of management interfaces, including VMM (Virtual
> Machine Manager -- https://virt-manager.org/screenshots/ ) that also appears
> to be a Red Hat entity.  Anyone using VMM?  VMM appears to allow a true host
> OS (supervisor, not hypervisor) with the VM ("hypervisor") running under the
> OS (as with VMWare workstation/player or VirtualBox), thus booting an OS, not
> a hypervisor that actually provisions for guest supervisors.  Is this correct?

This was a bit confusing for me (getting late, so probably stupid to reply now).

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.


I hope this gave a broader perspective.


--
kind regards,

David Sommerseth

Re: two mysteries

[Lamar Owen]

On 01/23/2016 01:30 PM, Yasha Karant wrote:
Perhaps someone else has experienced what I related below and can 
comment -- SL 7x.


1.  ... For 802.3, I prefer to use a manual configuration, not 
NetworkManager.


For a dynamic connection even with a wired Ethernet you should use the 
supported NetworkManager stack, your personal preferences aside.  NM 
works and doesn't require munging for a simple DHCP wired connection.




2.  ...Note that I must use MS Win to work with these devices as the 
application software for the device in question is *NOT* available for 
linux, the device is proprietary (no source code available), and 
CrossOver/Wine does not support USB -- forcing the use of a VM running 
a MS Win guest.


Neither VMware nor VirtualBox ship as part of SL.  KVM does, and USB 
passthrough works very well with Windows 7 running in a KVM virtual 
machine on my laptop.  It just works, and it's already part of SL; why 
not use it?  Performance is very good in my experience, and I'm running 
a few pieces of software in Win 7 for the same reasons as you.  You're 
also far more likely to get useful help using KVM, either from the list 
or from other sources, such as the Red Hat or Fedora documentation.

two mysteries

[Yasha Karant]

Perhaps someone else has experienced what I related below and can 
comment -- SL 7x.


1.  Over break, an SL7x machine I had configured for a colleague had 
ceased to work.  There was a power outage and upon reboot, the Dell BIOS 
was not recognizing the Nvidia video card -- somehow the Dell BIOS had 
changed state.  Upon physical removal of the Nvidia card and yum erase 
of the relevant Nvidia X11 driver RPMs, X11 was working, but now there 
was no network connectivity.  I routinely run gkrellm to get a quick 
view of machine function; in this case, the 802.3 NIC was transmitting 
but not receiving any response from the central DHCP server.  This was 
working before the break (no static IPs generally are allowed by the 
university IT to centralize and police all services, both for 802.11 and 
802.3) .  After some investigation, I discovered that the DHCP, etc., 
services were no longer trusted by the SL7 firewall.  I reconfigured to 
trusted.  The 802.3 NIC that had been identified by gkrellm as eml now 
is P2P1 and the system connected; the end user was satisfied.  The 
central IT claims to have made no changes (no new CA, etc.).  Any ideas 
as what might have happened?  Could Network Manager have activated?  For 
802.3, I prefer to use a manual configuration, not NetworkManager.


2.  The other issue concerns VMware and VirtualBox -- not EL per se, but 
someone on this list may have experience with the problem. Because of a 
lack of licensing funds, I am using VMware Player and VirtualBox (not 
simultaneously).My default is VirtualBox, but if necessary and as a 
test, VMWave Player.  Both are running images of MS Win 7 Pro that are 
simply the transformation of one virtual machine guest file format to 
the other.  Neither connects to the 802.11 host NIC and thus neither has 
Internet connectivity (a separate matter).  Both have bidirectional 
shared folders with the host.  Both have the extension packs, tool sets, 
etc., installed as specified by each.  VMware is able to use all USB 
devices that I connect to the host.  However, VirtualBox is not, 
producing an error that has been observed many times on posts I found on 
the web (Failed to create a proxy device for the USB device. (Error: 
VERR_READ_ERROR) ).   Has anyone on this list observed the VirtualBox 
USB issue?  USB 2 service is installed in for VirtualBox, vboxusers has 
the correct user entry, etc.  Some USB devices work, others do not -- 
but the same device that did not work for VirtualBox did work for 
VMWare.   Note that I must use MS Win to work with these devices as the 
application software for the device in question is *NOT* available for 
linux, the device is proprietary (no source code available), and 
CrossOver/Wine does not support USB -- forcing the use of a VM running a 
MS Win guest.


Yasha Karant


.