help! tests failing in latest vdsm
by lhornyak＠redhat.com
hi!
I am trying to update my dev environment with the latest VDSM and I follow the steps from http://wiki.ovirt.org/wiki/Vdsm_Developers
at `make rpm` I get test errors:
======================================================================
ERROR: test_mkIsoFs (mkimageTests.MkimageTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/rpmbuild/BUILD/vdsm-4.10.0/tests/mkimageTests.py", line 126, in test_mkIsoFs
iso_img = mkimage.mkIsoFs("vmId_iso", self.files)
File "/root/rpmbuild/BUILD/vdsm-4.10.0/vdsm/mkimage.py", line 106, in mkIsoFs
_commonCleanFs(dirname, isopath)
File "/root/rpmbuild/BUILD/vdsm-4.10.0/vdsm/mkimage.py", line 54, in _commonCleanFs
resolveGid(DISKIMAGE_GROUP))
OSError: [Errno 2] No such file or directory: '/tmp/tmpXehkKs/vmId_iso.b07ce1191cd15d3b28fdd41f3f69b649.img'
======================================================================
ERROR: test_removeFs (mkimageTests.MkimageTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/root/rpmbuild/BUILD/vdsm-4.10.0/tests/mkimageTests.py", line 144, in test_removeFs
iso_img = mkimage.mkIsoFs("vmId_iso", self.files)
File "/root/rpmbuild/BUILD/vdsm-4.10.0/vdsm/mkimage.py", line 106, in mkIsoFs
_commonCleanFs(dirname, isopath)
File "/root/rpmbuild/BUILD/vdsm-4.10.0/vdsm/mkimage.py", line 54, in _commonCleanFs
resolveGid(DISKIMAGE_GROUP))
OSError: [Errno 2] No such file or directory: '/tmp/tmpY271GA/vmId_iso.9097f086f947b3242acb9713083c94ac.img'
----------------------------------------------------------------------
Ran 200 tests in 125.623s
FAILED (SKIP=7, errors=2)
Is anyone working on this?
Thank you,
Laszlo
11 years, 8 months
empty vdsm cert files
by Ryan Harper
[root@ichigo-dom225 vdsm]# find . -type f| xargs -i ls -al {}
-r--r--r--. 1 vdsm kvm 0 Aug 20 14:49 ./certs/cacert.pem
-r--r--r--. 1 vdsm kvm 0 Aug 20 14:49 ./certs/vdsmcert.pem
-rw-------. 1 vdsm kvm 11 Aug 17 09:49 ./keys/libvirt_password
-r--r-----. 1 vdsm qemu 0 Aug 20 14:49 ./keys/dh.pem
-r--r-----. 1 vdsm qemu 0 Aug 20 14:49 ./keys/vdsmkey.pem
Anyone seen this problem?
host has:
[root@ichigo-dom225 tmp]# rpm -qa | grep vdsm
vdsm-python-4.10.0-7.fc17.x86_64
vdsm-4.10.0-7.fc17.x86_64
vdsm-cli-4.10.0-7.fc17.noarch
vdsm-xmlrpc-4.10.0-7.fc17.noarch
Install driven from engine (3.1 release) at this level:
[root@ichigo-dom223 ~]# rpm -qa | grep ovirt-engine
ovirt-engine-userportal-3.1.0-2.fc17.noarch
ovirt-engine-webadmin-portal-3.1.0-2.fc17.noarch
ovirt-engine-sdk-3.1.0.4-1.fc17.noarch
ovirt-engine-setup-3.1.0-2.fc17.noarch
ovirt-engine-restapi-3.1.0-2.fc17.noarch
ovirt-engine-3.1.0-2.fc17.noarch
ovirt-engine-backend-3.1.0-2.fc17.noarch
ovirt-engine-config-3.1.0-2.fc17.noarch
ovirt-engine-genericapi-3.1.0-2.fc17.noarch
ovirt-engine-tools-common-3.1.0-2.fc17.noarch
ovirt-engine-dbscripts-3.1.0-2.fc17.noarch
ovirt-engine-notification-service-3.1.0-2.fc17.noarch
Attaching the vds bootstrap.log ... I don't see anything broken in here (that I
can tell).
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
11 years, 8 months
Jenkins testing.
by robert＠middleswarth.net
After a few false starts it looks like we have per patch testing working
on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli. There are
3 status a patch can get. 1) Success - Means the patch ran though the
tests without issue. 2) Failure - Means the tests failed. 3) Aborted -
Generally means the submitter is not in the whitelist and the tests were
never run. If you have any questions please feel free to ask.
--
Thanks
Robert Middleswarth
@rmiddle (twitter/IRC)
11 years, 8 months
Re: [vdsm] About vdsm rest api
by smizrahi＠redhat.com
reposting to list
---
I know it might seem a bit of a cumbersome process. But installation is relatively simple nowadays and the API is a lot more stable and safe at the moment.
Because VDSM doesn't keep any information on the host you will end up having to develop your own solutions to problems already solved by the ovirt-engine.
You only need to use the VDSM API if you write your own management solution. But seeing as the ovirt-engine is open source there should be no reason not to just write the feature you need and push it upstream.
----- Original Message -----
> From: "Paolo Tonin" <paolo.tonin(a)gmail.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Sent: Monday, August 20, 2012 11:33:50 AM
> Subject: Re: [vdsm] About vdsm rest api
>
> Yes, because i don't want to install oVirt engine (and subsequely
> entire oVirt web interface and DB)
>
> 2012/8/20 Saggi Mizrahi <smizrahi(a)redhat.com>:
> > Hi, the rest API is going to move to a 2nd tier API very soon.
> > There is also a pretty big API restructuring going on so we could
> > supply a supported and documented API.
> >
> > Is there a reason you are not using the ovirt-engine REST-API?
> >
> > ----- Original Message -----
> >> From: "Paolo Tonin" <paolo.tonin(a)gmail.com>
> >> To: vdsm-devel(a)lists.fedorahosted.org
> >> Sent: Thursday, August 16, 2012 10:00:41 PM
> >> Subject: [vdsm] About vdsm rest api
> >>
> >> Hi all there!
> >>
> >> Is there any documentation about implemented http rest api in the
> >> current version of VDSM (4.10)
> >> I would to use vdsm without oVirt packages, actually i'm using
> >>
> >> # rpm -qa vdsm*
> >> vdsm-xmlrpc-4.10.0-0.42.12.el6.noarch
> >> vdsm-4.10.0-0.42.12.el6.x86_64
> >> vdsm-rest-4.10.0-0.42.12.el6.noarch
> >> vdsm-bootstrap-4.10.0-0.42.12.el6.noarch
> >> vdsm-python-4.10.0-0.42.12.el6.x86_64
> >> vdsm-reg-4.10.0-0.42.12.el6.noarch
> >> vdsm-cli-4.10.0-0.42.12.el6.noarch
> >>
> >> Thanks a lot
> >> _______________________________________________
> >> vdsm-devel mailing list
> >> vdsm-devel(a)lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >>
>
11 years, 8 months
About vdsm rest api
by Paolo Tonin
Hi all there!
Is there any documentation about implemented http rest api in the
current version of VDSM (4.10)
I would to use vdsm without oVirt packages, actually i'm using
# rpm -qa vdsm*
vdsm-xmlrpc-4.10.0-0.42.12.el6.noarch
vdsm-4.10.0-0.42.12.el6.x86_64
vdsm-rest-4.10.0-0.42.12.el6.noarch
vdsm-bootstrap-4.10.0-0.42.12.el6.noarch
vdsm-python-4.10.0-0.42.12.el6.x86_64
vdsm-reg-4.10.0-0.42.12.el6.noarch
vdsm-cli-4.10.0-0.42.12.el6.noarch
Thanks a lot
11 years, 8 months
Re: [vdsm] Change in vdsm[master]: Fix vdsm-faqemu VM launch failure on hosts with newer libvir...
by Ryan Harper
* Dan Kenigsberg <danken(a)redhat.com> [2012-08-16 03:37]:
> Dan Kenigsberg has posted comments on this change.
>
> Change subject: Fix vdsm-faqemu VM launch failure on hosts with newer libvirt
> ......................................................................
>
>
> Patch Set 1: I would prefer that you didn't submit this
>
> (1 inline comment)
>
> ....................................................
> File vdsm_hooks/faqemu/vdsm-faqemu
> Line 20:
> Line 21: qemu_argv += filter(lambda x: x != "-enable-kvm", sys.argv[1:])
> Line 22: # libvirt 0.9.10+ checks for the presence of /dev/kvm to provide
> Line 23: # better error messages, but this breaks this hook, fake it out
> Line 24: os.system("touch /dev/kvm")
> how can this work? this script runs as vdsm.
# sudo -u vdsm touch /dev/kvm
touch: cannot touch `/dev/kvm': Permission denied
But I can assure you that it did work. I didn't just touch the file as
root. I installed the faqemu hook and /dev/kvm is owned by root. Are
you sure hooks run as vdsm?
It's run as root:
[root@ichigo-dom228 tmp]# cat /usr/libexec/vdsm/vdsm-faqemu
#!/usr/bin/python
import os
import sys
qemu_paths = [
"/usr/bin/qemu-kvm",
"/usr/libexec/qemu-kvm",
]
for qemu_bin in qemu_paths:
if os.path.exists(qemu_bin): break
else:
raise RuntimeError, "QEMU binary not found"
qemu_argv = [ qemu_bin ]
if not "-no-kvm" in sys.argv:
qemu_argv += [ "-no-kvm" ]
qemu_argv += filter(lambda x: x != "-enable-kvm", sys.argv[1:])
os.system('id > /tmp/faqemu_id.out')
os.system('touch /dev/kvm')
os.execv(qemu_bin, qemu_argv)
[root@ichigo-dom228 tmp]# cat /tmp/faqemu_id.out
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:virtd_t:s0-s0:c0.c1023
>
> also, there are less expensive ways to create a file - how about shipping it in this hook's rpm ?
Is that really less expensive? I worry about having an rpm include the file;
and /dev gets remounted/changed accross reboots; so this wouldn't work.
What's expensive about a touch?
>
>
> --
> To view, visit http://gerrit.ovirt.org/7223
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: I1dc88f2931e8f716c1732a51d9f65f600f4fd1ef
> Gerrit-PatchSet: 1
> Gerrit-Project: vdsm
> Gerrit-Branch: master
> Gerrit-Owner: Ryan Harper <ryanh(a)us.ibm.com>
> Gerrit-Reviewer: Dan Kenigsberg <danken(a)redhat.com>
> Gerrit-Reviewer: Mark Wu <wudxw(a)linux.vnet.ibm.com>
> Gerrit-Reviewer: Ryan Harper <ryanh(a)us.ibm.com>
> Gerrit-Reviewer: oVirt Jenkins CI Server
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com
11 years, 8 months
Host network management roadmap inquiry
by wudxw＠linux.vnet.ibm.com
Sorry for cross-posting!
I would like to inquiry about the roadmap of host network management in
oVirt in order to
make sure the ideas to be worked on are welcomed by community.
I did some initial investigation on the following topics. I am not very
familiar with them, so the information may contain some inaccuracies or
errors.
netcf:
It provides cross-platform network configuration library/tool by
converting the XML definition of an interface into local config file.
It's already used by libvirt to manage host network interfaces.It
supports all network entities including bridge, vlan, bond, nic. And it
also supports configuration rollback. The benefit for vdsm is making
host network stack configuration easy to port to other distros.
Problems found:
It doesn't restore interface live state during config transaction
now. There's a feature request submit for it.
There're some advanced settings not supported in netcf, like
'NM_CONTROLLED' and some less used bonding options.
It doesn't provide python binding officially. But we can use
libvirt API to integrate it into vdsm. It shouldn't have any impact on
engine side.
IEEE 802.1Qbg(VEPA)
It can offload network switching from server to external physical
switch. It makes all VMs' traffic visible to physical switch, and
therefore the existing switch functions (firewall, QoS etc) can be
applied to VM immediately. The offload also frees up the server resource
used by switching.
Now libvirt supports it by using macvtap as vif and working with
lldpad, which registers vif's mac/vlan information to the physical
switch. We can just add a 'virtualport' element to an interface XML
definition to add a VEPA interface. Probably, to support it in oVirt we
still need configure lldpad and query available VSI types for
virtualport profile.
quantum
Both the plugins openvswitch and linuxbridge stores abstract network
entities (network, port) in database and create bridge/vlan via the tool
ip/brctl or ovs-vsctl on demand. Only one bridge is created on one
server and one vlan is created for each virtual network. That means that
only one nic can be configured for vm network. It doesn't configure nic
or bond even if openvswitch also supports bond. Both of traditional
network stack configuration and quantum will be supported oVirt for
different purpose, right?
Any comments? Thanks!
11 years, 8 months
Re: [vdsm] [RFC] Exception is VDSM
by smizrahi＠redhat.com
----- Original Message -----
> From: "Simon Grinberg" <simon(a)redhat.com>
> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> Cc: "arch" <arch(a)ovirt.org>, "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org>
> Sent: Thursday, August 16, 2012 12:12:04 PM
> Subject: Re: [RFC] Exception is VDSM
>
>
>
> ----- Original Message -----
> > From: "Saggi Mizrahi" <smizrahi(a)redhat.com>
> > To: "arch" <arch(a)ovirt.org>, "VDSM Project Development"
> > <vdsm-devel(a)lists.fedorahosted.org>
> > Sent: Thursday, August 16, 2012 6:39:26 PM
> > Subject: [RFC] Exception is VDSM
> >
> > Currently we have very specific exceptions.
> > This causes proliferation of exception with no real gain.
> >
> > There is really no benefit for each call to throw it's own error
> > message:
> > For instance,
> > MiscFileReadException
> > MiscFileWriteException
> > MiscBlockReadException
> > MiscBlockWriteException
> > * There are about a 100 of these.
> >
> > Could all just be "general exception". The user knows what command
> > it
> > ran there is no need have the exceptions specify that.
>
> Who is this 'user'?
Any person or program that users the API.
>
> Does 'user' operation necessary invokes just one of the above in a
> 1:1 correlation to what he tries to do? no complex operation that
> may lead to ambiguity?
The reason is whether this "ambiguity" is important. For instance when calling getVolumeSize you might find EntityNotFound ambiguous as you don't at which point the search failed. Pool, Domain, Image, or Volume.
The point I'm making is that it isn't important like open(2) returning ENOENT and not telling you at what point it failed the search. 99.9% of the time doesn't matter. If any of them are wrong, you need to change the "path" anyway because they are all dependent and there is no way for you to handle these differently. Also, in my opinion, returning StoragePoolUnknown is a mistake because this is all just a path to an entity. So you are talking about something else.
Exception handling is about handling exceptions. Throwing something that cannot be handled seems to me like a needless complication.
I'm also only talking about public exceptions here.
>
>
> >
> > Also exception like:
> > ImageDoesNotExistInSD
> > StoragePoolMasterNotFound
> > StoragePoolUnknown
> > VMPathNotExists
> >
> > Actually just mean ENOENT or EntityDoesNotExist in different
> > contexts. There is no real reason to distinguish between them
> > because they are also context driven.
> >
> > Cutting down on the amount of exceptions to error archetypes
> > similar
> > to standard c errors will give us simpler API.
> > Also, having a specific set of exceptions per call means that every
> > new API means a new group of supported exceptions. This makes
> > forward compatibility very problematic.
> > _______________________________________________
> > Arch mailing list
> > Arch(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
>
11 years, 8 months
[RFC] Exception is VDSM
by smizrahi＠redhat.com
Currently we have very specific exceptions.
This causes proliferation of exception with no real gain.
There is really no benefit for each call to throw it's own error message:
For instance,
MiscFileReadException
MiscFileWriteException
MiscBlockReadException
MiscBlockWriteException
* There are about a 100 of these.
Could all just be "general exception". The user knows what command it ran there is no need have the exceptions specify that.
Also exception like:
ImageDoesNotExistInSD
StoragePoolMasterNotFound
StoragePoolUnknown
VMPathNotExists
Actually just mean ENOENT or EntityDoesNotExist in different contexts. There is no real reason to distinguish between them because they are also context driven.
Cutting down on the amount of exceptions to error archetypes similar to standard c errors will give us simpler API.
Also, having a specific set of exceptions per call means that every new API means a new group of supported exceptions. This makes forward compatibility very problematic.
11 years, 8 months
