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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 1/8/20 5:06 PM, Tamas K Lengyel wrote:
> On Wed, Jan 8, 2020 at 9:34 AM George Dunlap <george.dunlap@xxxxxxxxxx> 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@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.
>>
>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel