From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 9 23:30:44 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDA4F106566B for ; Mon, 9 Jun 2008 23:30:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id A041C8FC1B for ; Mon, 9 Jun 2008 23:30:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 4086A2415; Mon, 9 Jun 2008 16:30:44 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 11CFD2D600E; Mon, 9 Jun 2008 16:30:44 -0700 (PDT) Message-ID: <484DBD23.6000501@elischer.org> Date: Mon, 09 Jun 2008 16:30:43 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Miroslav Lachman <000.fbsd@quip.cz> References: <484CC690.9020303@elischer.org> <20080609174826.Q83875@maildrop.int.zabbadoz.net> <484D8EDD.3040103@elischer.org> <484DA546.9060005@gritton.org> <484DAB87.6040706@elischer.org> <484DB357.80103@quip.cz> In-Reply-To: <484DB357.80103@quip.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-jails@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: kinda headsup.. X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jun 2008 23:30:44 -0000 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 http://wiki.freebsd.org/Jails 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. >