[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



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.

* not everything is exposed via libvirt:
virsh can retrieve vncdisplay
but libvirt (or at least the python bindings) does not. How come?
This happens to be one thing I need for writing a libvirt backend for my
virtual desktop software.

Cheers
Antoine




Antoine Martin wrote:
> Hi Daniel,
> 
> I'll take a look and get back to you asap.
> 
> Cheers
> Antoine
> 
> Daniel P. Berrange wrote:
>> On Tue, Mar 23, 2010 at 03:00:28AM +0700, Antoine Martin wrote:
>>> On 03/23/2010 02:15 AM, Anthony Liguori wrote:
>>>> On 03/22/2010 12:55 PM, Avi Kivity wrote:
>>>>>> Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by 
>>>>>> Anthony.
>>>>>> There's numerous ways that this can break:
>>>>> I don't like it either.  We have libvirt for enumerating guests.
>>>> We're stuck in a rut with libvirt and I think a lot of the 
>>>> dissatisfaction with qemu is rooted in that.  It's not libvirt that's 
>>>> the probably, but the relationship between qemu and libvirt.
>>> +1
>>> The obvious reason why so many people still use shell scripts rather 
>>> than libvirt is because if it just doesn't provide what they need.
>>> Every time I've looked at it (and I've been looking for a better 
>>> solution for many years), it seems that it would have provided most of 
>>> the things I needed, but the remaining bits were unsolvable.
>> If you happen to remember what missing features prevented you choosing
>> libvirt, that would be invaluable information for us, to see if there
>> are quick wins that will help out. We got very useful feedback when
>> recently asking people this same question
> 
>> http://rwmj.wordpress.com/2010/01/07/quick-quiz-what-stops-you-from-using-libvirt/
> 
>> Allowing arbitrary passthrough of QEMU commands/args will solve some of
>> these issues, but certainly far from solving all of them. eg guest cut+
>> paste, host side control of guest screen resolution, easier x509/TLS 
>> configuration for remote management, soft reboot, Windows desktop support
>> for virt-manager, host network interface management/setup, etc
> 
>> Regards,
>> Daniel


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