vdsm-devel January 2013

vdsm-devel@lists.stg.fedorahosted.org

28 participants
19 discussions

libvirt interface usage improvements, #1
by peet＠redhat.com 15 Jan '13

15 Jan '13

… Hello all. I'm working on improving libvirt usage in VDSM. Rationale is that libvirt driver has global lock, that holds us in any operation on many VMs simultaneously. Several small patches are prepared, so I'm starting to commit them. The first one [1] removes UUIDString check in VM startup. It was used to test local libvirt for the bug 603494 [2], which is closed so long time ago, so there is no need to support this case, fixed already all across the distributives, including RHEL 6.x. I wouldn't care, but in mass VM startup (dozens and hundreds of VMs) each extra call costs. So thanks for review/merge. [1] — http://gerrit.ovirt.org/#/c/11054/ [2] — https://bugzilla.redhat.com/show_bug.cgi?id=603494 -- Peter V. Saveliev

3 2

Q on git-review error
by deepakcs＠linux.vnet.ibm.com 15 Jan '13

15 Jan '13

Hi All, I got this error, while trying to push a topic branch..but in the end it looks like it did push the GLUSTERSD_DOMAIN patch ( which had a minor change ). The other 2 patches didn't have any change. Finally when i look up in gerrit, it shows GLUSTERSD_DOMAIn patch fine, but the link of that with the other 2 patches seems to have broken git-review -t gluster_domain_support You have more than one commit that you are about to submit. The outstanding commits are: 29f2048 (HEAD, dpk-gluster-support) tests/functional: Add GlusterSD functional test 3cc6fca tests/functional: Use deleteVolume instead of deleteImage 6d71286 Support for GLUSTERFS_DOMAIN Is this really what you meant to do? Type 'yes' to confirm: yes remote: Resolving deltas: 100% (20/20) remote: Processing changes: done remote: error: internal error while processing changes <<< throwing some error To ssh://dpkshetty@gerrit.ovirt.org:29418/vdsm.git * [new branch] HEAD -> refs/publish/master/gluster_domain_support <<<< it did push tho'

1 0

Meeting minutes, Jan 14
by Dan Kenigsberg 14 Jan '13

14 Jan '13

Speaking attendees (no particular order): Dustin, Saggi, Adam, Douglas, Federico, Danken. Issues raised: - Saggi's amqp patches: - Saggi will resend first json_rpc patch with bug fixes - Adam will ack the series since it is sane and does not break anything useful. - Saggi's old patches: - nothing is urgently waiting for review, stay idea for future reference - FlowID is broken for storage-related bugs, and people are complaining. Douglas would take a look to please Haim and Co. - gerrit routine (Deepack asked to mention this) It is sad to loose all the acks on a patch when you rebase something below it. But if there are no changes to the patch, Danken can copy the old score. Still it would be nice if the original reviewer does it. - imperfact documentation (raised by ShaoHe Feng on list) - There is sphinx-based documentation in tree, but it is old and its build is broken. Time for someone to fix it. ShaoHe Feng, maybe? ;-) - tests/functions has examples of api usage, and it should have many more. - Debian/Ubuntu support. - Adam raises the need to have it - we are all looking forward for participation of developers/packagers of new distributions. - This may mean the end of our easy life of requiring the latest Fedora package in order to consude a new feature or avoid a bug. We may need to discover installed version of a lib/exec during runtime, like libvirt does. - ovirt-3.2 release: - no advancement in the NetworkManager front of last month - Fedora f18 branch should have code from the relatively-tested ovirt-3.2 branch, not from "master". Douglas would keep it this way. - Yeela and Vered should backport their F18 blocker bugs to the ovirt-3.2 branch, and ping Federico. (iscsi_id location and udevadm settle issues). - Ongoing discussion on running vdsm for el6 - thanks for everyone who is fixing bugs there (mostly dreyou) - but please let us join forces and make this work out-of-the-box. See you again in two weeks! Regards, Dan.

1 0

Helping ovirt-3.2 run on EL6
by Dan Kenigsberg 14 Jan '13

