[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