- Devel - oVirt List Archives

[VDSM][sampling] thread pool status and handling of stuck calls
by Francesco Romani 16 Jul '14

16 Jul '14

Hi, Nir has begun reviewing my draft patches about the thread pool and sampling refactoring (thanks!), and already suggested quite some improvements which I'd like to summarize Quick links to the ongoing discussion: http://gerrit.ovirt.org/#/c/29191/8/lib/threadpool/worker.py,cm http://gerrit.ovirt.org/#/c/29190/4/lib/threadpool/README.rst,cm Quick summary of the discussion on gerrit so far: 1. extract the scheduling logic from the thread pool. Either add a separate scheduler class or let the sampling task reschedule themselves after a succesfull completion. In any way the concept of 'periodic task', and the added complexity, isn't needed. 2. drop all the *queue classes I've added, thus making the package simpler. They are no longer needed since we remove the concept of periodic task. 3. have per-task timeout, move the stuck task detection elsewhere, like in the worker thread, ot maybe better in the aforementioned scheduler. If the scheduler finds that any task started in the former pass (or even before!) has not yet completed, there is no point in keeping this task alive and it should be cancelled. 4. the sampling task (or maybe the scheduler) can be smarter and halting the sample in presence of not responding calls for a given VM, granted the VM reports its 'health'/responsiveness. (Hopefully I haven't forgot anything big) In the draft currently published, I reluctantly added the *queue classes and I agree the periodic task implementation is messy, so I'll be very happy to drop them. However, a core question still holds: what to do in presence of the stuck task? I think it is worth to discuss this topic on a medium friendlier than gerrit, as it is the single most important decision to make in the sampling refactoring. It all boils down to: Should we just keep somewhere stuck threads and wait? Should we cancel stuck tasks? A. Let's cancel the stuck tasks. If we move toward a libvirt connection pool, and we give each worker thread in the sampling pool a separate libvirt connection, hopefully read-only, then we should be able to cancel stuck task by killing the worker's libvirt connection. We'll still need a (probably much simpler) watchman/supervisor, but no big deal here. Libvirt allows to close a connection from a different thread. I haven't actually tried to unstuck a blocked thread this way, but I have no reason to believe it will not work. B. Let's keep around blocked threads The code as it is just leaves a blocked libvirt call and the worker thread that carried it frozen. The stuck worker thread can be replaced up to a cap of frozen threads. In this worst case scenario, we end up with one (blocked!) thread per VM, as it is today, and with no sampling data. I believe that #A has some drawbacks which we risk to overlook, and on the same time #B has some merits. Let me explain: The hardest case is a call blocked in the kernel in D state. Libvirt has no more room than VDSM to unblock it; and libvirt itself *has* a pool of resources (threads in this case) which can be depleted by stuck calls. Actually, retrying to do a failed task may deplete their pool even faster[1]. I'm not happy to just push this problem down the stack, as it looks to me that we gain very little by doing so. VDSM itself surely stays cleaner, but the VDS/hypervisor hosts on the whole improves just a bit: libvirt scales better, and that gives us some more room. On the other hand, by avoiding to reissue dangerous calls, I believe we make better use of the host resources in general. Actually, the point of keeping blocked thread around is a side effect of not reattempting blocked calls. Moreover, to keep the blocked thread around has a significant benefit: we can discover at the earliest moment when it is safe again to do the blocked call, because the blocked call itself returns and we can track this event! (and of course drop the now stale result). Otherwise, if we drop the connection, we'll lose this event and we have no more option that trying again and hoping for the best[2] I know the #B approach is not the cleanest, but I think it has slightly more appeal, especially on the libvirt depletion front. Thoughts and comments very welcome! +++ [1] They have extensions to management API to dinamically adjust their thread pool and/or to cancel tasks, but it is in the RHEL7.2 timeframe. [2] A crazy idea would be to do something like http://en.wikipedia.org/wiki/Exponential_backoff which I'm not sure would be beneficial Bests and thanks, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

6 18

Custom fencing with virsh_fence
by Adam Litke 15 Jul '14

15 Jul '14

Hi all, I am trying to configure custom fencing using fence_virsh in order to test out fencing flows with my virtualized oVirt hosts. I'm getting a failure when clicking the "Test" button. Can someone help me to diagnose the problem? I have applied the following settings using engine-config: ~/ovirt-engine/bin/engine-config -s CustomVdsFenceType="xxxvirt" ~/ovirt-engine/bin/engine-config -s CustomFenceAgentMapping="xxxvirt=virsh" ~/ovirt-engine/bin/engine-config -s CustomVdsFenceOptionMapping="xxxvirt:address=ip,username=username,password=password" (note that engine-config seems to arbitrarily limit the number of mapped options to 3. Seems like a bug to me). Here is the log output in engine.log: 2014-07-15 11:43:34,813 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (http--0.0.0.0-8080-1) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Host centennial from cluster block was chosen as a proxy to execute Status command on Host cascade. 2014-07-15 11:43:34,813 INFO [org.ovirt.engine.core.bll.FenceExecutor] (http--0.0.0.0-8080-1) Using Host centennial from cluster block as proxy to execute Status command on Host 2014-07-15 11:43:34,815 INFO [org.ovirt.engine.core.bll.FenceExecutor] (http--0.0.0.0-8080-1) Executing <Status> Power Management command, Proxy Host:centennial, Agent:virsh, Target Host:, Management IP:192.168.2.101, User:root, Options: 2014-07-15 11:43:34,816 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8080-1) START, FenceVdsVDSCommand(HostName = centennial, HostId = a34f7dbc-dd99-4831-a1a9-54c411080ec1, targetVdsId = b6b9d480-e20f-411a-9b9c-883fac32a4e5, action = Status, ip = 192.168.2.101, port = , type = virsh, user = root, password = ******, options = ''), log id: 24f33bda 2014-07-15 11:43:34,875 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8080-1) Failed in FenceVdsVDS method, for vds: centennial; host: 192.168.2.103 2014-07-15 11:43:34,876 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8080-1) Command FenceVdsVDSCommand(HostName = centennial, HostId = a34f7dbc-dd99-4831-a1a9-54c411080ec1, targetVdsId = b6b9d480-e20f-411a-9b9c-883fac32a4e5, action = Status, ip = 192.168.2.101, port = , type = virsh, user = root, password = ******, options = '') execution failed. Exception: ClassCastException: [Ljava.lang.Object; cannot be cast to java.lang.String 2014-07-15 11:43:34,877 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (http--0.0.0.0-8080-1) FINISH, FenceVdsVDSCommand, log id: 24f33bda -- Adam Litke

2 2

Fwd: Test run for ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso - Pass
by Fabian Deutsch 15 Jul '14

15 Jul '14

