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. Thanks, Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
