From: Andrew Cooper <andrew.cooper3@citrix.com>
To: sparvu@systemdatarecorder.org
Cc: xen-devel@lists.xen.org
Subject: Re: domains being migrated state message improvements
Date: Fri, 2 May 2014 18:37:51 +0100 [thread overview]
Message-ID: <5363D7EF.3030600@citrix.com> (raw)
In-Reply-To: <1399049215.3861.35.camel@nereid>
On 02/05/14 17:46, Stefan Parvu wrote:
>> So a human can take a look at a system and see if anything looks
>> obviously wrong.
> and in our case, it is indeed wrong, or ... confusing - Man page says
> what we should expect from the state field.
Which manpage?
> But instead we see ------
> How one should interpret that ? Even interactively :) vanished, not
> available, what really happened there ?!
>
> First of all this should be documented and explained somewhere.
It is. That would be "not running and not blocked" which is a valid
state for a VM to be in.
The comment in Xen still appears accurate:
/*
* - domain is marked as blocked only if all its vcpus are blocked
* - domain is marked as running if any of its vcpus is running
*/
Blocked gets set whenever a vcpu uses a SCHEDOP_block or SCHEDOP_poll
hypercall. The former for blocking until any event arrives, the latter
when waiting for a specific event. SCHEDOP_block is used by guests when
idle.
With vcpu oversubscription, it is easy to have none of the vcpus running
at the moments when their state are sampled. It is also easy for a
completely idle guest to have all vcpus blocked.
As a result, all 4 possible states of blocked/not blocked/running/not
running are valid.
Not blocked and not running therefore means "domain is not idle, but not
scheduled" which completely matches your description of oversubscribed
host with busy VMs.
>
>
>> How? it uses ncurses to be interactive on the terminal. Collecting this
>> output with automated tools is impractical.
> you put xentop on batch mode to record data for long periods of time.
> store it and analyze it.
Wow - you learn something every day. I was completely unaware of xentop
batch mode.
~Andrew
next prev parent reply other threads:[~2014-05-02 17:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-02 13:16 domains being migrated state message improvements Stefan Parvu
2014-05-02 13:23 ` Ian Campbell
2014-05-02 13:31 ` Stefan Parvu
2014-05-02 14:15 ` Ian Campbell
2014-05-03 7:41 ` Stefan Parvu
2014-05-02 13:24 ` Andrew Cooper
2014-05-02 13:29 ` Ian Campbell
2014-05-02 13:40 ` Andrew Cooper
2014-05-02 14:15 ` Ian Campbell
2014-05-02 15:47 ` Stefan Parvu
2014-05-02 15:55 ` Andrew Cooper
2014-05-02 16:46 ` Stefan Parvu
2014-05-02 17:37 ` Andrew Cooper [this message]
2014-05-02 17:59 ` Stefan Parvu
2014-05-02 20:22 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5363D7EF.3030600@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=sparvu@systemdatarecorder.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.