Re: [Engine-devel] direct manipulation of libvirt
Since you cannot know what kind of changes the user will do in libvirt you cannot be sure
that VDSM will be able to live with them.
By "Allowing" this officially you will create an impression that it is safe,
which will cause frustration for the user if VDSM breaks.
So keeping this as "do at your own risk, we want nothing to do with it" sounds
like a good plan to me :)
But ignoring that, what kind of behaviour would you like? maybe the ability to pass custom
libvirt flags on VM startup?
This can be pretty easily Implemented as an all purpose hook, isn't it? (write once,
pass any argument you like)
----- Original Message -----
From: "Dead Horse" <deadhorseconsulting(a)gmail.com>
To: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Friday, August 2, 2013 7:43:31 PM
Subject: [Engine-devel] direct manipulation of libvirt
A broad question here, perhaps not a possibility but I figured I would toss it out there
anyway.
VDSM is great at what it does, however there are those times when direct manipulation of
libvirt or libvirt VM configuration would be very handy. The safe defaults and tested VM
configurations that VDSM/ovirt provides are great. However at times it would be nice to
simply connect to a hypervisor managed by ovirt/vdsm and make a couple changes to a VM
(via virt-manager or directly via virsh).
This could be enabling a new feature that has made it's way into QEMU/libvirt/KVM or
tweaking a VM configuration for whatever reason. Now there is nothing stopping someone
from doing this now either directly or via VDSM hooks. Hooks are a pain along with the
custom properties to jack them into engine. Direct manipulation of libvirt since it has
been upstarted by vdsm results in an unhappy VDSM/engine.
Thoughts?
- DHC
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel