On Fri, Apr 20, 2007 at 11:35:00AM +0900, Saori Fukuta wrote:
Hi, Daniel and Dan
Thank you for various comments.
Exactly. Libvirt is just a library and it is better to not keep states there. The management states would be kept at end point server(eg. XenD, or QEMUD) or an application. So I would like to think again.
On Thu, 19 Apr 2007 16:18:28 +0100 "Daniel P. Berrange" wrote:
If we ignore case B, I think we still have lots of interesting combos to think about:
1. Static - change persistent config 2. Dynamic - change live VM config 3. Static and Dynamic - change persistent config, and live VM 4. Static or Dynamic - if domain is inactive, change persistent config, if it is active, change live VM
With the virDomainSetMem/MaxMem/VCPUs we in fact implement 3/4 depending on the backend, because until we switch to XenAPI, that's basically the only option that is actually possible when talking to XenD.
So if you want to only change the persistent config, then you need to redefine the entire domain XML file, using virDomainDefineXML() pasing in the updated XML doc for the new inactive config. This lets you indirectly do option 1.
Yes, that's a good idea. But I'm not sure how to change the presistent config without that libvirt maintain persiste state. Could you tell me your thinking ? Who has the XML file ?
This is already possible today actually. In Xen 3.0.4 or later there is the lifecycle management APIs, so there is an API which lets you define a config for a guest. So in this case we just convert from XML -> SEXPR, in the same way that we do to boot a guest. For older Xen, we simply write files straight into /etc/xen. The QEMUD daemon stores the XML files for QEMU/KVM in the native libvirt format, so that's easy. 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 -=|