git-review
by smizrahi@redhat.com
I've recently encountered more and more people not using the git-review tool and manually pushing their changes to Gerrit using raw git commands.
Even though there is nothing wrong with doing things the hard way. I prefer not using an overly complicated error prone way to interact with Gerrit.
Last I checked the version of git-review in Fedora is broken but I suggest using pip anyway as it is always synced with the master branch.
Also, please use topics. Either use a BZ# or a topic codename (eg. live_migration, vdsm_api, nfs4_support) so people can skim the review list for topics they might want to review.
Be careful, it automatically uses current the branch name (unless you use -t) so if you giving your branches funny names (I know I do) don't forget to manually specify a topic.
More information.
http://wiki.openstack.org/GerritWorkflow
https://github.com/openstack-ci/git-review
11 years, 8 months
Strange input from oVirt-engine for create (VM) API
by agl@us.ibm.com
Hi all,
Today I was watching the vdsm log as ovirt-engine started a VM and I saw
something peculiar with how VM device addresses were specified. Here is a
sample of the python dictionary for the VM from vdsm.log (I reformatted it with
pprint for readability):
{'address': {' bus': '1',
' controller': '0',
' target': '0',
' type': 'drive',
'unit': '0'},
Notice the whitespace in the 'controller', 'target', and 'type' keys. Could
someone explain why this is happening? Is it deliberate or a bug?
Thanks!
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 8 months
new API verb: getVersionInfo()
by peet@redhat.com
…
New verb proposal: getVersionInfo()
Background
Right now VDSM has only one possibility to discover the peer VDSM
version — it is to call getVdsCapabilities(). All would be nice, but the
verb does a lot of stuff, including disk I/O (rpm data query). It is a
serious issue for high-loaded hosts, that can even trigger call timeout.
Rationale
Working in an environment with multiple VDSM versions, it is inevitable
to fall in a simple choice:
* always operate with one API, described once and forever
* use different protocol versions.
It is a common practice to reserve something in a protocol, that will
represent the protocol version. Any protocols w/o version info sooner or
later face the need to guess a version, that is much worse.
On the other hand, involving rpm queries and CPU topology calculation
into the protocol version discovery is an overkill. So the simplest way
is to reserve a new verb for it.
Usecases
It can be used in the future in *any* VDSM communication that can expose
version difference.
Implementation
Obviously, the usage of a new verb in the current release, e.g. RHEV-3.1
can be done only in try/catch way, 'cause RHEV-3.0 does not support it.
But to be able to use it in RHEV-3.2, we should already have it in 3.1.
Even if we will not use it yet, the future usecases are pretty
straightforward.
So pls comment it: http://gerrit.ovirt.org/#/c/8431/
--
Peter V. Saveliev
11 years, 8 months
Re: [vdsm] Change in vdsm[master]: schema: New type VmParameters
by agl@us.ibm.com
On Thu, Oct 18, 2012 at 02:12:58AM -0400, lvroyce(a)linux.vnet.ibm.com wrote:
> Royce Lv has posted comments on this change.
>
> Change subject: schema: New type VmParameters
> ......................................................................
>
>
> Patch Set 4:
>
> Adam,
> I saw 3 kinds of vm related description spread in the code:
>
> (1)vm.conf: query via vm.status()(vm.py), used as return value when changed vm's conf(changeCD, hotplugDisk)
>
> (2)vm.stats: query via vm.getStats()(vm.py), which is VM's live stats and used when calling getVmStats.(also used by MOM)
>
> (3)vm.parameter: parameter passed to vm.create().(API.py)
>
> You are trying to split is (3) from (1); But the live info should be (2) from (1) according to me.
To me, VmDefinition contains the hardware properties of the VM (things like
devices, amount of memory, number of cpus). It also contains things that can
only be known at runtime (VNC display port, device bus information (if not
specified in advance), current cdrom disk, etc). VmStatistics are different
because they are measured (network activity, cpu usage, etc). VmParameters is
like a streamlined VmDefinition where we remove items that cannot be specified
at create time.
> --
> To view, visit http://gerrit.ovirt.org/7839
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I00d1b9aed55cbfc2210c1a4091bce17d45b90e67
> Gerrit-PatchSet: 4
> Gerrit-Project: vdsm
> Gerrit-Branch: master
> Gerrit-Owner: Adam Litke <agl(a)us.ibm.com>
> Gerrit-Reviewer: Adam Litke <agl(a)us.ibm.com>
> Gerrit-Reviewer: Federico Simoncelli <fsimonce(a)redhat.com>
> Gerrit-Reviewer: Royce Lv <lvroyce(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Saggi Mizrahi <smizrahi(a)redhat.com>
>
--
Adam Litke <agl(a)us.ibm.com>
IBM Linux Technology Center
11 years, 8 months
vdsClient error after reinstalling vdsm
by lhornyak@redhat.com
Hi!
This is a low priority problem. Each time I reinstall vdsm from rpm, I get this error when running vdsClient:
Traceback (most recent call last):
File "/usr/lib64/python2.6/runpy.py", line 122, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib64/python2.6/runpy.py", line 34, in _run_code
exec code in run_globals
File "/usr/share/vdsm/vdsClient.py", line 28, in <module>
from vdsm import vdscli
ImportError: cannot import name vdscli
And after a reboot it works fine again. Very strange behavior. Anyone knows how to make it work without reboot?
Thx,
Laszlo
11 years, 8 months
Network related hooks in vdsm
by Igor Lvovsky
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
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
11 years, 8 months
python vfs
by peet@redhat.com
…
Some time ago I posted about a side-result of the work on the VM
migration 3.1⇒3.0 issue. Here is several slides[1] about the pyvfs
library[2]. It is not a ready-to-use VDSM application, but some research
work. It is not designed specifically for VDSM and can be used in any
Python script.
I hope, with the library we can create some features for VDSM, like
file-based RPC or internal structures monitoring. Right now I use it to
observe VM objects and monitor internal VM config representation.
I would be glad to discuss it and can prepare a short presentation using
VDSM as a sample.
[1] slides: http://peet.spb.ru/pyvfs.pdf (53kB)
[2] the code on github: https://github.com/svinota/pyvfs
--
Peter V. Saveliev
11 years, 8 months
Re: [vdsm] [Users] Is this "dd" operation harmful?
by Dan Kenigsberg
On Thu, Oct 11, 2012 at 03:44:25PM +0800, Shu Ming wrote:
> Hi,
>
> I found some "dd" operations were launched contiguously in my vdsm.log.
> Is this harmful? How was this operation caused?
That's storage.storage_mailbox.SPM_MailMonitor, polling for lvextend
requests. dd is used, since in the old days, vdsm did not have
storage.fileUtils.DirectFile.
The behavior is expected, but I cannot say that it is harmless.
The mailbox should be high on
http://wiki.ovirt.org/wiki/Vdsm_TODO#refactoring
since forking so much is a waste, as well as using strings instead of
bytearrays. Making the module as a separate, testable entity, is important,
too.
>
> From vdsm.log:
>
> Dummy-51000::DEBUG::2012-10-11
> 15:38:57,243::__init__::1249::Storage.Misc.excCmd::(_log) 'dd
> if=/rhev/data-center/6f6d4801-7447-48ea-b516-627d83e7801e/mastersd/dom_md/inbox
> iflag=direct,fullblock count=1 bs=1024000' (cwd None)
11 years, 8 months
vdsClient -s localhost list ECONNREFUSED
by Paul Dyer
I have vdsm.conf set for ssl=true. When I run vdsClient from localhost, I
get connection refused.
# vdsClient -s localhost list table
Connection to localhost:54321 refused
# vdsClient -s 0 list table
Connection to 172.249.6.135:54321 refused
My host IPADDR is set to a 10. address internally, but I have added an
external secondary address to the nic.
# ip addr show
6: xxxx: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UNKNOWN
link/ether 14:fe:b5:ca:5a:78 brd ff:ff:ff:ff:ff:ff
inet 10.249.6.135/24 brd 10.249.6.255 scope global rhevm
inet 172.249.6.135/24 scope global rhevm
>From a remote host, the vdsClient works okay.
# vdsClient -s 172.249.6.135 list table
86e03987-8d54-4d1b-af39-85200b959e2f 7268 rh5-royal Up
My question, what could cause ECONNREFUSED from a localhost?
I got this from strace:
16:36:49 connect(3, {sa_family=AF_INET, sin_port=htons(54321),
sin_addr=inet_addr("172.249.6.135")}, 16) = -1 ECONNREFUSED (Connection
refused) <0.000439>
11 years, 8 months