10:56 p.m.
On 08/06/2013 06:49 PM, Dead Horse wrote:
It would be nice to be able to enable certain types of VM's (or
just
purposely for whatever reason) to be able to use for example:
VEPA (macvtap)
Change VRAM sizes
is this covering this?
http://gerrit.ovirt.org/#/c/16803/
change disk IO policies
change dsk Cache Policies
there is a built-in custom property for this one?
change input type to usbtablet or PS2
(new qemu/libvirt features to play or test)
This of course should be limited to admin level roles as it would come
with the understanding of the possibility of things exploding in ones face.
Perhaps this could be implemented as a "Really Advanced Options" on a VM
visible to superuser or admin roles only?
this would be akin to custom properties, some of which come via vdsm,
just without a special gui on engine side (i.e., they don't need hooks
on vdsm since they are supported out of the box).
reason they are custom properties without dedicated UI is the use case
is rare.
other than some custom property to pass libvirt command line args, or
xml overrides, i think the custom proeprties/hooks (or vdsm builtin
support) is the cleanest one
-DHC
On Sun, Aug 4, 2013 at 2:49 AM, Noam Slomianko <nslomian(a)redhat.com
<mailto:nslomian@redhat.com>> wrote:
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
<mailto:deadhorseconsulting@gmail.com>>
To: "engine-devel" <engine-devel(a)ovirt.org
<mailto:engine-devel@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 <mailto:Engine-devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel