>
> Only the memory mapped for the guest is striclty allocated from the
> NUMA node selected. The QEMU overhead should float on the host NUMA
> nodes. So it seems that the "reserved_host_memory_mb" is enough.
>
Even if that would be true and overhead memory could float in NUMA
nodes it generally
> Lastly, qemu has overhead that varies depending on what you're doing in the
> guest. In particular, there are various IO queues that can consume
> significant amounts of memory. The company that I work for put in a good
> bit of effort engineering things so that they work more reliably, and
Hi Roland,
> I don't think it would be difficult to add support for non-periodic
> metrics/alarms. There are a couple of approaches we could take, so a design
> discussion would be good to have if you are interested in implementing this.
> This is feature that we are not working on right now,
On 22 Jan 2016 17:43, "James Bottomley" <
james.bottom...@hansenpartnership.com> wrote:
>
> On Fri, 2016-01-22 at 14:58 +0100, Premysl Kouril wrote:
> > Hi Matt, James,
> >
> > any thoughts on the below notes?
>
> To be honest, not really. You've repe
y,
> this component could be added to the Agent.
>
> Using the Monasca Alarm API, an alarm could be defined, such as
> max(snmp{}) > 0.
>
> The latency for a min/max alarm expression in Monasca is very low.
>
> Regards --Roland
>
>
> On 1/18/16, 9:07 AM, "Pre
Hi Matt, James,
any thoughts on the below notes?
Best Regards,
Prema
On 19 Jan 2016 20:47, "Premysl Kouril" <premysl.kou...@gmail.com> wrote:
> Hi James,
>
>
> >
> > You still haven't answered Anita's question: when you say "sponsor" do
> &
> I'm not a Nova developer. I am interesting in clarifying what you are
> asking.
>
> Are you asking for current Nova developers to work on this feature? Or
> s your company interested in having your developers interact with Nova
> developers?
>
> Thank you,
> Anita.
Both. We are first trying
Hi James,
>
> You still haven't answered Anita's question: when you say "sponsor" do
> you mean provide resources to existing developers to work on your
> feature or provide new developers.
>
I did, I am copy-pasting my response to Anita here again:
Both. We are first trying this "Are you
Hi Matt,
thanks for letting me know, we will definitely do reach you out if we
start some activity in this area.
To answer your question: main reason for LVM is simplicity and
performance. It seems from our benchmarks that LVM behavior when
processing many IOPs (10s of thousands) is more stable
Hello,
we are just evaluating Monasca for our new cloud infrastructure and I
would like to ask if there are any possibilities in current Monasca or
some development plans to address following use case:
We have a box which we need to monitor and when something goes wrong
with the box, it sends
Hello everybody,
we are a Europe based operator and we have a case for LVM based nova
instances in our new cloud infrastructure. We are currently
considering to contribute to OpenStack Nova to implement some features
which are currently not supported for LVM based instances (they are
only
11 matches
Mail list logo
