refactor clientif move the api implement to sub-module
by Xu He Jie
Hi, folks
I am trying move api implement to sub-module, then we don't need
singleton and passing clientif to anywhere. So I sent this mail to
descript the idea. I think it's good for review.
So I add api registeration mechanism. Other modules can register
it's api implement to api layer.
I try to move VM api and vm stuff(like clientif.vmContainer, etc) to a
new module called vmm. the vmm.VMM is similar with hsm. It's
responsiable for managing vm and register VM implement to api layer.
Same with hsm, I move all storage related api to hsm, and hsm will
register them to api layer.
After all api move to submodule, we can rename clientif and needn't
passing client to any where. :)
I have already submit a rough version to gerrit:
http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:...
Appreciate any comment and review!
Thanks!
He Jie
12 years
My VDSM delopment workflow
by smizrahi@redhat.com
People asking me about my code\test cycle so I decided to just have a small writeup on the list.
Always test on latest stable fedora and RHEL, put yum upgrade -y as a nightly cron command!
My development storage is a FreeNAS VM (But I will be moving to f17+lio when I find the time to configure everything and they implement CHAP auth)
For things that have to be tested with a full blown VDSM install I have a script* that pulls from my git HEAD and installs it on the host. I don't use rsync because the timestamps confuse Make and might cause my local fedora files to be packaged by mistake.
I also delete the RPMs and clean install new ones each time. It takes longer and invokes a libvirt reconfigure each time but it caches a lot of elusive errors that QE often miss.
Always use yum! The rpm command is much less robust.
This script is meant to work on EL\Fedora that just has git and multipath installed, and a cloned repo in which your development machine is the origin.
Also note I explicitly clean "/usr/share/vdsm" because locally changed files don't have the same MD5 hash and might not be removed\replaced by yum.
It takes quite a while but it just makes writing unit tests that much more appealing :)
Make sure you have sudo rights to the appropriate commands
I hope people find this helpful.
-----------------------
#!/bin/bash
# Get git root
PROJ_GIT_DIR=$(git rev-parse --git-dir | xargs dirname | xargs readlink -f)
pushd $PROJ_GIT_DIR .
# Make sure autotools and other basic dependencies are installed
sudo yum install -y automake autoconf gcc rpm-build pyflakes
# Fetch remote head
git co HEAD~ &> /dev/null
git fetch -f origin HEAD:testhead
git co testhead
# Remove old RPMs
rm -rvf ~/rpmbuild
# Build
./autogen.sh --system
./configure
# Install build requirements
grep BuildRequires vdsm.spec | awk {'print $2'} | \
xargs sudo yum install -y
make clean
make rpm || exit 1
# Stop VDSM
sudo /sbin/service vdsmd stop
# Clean RPMs
rpm -qa | grep vdsm | xargs sudo yum remove -y
# Clean any local edits
sudo rm -rf /usr/share/vdsm
# Install new RPMs
ls ~/rpmbuild/RPMS/*/*.rpm | grep -v faqemu | grep -v hook | grep -v reg | \
grep -v bootstrap | xargs sudo yum localinstall --nogpgcheck -y
popd
# Start VDSM
sudo /sbin/service vdsmd start
# VDSM has a long standing issues with reporting OK on start when it's actually
# down
service vdsmd status
12 years
vdsm vs selinux
by lhornyak@redhat.com
hi,
I am running the latest VDSM (built from git repo) on rhel 6.2 and looks like it has some issues with selinux. setenforce 0 solves the problem, but is there a proper solution under way?
Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 570, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/libvirtvm.py", line 1364, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 82, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2490, in createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu-kvm: -drive file=/rhev/data-center/8c369da4-b3a0-11e1-9db0-273609afe0b1/efef4a96-16b1-4f14-a252-f33c7a8ce52b/images/40d2cc3a-9e9c-4224-af6f-2450efc883ca/e84617c5-8073-46de-85bd-2497235a5ba2,if=none,id=drive-virtio-disk0,format=raw,serial=40d2cc3a-9e9c-4224-af6f-2450efc883ca,cache=none,werror=stop,rerror=stop,aio=threads: could not open disk image /rhev/data-center/8c369da4-b3a0-11e1-9db0-273609afe0b1/efef4a96-16b1-4f14-a252-f33c7a8ce52b/images/40d2cc3a-9e9c-4224-af6f-2450efc883ca/e84617c5-8073-46de-85bd-2497235a5ba2: Permission denied
Thank you,
Laszlo
12 years
Re: [vdsm] [Users] How to configure sharedFS ?
by deepakcs@linux.vnet.ibm.com
On 02/29/2012 08:06 PM, Dan Kenigsberg wrote:
> On Wed, Feb 29, 2012 at 07:42:15PM +0530, Deepak C Shetty wrote:
>> On 02/27/2012 04:55 AM, Ayal Baron wrote:
>>> Any help on documenting this so people would not have to dig into the code would be greatly appreciated.
>>>
>>>> Great, let me start and get back if i land up into issues.
>>>> thanks for the pointer.
>>> Let us know if you need further assistance..
>>
> If you have that python script working for LOCALFS, I'd suggest you try
> making it work for SHAREDFS too.
>
>
I was able to use the VDSM_Standalone example, and modify it to use SHAREDFS
and export glusterfs as a DATA_DOMAIN and invoke VM backed by gluster
storage.
I edited http://www.ovirt.org/wiki/Vdsm_Standalone (scroll below) &
added it as
a SHAREDFS example.
12 years
100+ vdsm processes resides in system
by Royce Lv
Guys,
Noticed 100+ vdsm processes resides in my system,and all of them in
sleep status. I guess they're created by the process pool.Little confused
why we should keep so many vdsm processes alive in the system? Are there
any user scenario or considerations?
12 years
Q on vdsm rpm deps
by deepakcs@linux.vnet.ibm.com
Hello,
I am trying to install the vdsm RPMs after a successfull 'make rpm'.
But i get this error...
rpm -ivh ./vdsm*
error: Failed dependencies:
libvirt >= 0.9.10 is needed by vdsm-4.10.0-0.32.git61ecfc0.fc16.x86_64
lvm2 >= 2.02.95 is needed by vdsm-4.10.0-0.32.git61ecfc0.fc16.x86_64
ntp is needed by vdsm-4.10.0-0.32.git61ecfc0.fc16.x86_64
sanlock >= 2.1 is needed by vdsm-4.10.0-0.32.git61ecfc0.fc16.x86_64
I have all the above dep RPMs installed, albeit lesser version.
yum update does not update them.
Downloading libvirt 0.9.11 RPM separately did not help, since it in turn
looks for other deps.
How do i install these deps, when yum update is not updating any of these ?
Is there a diff repo that I need to point to ?
thanx,
deepak
12 years
Re: [vdsm] Change in vdsm[master]: Make vdsm/caps.py PEP8 clean
by shuming@linux.vnet.ibm.com
Dan,
Thanks for your work to merge these files. I notice that there are
three files conflicting with the master branch not yet merged. It is
because the change these files are big and not synced and get a higher
possibility to conflict with other changes. In order to save both the
maintainers and the submitter's time, I think we should have a protocol
to merge these big files. If the maintainer think the files are ready,
the maintainer should inform the submitter to rebase the patches with
the latest master head in one day(considering the time zone difference,
one day is a must). Also, it is the submitter's responsibility to
rebase the patches time to time, but not necessary every day.
Pending files:
a3cda3e Make vdsm/caps.py PEP8 clean Zhengsheng
b2cb196 Make vdsm/clientIF.py PEP8 clean Zhengsheng
970c465 Make vdsm/guestIF.py PEP8 clean Zhengsheng
On 2012-6-14 2:35, danken(a)redhat.com wrote:
> Dan Kenigsberg has posted comments on this change.
>
> Change subject: Make vdsm/caps.py PEP8 clean
> ......................................................................
>
>
> Patch Set 3: I would prefer that you didn't submit this
>
> currently requires non-trivial rebase.
>
> and btw, sorry of the excessive noise of my scripted push of former patches.
>
> --
> To view, visit http://gerrit.ovirt.org/4801
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I000b2e63f31d1e2ca64e05d367b6b9e1b79d2cdf
> Gerrit-PatchSet: 3
> Gerrit-Project: vdsm
> Gerrit-Branch: master
> Gerrit-Owner: Shu Ming<shuming(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Dan Kenigsberg<danken(a)redhat.com>
> Gerrit-Reviewer: Shu Ming<shuming(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Zhou Zheng Sheng<zhshzhou(a)linux.vnet.ibm.com>
>
--
Shu Ming<shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
12 years
A Tool for PEP 8 Patches to Find Code Logic Changes
by zhshzhou@linux.vnet.ibm.com
Hi,
Since there is no coverage report on tests in vdsm, if a PEP 8 patch
passes the tests, we still not sure if there is no mistake in it.
Viewing the diff reports on all the changes consumes a lot of time, and
some small but fatal mistakes(like misspelling variable name) can easily
be ignored by human eyes.
So I have a try on the compiler module of Python. I write a tool named
'pydiff'. pydiff parses two Python scripts into Abstract Syntax Trees.
These data structures can reflect the logic of the code, and pydiff
performs a recursive compare on the trees. Then pydiff reports
differences and the corresponding line numbers. In this way, pydiff
ignores code style changes, and reports only logical changes of the code.
I think this tool can save us a lot of time. After a PEP 8 patch passes
vdsm tests and pydiff, I will get some confidence on the patch and it
probably does not break anything in vdsm.
Here is a usage example:
-------- test_o.py --------
def foo(a, b):
pass
if __name__ == '__main__':
A = [1, 2, 3]
print (4, 5, 6), \
"over"
foo(1, 2)
print 'Hello World'
-------- test_n.py --------
def foo(a, b):
pass
if __name__ == '__main__':
A = [1,
2, 3]
print (4, 5, 6), "over"
fooo(
1, 2)
print ('Hello '
'World')
Some differences of the files are just a matter of style. The only
significant difference is the function call "foo()" is misspelled in
"test_n.py".
Run pydiff.py, it will report:
$ python pydiff.py test_*.py
1 difference(s)
first file: test_n.py
second file: test_o.py
((8, 'fooo'), (8, 'foo'))
This report tells us that 'fooo' in line 8 of "test_n.py" is different
from 'foo' in line 8 of "test_o.py".
It can also find insertions or deletions. Here is another simple example:
---- old.py ----
print 'Hello 1'
print 'Hello 2'
print 'Hello 3'
print 'Hello 4'
print 'Hello 5'
---- new.py ----
print 'Hello 1'
print 'Hello 3'
print 'Hello 4'
print 'Hello 5'
print 'Hello 5'
Run pydiff:
$ pydiff old.py new.py
2 difference(s)
first file: old.py
second file: new.py
((2, Printnl([Const('Hello 2')], None)), (2, None))
((5, None), (5, Printnl([Const('Hello 5')], None)))
Here "((2, Printnl([Const('Hello 2')], None)), (2, None))" means there
is a print statement in line 2 of old.py, but no corresponding statement
in new.py, so we can know the statement is deleted in new.py.
"((5, None), (5, Printnl([Const('Hello 5')], None)))" means there is a
print statement in line 5 of new.py, but no corresponding statement in
old.py, so we can know the statement is inserted in new.py.
Sometimes the change in code logic is acceptable, for example, change
"aDict.has_key(Key)" into "Key in aDict". pydiff can report a difference
in this case, but it is up to the user to judge whether it's acceptable.
pydiff is just a tool to help you finding these changes.
I hope it can be helpful for PEP 8 patch reviewers. If you find any
bugs, please let me know. The script is in the attachment.
--
Thanks and best regards!
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397
12 years
some questions about selinux policy on VDSM storage
by zhshzhou@linux.vnet.ibm.com
Hi all,
I am trying to create a VM in vdsm, but I find that selinux is
preventing qemu from visiting images in vdsm storage. I add two policies
to selinux then start the VM successfully. Not sure if I've done it
right, so I'd like to ask for some advice.
The directory structure of my vdsm storage is as follow:
$ tree -l /rhev
/rhev
`-- data-center
|-- 3ace0f74-a9fa-11e1-bb33-00247edb4743
| |-- 1de3f4e2-a9f9-11e1-9956-00247edb4743 -> /rhev/data-center/mnt/_teststorage/1de3f4e2-a9f9-11e1-9956-00247edb4743
| | |-- dom_md
| | | |-- ids
| | | |-- inbox
| | | |-- leases
| | | |-- metadata
| | | `-- outbox
| | |-- images
| | | `-- 8230cd4a-aa1b-11e1-970c-00247edb4743
| | | |-- b9e163b6-aa1c-11e1-94f6-00247edb4743
| | | `-- b9e163b6-aa1c-11e1-94f6-00247edb4743.meta
| | `-- master
| | |-- tasks
| | | `-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5
| | | |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.job.0
| | | |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.recover.0
| | | |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.recover.1
| | | |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.result
| | | `-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.task
| | `-- vms
| `-- mastersd -> /rhev/data-center/mnt/_teststorage/1de3f4e2-a9f9-11e1-9956-00247edb4743 [recursive, not followed]
|-- hsm-tasks
`-- mnt
`-- _teststorage -> /teststorage
`-- 1de3f4e2-a9f9-11e1-9956-00247edb4743
|-- dom_md
| |-- ids
| |-- inbox
| |-- leases
| |-- metadata
| `-- outbox
|-- images
| `-- 8230cd4a-aa1b-11e1-970c-00247edb4743
| |-- b9e163b6-aa1c-11e1-94f6-00247edb4743
| `-- b9e163b6-aa1c-11e1-94f6-00247edb4743.meta
`-- master
|-- tasks
| `-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5
| |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.job.0
| |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.recover.0
| |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.recover.1
| |-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.result
| `-- a01abf82-c8f2-4d52-8e50-f26a2a2994b5.task
`-- vms
22 directories, 24 files
The storage is constructed using vdsClient. I create a LOCALFS DATA
domain, a pool, an image and a volume.
I find that libvirtd can relable the volume to
"system_u:object_r:svirt_image_t:s0:cXXX,cXXX", and it starts qemu as
"system_u:system_r:svirt_t:s0:cXXX,cXXX"
$ ll -Z b9e163b6-aa1c-11e1-94f6-00247edb4743
-rw-rw-r--. vdsm kvm system_u:object_r:svirt_image_t:s0:c248,c603 b9e163b6-aa1c-11e1-94f6-00247edb4743
$ ps auxZ | grep qemu
system_u:system_r:svirt_t:s0:c248,c603 qemu 11132 60.0 6.9 1531336 273756 ? Sl 13:58 0:31 /usr/bin/qemu-kvm ...(lots of arguments)
This is an expected feature of sVirt, and qemu is supposed to have
access to the volume. To access the volume file
"b9e163b6-aa1c-11e1-94f6-00247edb4743", qemu must go through
"/rhev/data-center/3ace0f74-a9fa-11e1-bb33-00247edb4743/1de3f4e2-a9f9-11e1-9956-00247edb4743/images/8230cd4a-aa1b-11e1-970c-00247edb4743/",
so it must read the soft link "1de3f4e2-..." and "_teststorage".
However, these two soft links are created by vdsm with security label
"default_t", and qemu is labeled as "svirt_t", so selinux is preventing
qemu reading the soft links, this means qemu can not access the volume file.
I lookup the libvirt documentation, it says libvirt runs qemu in a
confined domain, only allowing qemu to access files and devices labeled
as "system_u:object_r:virt_image_t" or "system_u:object_r:svirt_image_t"
(http://libvirt.org/drvqemu.html#securityselinux). So I add two policies
as follow:
semanage fcontext -a -t virt_image_t '/rhev/data-center/mnt/[^/]+'
semanage fcontext -a -t virt_image_t '/rhev/data-center/[-0-9a-f]+/[-0-9a-f]+'
This let qemu to access those soft links.
Including the existing policies policies on /rhev, now the overall
policies are as follow:
# semanage fcontext -l | grep '^/rhev'
/rhev directory system_u:object_r:mnt_t:s0
/rhev(/[^/]*)? directory system_u:object_r:mnt_t:s0
/rhev/[^/]*/.* all files <<None>>
/rhev/data-center/[-0-9a-f]+/[-0-9a-f]+ all files system_u:object_r:virt_image_t:s0
/rhev/data-center/mnt/[^/]+ all files system_u:object_r:virt_image_t:s0
Then I "restorecon -Rv /rhev". After doing this, I can create and boot
VM in vdsm now.
Now I have three questions.
1. I think I'm giving qemu the least privilege it needs, but I'm not
sure if the policies are too permissive.
2. Does anyone ever have the same problem? Am I solving it in a right way?
3. Since the soft links are created by vdsm, this seems like a bug. If I
want to submit a patch for this bug, which project should I submit those
new policies: selinux, libvirt or vdsm?
--
Thanks and best regards!
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou(a)linux.vnet.ibm.com
Telephone: 86-10-82454397
12 years