On Wednesday, 21.10.2015 at 12:54, Antti Kantee wrote: > On 21/10/15 11:25, Martin Lucina wrote: > >The sed nonsense is there because qemu does some kind of (unknown, > >undocumented AFAICT) parsing on the content of -append options?! > > That's the only way I got it to work for the original rumprun version, and > it did involve reading the qemu sources. If someone knows of a better way, > I have no special love for the comma duplication. > > >I've just spent an hour trying to make this work with xl. The closest I got > >was: > > > >xl create /dev/null -c kernel=\"wopr.bin\" name=\"wopr\" extra=\"$(cat > >wopr.json|sed -e s/\"/\\\\\"/g | tr '\n' ' ')\" > > > >The above doesn't actually work due to some mismatch in the amount of '\'s > >required. In any case, passing the JSON via the command line as opposed to > >writing it to Xenstore is total madness. > > I imagined it would be done for xl exactly like the current rumprun launch > sequence does it, not your "total madness" approach. Why does appending -p > to the given command line, writing to xenstore, and unpausing not work? Now > that your crisis made me think of it more, the only thing I can imagine is > that the user might want to create the domain paused. That's not really > *too* hard to solve, e.g. with -p flag or an xlpaused target (not sure which > would be better).
Okay, so the minimal required steps to launch a rumprun Xen domain are: 1) xl create /dev/null -p kernel=\"wopr.bin\" name=\"wopr\" (Quoting required, unless you want to create a configuration file) 2) xenstore-write "/local/domain/$(xl domid wopr)/rumprun/cfg" "$(cat wopr.json)" 3) xl unpause wopr If you want to do the equivalent of "rumprun -i", i.e. launch a domain and get its output in a single step, you have to additionally do: 2a) *In a different window* run xl console wopr Now, I don't understand how, with the proposed syntax/abstraction you get from rumprun-launch xl [-c cfg1 -c cfg2 ...] backend params to the above steps. rumprun-launch now just sees opaque "backend params", therefor it's *impossible* for it to create the domain in step 1) as it doesn't have the information required (name, kernel). > There are obviously some restrictions on the options that can be given to > the backend tool if the user expects things to work. It's going to be that > way with or without a convenience tool. ...? I thought the whole point of removing the rumprun tool was to remove all such restrictions. > > >Unfortunately, with the proposed scope of the tool, we can't write to > >Xenstore, since this requires the > >create-domain-as-paused-then-write-to-xenstore dance. > > Can you elaborate what "scope of the tool" means here? You write in the root of this thread: ...having a mostly transparent launch tool (wrt. to the virtualization backend), but hiding details on how the config is passed to the guest... So the scope is just passing config to the guest, and nothing else. If we remove the need to pass config to the guest *at launch time*, problem goes away and no special launch tool is needed at all.
