User-mode Linux kernel port

On Fri, Feb 23, 2007 at 01:13:28PM -0600, Alex Strasheim wrote:
> Are there any links available to information about how KVM and UML are 
> going to be integrated?  I've just heard that this is going to happen 
> down the road, and I'm trying to get a handle on it.

I gave a talk on this at LCA, and have been lax in getting my slides online.

> Would that take us to a world in which UML performs about as well as 
> xen, a linux kernel on the host machine does the same thing a xen 
> hypervisor does (along with all the other stuff a linux kernel does), 
> and uml is no longer a different compile target for the kernel?

If you are talking about the ARCH=um business, UML will always be a
different compile target.

However, the rest of that will be true (with some crossed fingers on
the performance part since I have no numbers yet).

> My vague impression is that KVM will handle the VT stuff, and UML will 
> handle device virtualization, and provide the command line interface to 
> guest systems in pretty much the same way it does now.
> 
> Am I way off base here?

UML will look exactly the same as it does now, and will provide all
the same functionality in pretty much the same way.  KVM, plus a
yet-to-be-written userspace controller, together will handle the VT
stuff.

				Jeff

-- 
Work email - jdike at linux dot intel dot com

Jeff Dike <jdike@...> writes:

> However, the rest of that will be true (with some crossed fingers on
> the performance part since I have no numbers yet).

How much slower is UML than Xen anyway?

I've always found it pretty good.


By the way... I've been trying to setup a UML based startup and I
wanted to share one of the things that are really important to me
about UML.

Because it's a process I can use normal accounting to charge out
UMLs. I can't do that with Xen or KVM as far as I understand it.

Worth remembering what a boon having the UML represented as a real
process is.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   for all your tapsell ferrier needs

On Fri, Feb 23, 2007 at 10:26:17PM +0000, Nic James Ferrier wrote:
> By the way... I've been trying to setup a UML based startup and I
> wanted to share one of the things that are really important to me
> about UML.
> 
> Because it's a process I can use normal accounting to charge out
> UMLs. I can't do that with Xen or KVM as far as I understand it.

You can with KVM - this is one of the beauties of it.  UML/VT will start
as a normal process, which does some kvm magic to enter VT and start
the UML kernel as a guest.  This process will be charged for
everything the guest does.

> Worth remembering what a boon having the UML represented as a real
> process is.

Yup.

				Jeff

-- 
Work email - jdike at linux dot intel dot com

On Fri, Feb 23, 2007 at 01:10:53PM -0500, Jonas Meyer wrote:
> I just tested it, and exactly the same thing happens.  Does anybody have
> any ideas?  This is kind of annoying.
> 

I'd write a decent script to throw into /etc/network/if-up.d to
give you some eyes and ears on what's taking place and how long
it's taking. A good start would even be to just change your 
interfaces file to read [untested]:

iface eth0 inet static
         address 192.168.1.4
         netmask 255.255.255.0
         up strace -o /tmp/route-host -f -s 256 -t route \
			add -host 192.168.1.2 dev eth0
         up strace -o /tmp/route-gw -f -s 256 -t route \
			add default gw 192.168.1.2


If it turns out that the route command is the problem (very unlikely 
in my opinion), then you can install the iproute package and use the 
ip command to set up the route. This may or may not work.

As things stand at the moment, there's just way too many variables 
in the mix to start guessing at what the answer is. I partially 
replicated your setup on a debian box, and there were no glaring 
problems. More evidence is required - for my feeble mind at least.

On Fri, Feb 23, 2007 at 06:53:31PM +0000, jez wrote:
> On Fri, Feb 23, 2007 at 01:10:53PM -0500, Jonas Meyer wrote:
>
> I'd write a decent script to throw into /etc/network/if-up.d to
> give you some eyes and ears on what's taking place and how long
> it's taking. A good start would even be to just change your 
> interfaces file to read [untested]:
> 
> iface eth0 inet static
>          address 192.168.1.4
>          netmask 255.255.255.0
>          up strace -o /tmp/route-host -f -s 256 -t route \
> 			add -host 192.168.1.2 dev eth0
>          up strace -o /tmp/route-gw -f -s 256 -t route \
> 			add default gw 192.168.1.2
> 
> 

Err [still untested]. Might need to make that /usr/bin/strace just in
case.

On Thu, Feb 22, 2007 at 05:09:47PM -0500, Jonas Meyer wrote:
> then when I screen in to the guest and attempt to login, I have a
> problem.  I type my user name at the prompt and hit return, and I get an
> immediate "Login timed out after 60 seconds".  It is impossible to type
> the password before this message appears.

Can I have the filesystem that does this?

				Jeff

-- 
Work email - jdike at linux dot intel dot com

ok, it seems as though I hadn't rebooted since I created the group
umlusrs and for some reason while I was in the /etc/groups file as
being a member of umlusrs, that didn't take effect ... I had to
reboot.  Does anyone know why that is?  (newbie alert, newbie alert!)

After reboot I had to reset the permissions on /dev/net/tun to 660 but
then it all worked fine.  how can I get the permissions 660 to stick
on /dev/net/tun?

Respectfully,
Christopher Taylor

chtaylo3@... said:
> ok, it seems as though I hadn't rebooted since I created the group
> umlusrs and for some reason while I was in the /etc/groups file as
> being a member of umlusrs, that didn't take effect ... I had to
> reboot.  Does anyone know why that is?  (newbie alert, newbie alert!)

permissions are granted at login time. You didn't need to reboot, just
logout and log back in.

If you want to know what permissions you have, use id(1), not grep
/etc/group.

> After reboot I had to reset the permissions on /dev/net/tun to 660 but
> then it all worked fine.  how can I get the permissions 660 to stick
> on /dev/net/tun?

If the permissions change with reboot then they're probably put there by
udev. 

Jason

I've been out of UML for a while, but perhaps I can still throw =
something
useful in the mix.

rh

#!/bin/bash
# =20
# tuntap script
#
# Create and configure the tap devices for UML users
# This script will do a maximum of 10 (0-9), but can easily be changed
#
# You can delete (or rename) the "uml_net" helper to remove a security =
hole.
# UML users will not be able to reconfigure their network TAP device and
# will not be able to use another. As far as I know?!?!?!?
#
# The UMLaddr should be "real" so the UML server can be seen.
# The HOSTaddr can be "fake" or any address you like.  You can conserve =
IP
# addresses this way.  Of course, they can be real as well.
#
# The UML client is setup the normal way.  The default route gateway is
# the IP address for eth0.
#
# I use the following example ethernet specification on my command line:
#           eth0=3Dtuntap,tap0,FE:FF:C0:A8:01:C8,10.50.15.200
#
# 2004.08.13.Richard Hagemeyer,VE3UNW	Initial script  (a Friday)
#
#########################################################################=
###
##############################
#
#  Some variables to keep things easy
#
NETWORK=3D"192.168.1.0/24"						#
Your network address/netmask
UMLaddr=3D"192.168.1.20"		#ex: 192.168.1.200-209			# IP
addr prefix of the UML end
HOSTaddr=3D"10.50.15.20"		#ex: 10.50.15.200-209			# IP
addr prefix of the HOST end
UMLuser=3D"uml"			#ex: uml0,uml1,eml2....			#
The uml username "prefixes"
ETH=3D"eth0"								#
The real ethernet device

route del -net 169.254.0.0/16						#
Don't need this route
modprobe tun								#
Get the tun module loaded
echo 1 > /proc/sys/net/ipv4/ip_forward					#
Allow the host to forward

for i in 0 1 2 3 4 ; do							#
Loop to create devices/users
	tunctl -u ${UMLuser}${i} -t tap${i}				#
Create the TAP device
	ip link set dev tap${i} up					#
Add the TAP device
	ifconfig tap${i} ${HOSTaddr}${i} netmask 255.255.255.255 up	#
Configure the TAP device
	route add -host ${UMLaddr}${i} tap${i}				#
Need a route to the device
	route del -net ${NETWORK}					#
Delete the default route created
	echo 1 > /proc/sys/net/ipv4/conf/tap${i}/proxy_arp		#
Allow dynamic configuration
	arp -Ds ${UMLaddr}${i} ${ETH} pub				#
eth0 should respond to the UMLip
done

route add -net ${NETWORK} ${ETH}					#
Add the default route back

ifconfig								#
See what we've done
route -n
arp -n

On Fri, Feb 23, 2007 at 03:39:32AM +0000, Jason Lunz wrote:
> chtaylo3@... said:
> 
> > After reboot I had to reset the permissions on /dev/net/tun to 660 but
> > then it all worked fine.  how can I get the permissions 660 to stick
> > on /dev/net/tun?
> 
> If the permissions change with reboot then they're probably put there by
> udev. 
> 

For FC5, fixing this essentially amounts to changing something like:
    
    KERNEL=="tun",               NAME="net/%k"

to 

    KERNEL=="tun",       NAME="net/%k", GROUP="umlusrs", MODE="0660"

somewhere under /etc/udev/rules.d. Just grep for 'tun' under said
directory and all should be relatively clear. 

Oh yeah, and the permissions take effect when the tuntap module is
loaded, not when the system boots.