On 12/31/19 3:11 PM, Roger Pau Monné wrote: > On Tue, Dec 31, 2019 at 08:00:17AM -0700, Tamas K Lengyel wrote: >> On Tue, Dec 31, 2019 at 3:40 AM Roger Pau Monné <roger....@citrix.com> wrote: >>> >>> On Mon, Dec 30, 2019 at 05:37:38PM -0700, Tamas K Lengyel wrote: >>>> On Mon, Dec 30, 2019 at 5:20 PM Julien Grall <julien.gr...@gmail.com> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> On Mon, 30 Dec 2019, 20:49 Tamas K Lengyel, <ta...@tklengyel.com> wrote: >>>>>> >>>>>> On Mon, Dec 30, 2019 at 11:43 AM Julien Grall <jul...@xen.org> wrote: >>>>>> But keep in mind that the "fork-vm" command even with this update >>>>>> would still not produce for you a "fully functional" VM on its own. >>>>>> The user still has to produce a new VM config file, create the new >>>>>> disk, save the QEMU state, etc. >>> >>> IMO the default behavior of the fork command should be to leave the >>> original VM paused, so that you can continue using the same disk and >>> network config in the fork and you won't need to pass a new config >>> file. >>> >>> As Julien already said, maybe I wasn't clear in my previous replies: >>> I'm not asking you to implement all this, it's fine if the >>> implementation of the fork-vm xl command requires you to pass certain >>> options, and that the default behavior is not implemented. >>> >>> We need an interface that's sane, and that's designed to be easy and >>> comprehensive to use, not an interface built around what's currently >>> implemented. >> >> OK, so I think that would look like "xl fork-vm <parent_domid>" with >> additional options for things like name, disk, vlan, or a completely >> new config, all of which are currently not implemented, + an >> additional option to not launch QEMU at all, which would be the only >> one currently working. Also keeping the separate "xl fork-launch-dm" >> as is. Is that what we are talking about? > > I think fork-launch-vm should just be an option of fork-vm (ie: > --launch-dm-only or some such). I don't think there's a reason to have > a separate top-level command to just launch the device model.
So first of all, Tamas -- do you actually need to exec xl here? Would it make sense for these to start out simply as libxl functions that are called by your system? I actually disagree that we want a single command to do all of these. If we did want `exec xl` to be one of the supported interfaces, I think it would break down something like this: `xl fork-domain`: Only forks the domain. `xl fork-launch-dm`: (or attach-dm?): Start up and attach the devicemodel to the domain Then `xl fork` (or maybe `xl fork-vm`) would be something implemented in the future that would fork the entire domain. (This is similar to how `git am` works for instance; internally it runs several steps, including `git mailsplit`, `git mailinfo`, and `git apply-patch`, each of which can be called individually.) I think I would also have: `xl fork-save-dm`: Connect over qmp to the parent domain and save the dm file Then have `xl fork-launch-dm` either take a filename (saved from the previous step) or a parent domain id (in which case it would arrange to save the file itself). Although in fact, is there any reason we couldn't store the parent domain ID in xenstore, so that `xl fork-launch-dm` could find the parent by itself? (Although that, of course, is something that could be added later if it's not something Tamas needs.) Thoughts? -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
