[Engine-devel] direct manipulation of libvirt
Itamar Heim
iheim at redhat.com
Fri Aug 9 15:02:24 UTC 2013
On 08/08/2013 09:01 PM, Dead Horse wrote:
> I guess ultimately what would be nice is the provision to manipulate
> some the more advanced features if desired via API/CLI/GUI if desired.
> Correct these things can be manipulated now by custom properties but TBH
> they are a pain. You need to enter a key in the correct format into the
> custom properties dialog. Also if the function does not exist already
> you need to write the python hook to add it even if it is something
> simple like manipulating a libvirt DOM XML option. Would it not be nicer
> to the admin were to be able to simply (like is now with VM options)
> click advanced and they are presented advanced options GUI? The
> reasoning for this are cases at times to manipulate or want to have
> access to these options and be given the choice to choose if I want to
> do so. Pretty much every KVM management solution exposes the below
> options either by default or by advanced options. I understand the
> reasoning for wanting to hide or make it difficult to use some of what
> is in the below examples but the point is that again I should at least
> have the choice to do so in an easier manner then the hooking/custom
> props they way they are now.
>
> Example 1:
> "Add Disk UI"
> What we can do with libvirt:
> <disk ...>
> <driver io='threads | native' cache='default | none | writeback |
> writethrough'/>
> ...
> </disk>
> So Advanced UI Options for
> Disk IO Policy = threads | native
> Disk Cache Policy = default | none | writeback | writethrough
>
> Accordingly as well disk format:
> raw - preallocated
> raw - sparse
> qcow2- preallocated
> qcow2 - sparse
> qcow2 - pre-allocate metadata Yes/No ?
> qed - sparse
> and so on....
> For example now qcow2 is not allowed on NFS storage domains but if I the
> admin want to allow for this or use it, I should at least be given the
> choice as there is no reason it does not work.
Ayal - thoughts on above?
>
> Example 2
> "Add Network UI"
> What we can do with libvirt:
> <forward mode='route | bridge | private | vepa | passthrough | hostdev'>
> <interface dev='bond0'/>
> <interface dev='bond1'/>
> <interface dev='eth0'/>
> <interface dev='eth1'/>
> <interface dev='eth2'/>
> <interface dev='eth3'/>
> </forward>
> Right now all we can do is select a mode=bridge.
> How about under advanced option for:
> Network Mode= route | bridge | private | vepa | passthrough | hostdev
> Admin does thowever know that some of the above of course may require
> some networking prerequisites which must be satisfied first.
>
> Something else I have seen other KVM solutions provide in the case of
> the above examples is just a direct libvirt domain editor in GUI. One
> can simply load/preview the generated libivrt domain xml and add/edit
> options, validate and run with the changes either temporarily or
> permanently.
>
Livnat - thoughts on above?
> - DHC
>
>
>
> On Tue, Aug 6, 2013 at 2:56 PM, Itamar Heim <iheim at redhat.com
> <mailto:iheim at redhat.com>> wrote:
>
> 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/
> <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 at redhat.com <mailto:nslomian at redhat.com>
> <mailto:nslomian at redhat.com <mailto:nslomian at 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 at gmail.com
> <mailto:deadhorseconsulting at gmail.com>
> <mailto:deadhorseconsulting at __gmail.com
> <mailto:deadhorseconsulting at gmail.com>>>
> To: "engine-devel" <engine-devel at ovirt.org
> <mailto:engine-devel at ovirt.org>
> <mailto:engine-devel at ovirt.org
> <mailto:engine-devel at 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 at ovirt.org <mailto:Engine-devel at ovirt.org>
> <mailto:Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>__>
> http://lists.ovirt.org/__mailman/listinfo/engine-devel
> <http://lists.ovirt.org/mailman/listinfo/engine-devel>
>
>
>
>
>
> _________________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org <mailto:Engine-devel at ovirt.org>
> http://lists.ovirt.org/__mailman/listinfo/engine-devel
> <http://lists.ovirt.org/mailman/listinfo/engine-devel>
>
>
>
More information about the Engine-devel
mailing list