14 Jan '13

Hi Andrey, I just have seen your http://www.dreyou.org/ovirt/vdsm.patch for ovirt-3.2. I would like to thank you for your packaging and engineering work. I'd like to incorporate as much of it into vdsm's upstream so that it runs properly on any EL6 out-of-the-box. Could you help me understand some of your changes? I've posted http://gerrit.ovirt.org/#/c/10893/ which is taken from a former patchset of yours - is it intentionally missing form the 3.2 version of your patchset? > From adf7dc96767783ab81993504267c3cfd65b4c1bb Mon Sep 17 00:00:00 2001 > From: Andrey Gordeev <dreyou(a)gmail.com> > Date: Fri, 7 Dec 2012 13:12:19 +0400 > Subject: [PATCH 1/2] CentOS 6.2 changes > > --- > build-aux/pkg-version | 6 +++++- > vds_bootstrap/setup | 2 +- > vdsm.spec.in | 30 ++++++++++++++++++++++++++---- > vdsm/configNetwork.py | 5 +++++ > vdsm/storage/misc.py | 2 +- > vdsm/vdsmd.init.in | 3 ++- > 6 files changed, 40 insertions(+), 8 deletions(-) > > diff --git a/build-aux/pkg-version b/build-aux/pkg-version > index 346ad23..9c410ff 100755 > --- a/build-aux/pkg-version > +++ b/build-aux/pkg-version > @@ -32,7 +32,11 @@ if test "x$1" = "x--full"; then > elif test "x$1" = "x--version"; then > echo $PKG_VERSION | awk "$AWK_VERSION" | tr -cd '[:alnum:].' > elif test "x$1" = "x--release"; then > - echo $PKG_VERSION | awk "$AWK_RELEASE" | tr -cd '[:alnum:].' > + if [ $LOCAL_BUILDID ]; then > + echo $PKG_VERSION | awk "$AWK_RELEASE" | sed "s/git.*$/{$LOCAL_BUILDID}/" | tr -cd '[:alnum:].' > + else > + echo $PKG_VERSION | awk "$AWK_RELEASE" | tr -cd '[:alnum:].' > + fi > else > echo "usage: $0 [--full|--version|--release]" > exit 1 > diff --git a/vds_bootstrap/setup b/vds_bootstrap/setup > index 01306bd..177e089 100755 > --- a/vds_bootstrap/setup > +++ b/vds_bootstrap/setup > @@ -29,7 +29,7 @@ import re > import tempfile > from time import strftime > > -SUPPORTED_PLATFORMS = [ "RedHatEnterpriseServer", "Fedora" ] > +SUPPORTED_PLATFORMS = [ "RedHatEnterpriseServer", "Fedora", "CentOS", "Scientific", "Oracle" ] I see no reason not to take this upstream > HYPERVISOR_PLATFORMS = [ "RedHatEnterpriseVirtualizationHypervisor", "RedHatEnterpriseHypervisor", "oVirtNodeHypervisor" ] > HYPERVISOR_RELEASE_FILE = '/etc/rhev-hypervisor-release' > REDHAT_RELEASE_FILE = '/etc/redhat-release' > diff --git a/vdsm.spec.in b/vdsm.spec.in > index 465d548..a9de23d 100644 > --- a/vdsm.spec.in > +++ b/vdsm.spec.in > @@ -102,8 +102,10 @@ Requires: iscsi-initiator-utils >= 6.2.0.872-15 > Requires: device-mapper-multipath >= 0.4.9-52 > Requires: e2fsprogs >= 1.41.12-11 > Requires: kernel >= 2.6.32-279.9.1 > -Requires: sanlock >= 2.3-4, sanlock-python > -Requires: initscripts >= 9.03.31-2.el6_3.1 > +#Requires: sanlock >= 2.3-4, sanlock-python > +#Requires: initscripts >= 9.03.31-2.el6_3.1 These requirements are for real bugs. Better include them into your EL6 flavor or build yourself. > +Requires: sanlock >= 2.3-1, sanlock-python > +Requires: initscripts >= 9.03.31-2 > Requires: mom >= 0.3.0 > Requires: selinux-policy-targeted >= 3.7.19-80 > Requires: lvm2 >= 2.02.95-10.el6_3.2 > @@ -431,6 +433,8 @@ install -Dm 0644 vdsm/limits.conf \ > # Install the SysV init scripts > install -Dm 0755 vdsm/vdsmd.init %{buildroot}%{_initrddir}/vdsmd > install -Dm 0755 vdsm_reg/vdsm-reg.init %{buildroot}%{_initrddir}/vdsm-reg > +install -Dm 0644 vdsm/vdsm.conf.sample \ > + %{buildroot}%{_sysconfdir}/vdsm/vdsm.conf Federico, do you recall why don't we ship vdsm.conf on el? > > # This is not commonplace, but we want /var/log/core to be a world-writable > # dropbox for core dumps > @@ -475,6 +479,15 @@ export LC_ALL=C > /usr/sbin/usermod -a -G %{qemu_group},%{vdsm_group} %{snlk_user} > > %post > +if [ -f /etc/sysconfig/modules/softdog.modules ] > +then > + cp /etc/sysconfig/modules/softdog.modules /etc/vdsm/softdog.modules.prevdsm > +fi > +echo -e '#!/bin/sh\nmodprobe softdog\nexit 0' > /etc/sysconfig/modules/softdog.modules > +chmod +x /etc/sysconfig/modules/softdog.modules > +/sbin/chkconfig wdmd on > +/sbin/chkconfig sanlock on > + Andrey/Federico: why is this hack required? > %{_bindir}/vdsm-tool sebool-config > # set the vdsm "secret" password for libvirt > %{_bindir}/vdsm-tool set-saslpasswd > @@ -538,6 +551,15 @@ exit 0 > %endif > > %postun > +if [ -f /etc/sysconfig/modules/softdog.modules ] > +then > + cp /etc/sysconfig/modules/softdog.modules /etc/vdsm/softdog.modules.prevdsm > +fi > +echo -e '#!/bin/sh\nmodprobe softdog\nexit 0' > /etc/sysconfig/modules/softdog.modules > +chmod +x /etc/sysconfig/modules/softdog.modules > +/sbin/chkconfig wdmd on > +/sbin/chkconfig sanlock on > + > %if 0%{?rhel} > if [ "$1" -ge 1 ]; then > /sbin/service vdsmd condrestart > /dev/null 2>&1 > @@ -762,9 +784,9 @@ exit 0 > %files python > %defattr(-, root, root, -) > %{_bindir}/vdsm-tool > -%if !0%{?rhel} > +#%if !0%{?rhel} > %config(noreplace) %{_sysconfdir}/%{vdsm_name}/vdsm.conf > -%endif > +#%endif > %{python_sitearch}/%{vdsm_name}/__init__.py* > %{python_sitearch}/%{vdsm_name}/config.py* > %{python_sitearch}/%{vdsm_name}/constants.py* > diff --git a/vdsm/configNetwork.py b/vdsm/configNetwork.py > index 78fd3af..7bf6af7 100755 > --- a/vdsm/configNetwork.py > +++ b/vdsm/configNetwork.py > @@ -890,6 +890,11 @@ def addNetwork(network, vlan=None, bonding=None, nics=None, ipaddr=None, > _netinfo = netinfo.NetInfo() > bridged = utils.tobool(bridged) > > + # Hack here, netmask may be not defined, if this happen, > + # set netmask to 255.255.255.0 > + if not netmask: > + netmask = "255.255.255.0" > + When is this needed? Could it be related to PREFIX instead of NETMASK issue of http://gerrit.ovirt.org/9322 ? > if mtu: > mtu = int(mtu) > > diff --git a/vdsm/storage/misc.py b/vdsm/storage/misc.py > index 17d38ee..ada3196 100644 > --- a/vdsm/storage/misc.py > +++ b/vdsm/storage/misc.py > @@ -748,7 +748,7 @@ class RollbackContext(object): > > # re-raise the earliest exception > if firstException is not None: > - raise firstException, None, traceback > + raise firstException(None, traceback) I do not believe that it is correct - is it only to satisfy old pep8 tool not recognizing the peculiar "raise" syntax that is used here? Could you ship http://danken.fedorapeople.org/python-pep8-1.3.3-3.el6.noarch.rpm instead? > > def defer(self, func, *args, **kwargs): > self._finally.append((func, args, kwargs)) > diff --git a/vdsm/vdsmd.init.in b/vdsm/vdsmd.init.in > index 7c709a6..0fd206e 100755 > --- a/vdsm/vdsmd.init.in > +++ b/vdsm/vdsmd.init.in > @@ -136,7 +136,8 @@ shutdown_conflicting_srv() { > } > > libvirt_should_use_upstart() { > - [[ -x /sbin/initctl ]] > +# [[ -x /sbin/initctl ]] > + [[ -x /sbin/foo ]] Why is that? Don't you want to use upstart's libvirtd autostart after crash? > } > > start_needed_srv() { > -- > 1.7.1 > > > From 6f7ea3241047f06a196c90549960460c174362fd Mon Sep 17 00:00:00 2001 > From: Andrey Gordeev <dreyou(a)gmail.com> > Date: Tue, 11 Dec 2012 11:47:33 +0400 > Subject: [PATCH 2/2] Reset SecureXMLRPCServer.py due to M2Crypto errors This worries me quite a bit. Which M2Crypto errors are you referring to? We may need to revert http://gerrit.ovirt.org/8123 - but it has performance improvement that is a shame to miss. > > --- > vdsm/SecureXMLRPCServer.py | 92 +++++++------------------------------------- > 1 files changed, 14 insertions(+), 78 deletions(-) > > diff --git a/vdsm/SecureXMLRPCServer.py b/vdsm/SecureXMLRPCServer.py > index 2de1cf7..9396a28 100644 > --- a/vdsm/SecureXMLRPCServer.py > +++ b/vdsm/SecureXMLRPCServer.py > @@ -34,86 +34,10 @@ import ssl > import httplib > import socket > import SocketServer > -import logging > - > -from M2Crypto import SSL, X509 > > SecureXMLRPCRequestHandler = SimpleXMLRPCServer.SimpleXMLRPCRequestHandler > > > -class SSLSocket(object): > - """SSL decorator for sockets. > - > - This class wraps a socket returned by the accept method of a > - server socket providing the SSL socket methods that are missing in > - the connection class. The rest of the methods are just delegated. > - """ > - > - def __init__(self, connection): > - # Save the reference to the connection so that we can delegate > - # calls to it later: > - self.connection = connection > - > - def gettimeout(self): > - return self.connection.socket.gettimeout() > - > - def __getattr__(self, name): > - # This is how we delegate all the rest of the methods to the > - # underlying SSL connection: > - return getattr(self.connection, name) > - > - > -class SSLServerSocket(SSLSocket): > - """SSL decorator for server sockets. > - > - This class wraps a normal socket so that when the accept method is > - called the accepted socket is also decorated. > - """ > - > - def __init__(self, raw, certfile=None, keyfile=None, ca_certs=None, > - session_id="vdsm", protocol="sslv23"): > - # Create the SSL context: > - self.context = SSL.Context(protocol) > - self.context.set_session_id_ctx(session_id) > - > - # Load the server certificate and key files: > - if certfile and keyfile: > - self.context.load_cert_chain(certfile, keyfile) > - > - def verify(context, certificate, error, depth, result): > - # The validation of the client certificate has already been > - # performed by the OpenSSL library and the handhake already aborted > - # if it fails as we use the verify_fail_if_no_peer_cert mode. We > - # are not doing any additional validation, so we just need to log > - # it and return the same result. > - if not result: > - certificate = X509.X509(certificate) > - logging.error( > - "invalid client certificate with subject \"%s\"", > - certificate.get_subject()) > - return result > - > - # Load the certificates of the CAs used to verify client > - # connections: > - if ca_certs: > - self.context.load_verify_locations(ca_certs) > - self.context.set_verify( > - mode=SSL.verify_peer | SSL.verify_fail_if_no_peer_cert, > - depth=10, > - callback=verify) > - > - # Create the SSL connection: > - self.connection = SSL.Connection(self.context, sock=raw) > - > - def accept(self): > - # The SSL connection already returns a SSL prepared socket, but it > - # misses some of the methods that the XML PRC server uses, so we need > - # to wrap it as well: > - client, address = self.connection.accept() > - client = SSLSocket(client) > - return client, address > - > - > class SecureXMLRPCServer(SimpleXMLRPCServer.SimpleXMLRPCServer): > def __init__(self, addr, > requestHandler=SimpleXMLRPCServer.SimpleXMLRPCRequestHandler, > @@ -129,15 +53,27 @@ class SecureXMLRPCServer(SimpleXMLRPCServer.SimpleXMLRPCServer): > requestHandler, > logRequests, allow_none, encoding, > bind_and_activate=False) > - self.socket = SSLServerSocket(raw=self.socket, certfile=certfile, > - keyfile=keyfile, ca_certs=ca_certs) > + self.socket = ssl.wrap_socket(self.socket, > + keyfile=keyfile, certfile=certfile, > + ca_certs=ca_certs, server_side=True, > + cert_reqs=ssl.CERT_REQUIRED, > + do_handshake_on_connect=False) > if timeout is not None: > self.socket.settimeout = timeout > if bind_and_activate: > self.server_bind() > self.server_activate() > > + def finish_request(self, request, client_address): > + request.do_handshake() > + > + return SimpleXMLRPCServer.SimpleXMLRPCServer.finish_request( > + self, > + request, > + client_address) > + > def handle_error(self, request, client_address): > + import logging > logging.error('client %s', client_address, exc_info=True) > >

