Re: [Libvir] Request for additional entry points
On Tue, Apr 18, 2006 at 12:40:01PM -0400, Daniel Veillard wrote:
On Fri, Apr 14, 2006 at 10:38:23AM -0400, Bret McMillan wrote:
> I think we're confusing the notion of what a passive domain is with what
> config files happen to be sitting on / exposed to the dom0 machine. I
> could very easily look at having an rdbms store the info about the
> passive domain, hand that down to the dom0 via rpc, and directly call
> the createLinux call. To me, that's still a passive domain, even though
> it's configs haven't touched disk yet.
Yup, to me they are different level.
> I guess I'm also struggling to understand why you'd toss this into
> xenstore... it just seems this is a higher level concept that needs to
> be tracked in too specific a way by management systems.
The reason it would be useful to save this in xenstore is to garantee
the same vision between different application managing that node (for example
a remote supervision tool and a local launcher used by the user). Otherwise
The trouble is this imoses a representational model on the application, which does
not neccessarily mesh with the requirements of the application. So by having
this in libvirt/xenstore, either the application's model will be compromised,
or the app will have its master model how it likes & have to worry about keeping
a denormalization of the master model synced to libvirt / xenstore. In the latter
case, you're now loosing the guareentee of shared app vision this was trying to
achieve in the first place.
just keeping this information in libvirt own memory would be just
fine,
I'm still unsure the need to synchronize is really there.
What would be the application gain in this scenario - why wouldn't the app
just store manage it directly itself & pass the XML to libvirt at time of
domain creation?
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 -=|