Hey, forwarding this results. - fabian ----- Forwarded Message ----- From: "Haiyang Dong" <hadong(a)redhat.com> To: "Fabian Deutsch" <fabiand(a)redhat.com>, "Lei Wang" <leiwang(a)redhat.com>, "ycui" <ycui(a)redhat.com> Cc: ovirt-devel(a)ovirt.org, "node-devel" <node-devel(a)ovirt.org> Sent: Tuesday, 15 July, 2014 11:15:03 AM Subject: Test run for ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso - Pass SUMMARY: The ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso - run testing result is pass due to most functions of this iso could be work. ISO Link: http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ovirt-node-iso-3.5.0.ovirt… New Feature Sanity Test: 1. Configure kdump via ssh + sshkey -PASS 2. Set Logroate log with Interval Daily/ weekly/Monthly -PASS 3. Set ssh daemon port -PASS 4. Set console path -PASS 5.ovirt-node-config tools Parameters： (a). h -FAILED (b). --module -PASS (c). --dry -PASS (d). --config -PASS 6. ovirt-node-features tools Parameters: (a). -d -FAILED (b). dumpxml -FAILED Auto test runs: http://10.66.8.158:3000/profile/by/ovirt-node-iso-3.5.0.ovirt35.20140707.el… Automated - Auto Install cover parameters No. Auto-install parameters Stautus Case Comments 1 gateway PASS 1 cases 2 hostname PASS 1 cases 3 ntp FAIL 2 cases bz#1119665 4 bond_setup PASS 1. mode related(14 cases) 2. bond + vlan (1 cases) 5 network_layout PASS 2 cases 6 adminpw PASS 1 cases 7 kdump_nfs PASS 1 cases 8 netconsole FAILED 2 Cases 1. default port 2. customer port bz# 1119566 9 mem_overcommit PASS 1 cases 10 reinstall PASS 1 cases 11 logrotate_max_size PASS 1 cases 12 ssh_pwauth PASS 1 cases 13 dns PASS 1 cases 14 nocheck PASS 1 cases 15 tuned PASS 13 cases 16 keyboard PASS 1 cases 17 nfsv4_domain PASS 1 cases 18 syslog PASS 1 cases 19 iscsi_install PASS 2 cases 1.Soft iscsi 2.hard lun iscsi 20 Host VG in two disk PASS 1 cases 21 Host VG and APP VG PASS 1 cases 22 disable_aes_ni PASS 1 cases 23 use_strong_rng PASS 1 cases 24 storage_init PASS 5 cases /dev/mapper,ata,usb,scsi:,/dev/sda 25 swap_encrypt PASS 1 Cases 26 storage_vol PASS 2 cases Default,customize Total Manual test runs: https://tcms.engineering.redhat.com/run/159715/?from_plan=13675 https://tcms.engineering.redhat.com/run/159716/?from_plan=13675 https://tcms.engineering.redhat.com/run/159714/?from_plan=13675 https://tcms.engineering.redhat.com/run/159713/?from_plan=13675 Manual Acceptance testing Matrix: Main Function Basic Function TUI Status Auto Status Main Function Basic Function TUI Status Auto Status Boot PXE ------- ------- Logging Rsyslog PASS ------- USB PASS PASS Netconsole FAIL ------- CD-ROM PASS PASS Kdump NFS PASS ------- Virtual-Media PASS PASS SSH PASS ------- Partition Partition storage PASS PASS Local PASS ------- Installation FC PASS FAIL RHN RHN No rhn plungins in upstream No rhn plungins in upstream iSCSI ------- PASS Satellite No rhn plungins in upstream No rhn plungins in upstream Local Disk PASS PASS SAM No rhn plugin in upstream No rhn plungins in upstream CCISS PASS PASS SNMP SNMP no snmp plugin in rthis base image no snmp plugin in rthis base image USB ------- PASS CIM CIM no cim plugin in rthis base image no cim plugin in rthis base image Upgrade PXE ------- FAIL Keyboard US / German PASS PASS CD-ROM PASS FAIL Diagnostics Diagnostics PASS ------- USB PASS ------- Performance Performances PASS PASS Virtual-Media PASS FAIL Plugins Plugins PASS ------- Uninstall Uninstall ------- ------- Other Menu Support Menu PASS ------- Network IPv4 PASS ------- iSCSI initiator PASS PASS Ipv6 PASS ------- Hostname PASS PASS vlan ------- ------- Authentication PASS PASS For detail test cases, you can check the following test runs. ======ovirt-node-iso-3.5.0.ovirt35.20140707.el6.iso======== Test Result: PASS Packages Tested: (1) ovirt-node-3.1.0-0.0.master.20140707.git2f40d75.el6.noarch New Bug: (10) Bug ID Summary Status Reporter Component 1118729 Configure kdump via ssh failed after configured kdump via ssh +sshkey. New hadong ovirt-node 1118758 Add validator for ssh port to only accpet "22" or "1024-65535" New hadong ovirt-node 1118952 Thrown nameerror:global name 'Feature' is not defined when using "ovirt-node-features dumpxml" New hadong ovirt-node 1118962 Thrown IndexError: list index out of range when using "ovirt-node-config h" New hadong ovirt-node 1118965 [RFE]Move "ovirt-config-password" from "/usr/libexec/" into "/usr/bin/" or "/usr/sbin/" New hadong ovirt-node 1119566 Configuring the Netconsole with ipv4 address failed New guasun ovirt-node 1119571 confirmation_page:Boot device still shown the first disk even if selected the second disk as the boot device New hadong ovirt-node 1119606 The name of "ovirt-node-plugin-vdsm" is incorrect New cshao ovirt-node 1119620 Upgrade failed via kernel cmdline. New cshao ovirt-node 1119665 Auto install with parameter "ntp" to set ntp server failed New hadong ovirt-node Existed bug List: (0) Bug ID Summary Status Reporter Component Verified: (0) Bug ID Summary Status Reporter Component

2 1

Info related to display port allocation
by Vinzenz Feenstra 15 Jul '14