5 8

Live storage migration status in oVirt 3.2
by shuming＠linux.vnet.ibm.com 13 Jan '13

13 Jan '13

Hi, I am reviewing the live storage migration with my oVirt environment updated from the public nightly repository two weeks ago. I found that the "move" button was still gray as before when the VM was up. Only after I deactivated the disk, did the button become into non-gray state. I am wondering if the live storage migration will be supported in oVirt 3.2 release or not. BTW: These patches below should enable the live storage migration already, but I can not see it enabled in my engine. http://gerrit.ovirt.org/5252 Change I91e641cb: pool: live storage migration implementation http://gerrit.ovirt.org/8105 Change subject: core: Live Storage Migration commands http://gerrit.ovirt.org/8103 Change subject: core: VDS Commands for Live Storage Migration http://gerrit.ovirt.org/8102 Change subject: core: Adding VDSM API for Live Storage Migration http://gerrit.ovirt.org/8470 Change subject: webadmin: Adding Live Storage Migration support http://gerrit.ovirt.org/8857 core: disable LiveStorageMigration on 3.1 -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

3 3

ATTN: Project Maintainers: Code Freeze/Branch/Beta Build deadlines
by mburns＠redhat.com 09 Jan '13

09 Jan '13

(Sorry for cross posting, trying to ensure I hit all the relevant maintainers) If you are the primary maintainer of a sub-project in oVirt, this message is for you. At the Weekly oVirt Meeting, the final devel freeze and beta dates were decided. Freeze: 2013-01-14 Beta Post: 2013-01-15 Action items: * You project should create a new branch in gerrit for the release * You should create a formal build of your project for the beta post * Get the formal build of your project into the hands of someone who can post it [1][2] These should all be done by EOD on 2013-01-14 (with the exception of ovirt-node-iso) [3] Packages that this impacts: * mom * otopi * ovirt-engine * ovirt-engine-cli * ovirt-engine-sdk * ovirt-guest-agent * ovirt-host-deploy * ovirt-image-uploader * ovirt-iso-uploader * ovirt-log-collector * ovirt-node * ovirt-node-iso * vdsm Thanks Mike Burns [1] This is only necessary if the package is *not* already in fedora repos (must be in actual fedora repos, not just updates-testing or koji) [2] Communicate with mburns, mgoldboi, oschreib to deliver the packages [3] ovirt-node-iso requires some of the other packages to be available prior to creating the image. This image will be created either on 2013-01-14 or 2013-01-15 and posted along with the rest of the Beta.

