From: Anthony Liguori <aliguori@us.ibm.com>
To: Noam Taich <noam.taich@qumranet.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Domain save/migrate issue
Date: Wed, 15 Feb 2006 08:16:44 -0600 [thread overview]
Message-ID: <43F337CC.9090900@us.ibm.com> (raw)
In-Reply-To: <64F9B87B6B770947A9F8391472E0321603494ADB@ehost011-8.exch011.intermedia.net>
Noam Taich wrote:
> We need the memory image of the domain to be static, So we can't allow
> the domain to run. So, the first idea is to use pause/unpause instead of
>
Suspend does more than just canonicalize the p2m, it also provides
callbacks for all of the devices so that they can canonicalize their own
page references and set them self up to reinitialize upon resume.
While the save code can access the p2m table, it has no way of knowing
the device information so just pausing isn't really an option (also, you
could do bad things like checkpoint before a storage operation was
committed or something like that).
Regards,
Anthony Liguori
> suspend.
>
> Now for the next (serious) problem:
> This seems to work fine (in live or non live settings) until the
> xc_linux_save() function reaches the part where it checks the frame
> number
> Of the suspend record, which makes sense, because now, we have NO
> suspend record. So, the second idea is to (simply?) write all that info
> on the io_fd
> The function gets ourselves. Just canonicalize the fns that suspend
> does,
> And write the appropriate info.
>
> The restore function does not have to change at all... it sees the same
> input.
>
> So, what do you think, is this a good idea? Even possible? Will it
> entail a lot?
>
> One of my concerns is this: the shared pages.
> Can Xen write to them while the guest is "only" paused? And if so, what
> Can it (practically) write there while the guest is paused?
> Even if it CAN, is it Reasonable to expect it won't do that usually?
>
>
> I'm not really troubled by the storage issues. This feature would be
> useful in many cases even with no solution to that problem.
>
> Sorry for the multiple messages on the original subject. It was an
> unfortunate misunderstanding.
>
>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>
>>
>
>
>
next prev parent reply other threads:[~2006-02-15 14:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 8:38 Domain save/migrate issue Noam Taich
2006-02-15 14:16 ` Anthony Liguori [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-02-15 16:42 Noam Taich
2006-02-15 16:22 Noam Taich
2006-02-15 16:26 ` Anthony Liguori
2006-02-15 9:32 Noam Taich
2006-02-14 14:08 Noam Taich
2006-02-14 14:41 ` Daniel Veillard
2006-02-14 14:44 ` Steven Hand
2006-02-14 14:55 ` Anthony Liguori
2006-02-14 14:57 ` Daniel Veillard
2006-02-15 11:28 ` Jacob Gorm Hansen
2006-02-14 13:45 Noam Taich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43F337CC.9090900@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=noam.taich@qumranet.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.