15 Jul '14

Hi, I just want to give all of you an update on a recently created bug on VDSM. Until recently we had 2 ports allocated for spice one for tls and one plain text. We have now observed the behaviour on RHEL7 and I also did now on RHEL6 that when all spice channels are marked as secure, only the tlsPort value is set in the domain xml. VDSM will report the non-tls port as 'port=-1' For us this is a good thing since we're saving one port in these cases and we're encouraging users to use the ssl configuration anyway. I just wanted to give you a heads up on this, in case anyone is assuming the 'port' value reported by getAllVmStats or list full=True API calls would be returning any value but -1. -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Fwd: Re: [ovirt-users] VDSM respawning too quickly
by Sven Kieske 15 Jul '14

15 Jul '14

FYI, please share some karma for this package! It seems that all host installation for ovirt fail until this is resolved, maybe there should be additional tests before releasing new software? I need to install a new host today and I hope it will work. Currently epel still offers 0.1.3-2 :( Thanks -------- Original-Nachricht -------- Betreff: Re: [ovirt-users] VDSM respawning too quickly Datum: Mon, 14 Jul 2014 15:53:17 -0500 Von: Chris Adams <cma(a)cmadams.net> An: <users(a)ovirt.org> Once upon a time, Kyle Gordon <kyle(a)lodge.glasgownet.com> said: > Following an upgrade from 3.3 to 3.4, I've been greeted with this > message in /var/log/messages, on my CentOS 6.5 server. I'm hitting the same thing with an up-to-date CentOS 6.5 trying to install hosted-engine. It appears the problem is an updated pythong-pthreading package in EPEL, version 0.1.3-2. There's already a 0.1.3-3 in koji that rolls back the patch in 0.1.3-2. http://koji.fedoraproject.org/koji/buildinfo?buildID=543650 -- Chris Adams <cma(a)cmadams.net> _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

2 1

Weekly oVirt Engine Appliance builds
by Fabian Deutsch 14 Jul '14

14 Jul '14

Hey, Finally there are weekly Fedora 19 based oVirt Engine Appliance builds. They can be found in oVirt’s jenkins instance: http://jenkins.ovirt.org/view/All/job/ovirt-appliance_master_merged/ An ova file is created, this can either be used with Engine or you can extract it (it's a compressed tarball) and use it with four favorite virtualization solution. - fabian

1 0

Removing boilerplate code in engine
by Mike Kolesnik 14 Jul '14

14 Jul '14

Hi, I recently introduced 2 changes for removing boilerplate code: 1. http://gerrit.ovirt.org/29414 - Fluent syntax for writing validations 2. http://gerrit.ovirt.org/29617 - Wrapper for locks to use with try-with-resources By removing boilerplate code we're making the code less error prone and easier to read (and maintain). I've already sent some simple refactors to use these new styles of writing, but more work is necessary to apply to the whole project. I urge all engine developers that need to write such code to use the new styles of writing. Below are examples for each change. 1. When expecting a negative outcome, instead of using: return getVds() == null ? new ValidationResult(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST) : ValidationResult.VALID; use: return ValidationResult.failWith(VdcBllMessages.ACTION_TYPE_FAILED_HOST_NOT_EXIST) .when(getVds() == null); When expecting a positive outcome, instead of using: return FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version()) ? ValidationResult.VALID : new ValidationResult(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL); use: return ValidationResult.failWith(VdcBllMessages.NON_VM_NETWORK_NOT_SUPPORTED_FOR_POOL_LEVEL) .unless(FeatureSupported.nonVmNetwork(getDataCenter().getcompatibility_version())); 2. To lock a block of code, instead of using [1]: lock.lock(); try { // Thread safe code } finally { lock.unlock(); } use: try (AutoCloseableLock l = new AutoCloseableLock(lock)) { // Thread safe code } [1] This is best used with locks from java.util.concurrent.locks package. For regular thread safe blocks it's best to use the standard synchronized block. Regards, Mike

2 1

python-pthreading 0.1.3-3
by ybronhei 13 Jul '14

13 Jul '14

Hello everybody, Few days ago we published python-pthreading 0.1.3-2 which included a patch ([1]) that fixes urgent bug in ovirt ([2]) Today we found out that this build also includes a patch (called monkey_patch: Fail if it is too late to monkey-patch) that introduces regression with older versions of ovirt. Therefore we publish new build (0.1.3-3) that includes only the required fix. Please test and give it a karma for your environment, if you can [3] [4] [5] [6] [7] Thanks, [1] Add the missing locked() interface [2] https://bugzilla.redhat.com/show_bug.cgi?id=1117795 [3] http://koji.fedoraproject.org/koji/buildinfo?buildID=543650 (el6) [4] http://koji.fedoraproject.org/koji/buildinfo?buildID=543651 (f19) [5] http://koji.fedoraproject.org/koji/buildinfo?buildID=543653 (f20) [6] http://koji.fedoraproject.org/koji/buildinfo?buildID=543649 (f21) [7] http://koji.fedoraproject.org/koji/buildinfo?buildID=543655 (el7) -- Yaniv Bronhaim.

1 0

Re: [ovirt-devel] [vdsm] compile vdsm and attach it to a engine.
by ybronhei 13 Jul '14

13 Jul '14

On 07/03/2014 05:11 AM, aaron Beein wrote: > Hi, > > Thank you for your great job on ovirt and vdsm. Now I devote myself to > compile vdsm on centos 6.3 host and attach it to a ovirt engine. But when I > attach the host which contains a compiled vdsm to a ovirt engine , the > status of the host is always ‘Non Responsive’(step 11 below). I reference > the links below: > > http://www.ovirt.org/Vdsm_Developers > > http://www.ovirt.org/Installing_VDSM_from_rpm > > > > The steps( 1-9 ) are executed on centos6.3 host, and the steps(10--11) are > executed on ovirt engine. So I would be very grateful if you can give me > some clues that if I've missed anything or I done something wrong. > > The attachment is the same as the bellow which makes it easier for you to > read. > 1 Deployment platform > > Centos6.3 > > Linux bogon 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 > x86_64 x86_64 x86_64 GNU/Linux > > Ip ： 10.1.8.252 > > CPU supports hardware virtualization extensions: > > # cat /proc/cpuinfo | egrep 'svm|vmx'| grep nx > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc > aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr > pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb > xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc > aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr > pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm arat epb > xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid > 2 Apply all updates # yum -y update 3 Installing required packages > > RHEL 6 users must add EPEL yum repository for installing python-ordereddict > and pyton-pthreading. The rpm bellow will install the epel yum repo and > required gpg keys. > > # yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.r… > > RHEL 6 users must install a newer pep8 version than the one shipped in > EPEL6. Older pep8 versions have a bug that's tickled by vdsm. You can use > `pip`, or > > yum install http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm > > oVirt repo: > > yum install http://resources.ovirt.org/releases/ovirt-release.noarch.rpm > > RHEL 6 users must add the glusterfs repository, providing newer glusterfs > not available on RHEL 6. Optionally install 'wget' if not present > > rpm -q wget 2> /dev/null || yum install wget > > wget -O /etc/yum.repos.d/glusterfs-epel.repo > *http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/glusterfs-epel.repo* > <http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/glusterf…> > > Fedora and RHEL 6 users must verify the following packages are installed > before attempting to build: > > yum install make autoconf automake pyflakes logrotate gcc python-pep8 > libvirt-python python-devel \ > > python-nose rpm-build sanlock-python genisoimage python-ordereddict > python-pthreading libselinux-python\ > > python-ethtool m2crypto python-dmidecode python-netaddr > python-inotify python-argparse git \ > > python-cpopen bridge-utils libguestfs-tools-c pyparted openssl libnl > libtool gettext-devel python-ioprocess libvirt libvirt-client > libvirt-lock-sanlock > > 4 Getting the source > > cd /root > > git clone *http://gerrit.ovirt.org/p/vdsm.git* > <http://gerrit.ovirt.org/p/vdsm.git> > > cd vdsm > > 5 Building a Vdsm RPM > > ./autogen.sh –system > > > > ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var > --libdir=/usr/lib --enable-hooks > > make rpm NOSE_EXCLUDE=.* > 6 Basic installation and start > > When building from source, you should enable the ovirt-beta repository, to > satisfy dependencies that are not available yet in the release repository. > > # cd ~/rpmbuild/RPMS > > # yum install --skip-broken > --enablerepo=ovirt-master-snapshot-static x86_64/* noarch/vdsm-xml* > noarch/vdsm-cli* noarch/vdsm-python-zombiereaper* > noarch/vdsm-*jsonrpc* > > > > Before starting vdsmd service for the first time vdsm requires some > configuration procedures for external services that being used by vdsmd. To > ease this process vdsm provides a utility (vdsm-tool). To perform full > reconfiguration of external services perform: > > # vdsm-tool configure --force > > (for more information read "vdsm-tool --help") > > > > > 7 Finally start the vdsmd service > > # service vdsmd start > > > 8 Yum install -y bridge-utils > > Configuring the bridge Interface as below > > Disable the network manager service by executing as root: > > systemctl stop NetworkManager.service > > systemctl disable NetworkManager.service > > > > service network start > > chkconfig network on > > Add the following content into a new file named: > */etc/sysconfig/network-scripts/ifcfg-ovirtmgmt*: > > DEVICE=ovirtmgmt > > TYPE=Bridge > > ONBOOT=yes > > DELAY=0 > > BOOTPROTO=static > > IPADDR=10.1.8.252 > > NETMASK=255.255.255.0 > > GATEWAY=10.1.8.254 > > Add the following line into the configuration file of your out going > interface (usually em1/eth0) the file is located at: > */etc/sysconfig/network-scripts/ifcfg-em1* (assuming the device is em1) > > BRIDGE=ovirtmgmt > > and remove the IPADDR, NETMASK and BOOTPROTO keys, since the interface > should not have an IP address of its own. Full Example > > DEVICE=em1 > > ONBOOT=yes > > BRIDGE=ovirtmgmt > > Restart the network service by executing: > > service network restart > > *Note that if any other bridge (from ovirtmgmt) is present at the time of > host installation, the bridge creation operation is skipped and you have to > change the bridge settings to correspond to above shown configuration > manually.* > > > > *9 Configuring VDSM* > > Add the following content into the file: */etc/vdsm/vdsm.conf* (you may > need to create that file): > > [vars] > > ssl = false > > Restart the vdsmd service by executing: > > service vdsmd restart > > If Vdsm was started earlier with ssl=true, it would refuse to start and you > may need to use the undocumented verb > > service vdsmd reconfigure you should perform - "vdsm-tool configure --force" without touching other conf files. you already did it, so nothing else required although, we you set InstallVds to true (few lines underneath), it means that when you add the host to engine it will perform all those deploying vdsm steps for you. So you don't have to do all those vdsm configuration and installation steps at all. > > service vdsmd start > > which edits */etc/libvirt/qemu.conf* and changes *spice_tls=1* to > *spice_tls=0*. > > > 10 Connect to overt-engine > > *ref: OVirt_-_connecting_development_vdsm_to_ovirt_engine > <http://www.ovirt.org/OVirt_-_connecting_development_vdsm_to_ovirt_engine>.* > > > > *su - postgres -c "psql engine -c \"UPDATE vdc_options set option_value = > 'true' where option_name = 'InstallVds'\""* > > > > *service overt-engine restart* > 11 Attach the host to the engine > > I login the engine Administration Portal , and attach the centos host to a > cluster. But it failed. > can you please attach logs (host deploy logs under /var/log/ovirt-engine/host-deploy , vdsm log under /var/log/vdsm (on host side) and engine log /var/log/ovirt-engine/engine.log) I forward the mail to devel(a)ovirt.org, vdsm-devel was merged to this one few months ago. > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > Regards. -- Yaniv Bronhaim.

1 0

[IMPORTANT] DB script numbering reminder
by Oved Ourfali 13 Jul '14

13 Jul '14

Hi Now that a branch was created for ovirt-engine-3.5, master is practically of version 3.6. So, when adding a DB script in a patch that is pushed to master, the numbering should start with 03_06_ABCD, where ABCD starts with 0010, second should be 0020, and so on... When this patch needs to be ported to 3.5 as well, the numbering there should be 03_05_EFGH, where EFGH is the next number in the stable branch. So, for example, if the last upgrade script in the stable branch starts with 03_05_0750, then the next should start with 03_05_0760, even if it starts with 03_06_0040 on master. Confused? we're here to help! Got it? go ahead and push some stuff! Have a great day, Oved

1 0