Re: Starting save/restore for port-xen - initial questions

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Mar 11, 2008 at 12:11:18PM +0100, Christoph Egger wrote:
> > Well, it's great to have someone working on this :)
> 
> indeed.
> 
> [...]
> 
> > > Hence, I have some questions. Having extra pointers to areas in
> > > /usr/src/sys/ (I am mostly relying on ctags right now...) would be of
> > > great help. Note that I am not making any difference between "suspend"
> > > and "save", and "resume" and "restore". Please correct me if I am wrong.
> >
> > this is correct. suspend/resume is the same as save/restore for Xen.
> > The difference with a real hardware is that we may resume on a different
> > hardware than one we did suspend (migration).
> 
> ACPI S3 support in Xen has been introduced in Xen 3.2.
> So for real hardware suspend/resume with Xen, an update to Xen 3.2
> is required.

Sure. But lets do the domU suspend first :)

> 
> > > - Same question goes for externally dependent mechanisms, like, TCP
> > > connections, which will inevitably timeout if we suspend the domain for
> > > a long time,
> >
> > Sure, but it'll be handled by the TCP stack. It's not different from
> > suspending a laptop.
> 
> That's correct. But TCP connections should not drop on live migration.

Yes. But that's no different from a laptop suspend/resume: if it resumes
fast enough (within 10mn, for default TCP timeouts), no connection
should be droppped, as long as the ethernet interface didn't dissapear.

> > > feel free to correct me. If yes, did the code using *_resume() land
> > > somewhere?
> >
> > When I wrote these code, I started thinking about suspend/resume and
> > tried to split the code required to boot appropriately. But for
> > now it has only been tested for a full domain boot, and I'm not sure
> > the split between attach and resume is 100% correct. This is one of the
> > things to look at :)
> 
> You can test at runtime with xm block-attach/detach and xm 
> network-attach/detach.

This is already working. But it's a bit different from suspend:
with xm foo-detach, the device will dissapear on the domU side too
(just like if you had unplugged your USB key, or PCMCIA network interface).
For suspend/resume we want the devices to stay here. If after resume
the block device instance changed, the mounted filesystems will become
invalid (which is annoying for / :). The same goes for IP addresses and
ethernet devices.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--