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.
What should happen if one tries to resume the same image twice?
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?
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.
Does the xen driver handle this any better?
Also, is there a reason qemudAssignVMDef match by name rather than
UUID? Are names supposed to be unique?
-jim