kinda headsup..

Julian Elischer julian at
Mon Jun 9 23:30:44 UTC 2008

Miroslav Lachman wrote:
> Julian Elischer wrote:
>> James Gritton wrote:
>>> Could we have a list of what isn't expected to actually commit?  So 
>>> the scheduler stuff is out.  Is that all of the struct vcpu?  Parts 
>>> of struct vprocg?  I see some scheduling bits in both.
>>> Aside from vnet/vinet and the doomed scheduling bits, I see not much 
>>> besides the hostname, domain name, and morphing symlinks.  Are these 
>>> staying?  The hostname is already in jails ,and the domainname makes 
>>> sense in my new jail framework - the morphing symlinks might be 
>>> something best left for later.
>> domain name and hostname both stay..
>> Hostname is tricky because both jail and vimage expect to change it..
>> though jail only really expects it to be virtualised to the user
>> rather than REALLY VIRTUALISED.
>> The morphing symlinks are an experimental feature.
>> The verio guys have some work in that direction too that they want to
>> work on.... hmmm that's not you is it?
> Are there somebody who can shed some light on "what is planned in Jail / 
> Vimage" for near future? I read many times "we talked about it at the 
> developers summit" or "we will publish them on a wiki", but it is a long 
> time ago and real informations are still kind of secret.
> I am working on page and I will be glad to 
> publish as more informations as I can.

I am sorry that I didn't realise that page existed earlier,
and it reminds me that maybe we should be using the jails mailing list 
if we plan to make this all merged in with jails..

> For example, what is morphing symlinks? Or I know Verio has VPS on 
> FreeBSD with fair-share resource management - are there some plans to 
> have it in the src tree? Are you in contact with them?

I will try edit the (2 hour) video of the discussion on the topic and 
get it up on the web asap..

basically we are trying to pull everyone together onto the
basis of a merged vimage/jail implementation.
It seems a big job, having read your wiki page!

> I think there are many developers working / thinking on some 
> virtualization stuff but diverged and users (potential testers) know 
> almost nothing about this 'work-in-progress'.

yes I agree.

>> Loadavg etc. is not "out for ever" just "not in the first commit set."
>> as they have not been extensively tested, and probably need more work.
> What we can expect from loadavg and "scheduler" stuff?

being able for example to see which jails have which load-averages
and thus being able to see who is using the resources.

Scheduler partitioning is a bigger problem and I wouldn't care to
try do it yet..

The Verio guys have some interesting stuff in this direction which
may be useful to us but we need to do some more talking.

>>> Ideally, for integration purposes, the vnet/vinet would hang off 
>>> jails that have pretty much the same capability as the vimage 
>>> structure, and then other bits could be added later.  I don't want to 
>>> worry about trying to integrate features that aren't in the final cut 
>>> anyway.
>> the aim is that vimage and jail structures would merge.
> Are there some good examples of how things "will work" in vimage+jail 
> world? (not from developers view, but from users view)

Not such a document at the moment.
but I plan to try write some docs over the next couple of weeks..

basically, it is much like being in a jail except that you ahve your
own firewall, routing tables and interfaces. You can run your own
ipsec tunnels and whatever. You can also set the tcp sysctls yourself
(for example) to turn on or off things like mtu discovery or rando
portnumbers.. (etc.etc.)

you can also make a jail inside your jail if you want to and let it 
run in a different virtual machine.. with a different IP space etc.

which brings up a point which is that we need to provide a way
to limit the damage that a vimage based jail can do by assigning
Ip addresses.. i.e. we need to add some constraint based on the
current jail code's ip constraints to allow a sub jail
to only be allowed to set some addresses... We discussed this
at BSDCan but didn't resolve it.


More information about the freebsd-virtualization mailing list