1 0

ovirt nightly FC17 public repositories broken?
by shuming＠linux.vnet.ibm.com 07 Jan '13

07 Jan '13

Hi, Any one was encountering this error message when using yum on ovirt public repositories? http://ovirt.org/releases/nightly/rpm/Fedora/17/repodata/primary.xml.gz <http://ovirt.org/releases/nightly/rpm/Fedora/17/repodata/primary.xml.gz>: [Errno -1] Metadata file does not match checksum My vdsm host and engine server was installed with FC17+virt-review, so I used FC17 nightly releases to update my VDSM and engine packages. After a bit investigation, I found these issues. [root@node1-sming ovirt-nightly]# ls -lh * -rw-r--r--. 1 root root 0 Jan 7 16:47 cachecookie -rw-r--r--. 1 root root 702K Jan 7 14:22 filelists.xml.gz -rw-r--r--. 1 root root 132K Jan 7 14:22 other.xml.gz -rw-r--r--. 1 root root 279K Jan 7 14:22 primary.xml.gz -rw-r--r--. 1 root root 1.4K Jan 5 14:35 repomd.xml *<---the date was always Jan 5 different from other files even http://resources.ovirt.org/releases/nightly**/rpm/Fedora/17/repodata/ showed it was Jan 7, also I tried to use wget to download this file and got the same thing.** * [root@node1-sming ovirt-nightly]# sha1sum other.xml.gz filelists.xml.gz primary.xml.gz 453559e86950af07c876931f318d1e92ab58f289 other.xml.gz 5318e237c0f4d2ea3d1ec24e82b9f9bbe9d23a31 filelists.xml.gz e667267d45b576844a5f2cb27ce7bcfb8bb9b4f0 primary.xml.gz [root@node1-sming ovirt-nightly]# cat repomd.xml |grep open-checksum <open-checksum type="sha256">ce6a5243ee81c124d0fe48d103174b93fabe60573e80b5851888298373d3be9e</open-checksum> <open-checksum type="sha256">554a301c526d335ca4a7985e7fc7b0374bca8c061ff5addbd164de81996dc5a0</open-checksum> <open-checksum type="sha256">be3f9e6860cd9a4ac4f3f5000ad503175e7ac79a43185a778d4ab732c0d8190c</open-checksum> *Note: These checksum from repmod.xml were quite different from the result of sha1sum above.* Any clues here? -- --- 舒明 Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC

