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

[Julien Grall <julien@xxxxxxx>]

Hi Tamas,

On 31/12/2019 16:36, Tamas K Lengyel wrote:
> On Tue, Dec 31, 2019 at 9:08 AM Tamas K Lengyel <tamas@xxxxxxxxxxxxx> wrote:
> > On Tue, Dec 31, 2019 at 8:11 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxx> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, 30 Dec 2019, 20:49 Tamas K Lengyel, <tamas@xxxxxxxxxxxxx> wrote:
> > > > > > > > On Mon, Dec 30, 2019 at 11:43 AM Julien Grall <julien@xxxxxxx> 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.
> > It's just that the fork-launch-dm needs the domid of the fork, while
> > the fork-vm needs the parent's domid. But I guess we can interpret the
> > "domid" required input differently depending on which sub-option is
> > specified for the command. Let's see how it pans out.
> How does the following look for the interface?
>
>      { "fork-vm",
>        &main_fork_vm, 0, 1,
>        "Fork a domain from the running parent domid",
>        "[options] <Domid>",
>        "-h                           Print this help.\n"
>        "-N <name>                    Assign name to VM fork.\n"
>        "-D <disk>                    Assign disk to VM fork.\n"
>        "-B <bridge                   Assign bridge to VM fork.\n"
>        "-V <vlan>                    Assign vlan to VM fork.\n"
>        "-C <config>                  Use config file for VM fork.\n"
>        "-Q <qemu-save-file>          Use qemu save file for VM fork.\n"
>        "--launch-dm  <yes|no|late>   Launch device model (QEMU) for VM fork.\n"
>        "--fork-reset                 Reset VM fork.\n"
>        "-p                           Do not unpause VMs after fork."
>        "-h                           Print this help.\n"
>        "-d                           Enable debug messages.\n"
>      },
>
> Currently the parts that are implemented would look like:
> xl fork-vm -p --launch-dm no <parent_domid>
> xl fork-vm -p --launch-dm late -C <config> -Q <qemu-save-file> <fork_domid>
> xl fork-vm -p --fork-reset <fork_domid>
The interface looks good to me. Note that I don't think you need to 
describre all the unimplemented option in the help. It would be 
sufficient to describe what you only support and bail out if the user 
gives something different.
What matters is we are able to extend the command line option over the time.

Cheers,

--
Julien Grall

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