7:43 p.m.
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
10:49 a.m.
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
6:49 p.m.
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
change disk IO policies
change dsk Cache Policies
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?
-DHC
On Sun, Aug 4, 2013 at 2:49 AM, Noam Slomianko <nslomian(a)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>
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
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
9:01 p.m.
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.
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.
- DHC
On Tue, Aug 6, 2013 at 2:56 PM, Itamar Heim <iheim(a)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(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<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<http://lists.ov...
>
>
>
>
>
> ______________________________**_________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/**mailman/listinfo/engine-devel<http://lists.ov...
>
>
6:02 p.m.
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(a)redhat.com
<mailto:iheim@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(a)redhat.com <mailto:nslomian@redhat.com>
<mailto:nslomian@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>
<mailto:deadhorseconsulting@__gmail.com
<mailto:deadhorseconsulting@gmail.com>>>
To: "engine-devel" <engine-devel(a)ovirt.org
<mailto:engine-devel@ovirt.org>
<mailto:engine-devel@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>
<mailto:Engine-devel@ovirt.org <mailto:Engine-devel@ovirt.org>__>
http://lists.ovirt.org/__mailman/listinfo/engine-devel
<http://lists.ovirt.org/mailman/listinfo/engine-devel>
_________________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org <mailto:Engine-devel@ovirt.org>
http://lists.ovirt.org/__mailman/listinfo/engine-devel
<http://lists.ovirt.org/mailman/listinfo/engine-devel>
4122
days inactive
4129
days old
5 comments
3 participants
participants (3)
-
Dead Horse -
Itamar Heim -
Noam Slomianko