[Libvir] save/restore support for KVM

[Daniel P. Berrange]

On Sat, Aug 11, 2007 at 03:16:38PM -0400, Jim Paris wrote:
> Daniel Veillard wrote:
> > On Fri, Aug 10, 2007 at 12:36:05PM -0400, Jim Paris wrote:
> > > I think appending unrelated data to the migration image is a bit of a
> > > hack anyway.  A better plan would be a file containing
> > >   <header> <XML config> <migration data>
> > 
> >   Hum, beware you then need to make sure that you indicate in the
> > header the lenght of the XML config, because you can't ask the XML parser
> > to tell you when the XML file ends. Should not be hard but it's a pitfall
> > I have seen too many people trip on :-)
> 
> Remembering to null-terminate the XML config before passing it to
> qemudParseVMDef is also helpful :)
> 
> I have it mostly working now.  Saving works fine, but restoring is a
> bit buggy with regards to multiple copies of the same domain, config
> files, etc.  This is what I'm using for resuming:
> 
>   xml = read XML
>   def = qemudParseVMDef(xml)
>   vm = qemudAssignVMDef(def)
>   if (qemudStartVMDaemon(vm) < 0)
>       qemudRemoveInactiveVM(vm)
> 
> My questions:
> 
> Should I add qemudSaveVMDef somewhere?  Currently, if I undefine a
> domain and then restore from an image, I don't think there's any way
> to then save that domain back to a config file.

There's no need to call saveVMDef - the current save/restore API is what
I term 'unmanaged'. So if the VM already has a persistent config on disk
and you restore it, there's no need to save it. If the VM doesn't have
a persistent config, then the original domain was 'transient' and the
new domain will also be 'transient' so no need to save in this case either.

> What should happen if one tries to resume the same image twice?

If we see an existing VM running with matching name or UUID, then it should
cause an error. If there is an existing config then it'll simply be 
overwritten. Now in general restoring twice is only safe if the admin is doing
snapshotting of the disks - we've no way of knowing this so just have to assume
the admin knows what they're doing if they restore twice (or more).

> Currently I think qemudAssignVMDef returns a pointer to the first vm,
> the start fails, and then RemoveInactiveVM removes the running one --
> not good.  Should I try to detect when the name/UUID already exists
> and refuse? 

Yes, refuse if there is an active VM with maching name or UUID. 

> The "test" driver seems to also be broken in this regard:
>   $ virsh --connect test:///default
>   virsh > save test /tmp/test
>   virsh > restore /tmp/test
>   virsh > shutdown 2
>   virsh > list --all
>    Id Name                 State
>   ----------------------------------
>     - test                 shut off
>     - test                 shut off
> 
> There's no way to uniquely refer to either of those now.

That's a bug in the test driver - i'll sort it out.

> Does the xen driver handle this any better?

Not sure.

> Also, is there a reason qemudAssignVMDef match by name rather than
> UUID?  Are names supposed to be unique?

Both names & UUIDs should be considered unique. As for why AssignVMDef
matches by name I can't really recall any particular reason. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|