On Thu, 2006-04-13 at 12:00 -0400, libvir-list-request(a)redhat.com wrote:
We've discussed this before and I think the most compelling
argument for
passive domain support in libvirt (and even at a lower level such as
Xend) is the following scenario:
Let's say a user creates a virtual FC6 virtual machine that she is going
to use to test her apps under Gnome (she's a KDE user). The machine
isn't always there b/c she rarely needs it. She created it with some
nifty KDE tool that has yet to be written.
Of course, she finds out about this neat applet that you can use to
managing running domains. If there isn't a common way of accessing
passive domains then she won't see the FC6 VM.
Now, I don't think that *all* domains should have to have passive
equivalents (which is a requirement in the CIM provider today) because
of some of the scenarios you outlined. However, I think not attempting
to have a common API for passive domains is going to creative a mess as
we get a larger number of management tools.
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.
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.
--Bret