Back to Home / #uml / 2009 / 05 / Prev Day | Next Day
#uml IRC Logs for 2009-05-07

---Logopened Thu May 07 00:00:10 2009
00:16-!-Basic [] has joined #uml
00:58-!-Basic [] has quit [Quit: Basic]
01:11-!-Basic [] has joined #uml
01:11-!-Basic [] has quit []
03:03-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
03:29-!-Basic [] has joined #uml
03:29-!-BasicOSX [] has joined #uml
03:29-!-Basic [] has quit [Read error: Connection reset by peer]
03:41-!-balbir_ [~balbir@] has joined #uml
04:09-!-BasicOSX [] has quit [Quit: BasicOSX]
09:10-!-lanas [] has joined #uml
09:14-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
09:22-!-balbir_ [~balbir@] has joined #uml
09:25-!-lanas [] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
09:36-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
10:23-!-balbir_ [~balbir@] has joined #uml
10:24-!-lanas [] has joined #uml
10:24<lanas:#uml>Hello. Anyone know how VNUML does it to pass params to new UMLs ?
10:25<caker:#uml>command line maybe?
10:25<caker:#uml>check a UML's /proc/cmdline
10:25<lanas:#uml>I don't think so. The main script is creating a filesystem with a umlboot script in it.
10:26<lanas:#uml>as far as I see it, this fs is used by the UML at the start.
10:26<lanas:#uml>and it sets various parameters inside the UML
10:26<caker:#uml>that'd be a good place to look then
10:27<lanas:#uml>I'm looking for a way to configure UMLs automatically, possibily out-of-band, so I'm looking now at VNUML and how they could do it ;-)
10:27<lanas:#uml>I also thought about expanding the mconsole utility to actually pass commands to UMLs.
10:31<bunk:#uml>ups, completely wrong channel...
10:31<caker:#uml>lanas: what are you looking to "configure" exactly?
10:32<lanas:#uml>Things like network interfaces, hostname, possibly even some applications like VRRP, OSPF, basically to be able to start UMLs according to configurations that were made before they started.
10:32<lanas:#uml>VNUML seems to do it. There's also clownix who does it.
10:33<caker:#uml>interfaces and hostname and whatnot is easy -- mount the filesystem and make the modifications directly
10:33<caker:#uml>or use dhcp with static assignments based on MAC addresses
10:34<caker:#uml>app stuff you'll probably want pre-canned distros witht that stuff pre-installed, and then you copy off a specific fs based on what the user is requesting
10:34<lanas:#uml>I do not want to rely on DHCP as this introduces a network variable. I'd like users to be able to configure UMLs offline so to speak and then launch them. Upon startup the UMLs would adopt their specific configurations w/o any interaction on the part of the users.
10:35<lanas:#uml>Your mention of copying off a specific fs is interesting. Would that be a host fs ?
10:35<caker:#uml>I wouldn't bother with hostfs. Just make pre-canned fs templates as files/LVs whatever
10:36<lanas:#uml>I have the impression that this could be the key, but I'm not figuring it out right now. How would these informations find their way to an UML ?
10:37<lanas:#uml>Ah. I'd like to use COWs.
10:38<lanas:#uml>So that'd mean one fs with multiple COWs, each UML being configured differently. Unless I really have to, I wouldn't go the one fs per UML way. There could be as much as 35 UMLs running there.
10:39<caker:#uml>COW sucks if you ever intend on making your filesystems a different size than the source image
10:40<caker:#uml>It's simple: Make a filesystem, reduce it's size. Call it "template1". When you need to provision a UML, *copy* that filesystem somewhere (into an LV, or whatever), resize it, mount it, fix it up with instance-specific information (hostname, interfaces, etc), unmount it and boot it. Done
10:41<lanas:#uml>Yes, but then this is a 1 fs per UML thing.
10:41-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
10:41<caker:#uml>that's life
10:42<caker:#uml>If you make a COW image, say .. 1GB, right? And then you have a bunch of instances that are based on that, guess what the size will forever be for all of those images?
10:42<lanas:#uml>Not that the fs are large .. about 200 M eahc.
10:43<caker:#uml>also, if your COW image gets messed up, you have 40 dead UMLs
10:43<caker:#uml>just copy the damn thing :)
10:43<lanas:#uml>I grok that the COWs will only be the size of the differences between them and the original fs
10:43<caker:#uml>you're worried about DHCP but accept the risk of basing everything off of one COW image.. ?? :)
10:44<lanas:#uml>Yeah. So far I haven't seen any COW failing.
10:44<caker:#uml>if you ever, ever look at the cow image the wrong way (touch it, or anyhting) you're screwed.
10:44<lanas:#uml>The prupose is network simulation. Can't have DHCP if it's not part of the simulation.
10:45<lanas:#uml>I know.
10:45<lanas:#uml>1 fs per UML would be much easier, though.
10:47<lanas:#uml>In VNUML they produce this umlboot script that resides inside a fs of its own. It seemingly contains all params for the UML, and actions to install them. I'll see how they make the UML act on this script/fs. How they it loaded on vanilla fs.
11:00-!-duraperidol [~nohost@] has quit [Ping timeout: 480 seconds]
11:28-!-balbir_ [~balbir@] has joined #uml
12:04-!-mjf [] has joined #uml
12:34-!-jdike [] has joined #uml
12:34<jdike:#uml>Hi guys
12:47-!-l_r [~l_r@] has joined #uml
12:53<lanas:#uml>I was wondering about how to automatically configure UMLs ...
12:56<lanas:#uml>I'm looking at the VNUML code and see that they are injecting at least one boot script in a copy (that they call a COW) of the fs.
12:56<lanas:#uml>I haven't went through all that VNUML code yet, though.
12:58<lanas:#uml>If I copy a fs, then strip it down to a few config files, is it possible to include it as a COW ? I guess not, the COW must have something more, it cannot be simply a stripped down copy of the main fs.
13:03<jdike:#uml>It's a block-level image of the changed blocks in the fs
13:03-!-mjf [] has quit [Ping timeout: 480 seconds]
13:09<lanas:#uml>I just noticed the uml_mkcow utility. after making a COW file with this utility, is it possible to copy files from the main fs into it ?
13:11<lanas:#uml>If it's possible, then I could copy specific config files into this new COW file, then boot the UML speifying both that COW file and the original fs. The UML would then take heed fo the changed files in the COW. Changed files could be various system configs. Even new boot scripts.
13:16<jdike:#uml>the easiest way is to boot a UML with the original and cow as disks, and copy stuff into the COW file
13:17<lanas:#uml>Yes, but what I'd like to do is to let users pre-configure UMLs (for network simulations) and then have all pre-configured UMls launched to start the live simulation.
13:57<lanas:#uml>I wonder if there's an easy way to put files inside a new COW file. Mounting it will not work (for obvious reasons). Perhaps treating it like a device ?
14:00<jdike:#uml>boot a UML with it
14:00<lanas:#uml>Without booting a UML.
14:32<jdike:#uml>why not?
14:44<lanas:#uml>Because I wouldn't want users to be doing it. If each UML has to be booted in order to be configured then it makes not much sense. Nor for one, neither for 35 of them (which can be the extent of some simulations). users should be able to configure their simulation w/o any UML running, then the simulation would launch eahc required UML and 'magically' have them configured.
14:44<jdike:#uml>You boot it in order to set up the COW file
14:46<lanas:#uml>I've merged the COW file produced by VNUML now to a new fs, and am diffing this new fs with the original. All VNUML changes are there. Is it legal to boot a UML w/o a fs but only a COW (the backing fs would be referenced through the COW) as in: ubda=cow instead of: ubda=cow,fs ?
14:47<jdike:#uml>the backing file name is stored in the COW file
14:48<lanas:#uml>OK. Curiously I've hexedited the VNUML COW file and for the life of me, apart from some stuff at the beginning, none of the changes I'm seeing after merging it with the backing fs are in there.
15:01-!-mjf [] has joined #uml
15:29-!-duraperidol [~nohost@] has joined #uml
15:31-!-duraperidol is now known as theodred
15:31-!-theodred is now known as duraperidol
15:32<lanas:#uml>Would an 'init=/root/' statement as a parameter when launching a UML make that script execute once init.d boot scripts are done ?
15:36<jdike:#uml>it would make that script be init
15:57<lanas:#uml>Looks like the VNUML guys made it by effectively launching the UML to configure it, after all. And terminating it abruptly by issuing a 'halt -d -f', then going on with some other config tasks, then launching the UML for good a bit later.
15:57<lanas:#uml>I presume trying to modify a COW file statically w/o the UML running was deemed to much of a task to do ;-)
15:59<jdike:#uml>you'd need a COW driver in the host kernel
15:59<jdike:#uml>which is doable, just no one has done it
16:00<lanas:#uml>Which pretty much makes do with running a simulation setup in a portable manner.
16:01<lanas:#uml>About a much more doable thing: I'm considering expanding the mconsole interface to add more out-of-band interaction with the UMLs.
16:01<lanas:#uml>Like getting run-time infos, chaning some params, etc...
16:01<lanas:#uml>Was there any requests in the past about expanding the mconsole interface ?
16:03<jdike:#uml>but it's easy enough
16:04<lanas:#uml>I thought so. If I do anything regarding this, would there be a possibility to submit changes upstream ?
16:05<jdike:#uml>if they make sense
16:05<lanas:#uml>The difficult part would be to come up with a generic enough API.
16:05<jdike:#uml>just random additions because you felt like it wouldn't be
16:06<lanas:#uml>Ah. Is there any improvement of the networking performance in sight ? I think I read somewhere that a KVM-like approach could be added to UML....
16:13<jdike:#uml>I haven't really done anything serious to UML in a while
16:34-!-jdike [] has quit [Quit: Leaving]
16:56<thomas_adam:#uml>You should, it's good software.
17:11<lanas:#uml>Bye all. Thanks Jeff for the comments.
17:11-!-lanas [] has left #uml [ERC Version 5.3 (IRC client for Emacs)]
19:49-!-mjf [] has quit [Ping timeout: 480 seconds]
20:13-!-l_r [~l_r@] has quit [Read error: Connection reset by peer]
20:55-!-darodrig [] has joined #uml
21:40-!-Electric1lf [] has joined #uml
21:43-!-ElectricElf [] has quit [Ping timeout: 480 seconds]
22:12-!-Basic [] has joined #uml
23:59-!-VS_ChanLog [] has left #uml [Rotating Logs]
23:59-!-VS_ChanLog [] has joined #uml
---Logclosed Fri May 08 00:00:14 2009