Re: [Xen-devel] [PATCH v2 00/20] VM forking

[Tamas K Lengyel <tamas@tklengyel.com>]

On Wed, Jan 8, 2020 at 9:34 AM George Dunlap <george.dunlap@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.pau@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.grall@gmail.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> On Mon, 30 Dec 2019, 20:49 Tamas K Lengyel, <tamas@tklengyel.com> wrote:
> >>>>>>
> >>>>>> On Mon, Dec 30, 2019 at 11:43 AM Julien Grall <julien@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.

>
> (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

Aye, could be done. For now I didn't bother since its trivial to do
manually already.

>
> 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.

Thanks,
Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel