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