Re: [vdsm] [Engine-devel] Network related hooks in vdsm
by Igor Lvovsky
----- Original Message -----
> From: "Simon Grinberg" <simon(a)redhat.com>
> To: "Igor Lvovsky" <ilvovsky(a)redhat.com>
> Cc: "Dan Yasny" <dyasny(a)redhat.com>, "vdsm-devel" <vdsm-devel(a)lists.fedorahosted.org>, "engine-devel"
> <engine-devel(a)ovirt.org>
> Sent: Wednesday, October 10, 2012 5:03:52 PM
> Subject: Re: [Engine-devel] Network related hooks in vdsm
>
>
>
> ----- Original Message -----
> > From: "Igor Lvovsky" <ilvovsky(a)redhat.com>
> > To: "vdsm-devel" <vdsm-devel(a)lists.fedorahosted.org>,
> > "engine-devel" <engine-devel(a)ovirt.org>
> > Cc: "Dan Yasny" <dyasny(a)redhat.com>
> > Sent: Wednesday, October 10, 2012 4:47:28 PM
> > Subject: [Engine-devel] Network related hooks in vdsm
> >
> > Hi everyone,
> > As you know vdsm has hooks mechanism and we already support dozen
> > of
> > hooks for different needs.
> > Now it's a network's time.
> > We would like to get your comments regarding our proposition for
> > network related hooks.
> >
> > In general we are planning to prepare framework for future support
> > of
> > bunch network related hooks.
> > Some of them already proposed by Itzik Brown [1] and Dan Yasny [2].
> >
> > Below you can find the additional hooks list that we propose:
> >
> > Note: In the first stage we can implement these hooks without any
> > parameters, just to provide an entry point
> > for simple hooks.
> >
> > Networks manipulation:
> > - before_add_network(conf={}, customProperty={})
> > - after_add_network(conf={}, customProperty={})
> > - before_del_network(conf={}, customProperty={})
> > - after_del_network(conf={}, customProperty={})
> > - before_edit_network(conf={}, customProperty={})
> > - after_edit_network(conf={}, customProperty={})
> > - TBD
>
> + VM networking related points in addition to before/after vm
> start/stop
> before_hotplug_nic(conf={}, customProperty={})
> *after_hotplug_nic(conf={}, customProperty={})
> before_hotunplug_nic(conf={}, customProperty={})
> *after_hotunplug_nic(conf={}, customProperty={})
>
> * Not sure about use case for those two
>
Yep, part of them already proposed by Itzik (look at [1])
> The above will require VM IDs and networks? Sorry that I did not look
> into the actual implementation of the above naming is more of a
> guess work, but I think the meaning is clear. There may be other VM
> networking related entry points I've missed.
>
> >
> > Bondings manipulations:
> > - before_add_bond(conf={}, customProperty={})
> > - after_add_bond(conf={}, customProperty={})
> > - before_del_bond(conf={}, customProperty={})
> > - after_del_bond(conf={}, customProperty={})
> > - before_edit_bond(conf={}, customProperty={})
> > - after_edit_bond(conf={}, customProperty={})
> > - TBD
> >
> > General purpose:
> > - before_persist_network
> > - after_persist_network
> >
> >
> > Now we just need to figure out the use cases.
> >
> > Your input more than welcome...
> >
> > [1] http://gerrit.ovirt.org/#/c/7224/ - Adding hooks support for
> > NIC hotplug
> > [2] http://gerrit.ovirt.org/#/c/7547/ - Hook: Cisco VM-FEX
> > support
> >
> >
> > Regards,
> > Igor Lvovsky
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
11 years, 6 months
Re: [vdsm] Mom Balloon policy issue
by agl＠us.ibm.com
Thanks for writing this. Some thoughts inline, below. Also, cc'ing some lists
in case other folks want to participate in the discussion.
On Tue, Oct 09, 2012 at 01:12:30PM -0400, Noam Slomianko wrote:
> Greetings,
>
> I've fiddled around with ballooning and wanted to raise a question for debate.
>
> Currently as long as the host is under memory pressure, MOM will try and reclaim back memory from all guests with more free memory then a given threshold.
>
> Main issue: Guest allocated memory is not the same as the resident (physical) memory used by qemu.
> This means that when memory is reclaimed back (the balloon is inflated) we might not get as much memory as planed back (or non at all).
>
> *Example1 no memory is reclaimed back:
> name | allocated memory | used by the vm | resident memory used in the host by qemu
> Vm1 | 4G | 4G, | 4G
> Vm2 | 4G | 1G | 1G
> - MOM will inflate the balloon in vm2 (as vm has no free memory) and will gain no memory
One thing to keep in mind is that VMs having less host RSS than their memory
allocation is a temporary condition. All VMs will eventually consume their full
allocation if allowed to run. I'd be curious to know how long this process
takes in general.
We might be able to handle this case by refusing to inflate the balloon if:
(VM free memory - planned balloon inflation) > host RSS
> *Example1 memory is reclaimed partially:
> name | allocated memory | used by the vm | resident memory used in the host by qemu
> Vm1 | 4G | 4G, | 4G
> Vm2 | 4G | 1G | 1G
> Vm3 | 4G | 1G | 4G
> - MOM will inflate the balloon in vm2 and vm3 slowly gaining only from vm3
The above rule extension may help here too.
> this behaviour might in the cause us to:
> * spend time reclaiming memory from many guests when we can reclaim only from a subgroup
> * be under the impression that we have more potential memory to reclaim when we do
> * bring inactive VMs dangerously low as they are constantly reclaimed (I've had guests crashing from kernel out of memory)
>
>
> To address this I suggest that we collect guest memory stats from libvirt as well, so we have the option to use them in our calculations.
> This can be achieved with the command "virsh dommemstat <domain>" which returns
> actual 3915372 (allocated)
> rss 2141580 (resident memory used by qemu)
I would suggest adding these two fields to the VmStats that are collected by
vdsm. Then, to try it out, add the fields to the GuestMemory Collector. (Note:
MOM does have a collector that gathers RSS for VMs. It's called GuestQemuProc).
You can then extend the Balloon policy to add a snippet to check if the proposed
balloon adjustment should be carried out. You could add the logic to the
change_big_enough function.
> additional topic:
> * should we include per guest config (for example a hard minimum memory cap, this vm cannot run effectively with less then 1G memory)
Yes. This is probably something we want to do. There is a whole topic around
VM tagging that we should consider. In the future we will want to be able to do
many different things in policy based on a VMs tag. For example, some VMs may
be completely exempt from ballooning. Others may have a minimum limit.
I want to avoid passing in the raw guest configuration because MOM needs to work
with direct libvirt vms and with ovirt/vdsm vms. Therefore, we want to think
carefully about the abstractions we use when presenting VM properties to MOM.
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 6 months
Cancelled: VDSM Sync call
by abaron＠redhat.com
A single instance of the following meeting has been cancelled:
Subject: VDSM Sync call
Organizer: "Ayal Baron" <abaron(a)redhat.com>
Location: intercall 8425973915
Time: Monday, October 8, 2012, 4:30:00 PM - 5:30:00 PM GMT +02:00 Jerusalem
Invitees: vdsm-devel(a)lists.fedorahosted.org; tasleson(a)redhat.com; thang.pham(a)us.ibm.com; ilvovsky(a)redhat.com; kroberts(a)redhat.com; GARGYA(a)de.ibm.com; lpeer(a)redhat.com; bressers(a)redhat.com; Dustin.Schoenbrun(a)netapp.com; zwu.kernel(a)gmail.com
*~*~*~*~*~*~*~*~*~*
Holiday in Israel.
If someone has a specific agenda item that needs to be discussed, please reply and I will try to reschedule for later in the week.
11 years, 7 months
Re: [vdsm] Change in vdsm[master]: Use 'yum clean expire-cache' instead of 'yum clean all'
by Ryan Harper
* Alon Bar-Lev <alonbl(a)redhat.com> [2012-09-27 13:38]:
> Alon Bar-Lev has posted comments on this change.
>
> Change subject: Use 'yum clean expire-cache' instead of 'yum clean all'
> ......................................................................
>
>
> Patch Set 2:
>
> Ok... I was discussing... I think that if you don't get +1 from parties you should wait... :)
>
> I see -1 as final decision... for the entire change... or if contributer is not cooperating.
>
I'm interested in a little clarity here.
As I see it, -1 means you don't want the current version submitted.
I like the idea of putting a patch on hold while various issues are
discussed, and it seems like a -1 is the right idea here since the
submitter can reply and original reviewer can re-review and remove a -1
if the submitter has fully explained the issue. Additionaly the
submitter can resubmit with changes (and the -1 is removed anyhow).
What is the maintainer view of how best to use -1? And if we don't use
a -1, how does one do the above?
> --
> To view, visit http://gerrit.ovirt.org/8206
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I1019690e4a27caeff923655f9562892ce7f909af
> Gerrit-PatchSet: 2
> Gerrit-Project: vdsm
> Gerrit-Branch: master
> Gerrit-Owner: Mark Wu <wudxw(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Alon Bar-Lev <alonbl(a)redhat.com>
> Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
> Gerrit-Reviewer: Doron Fediuck <dfediuck(a)redhat.com>
> Gerrit-Reviewer: Douglas Schilling Landgraf <dougsland(a)redhat.com>
> Gerrit-Reviewer: Greg Padgett <gpadgett(a)redhat.com>
> Gerrit-Reviewer: Mark Wu <wudxw(a)linux.vnet.ibm.com>
> _______________________________________________
> vdsm-patches mailing list
> vdsm-patches(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-patches
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
11 years, 7 months
API: Supporting internal/testing interfaces
by agl＠us.ibm.com
Hi,
A recent patch: http://gerrit.ovirt.org/#/c/8286/1 has brought up an important
issue regarding the vdsm API and I would like to open up a discussion about how
we should expose testing/internal interfaces in the next-generation vdsm API.
The above change exposes an internal HSM verb 'sendExtendMsg' via the xmlrpc
interface. There is no doubt that this is useful for testing and debugging the
storage mailbox functionality. Until now, all new APIs were required to be
documented in the vdsm api schema so that they can be properly exported to end
users. But we don't really want end users to consume this particular API.
How should we handle this? I see a few options:
1) Don't document the API and omit it from the schema. This is the patch's
current approach. I do not favor this approach because eventually the xmlrpc
server will be going away and then we will lose the ability to use this new
debugging API. We need to decide how to support debugging interfaces going
forward.
2) Expose it in the schema as a debugging API. This can be done by extending
the symbol's dictionary with {'debug': True}. Initially, the API documentation
and code generators can simply skip over these symbols. Later on, we could
generate an independent libvdsm-debug.so library that includes these debugging
APIs.
Thoughts?
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 7 months
NFS issues with ovirt 3.1 on Fedora
by smizrahi＠redhat.com
I have a patch up on gerrit that should fix the errors everyone have been experiencing.
This seems to affect everyone differently (and some non at all) so I want to have as many people as possible tick the verify flag.
The kernel folk suspect there might be a memory corruption bug in the kernel so if this doesn't fix everyone's problem we might need this person's help tracking this issue.
It never actually reproduced for me after the initial fix so it's hard for me to do proper testing.
Thanks! and sorry for the inconvenience.
http://gerrit.ovirt.org/#/c/8356/
11 years, 7 months
Re: [vdsm] Change in vdsm[master]: Add support for KVM on IBM POWER processor (ppc64)
by Ryan Harper
* Pradipta Kumar Banerjee <bpradip(a)in.ibm.com> [2012-10-02 06:41]:
> [snip]
> > Line 330: """
> > Line 331: arch = getPlatformArch()
> > One last nit. Unless we have another caller for getPlatformArch() I suggest just doing:
> >
> > arch = platform.machine()
> Hi Ryan,
> I thought about it but at this point I'm not sure of other callers for
> getPlatformArch(). However I'm of the opinion of retaining the method.
> Is it a concern ?
Since you're introducting the call, no one else is using it yet. If in
the future getPlatformArch needs to be more complicated it can be added
at that time.
For now, let's minimize the amount of code we have to maintain. As a
reader of the code, if I see arch = getPlatformArch(), I need to then
look up the function. The current implementation is trivial enough not
to require a function; it adds nothing to readability to have a function
but it does increase the lines of code.
>
> >
> > and dropping the other function altogether.
> > Line 332: if arch == 'x86_64':
> > Line 333: out, err, ret = _logExec([EX_DMIDECODE, "-s", "system-uuid"])
> > Line 334: out = '\n'.join( line for line in out.splitlines()
> > Line 335: if not line.startswith('#') )
> >
> >
> > --
> > To view, visit http://gerrit.ovirt.org/8094
> > To unsubscribe, visit http://gerrit.ovirt.org/settings
> >
> > Gerrit-MessageType: comment
> > Gerrit-Change-Id: I2d8767c52488ab8083123d0ec1e789d3857e2358
> > Gerrit-PatchSet: 4
> > Gerrit-Project: vdsm
> > Gerrit-Branch: master
> > Gerrit-Owner: Pradipta Banerjee <bpradip(a)in.ibm.com>
> > Gerrit-Reviewer: Alon Bar-Lev <alonbl(a)redhat.com>
> > Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
> > Gerrit-Reviewer: Pradipta Banerjee <bpradip(a)in.ibm.com>
> > Gerrit-Reviewer: Ryan Harper <ryanh(a)us.ibm.com>
> >
>
>
> --
> Regards,
> Pradipta
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
11 years, 7 months
