AUTO: Yih-Herng Chuang is out of the office (returning 12/13/2011)
by Yih-Herng Chuang
I am out of the office until 12/13/2011.
I will respond to emails when return back to office. If there is an
emergency please contact Doug Jans for technical issues or my manager Carol
Roth.
Note: This is an automated response to your message "vdsm-devel Digest,
Vol 7, Issue 13" sent on 12/9/2011 5:00:17.
This is the only notification you will receive while this person is away.
12 years, 6 months
ovirt-guest-agent memory statistics
by agl@us.ibm.com
To support decisions regarding a host's capacity to run virtual machines, it is
useful to have an expanded set of guest memory statistics. These should be
collected by the ovirt-guest-agent and made available by the vdsm getVmStats()
API. Once this has been done, it will be possible to write a host-side MOM
policy for auto-ballooning.
The current set of vetted memory stats is published in the virtio specification:
http://ozlabs.org/~rusty/virtio-spec/virtio-0.9.3.pdf (Appendix G, page 42)
swap_in - the total number of pages swapped in
swap_out - the total number of pages swapped out
minflt - the total number of minor page faults
majflt - the total number of major page faults
memfree - the amount of memory that is completely unused (in Linux: MemFree)
memtot - the total amount of available memory (in Linux: MemTotal)
In Linux, these values can all be obtained by reading /proc/meminfo and
/proc/vmstat. On Windows there is an existing implementation in the virtio
balloon driver.
How does everyone feel about adding these to the current set of guest stats?
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
API design and plan
by agl@us.ibm.com
Hi everyone. On today's VDSM call we discussed the requirements, design, and
plan for updating the API to include support for QMF and single-host REST API.
All members present arrived at a general consensus on the best way to design the
next-generation API. I have tried to capture this discussion in the oVirt wiki:
http://ovirt.org/wiki/Vdsm_API
Please take a look at this page and let's discuss any changes that may be needed
in order to adopt it as a working plan that we can begin to execute. Thanks!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
Fix error message "UnboundLocalError: local variable 'path' referenced before assignment" when running vm.
by Jarod.w
Hi, All
The patch will fix error message "UnboundLocalError: local variable
'path' referenced before assignment" when running vm.
thanks.
>From 1f99c4f5b04100231c8712f2caf97d11dcc9eb37 Mon Sep 17 00:00:00 2001
From: "jarod.w" <work.iec23801(a)gmail.com>
Date: Tue, 6 Dec 2011 14:00:58 +0800
Subject: [PATCH] Fix error message "UnboundLocalError: local variable 'path'
referenced before assignment" when running vm.
When the drive argument can't be parsed in _prepareVolumePath function, the
self.log.info statement will report the error in the /var/log/vdsm/vdsm.log
because the local variable 'path' isn't assigned. The patch adds the else
statement to assign the local variable.
---
vdsm/clientIF.py | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/vdsm/clientIF.py b/vdsm/clientIF.py
index 9d6b942..10e3a24 100644
--- a/vdsm/clientIF.py
+++ b/vdsm/clientIF.py
@@ -590,6 +590,9 @@ class clientIF:
path = drive
elif os.path.exists(drive):
path = drive
+ else:
+ self.log.info("invaild drive : %s" % str(drive) )
+ path = ''
self.log.info("prepared volume path: %s" % path)
return path
--
1.7.7.3
12 years, 6 months
reorganizing constants and config
by smizrahi@redhat.com
I want to suggest a different way of handling constants.py and config.py
the current way is clumsy and makes making convoluted code easy.
GLOBAL VARIABLES ARE BAD. It's not something I invented. It's well
accepted that proper scoping yields better code.
The way we use those two files shows how much of a mess globally
accessible variable can be.
Not putting paths to executable in constants.py
-----------------------------------------------
Instead we should have a module for each utility executable. The module
should wrap the utility with a pythonic interface. That way there is no
reason for more then one module to have access to a utility's path.
For example:
cat.py
------
_CAT_PATH = @CAT_PATH@
def cat(files):
cmd = [_CAT_PATH] + files
out, err = exec(cmd)
return out
Now there is no need to know where cat is. You have a proper interface
to use. Preventing people from re-wrapping the utility over and over.
This in turn means you have a canonical wrapper that is more likely to work.
Every other constant
--------------------
Other constants should be moved to their proper modules and used only
when importing the module makes sense this will give you another step
where you make sure your decencies are correct.
Configuration
-------------
Configuration files are just parameters to the program. They should be
treated as such. Their scope should not leave the main class of the
project. In our case VDSM is actually 2 projects meshed together like
Siamese twins so I think clientIf.py and hsm.py should be the only ones
with access to the config. Everything else should expect to get those
values in a regular programmatic fashion.
In my opinion these changes will make VDSM a lot more flexible, will
make more parts independent and easily separated and at that end help us
make VDSM better for generations to come.
You can help!
-------------
* Start by taking you favorite utility and write a proper safe module
around it.
* When writing new code try and not access the configuration directly.
* Modules are free (really) don't just put stuff in misc\utils try and
put some order to things.
12 years, 6 months
can't start vdsmd and failed to connect it
by Jenna Johnson
Folks,
Installed vdsm,nothing abnormal encountered,but when start vdsmd:
$ sudo service vdsmd start
vdsm: libvirt already configured for vdsm [
OK ]
Starting iscsid:
Starting libvirtd daemon:
Starting up vdsm daemon:
vdsm start [
OK ]
$ sudo service vdsmd status
VDS daemon is not running
and then all connctions fail:
$ vdsClient -s 0 getVdsCapabilities
Connection to 0:54321 refused
Any thoughts?
12 years, 6 months
Proposed next-generation vdsm API
by agl@us.ibm.com
Recently we've had some very productive discussions concerning the VDSM API. I
want to attempt to refocus the discussion around an emerging proposal and see if
we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that
a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to
vdsm
2.) Full vdsm capabilities are exposed without requiring ovirt-engine
- ovirt components should be modular and independently useful
- Some deployments might want to manage nodes without ovirt-engine
3.) Standardized protocol with low overhead
- Required for widespread adoption
4.) Support for asynchronous tasks and events
- Needed by ovirt-engine and other consumers
Based on these requirements, the following proposal has started to emerge:
Create a REST API that will provide all of the functionality that is currently
available via the xmlrpc interface (with the goal of deprecating xmlrpc once it
becomes mature enough). To support advanced clustering features that
ovirt-engine is planning, we'll write an QMF broker that can proxy the REST API
onto a message bus. ovirt-engine will interact with vdsm exclusively over this
bus but the REST API will be the principle API and the entry point for ISV apps.
A REST API provides a light-weight and standard way to access all of the vdsm
functionality.
The REST API will handle events by exposing a new 'events' collection at the api
root. REST users will use some sort of polling to collect these events. The
details of this interface are being worked on. Several ways for minimizing the
impact of polling have been discussed. The QMF broker can expose a
publish/subscribe model for events as appropriate.
Is this model an acceptable way to improve the vdsm API? I would like to hear
the opinions of ovirt-engine developers, vdsm developers, and other
stakeholders. Thanks for providing feedback on this proposal!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
12 years, 6 months
AUTO: Yih-Herng Chuang is out of the office (returning 12/05/2011)
by Yih-Herng Chuang
I am out of the office until 12/05/2011.
I will respond to emails when return back to office. If there is an
emergency please contact Doug Jans for technical issues or my manager Carol
Roth.
Note: This is an automated response to your message "vdsm-devel Digest,
Vol 7, Issue 3" sent on 12/2/2011 5:00:48.
This is the only notification you will receive while this person is away.
12 years, 6 months