1 0

Re: [vdsm] starting up vdsm and svdsm
by lvroyce＠linux.vnet.ibm.com 06 Jan '13

06 Jan '13

>Currently, vdsm deamon script starts (respawn) vdsm process as vdsm >user, and during that vdsm starts super vdsm process as root. > * when vdsm dies, svdsm process supposed to notice and exit by itself. > * if svdsm dies, in the next proxy call by vdsm, vdsm supposed to >start new svdsm instance after verifying that old instance is dead and >call it. >This is super vdsm and vdsm startup design in general. >-- >In current implementation we have some edge cases that we need to handle: > * vsdm can try to communicate with old instance of svdsm. > * vdsm can kill wrong process that got last svdsm pid before starting >the new instance of svdsm. > * vdsm can try to communicate with svdsm before svdsm starts to serve >requests. >And i guess there are many more possible senerios that can cause bugs.. >As it seems, it doesn't make sense that vdsm manages root process, and >can kill it.. >What if svdsm will be the manager of vdsm: > * deamon script starts up svdsm instance instead of vdsm > * svdsm forks vdsm and changes its privilege (uid to vdsm) > * vdsm receives as parameter svdsm pid for sudo requests you mean vdsm can kill svdsm? I'd suggest svdsm exports a getProxy().killSvdsm() functinon. > * when vdsm dies, svdsm will start new instance of vdsm automatically, supervdsm poke should be change to periodically wait() and restart. >and note the crash reason to syslog. > * svdsm starts with respawn, so when svdsm dies, vdsm dies also as its >son process, and another instance of svdsm will start automatically and >start new instance of vdsm. usecase: svdsm recieve SIGTERM, (1)if svdsm waits to join vdsm in a thread: vdsm as its child process should receive signal to terminate, Using Process() to start vdsm, and if supervdsm reload SIGTERM(sigterm handler is to kill vdsm), supervdsm will never join vdsm and exit.It will just hang there. (2)when svdsm not wait: vdsm still be alive,svdsm will need to kill vdsm at next time startup or will result in: error: [Errno 98] Address already in use when start a new vdsm to bind xmlrpc server also, Not sure about if it is safe for svdsm to terminate vdsm because vdsm may in the middle of other activities. >Also, svdsm can init whatever vdsm needs and is limited to do as a vdsm >user (check log permissions, clean old temporary files and so on if >needed..) >Royce Lv has already started to work on such design here >http://gerrit.ovirt.org/#/c/4145/ So my previous choice is to : 1) As root, create a new process for supervdsmServer 2) Drop privileges in the parent 3) Start vdsm in the parent Then, if vdsm detects a problem with supervdsm, it can just exit. This will cause respawn to restart everything again. So if either process (vdsm, or supervdsm) dies, the whole thing will be respawned. See the draft here, let's discuss about it: http://www.ovirt.org/Normalize_vdsm_start_up_process I'm also agree with breaking these two as dependent services just as vdsmd and libvirtd. These will involve supervdsm died and vdsm reconnect, if we use key this will be security issue. So now we use key as local variable.If just use child/parent pipe, here is similar restart logic to handle. >I want to update it and push it forward. >I would like to hear more opinions and point of views on this change, >Thanks.

3 4

FW: Querying for and registering unknown disk images on a storage domain
by Morrissey, Christopher 02 Jan '13

02 Jan '13

Hi All, I've been working on a bit of functionality for the engine that will allow a user to query a domain for new disk images (GetUnregisteredImagesQuery) for which the engine was previously unaware and a separate command to register those images (ImportImageCommand). These commands will be exposed through the REST API. This functionality is needed as we are developing an extension/plugin to oVirt that will allow a NetApp storage controller to handle cloning the actual disks outside of oVirt and need to import them once they are cloned. We'll be using other existing APIs to attach the disk to the necessary VM once the disk is cloned. On the NetApp side, we'll ensure the disk is coalesced before cloning so as to avoid the issues of registering snapshots. GetUnregisteredImagesQuery will be accessible through the disks resource collection on a storage domain. A "disks" resource collection does not yet exist and will need to be added. To access the unregistered images, a parameter (maybe "unregistered=true") would be passed. So the path to "GET" the unregistered disk images on a domain would be something like /api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true. This will return a list of disk images that can be each used as input to the ImportImageCommand to get them added to oVirt. ImportImageCommand will be accessible through "POST"ing a disk to /api/disks?import=true. The disk will be added to the oVirt DB based on the information supplied and afterward would be available to attach to a VM. When querying for unregistered disk images, the GetUnregisteredImagesQuery command will use the getImagesList() VDSM command. Currently this only reports the GUIDs of all disk images in a domain. I had been using the getVolumesList() and getVolumeInfo() VDSM commands to fill in the information so that valid disk image objects could be registered in oVirt. It seems these two functions are set to be removed since they are too invasive into the internal VDSM workings. The VDSM team will need to either return more information about each disk as part of the getImagesList() function or add a new function getImageInfo() that will give the same information for a given image GUID. Note that much of this work had originally been submitted under patch http://gerrit.ovirt.org/#/c/9603/. After several reviews it was found to be lacking in its design and was using deprecated APIs that did not yet have replacements. I'm reworking the code now to conform to this design and asking for further input from the VDSM, core, and restapi teams to ensure we can get this done quickly and correctly as it is needed for the 3.2 release. -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel January 2013