On 1/8/20 5:06 PM, Tamas K Lengyel wrote: > On Wed, Jan 8, 2020 at 9:34 AM George Dunlap <george.dun...@citrix.com> wrote: >> >> 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? > > For my current tools & tests - no. I don't start QEMU for the forks at > all. So at this point I don't even need libxl. But I can foresee that > at some point in the future it may become necessary in case we want > allow the forked VM to touch emulated devices. Wiring QEMU up and > making the system functional as a whole I found it easier to do it via > xl. There is just way too many moving components involved to do that > any other way. > >> >> 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. > > I really don't have a strong opinion about this either way. I can see > it working either way. Having them all bundled under a single > top-level comment doesn't pollute the help text when someone is just > looking at what xl can do in general. Makes that command a lot more > complex for sure but I don't think it's too bad.
One thing I don't like about having a single command is that since you're not planning on implementing the end-to-end "vm fork" command, then when running the base "fork-vm" command, you'll have to print an error message that says "This command is not available in its completeness; you'll have to implement your own via fork-vm --domain, fork-vm --save-dm, and fork-vm --launch-dm." Which we could do, but seem a bit strange. :-) >> 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.) > > Could be done. But I store ID internally in my tools anyway since I > need it to initialize VMI. So having it in Xenstore is not required > for me. In fact I would prefer to leave Xenstore out of these > operations as much as possible cause it would slow things down. In my > latest tests forking is down to 0.0007s, having to touch Xenstore for > each would slow things down considerably. Right, that makes sense. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
