[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 00/20] VM forking
> > > > Why do you need a config file for launching the Qemu device model? > > > > Doesn't the save-file contain all the information? > > > > > > The config is used to populate xenstore, not just for QEMU. The QEMU > > > save file doesn't contain the xl config. This is not a full VM save > > > file, it is only the QEMU state that gets dumped with > > > xen-save-devices-state. > > > > TBH I think it would be easier to have something like my proposal > > below, where you tell xl the parent and the forked VM names and xl > > does the rest. Even better would be to not have to tell xl the parent > > VM name (since I guess this is already tracked internally somewhere?). > > The forked VM has no "name" when it's created. For performance reasons > when the VM fork is created with "--launch-dm no" we explicitly want > to avoid touching Xenstore. Even parsing the config file would be > unneeded overhead at that stage. And to answer your question, no, the parent VM's name is not recorded anywhere for the fork. Technically not even the parent's domain id is kept by Xen. The fork only keeps a pointer to the parent's "struct domain". So right now there is no hypercall interface to retrieve a fork's parent's ID - it is assumed the tools using the interface are keeping track of that. Could this information be dumped into Xenstore as well? Yes. But we specifically want be able to create the fork as fast possible without any unnecessary overhead. Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |