From pred at telenet.be Wed Sep 1 08:10:07 2010 From: pred at telenet.be (pred@telenet.be) Date: Wed Sep 1 08:10:16 2010 Subject: kern/147162: [jail] [panic] Page Fault / Kernel panic when jail starts on boot Message-ID: <201009010810.o818A54M006693@freefall.freebsd.org> The following reply was made to PR kern/147162; it has been noted by GNATS. From: pred@telenet.be To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/147162: [jail] [panic] Page Fault / Kernel panic when jail starts on boot Date: Wed, 1 Sep 2010 09:55:47 +0200 (CEST) ------=_Part_235589_241905550.1283327747791 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just a quick note that I've upgraded this server to 8.1-RELEASE and re-enab= led the PF routing rule that was causing the kernel panic.=20 The server did a clean reboot so it seems this problem is no longer present= in 8.1-RELEASE, which is ofcourse=C2=A0good news.=20 ------=_Part_235589_241905550.1283327747791 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Just a quick note that I've upgraded this server to 8.1-RELEASE and re-enabled the PF routing rule that was causing the kernel panic.

The server did a clean reboot so it seems this problem is no longer present in 8.1-RELEASE, which is ofcourse good news.

------=_Part_235589_241905550.1283327747791-- From jamie at FreeBSD.org Thu Sep 2 23:13:05 2010 From: jamie at FreeBSD.org (Jamie Gritton) Date: Thu Sep 2 23:13:12 2010 Subject: First stab at a new jail(8) Message-ID: <4C802828.8030404@FreeBSD.org> I've got code for a config-based jail(8) at http://people.freebsd.org/~jamie/jail.tbz . It drops in under /usr/src/usr.sbin, but is a big enough change from the current sources that I didn't bother with a diff. I haven't yet updated the man page for it, so I'll give a quick overview here... Its syntax is an extension of the current jail(8), which is itself an extension of the previous jail(8). In addition to starting a single jail with "-c name=value ... command=do something here" or modifying one with "-m name=value ...", you can just specify a single jail name on the command line and it will operate on that jail from the config file. So "jail -c foo" will start up the jail "foo" from /etc/jail.conf (or whatever file you specify with "-f"). Just saying "jail -c" will start up all jails in the config file if they aren't already running. More generally, when running from the config file you can do the following: jail -c [jailname] Start the specified jail, or all jails. Note that is a single argument. You can't start multiple jails at once this way (e.g. jail -c firstjail secondjail), because if you put two arguments, jail(8) will think you're specifying a jail on the command line with parameters like "firstjail" and "secondjail". You can start multiple jails with simple wildcards: specifying "foo.*" will start jails that start with "foo.". This isn't a regular expression or globbing, but wildcarding entire name components. jail -m [jailname]. Modify parameters of the specified jail, or all jails. It will set the jail to whatever the current parameters in the config file are. Some parameters, like "path", can only be set on jail startup. If these are the same in the config file and the currently running jail, it will silently skip them. If they're different, it will report and error and not update the jail. jail -r In this case, the jail name isn't optional, because I thought it would be too easy to accidentally remove everything. If you want to remove all jails, you can say "jail-r '*'". If you specify a wildcard, it will apply only to jails in the config file. But unlike -c and -m, if you specify a single jail, it will first look it up in the config file but then back up to looking at currently running jails. Thus "jail -r 47" will remove the jail with jid 47 just like it currently does, unless you have a jail called "47" in the config file. jail -R Similar to jail -r, but this doesn't use the config file at all. The jailname must be the name or jid of a running jail, or a wildcard. In this case, the wildcards also apply to running jails, so "jail -R '*'" will remove all current jails. Since the config file isn't used, no shutdown scripts will be run and every jail will be removed "hard". jail -cm [jailname] Like the "-cm" flags of the current version, this will create a jail if it doesn't exist, or update it if it does exist. This will make sure every jail in the config file is up and running. jail -rc [jailname] This combination of -r and -c restarts jails - first the entire remove procedure then the entire create procedure. jail -mr [jailname] jail -cmr [jailname] These variations on -m and -cm will restart a jail if necessary - instead of exiting on an error when attempting to change a create-only parameter, it will restart the jail. The -cmr option, which can also create new jails, can make sure every jail is in exactly the same state as specified in the config file. I've described the format of the config while a while back, and I'm including a small sample config file in the tarball. Right now it handles all the regular jail parameters, as well as some internal pseudo-parameters mostly taken from the current rc.d/jail: allow-dying Same as the -d flag, allow modifying a dying jail. depend Make a jail's startup depend on another jail. The jail won't be started until every jail it depends on is successfully started first. If you specify starting a single jail on the command line and it has dependencies, its dependencies are implicitly included. If you modify a jail with dependencies, it will make any changes in dependency order, but will not actually modify jails that aren't specified. The dependencies apply in reverse order for removing jails. ip_hostname Same as the -h flag, implicitly set the jails' ip4.addr and ip6.addr parameters based on a DNS lookup of the host.hostname parameter. exec.prestart exec.start command exec.afterstart exec.poststart The same as used in rc.d/jail, except that there's also a "command" parameter as in the current jail(8). The specified programs are executed in the order given, and each parameter can specify multiple programs (using the "+=" specifier in the config file). The jail is created after exec.prestart is run. The exec.start, command, and exec.afterstart programs are run inside the jail; the exec.prestart and exec.poststart programs are run in the host system. For backward compatibility and convenience, "command" stops the parsing of parameters on the command line, and gives all remaining arguments to the program. exec.prestop exec.stop exec.poststop The same as used in rc.d/jail. The jail is removed after exec.stop completes (and after sending all jailed processes SIGTERM and waiting for them to die). The exec.stop program is run inside the jail; the exec.prestop and exec.poststop programs are from in the host system. exec.clean exec.jail_user exec.system_jail_user exec.system_user Similar to the -l, -u, and -U options. exec.clean is the same as -l, except that it doesn't require -[uU] to be set as well, but instead uses the current user (passwd lookup by uid) if no user is specified. If people aren't using fancy permission models or making jail(8) setuid, this user will be root. exec.jail_user is the same as the -U option, and specifies a user to look up in the jail's passwd file when running a program inside the jail. exec.system_jail_user is a boolean that says to look up exec.jail_user in the host system's passwd file instead; specifying both exec.jail_user and exec.system_jail_user is the equivalent of the -u option. exec.system_user specified a user for programs that run outside the jail, e.g. from exec.prestart. It has no analog in the current jail(8). I haven't yet handled the other rc.d/jail parameters. Those are the next thing for me to work on, but I think the current version is at least useful enough to start looking at. Most of the things the rc.d/jail does can be handled to at least some degree by specifying exec.prestart and exec.afterstop programs. - Jamie From linimon at FreeBSD.org Mon Sep 6 07:18:37 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Sep 6 07:18:43 2010 Subject: kern/147162: [jail] [panic] Page Fault / Kernel panic when jail starts on boot Message-ID: <201009060718.o867IaxD045689@freefall.freebsd.org> Synopsis: [jail] [panic] Page Fault / Kernel panic when jail starts on boot State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Mon Sep 6 07:18:03 UTC 2010 State-Changed-Why: Submitter notes that this seems to be fixed on 8.1. http://www.freebsd.org/cgi/query-pr.cgi?pr=147162 From bugmaster at FreeBSD.org Mon Sep 6 11:06:58 2010 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 6 11:08:43 2010 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <201009061106.o86B6woN011811@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/149050 jail [jail] rcorder ``nojail'' too coarse for Jail+VNET s conf/142972 jail [jail] [patch] Support JAILv2 and vnet in rc.d/jail o conf/141317 jail [patch] uncorrect jail stop in /etc/rc.d/jail o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 7 problems total. From freebsd at snap.net.nz Fri Sep 10 04:59:01 2010 From: freebsd at snap.net.nz (Peter Toth) Date: Fri Sep 10 04:59:04 2010 Subject: Jail hot migration Message-ID: <4C89B3DF.7050004@snap.net.nz> Hi guys, I was lately thinking around jail hot-migration feature where one jail could be moved from one host to another without shutting it down, something like vmotion in VMware world. The storage layer should be easy with zfs send and receive or some form of shared storage. The tricky part would be a memory copy from one node to another and also the CPU handling. Anyone has an idea how this could be achieved? I guess it would require a kernel module which could take care of memory reservations and a daemon to copy and incrementally sync the jails memory across. Then also there is the CPU problem.. Sounds like a fair amount of work and development. All comments are welcomed! Cheers, Peter From andrew.hotlab at hotmail.com Fri Sep 10 12:48:45 2010 From: andrew.hotlab at hotmail.com (Andrew Hotlab) Date: Fri Sep 10 12:48:47 2010 Subject: Jail hot migration Message-ID: > Date: Fri, 10 Sep 2010 16:28:15 +1200 > From: freebsd@snap.net.nz > To: freebsd-jail@freebsd.org > Subject: Jail hot migration > > Hi guys, > > I was lately thinking around jail hot-migration feature where one jail > could be moved from one host to another without > shutting it down, something like vmotion in VMware world. > > The storage layer should be easy with zfs send and receive or some form > of shared storage. The tricky part would > be a memory copy from one node to another and also the CPU handling. > > Anyone has an idea how this could be achieved? I guess it would require > a kernel module which could take care of memory > reservations and a daemon to copy and incrementally sync the jails > memory across. > > Then also there is the CPU problem.. > > Sounds like a fair amount of work and development. > > All comments are welcomed! > Well, I'm not a developer, but I think that the jail framework surely deservestobe evolved in something more "friendly" from a sysadmin's point of view. The architecture is great, and that's just enough to consolidate a lot of workloads,but for some applications there are features (resource containers, offline andonline migration of jails, etc.) that need to be improved to be affordable in aproduction environment. I think that a lot of work is getting done (resource container and virtualizationstack projects have ben just sponsored by the FreeBSD Foundation), I do not knowhow much time will take to reach a complete "business-ready" virtualizationframework, neither if they are on the right path, but I'm quite confident, because I'msure that the simplicity of the FreeBSD solution will rule any other virtualizationframework out there. As the feature you are asking for, I think that resource containers and offlinemigration should be considered first, because overall they'll have more impact onbusiness environments. Further, I believe that building a hot migration procedureworking with third-party running applications will be a very complex task to achieve,maybe too expensive at this time, compared to the amount of work required. That's an interesting argument, I'll be glad if more member of the Community willcontribute with their considerations. Sincerely. Andrew From gnrp at gnrp.in-berlin.de Fri Sep 10 15:14:26 2010 From: gnrp at gnrp.in-berlin.de (Julian Fagir) Date: Fri Sep 10 15:14:29 2010 Subject: Jail hot migration In-Reply-To: <4C89B3DF.7050004@snap.net.nz> References: <4C89B3DF.7050004@snap.net.nz> Message-ID: <20100910164222.31ae35d8@adolfputzen> Hi, correct me if I'm wrong, I never actually worked with VMware (only a bit with Xen) but read a bit about the theory behind it. I don't think this can be as easilly achieved as it is with VMware (or Xen). > I was lately thinking around jail hot-migration feature where one jail > could be moved from one host to another without > shutting it down, something like vmotion in VMware world. With paravirtualisation, you have the machine in a 'container', the host system does not know except for the interfaces what the guest system is doing with the ram it has reserved. So moving a machine is 'not more' than copying a bunch of memory to another machine and transferring the interfaces. Jails are no virtualisation, in the end, what makes up a jail, are only a few data structures. Moving a jail would mean to transfer all these single fragments of data reasonably to another machine. I.e. you would have to transfer all the kernel-things a process does to another machine. How sould locks or access to system ressources be managed when transferring to another machine? I don't even know if the kernel does know all the stuff about a process on a central place to do this transfer. > The storage layer should be easy with zfs send and receive or some form > of shared storage. The tricky part would > be a memory copy from one node to another and also the CPU handling. Afaik you have containers for the machines with VMware/Xen, as the host system does not have to know the file system underneath. Again, transferring/sharing those is simple as it is only one file to the host system. With jails, you only have mount points. What happens to locks and other fs-specific stuff, ACLs etc (ok, zfs perhaps handles that)? But you can't rely on the other system having the same filesystem underneath. Also, sharing file systems is not as easy as sharing a single file (without caring for permissions). You see the problem when you just look at all the different ways for locking over the network... > Anyone has an idea how this could be achieved? I guess it would require > a kernel module which could take care of memory > reservations and a daemon to copy and incrementally sync the jails > memory across. In case you could build a jail-transportation, a framework for transferring a single process to another machine would be more appropriate imho as more generic and simpler. Then just adding the possibility of jailing such a process is not much work. A single example why the whole target cannot be achieved easily: Imagine a program which writes its pid into a lockfile. As jails and host share the pids, this pid could be already in use by the other host you want to transfer the jail to. So what to do know? Just change the pid? Then the process would be confused and possibly die or malfunction. Not changing the pid would not be possible as then there would be two processes with the same pid. Sure, remapping pids would be possible but not within the current jails and the complications could be great (if the process sees another pid than the host-system, what will rc-files do which check lockfiles?). And there are other cases where processes do things the kernel cannot predict and so cannot transfer that easily. Also, the nic-transfer would make problems. When you usually have a bridge or so with Xen/VMware, you have real interfaces or aliases on a BSD-machine, how should they be taken out of service in time and back to service without problems (I often have cases when just taking up an alias does not work)? Jails are no virtualisation. They are an 'extended chroot'-environment and thus moving a jail is like moving a working machine except for the system drivers. I hope this was not all too wrong. Regards, Julian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20100910/ff784cd8/signature.pgp From freebsd at deman.com Fri Sep 10 15:17:15 2010 From: freebsd at deman.com (Michael DeMan) Date: Fri Sep 10 15:17:20 2010 Subject: Jail hot migration In-Reply-To: <4C89B3DF.7050004@snap.net.nz> References: <4C89B3DF.7050004@snap.net.nz> Message-ID: <1FD7CB89-8F7F-4E8B-A507-16E72784D906@deman.com> There are other issues too - like network I/O, particularly dealing with established TCP connections? Basically, you have to retain the in-state 'memory' of the machine being migrated from, while also letting all those 3rd party sockets know that everything is okay Thus far, I have yet to see any vendor that delivers 'zero downtime' virtual migrations. There is always downtime - question is whether it is costed in terms of milliseconds, seconds, minutes, hours, or worse? Definitely worth doing though. Personally, I have found value in running OSPF/BGP on the jail host itself, and putting the actual jails on the loopback interface. It certainly does not solve the problem in terms of 'minute' by any means, but having the Iayer-3 component work automatically definitely helps. I think this idea is a worthwhile goal, but I would much, much rather see NFSv4 and ZFS wrapped up first. On Sep 9, 2010, at 9:28 PM, Peter Toth wrote: > Hi guys, > > I was lately thinking around jail hot-migration feature where one jail > could be moved from one host to another without > shutting it down, something like vmotion in VMware world. > > The storage layer should be easy with zfs send and receive or some form > of shared storage. The tricky part would > be a memory copy from one node to another and also the CPU handling. > > Anyone has an idea how this could be achieved? I guess it would require > a kernel module which could take care of memory > reservations and a daemon to copy and incrementally sync the jails > memory across. > > Then also there is the CPU problem.. > > Sounds like a fair amount of work and development. > > All comments are welcomed! > > Cheers, > Peter > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" From freebsd at deman.com Fri Sep 10 15:17:15 2010 From: freebsd at deman.com (Michael DeMan) Date: Fri Sep 10 15:17:20 2010 Subject: Jail hot migration In-Reply-To: References: Message-ID: <1C266502-EAF4-4211-93E1-83BA1090C94E@deman.com> See inline. On Sep 10, 2010, at 5:36 AM, Andrew Hotlab wrote: > >> Date: Fri, 10 Sep 2010 16:28:15 +1200 >> From: freebsd@snap.net.nz >> To: freebsd-jail@freebsd.org >> Subject: Jail hot migration >> >> Hi guys, >> >> I was lately thinking around jail hot-migration feature where one jail >> could be moved from one host to another without >> shutting it down, something like vmotion in VMware world. >> >> The storage layer should be easy with zfs send and receive or some form >> of shared storage. The tricky part would >> be a memory copy from one node to another and also the CPU handling. >> >> Anyone has an idea how this could be achieved? I guess it would require >> a kernel module which could take care of memory >> reservations and a daemon to copy and incrementally sync the jails >> memory across. >> >> Then also there is the CPU problem.. >> >> Sounds like a fair amount of work and development. >> >> All comments are welcomed! >> > Well, I'm not a developer, but I think that the jail framework surely deservestobe evolved in something more "friendly" from a sysadmin's point of view. > The architecture is great, and that's just enough to consolidate a lot of workloads,but for some applications there are features (resource containers, offline andonline migration of jails, etc.) that need to be improved to be affordable in aproduction environment. > I think that a lot of work is getting done (resource container and virtualizationstack projects have ben just sponsored by the FreeBSD Foundation), I do not knowhow much time will take to reach a complete "business-ready" virtualizationframework, neither if they are on the right path, but I'm quite confident, because I'msure that the simplicity of the FreeBSD solution will rule any other virtualizationframework out there. > As the feature you are asking for, I think that resource containers and offlinemigration should be considered first, because overall they'll have more impact onbusiness environments. Further, I believe that building a hot migration procedureworking with third-party running applications will be a very complex task to achieve,maybe too expensive at this time, compared to the amount of work required. > That's an interesting argument, I'll be glad if more member of the Community willcontribute with their considerations. > Sincerely. > Sorry, I'm accustomed to 'top positing' - LIFO - polish notation. Anyway, yes, is it no the plan that ezjail-admin *MIGHT* be integrated into the FreeBSD core release? Once that is done, anybody could feel comfortable writing a webmin module to manage jails? From k at 7he.at Fri Sep 10 20:03:28 2010 From: k at 7he.at (Klaus P. Ohrhallinger) Date: Fri Sep 10 20:03:31 2010 Subject: Jail hot migration In-Reply-To: <4C89B3DF.7050004@snap.net.nz> References: <4C89B3DF.7050004@snap.net.nz> Message-ID: <20100910200250.GS2965@mx.7he.at> On Fri, Sep 10, 2010 at 04:28:15PM +1200, Peter Toth wrote: > Hi guys, > > I was lately thinking around jail hot-migration feature where one jail > could be moved from one host to another without > shutting it down, something like vmotion in VMware world. > [snip] Hello; I implemented a working prototype of a container-style virtualization for FreeBSD, capable of live/hot migration. It has nothing to do with jail, but it makes use of vimage/vnet. I am going to do a presentation at the EuroBSDCon in October, but a paper and a demo video (no sources yet, sorry) are already online at: http://www.7he.at/freebsd/vps/ Best regards, klaus -- Alle sagten ''es geht nicht''. Dann kam einer, der wusste das nicht. Der hat's einfach gemacht. From k at 7he.at Fri Sep 10 20:10:28 2010 From: k at 7he.at (Klaus P. Ohrhallinger) Date: Fri Sep 10 20:10:31 2010 Subject: Jail hot migration In-Reply-To: <4C89B3DF.7050004@snap.net.nz> References: <4C89B3DF.7050004@snap.net.nz> Message-ID: <20100910194520.GP2965@mx.7he.at> On Fri, Sep 10, 2010 at 04:28:15PM +1200, Peter Toth wrote: > Hi guys, > > I was lately thinking around jail hot-migration feature where one jail > could be moved from one host to another without > shutting it down, something like vmotion in VMware world. > [snip] Hello; I implemented a working prototype of a container-style virtualization for FreeBSD, capable of live/hot migration. It has nothing to do with jail, but it makes use of vimage/vnet. I am going to do a presentation at the EuroBSDCon in October, but a paper and a demo video (no sources yet, sorry) are already online at: http://www.7he.at/freebsd/vps/ Best regards, klaus -- Alle sagten ''es geht nicht''. Dann kam einer, der wusste das nicht. Der hat's einfach gemacht. From andrew.hotlab at hotmail.com Fri Sep 10 22:28:10 2010 From: andrew.hotlab at hotmail.com (Andrew Hotlab) Date: Fri Sep 10 22:28:13 2010 Subject: Jail hot migration Message-ID: > Date: Fri, 10 Sep 2010 19:45:20 +0000 > From: k@7he.at > To: freebsd-jail@freebsd.org > Subject: Re: Jail hot migration > > On Fri, Sep 10, 2010 at 04:28:15PM +1200, Peter Toth wrote: > > Hi guys, > > > > I was lately thinking around jail hot-migration feature where one jail > > could be moved from one host to another without > > shutting it down, something like vmotion in VMware world. > > > > I implemented a working prototype of a container-style virtualization > for FreeBSD, capable of live/hot migration. It has nothing to do with > jail, but it makes use of vimage/vnet. > > I am going to do a presentation at the EuroBSDCon in October, > but a paper and a demo video (no sources yet, sorry) are already > online at: > > http://www.7he.at/freebsd/vps/ > I was really impressed by the live migration demo video and I wish to ask you a few questions about your solution... At this time VPS technology lacks resource limiting capability, do you think it could be compatible with the resource container project sponsored by the FreeBSD Foundation? Multiple virtual instances of FreeBSD running as VPS are required to share the same kernel, as in the Jail paradigm, or they may run different kernels, as in NetBSD (http://www.NetBSD.org/docs/rump/)? How many resources do you estimate in order to complete your project? It seems that it will be far more difficult to implement the live migration feature on the Jail framework than in VPS, but how about offline migration and resource control? Some work has been done to achieve that with the current Jail paradigm, do you think that VPS will be able to do a better job in these areas too? Sorry if any question sounds stupid: I do not know much on the internals of the technologies I mentioned. Thank you very much for your work. Andrew P.S. I'm sorry for the format of the e-mail, I'm using this awful Hotmail web interface. :( From k at 7he.at Sat Sep 11 09:18:23 2010 From: k at 7he.at (Klaus P. Ohrhallinger) Date: Sat Sep 11 09:18:26 2010 Subject: Jail hot migration In-Reply-To: References: Message-ID: <20100911091742.GA14592@mx.7he.at> On Fri, Sep 10, 2010 at 10:28:09PM +0000, Andrew Hotlab wrote: Hello; > > I was really impressed by the live migration demo video and I wish to ask you a few questions about your solution... > At this time VPS technology lacks resource limiting capability, do you think it could be compatible with the resource container project sponsored by the FreeBSD Foundation? I heard about that resource container project, but don't know any details. But it sounds like it could be adapted or integrated to my work. I didn't put any effort in resource accounting/limiting yet because it's the most boring part of the whole story, IMHO. > Multiple virtual instances of FreeBSD running as VPS are required to share the same kernel, as in the Jail paradigm, or they may run different kernels, as in NetBSD (http://www.NetBSD.org/docs/rump/)? They share the same kernel, altough it works different from jail. Jail restricts processes from seeing and accessing certain resources, while VPS duplicates almost any resource. Please see my paper for details. > How many resources do you estimate in order to complete your project? Well, if I get positive feedback at the EuroBSDCon and people want to have it I can put quite a large amount of my time in it, but then it's still a long way to go until production quality. Anyways I plan to publish patches and binaries for testing in october. > It seems that it will be far more difficult to implement the live migration feature on the Jail framework than in VPS, but how about offline migration and resource control? Some work has been done to achieve that with the current Jail paradigm, do you think that VPS will be able to do a better job in these areas too? Live migration of jails is asking for some really nasty hacks. For example imagine what to do if a process has a PID number that is already assigned on the host you are migrating the jail to. > Sorry if any question sounds stupid: I do not know much on the internals of the technologies I mentioned. > Thank you very much for your work. > Andrew > P.S. I'm sorry for the format of the e-mail, I'm using this awful Hotmail web interface. :( > > Best regards, Klaus -- Alle sagten ''es geht nicht''. Dann kam einer, der wusste das nicht. Der hat's einfach gemacht. From peter.toth at snap.net.nz Sat Sep 11 10:08:07 2010 From: peter.toth at snap.net.nz (Peter Toth) Date: Sat Sep 11 11:17:56 2010 Subject: Jail hot migration Message-ID: <4C8B4DF3.9050209@snap.net.nz> That VPS solution is exactly what I was thinking of. Klaus, will this be licensed under BSD? How far is the source release? Regards From k at 7he.at Sat Sep 11 21:16:28 2010 From: k at 7he.at (Klaus P. Ohrhallinger) Date: Sat Sep 11 21:16:32 2010 Subject: Jail hot migration In-Reply-To: <4C8B4DF3.9050209@snap.net.nz> References: <4C8B4DF3.9050209@snap.net.nz> Message-ID: <20100911211555.GB14592@mx.7he.at> On Sat, Sep 11, 2010 at 09:37:55PM +1200, Peter Toth wrote: > That VPS solution is exactly what I was thinking of. > > Klaus, will this be licensed under BSD? How far is the source release? > Hello; It will be BSD licensed. I am going to release it in october, but it still has to be considered highly experimental, and there are still many points where virtualization doesn't take effect yet. Regards, Klaus -- Alle sagten ''es geht nicht''. Dann kam einer, der wusste das nicht. Der hat's einfach gemacht. From bugmaster at FreeBSD.org Mon Sep 13 11:06:57 2010 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 13 11:07:35 2010 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <201009131106.o8DB6vnQ001920@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/149050 jail [jail] rcorder ``nojail'' too coarse for Jail+VNET s conf/142972 jail [jail] [patch] Support JAILv2 and vnet in rc.d/jail o conf/141317 jail [patch] uncorrect jail stop in /etc/rc.d/jail o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 7 problems total. From 000.fbsd at quip.cz Mon Sep 13 11:55:31 2010 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Mon Sep 13 11:55:33 2010 Subject: Jail hot migration / new VPS for FreeBSD In-Reply-To: <20100911211555.GB14592@mx.7he.at> References: <4C8B4DF3.9050209@snap.net.nz> <20100911211555.GB14592@mx.7he.at> Message-ID: <4C8E0D2A.8080809@quip.cz> Klaus P. Ohrhallinger wrote: [...] > Hello; > > It will be BSD licensed. > > I am going to release it in october, but it still has to be > considered highly experimental, and there are still many points > where virtualization doesn't take effect yet. You can send Heads Up / Work In Progress announcement e-mail to freebsd-virtualization@FreeBSD.org where you may get wider audience for your virtualization project! I am really glad that you are working on this type of VPS for FreeBSD. Miroslav Lachman From bugmaster at FreeBSD.org Mon Sep 20 11:06:58 2010 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 20 11:07:12 2010 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <201009201106.o8KB6vSC014984@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/149050 jail [jail] rcorder ``nojail'' too coarse for Jail+VNET s conf/142972 jail [jail] [patch] Support JAILv2 and vnet in rc.d/jail o conf/141317 jail [patch] uncorrect jail stop in /etc/rc.d/jail o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 7 problems total. From linimon at FreeBSD.org Sun Sep 26 20:57:59 2010 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sun Sep 26 20:58:09 2010 Subject: conf/150599: [patch] /etc/rc.d/jail does not set jailname. Message-ID: <201009262057.o8QKvw9X095339@freefall.freebsd.org> Old Synopsis: /etc/rc.d/jail does not set jailname. New Synopsis: [patch] /etc/rc.d/jail does not set jailname. Responsible-Changed-From-To: freebsd-bugs->freebsd-jail Responsible-Changed-By: linimon Responsible-Changed-When: Sun Sep 26 20:57:37 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150599 From bugmaster at FreeBSD.org Mon Sep 27 11:06:57 2010 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Sep 27 11:07:29 2010 Subject: Current problem reports assigned to freebsd-jail@FreeBSD.org Message-ID: <201009271106.o8RB6uUA023505@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/150599 jail [patch] /etc/rc.d/jail does not set jailname. o conf/149050 jail [jail] rcorder ``nojail'' too coarse for Jail+VNET s conf/142972 jail [jail] [patch] Support JAILv2 and vnet in rc.d/jail o conf/141317 jail [patch] uncorrect jail stop in /etc/rc.d/jail o kern/133265 jail [jail] is there a solution how to run nfs client in ja o kern/119842 jail [smbfs] [jail] "Bad address" with smbfs inside a jail o bin/99566 jail [jail] [patch] fstat(1) according to specified jid o bin/32828 jail [jail] w(1) incorrectly handles stale utmp slots with 8 problems total.