[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project



Daniel Veillard wrote:
> On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
>> Hi,
>>
>> I am moving this thread here as this seems more appropriate.
>> Sorry it has taken so long..
>>
>> Here are 2 things that really get in the way of moving my existing
>> installations to libvirt:
>> * I tend to store much meta data with each VM instance: it can be things
>> like ownership (contact details as text), monitoring info (sms phone
>> numbers), backup (list of paths), firewall rules (custom syntax, with
>> failover rules, etc), etc.
>> At the moment, these extra bits of information consist of just a few
>> optional lines of shell in each VM's definition file. I can extend these
>> whenever I need, enumerate the VMs using the standard mechanism and
>> trigger my specific actions as needed (firewall rules, backup or whatever).
>> I see no way of doing this with libvirt. But please correct me if I am
>> wrong.
> 
>   One of the things I'm gonna do post 0.8.0 is allow to bundle comments
> and elements from a foreign namespace in the libvirt XML definition.
> 
>   Currently libvirt will happilly consume such a definition but all the
> extra are lost, basically at parse time we just extract the informations
> we know about, and everything else is lost. I want to provide clean ways
> to add metadata coming from the user and preserve them. I will probably
> limit the places where such metadata will be allowed:
> 
>   1/ to avoid the full complexity of an XML structured editor within
>      libvirt
>   2/ to not have to completely modify our configuration reading and
>      saving code, but add this as an extra layer
>   3/ to be able to modify the Relax-NG schemas in a reasonnable way
>      to allow those elements from foreign namespaces
> 
>   It's not a piece of cake, there will have to be some limitation and
> heuristics to avoid the extreme complexity and changes that a full tree
> preservation system would requires, but I think that should be
> sufficient for your kind of use case,
Yes, I think it would. Please do contact me again when that's ready for
testing and I'll give it a go.

Cheers
Antoine


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]