Re: [Xen-devel] [PATCH RESEND v5 6/6] xen/arm: Implement toolstack for xl restore/save and migrate

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-11-19 at 15:06 +0400, Eugene Fedotov wrote:
> Our migration protocol consists of: header (Console and XenStore PFN), 
> memory data, HVM context. Can we guarantee that HVM context of version X 
> is compatible (or the same) as HVM context of version X ? I think if we 
                                                        ^ +1 ?
> add some HVM hardware (such as virtual RTC) in version X+1 we may have a 
> compatibility problem, because HVM buffer structure had been changed. I 
> think we cannot predict such things in future versions.

Indeed, it may well be that Xen version X+1 needs some code adding to be
able to consume Xen version X save records.

I thin x86 does this with either explicit or implicit versioning of the
individual save structures.

>  But our 
> migration protocol may have version number and migration between X and 
> X+1 Xen versions is possible when we use the same protocol number in 
> both sides (we may compare protocol versions during the migration runtime).

On x86 the protocol almost always changes in some (possibly minor) way
between versions, so this approach would mean that we didn't support
X->X+1 migrations in the majority of releases which would be
unacceptable.

> >>> [...]
> >>>> +
> >>>> +static int restore_guest_params(xc_interface *xch, int io_fd,
> >>>> +                                uint32_t dom, guest_params_t *params)
> >>>> +{
> >>>> [...]
> >>>> +    if ( xc_domain_setmaxmem(xch, dom, maxmemkb) )
> >>>> +    {
> >>>> +        ERROR("Can't set memory map");
> >>>> +        return -1;
> >>>> +    }
> >>>> +
> >>>> +    /* Set max. number of vcpus as max_vcpu_id + 1 */
> >>>> +    if ( xc_domain_max_vcpus(xch, dom, params->max_vcpu_id + 1) )
> >>> Does the higher level toolstack not take care of vcpus and maxmem? I
> >>> thought so. I think this is how it shoud be.
> >> For my tests guest config information is not transferred for ARM case
> >> from high-level stack. At the migration receiver side toolstack always
> >> create a new domain with vcpus=1 and default max. mem. So we have to
> >> send guest information as our local guest_params structure (at the
> >> beginning of migration).
> >> It is easy way to work "xl save" or "xl migrate" without modification of
> >> libxl level, but you may have another idea?
> >> Also, toolstack_restore callback is not set (NULL) for ARM case.
> > So you aren't using xl to do the migration? This is what we should
> > ultimately be aiming for. It is almost certainly going to require fixes
> > at the libxl level though.
> >
> > If you need to send additional information for your usecase then it
> > should be done at the layer above libxc.
> I found the reason why guest config information is not saved in libxl. 
> the following line in xl_cmdimpl.c:
> if (!dom_info->quiet)
>          printf("Parsing config from %s\n", config_source);
> in function "create_domain"
> calls printf instead of fprintf(stderr, ...).
> It is not the same on ARM. I have feeling that printf() causes output to 
> socket buffer and it breaks config data.

If the socket buffer is attached to stdout then that is a bug which
needs fixing. I'd be surprised if this turned out to be the case though
-- nothing ought to be closing stdout!

> Should we use fprintf(stderr, "Parsing config from %s\n", 
> config_source); here?
> If we do this, config is transferred and we do not need set VCPU number 
> and memory manually.
> 
> Best regards,
> Evgeny.
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel