jail_set_vimage - Vimage under new jails

[Julian Elischer]

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
not hierarchical?

>>
>> 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
>>  mentioned.
>>
>> 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
> incorporated?
> 
> Julian
> 
> 
> 
> 
> 
> 
>>
>> - Jamie
>> _______________________________________________
>> freebsd-virtualization at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>> To unsubscribe, send any mail to 
>> "freebsd-virtualization-unsubscribe at freebsd.org"
> 
> _______________________________________________
> freebsd-virtualization at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscribe at freebsd.org"