jail_set_vimage - Vimage under new jails
julian at elischer.org
Tue Jul 15 00:15:04 UTC 2008
Julian Elischer wrote:
> James Gritton wrote:
>> I've finished the merge of jail_set and Vimage. This uses the
>> name-based jails instead of the jail-similar vimage frameworks, with
>> Vimage's VNET stuff being enabled in a jail with the "vnet" parameter
>> (in this scenario, it's optional whether a jail has its own network
>> stack or just inherits its parent's). Once such a jail is set up, it
>> behaves in the same way as a vimage does, as far as the network stack
>> separation goes. The only difference is in administration, which uses
>> the jail framework.
I liked the hierarchical feature of the vimage system.
when you say "name based", do you mean the code you refer to is
>> In addition to the main changes of moving vnet from struct vimage to a
>> prison service, some related changes are:
>> * Future-compat hooks for the vprocg and vcpu stuff has been removed -
>> when such stuff is added, it would belong under the jail umbrella.
>> This means that the three subsystems V_NET, V_PROCG, and V_CPU are
>> reduced to one subsystem V_VNET, which actually amounts to no
>> subsystems at all anymore.
>> * The IMUNES_SYMLINK_HACK has gone away, though I suppose it could
>> come back.
>> * The V_hostname (and G_hostname and *_domainname) stuff has been
>> removed, in favor of the way jail_set handles virtual hostnames.
>> * The jail_set userspace changes to jail programs have been added.
>> * The vimage program has been superseded by the vifmove program. It
>> uses a struct vifmovereq, which replaces the obsolete struct vi_req.
>> * Some other bits I mentioned (simpler sysctls and a locking fix) have
>> found their way in. Probably also some other bits I haven't
>> The VNET modularization is still that way it was. While vnet has
>> become a prison service, essentially a jail module, the network
>> modules that plug in to vnet know nothing of the jail situation, and
>> remain VNET modules. The vnet pointers still live in interfaces,
>> sockets, threads, wherever they used to be. The places that had
>> vimage pointers now have prison pointers, but there weren't very many
>> of those.
>> This is in the perforce tree //depot/user/jamie/jail_set_vimage, and a
>> patch is at http://gritton.org/jail_set_vimage.diff.
>> This is my vision of the future direction of Vimage, and of course I hope
>> it becomes "the" vision. In other words: Marko and Julian, give it a try
>> and let me know what you think.
> This is cool stuff..
> You have no idea how good it is to have other people looking at
> the Vimage code with fresh eyes and thoughts.
> Vimage importation was delayed for a number of reasons, some technical
> as people brought up issues, but ONE of them was I saw this on the
> side and after thinking about our talk at BSDCan I thought it would
> be better to see what came from it. (Also because both Marko and
> I ran out of hours for awhile while $LIFE intervened in one way
> or another.
> It was pointed out at BSDCan that "BSD Jails" is a kind of
> "unofficial trade name" that BSD has that is well known and
> respected and that keeping The "Jail" name maybe with
> "new and improved, now with 'VNET' support for whiter whites"
> might be a smart move from the PR point of view.
> One question I have is to do with Jails in general.
> There are a lot of other patches floating around with
> jails features. How many of those patches are going to be
>> - Jamie
>> freebsd-virtualization at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-virtualization-unsubscribe at freebsd.org"
> freebsd-virtualization at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe at freebsd.org"
More information about the freebsd-virtualization