|
Y
yup - I've been following the discussion on the libvirt mailing list with some interest. I too dont have strong feelings either way... We initially decide to not try to support xm config files in the LTC in-house Xen CIM providers because (1) the file format was still evolving, and (2) since these files are effectively python *scripts* sticking a python interpretor in the CIM providers seemed a little excessive. However, we also inherently had more control of what paths our particular Xen management app could control things, so not supporting existing xm config files was something we could get away with...
Some management apps wont care or need to keep track of non-running DomU's, so they wont care. However, a lot of more advanced management apps will and may treat an inactive DomU as just being another state that their virtual systems can go thru (eg think of a paused DomU vs a suspended DomU vs a stopped DomU as being various states of a virtual system relinquishing its resources back to the system). In particular, once we start wanting to talk about snapshots, static migration, etc, the ability to manage and keep track of DomU's that might be "inactive" becomes quite important.
I think the dicussion going on in libvirt is a good one and maybe something the rest of the folks in xen-cim want to wade into the fray and express an opinion. Lets discuss tomrrow on the call if there is no other pressing business.
BTW - I'm starting to work on the XenSource CIM wiki page and will post some docs there in the next few days, in preparation for a walkthru next Fri (Apr 14).
- Gareth
Gareth S. Bestor, PhD.
IBM Linux Technology Center
M/S DES2-01
15300 SW Koll Parkway, Beaverton, OR 97006
503-578-3186, T/L 775-3186, Fax 503-578-3186
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
To: <xen-cim@xxxxxxxxxxxxxxxxxxx>
cc:
Subject: [Xen-cim] xm shim
All,
I have finally gotten around to testing the xm to libvirt (temporary) shim. It is looking good with the exception of xm_set_domain(), xm_delete(), xm_create() and xm_migrate() - no corresponding libvirt entry points as discussed earlier. These routines are coded to proposed entry points posted on libvirt mailing list.
I opened a discussion on libvirt ml concerning additional entry points to support the idea of setting config, activating a domain based on previously set config, and deleting config. There seems to be some resistance to providing this functionality in libvirt and I'm not sure that I disagree. Perhaps better said is that I don't have any compelling arguments supporting the idea :-). Please join in the discussion if you think otherwise. Other tools will surely use libvirt and they don't know or care about defined vm's. The provider should probably implement this functionality IMHO. Question is whether config is written to xenstore, a file, the cimom's static instance repository?? If written to xenstore, then as Gareth pointed out why use a middleman ** jim sighs **.
I would like to get this resolved quickly so we can move the provider forward. Also would like to get the new code base running on SLES as I've abandoned the OpenWBEM-based provider.
I can send the shim for review or commit it to the repository after determining where it belongs in the tree.
Regards,
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
Home