- Users - oVirt List Archives

Re: [ovirt-users] oVirt + opennode or oVirt+proxmox
by Juan Pablo Lorier 20 Jul '14

20 Jul '14

Hi Robson, I don't know openode, but I can tell you that I can't think of a way of using proxmox along ovirt. Both are virtualization platforms based on KVM (so you can run vms from one platafrom into the other without any conversion, just export-improt,copy or whatever you need to go from one to the other). They have both their upsides and downsides, basically IMHO, I like proxmox decentralized way of managing the platform, but I love more the great community around ovirt and it's fast evolution. One thing is certain, your virtualization host can't be both, ovirts and proxmox virtualization hosts. Regards,

1 0

oVirt + opennode or oVirt+proxmox
by Robson Kobayashi - TRE/MS 19 Jul '14

19 Jul '14

--=_ff960f68-5088-4f9c-b8f3-74757b194884 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Has anyone using proxmox or opennode with oVirt? Is that possible?  Robson Massaki Kobayashi  --=_ff960f68-5088-4f9c-b8f3-74757b194884 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'><span>Has anyone using proxmox or opennode with oVirt? Is that possible?<br><br><span name="x"></span><br>Robson Massaki Kobayashi<br><span name="x"></span><br></span><br></div></body></html> --=_ff960f68-5088-4f9c-b8f3-74757b194884--

2 1

Ceph support
by Johan Kooijman 18 Jul '14

18 Jul '14

Hi all, Does somebody have *any* idea on when oVirt will start to support Ceph through libvirtd? I could mount an RBD volume onto a server and then expert it as NFS, but that kills my I/O throughput quite severely (write IOPS go down by 84%). Ceph is the way to go for storage needs if you ask me, but I'd rather not move away from ovirt because there's no support. -- Met vriendelijke groeten / With kind regards, Johan Kooijman

2 1

Relationship bw storage domain uuid/images/children and VM's
by Steve Dainard 18 Jul '14

18 Jul '14

Hello, I'd like to get an understanding of the relationship between VM's using a storage domain, and the child directories listed under .../<storage domain name>/<storage domain uuid>/images/. Running through some backup scenarios I'm noticing a significant difference between the number of provisioned VM's using a storage domain (21) + templates (6) versus the number of child directories under images/ (107). Running RHEV 3.4 trial. Thanks, Steve

2 2

[ANN] oVirt 3.4.3 Release is now available
by Sandro Bonazzola 18 Jul '14

18 Jul '14

The oVirt development team is pleased to announce the general availability of oVirt 3.4.3 as of Jul 18th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system if you're upgrading from an older release. Please refer to release notes [1] for Installation / Upgrade instructions. Please note that mirrors will need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.4.repo commenting the mirror line and removing the comment on baseurl line. A new oVirt Live ISO will be available too[2]. [1] http://www.ovirt.org/OVirt_3.4.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.3.iso -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 3.4.3 GA postponed due to blocker
by Sandro Bonazzola 17 Jul '14

17 Jul '14

Hi, recent python upgrade in Fedora 19 broke vdsmd service. While we wait for an updated python-cpopen package to be built, we're postponing oVirt 3.4.3 GA. The package should be built for tomorrow and will be hosted on ovirt repo until it will be available on Fedora repositories. We'll release 3.4.3 after basic sanity testing with the new package. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 3

small cluster
by urthmover 17 Jul '14

17 Jul '14

I have 10 mac minis at my disposal. (Currently, I’m booting each device using a centos6.5 usbstick leaving the 2 disks free for use) GOAL: To build a cluster of 10 servers running postgres-xc EQUIPMENT: 10 mac mini: i7-3720QM(a)2.60GHz/16G RAM/1x1gbit NIC/2x1TB SSDs (zfs mirrored) REQUEST: Please run the software application postgres-xc (a multi-master version of postgres). I'm told by the DBA that disk IO is the most important factor for the tasks that he’ll be running. The DBA wants 10 servers each with a 50G OS partition and a 800GB /data. THOUGHTS: I have a few ideas for how to accomplish but I'm unsure which is the best balance between disk IO and overall IT management of the environment. QUESTIONS FOR THE LIST: Should I present each of the 10 mac mini’s mirrored disks to glusterfs thus creating a large 10TB storage area. Then connect the storage area to ovirt-engine creating on 10TB storage domain, and use it as the storage domain for 10 large 800GB disks (a /data for each guest) ? Should I present each mac mini’s mirrored pair as an nfs share to ovirt-engine? This would create 10 1TB storage domains. Then create 10 large 800GB /data partitions (a /data for each guest). Should I NOT use ovirt and just run each mac mini as a mirrored pair of disks and a sandalone server? LASTLY: I’m open to any other thoughts or ideas for how to best accomplish this task. Thanks in advance, -- urthmover

2 5

[QE] Hardening Guide
by Sandro Bonazzola 17 Jul '14

17 Jul '14

Hi, while I was working on Bug 1097022 - ovirt-engine-setup: weak default passwords for PostgreSQL database users I was wondering where to write hardening tips described in comment #18. It looks like we don't have any page on oVirt wiki about hardening. Anyone interested in contributing to such page? I guess it can be created as http://www.ovirt.org/OVirt_Hardening_Guide Thoughts? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

Missing Storage domain
by Maurice James 17 Jul '14

17 Jul '14

------=_Part_12515_719070347.1405534873658 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit What do I do when a host in a cluster cant find a storage domain that "it thinks" doesnt exist? The storage domain is in the db and is online because one of the other hosts is working just fine. I pulled this out of the vdsm.log. I even tried rebooting Thread-30::ERROR::2014-07-16 14:19:10,522::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) Error while collecting domain b7663d70-e658-41fa-b9f0-8da83c9eddce monitoring information Traceback (most recent call last): File "/usr/share/vdsm/storage/domainMonitor.py", line 204, in _monitorDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 98, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain dom = findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 171, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: ('b7663d70-e658-41fa-b9f0-8da83c9eddce',) ------=_Part_12515_719070347.1405534873658 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div>What do I do when a host in a cl= uster cant find a storage domain that "it thinks" doesnt exist? The storage= domain is in the db and is online because one of the other hosts is workin= g just fine. I pulled this out of the vdsm.log. I even tried rebooting<br><= /div><div><br></div><div><br></div><div>Thread-30::ERROR::2014-07-16 14:19:= 10,522::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) E= rror while collecting domain b7663d70-e658-41fa-b9f0-8da83c9eddce monitorin= g information<br>Traceback (most recent call last):<br>  File "/usr/sh= are/vdsm/storage/domainMonitor.py", line 204, in _monitorDomain<br> &n= bsp;  self.domain =3D sdCache.produce(self.sdUUID)<br>  File "/us= r/share/vdsm/storage/sdc.py", line 98, in produce<br>    dom= ain.getRealDomain()<br>  File "/usr/share/vdsm/storage/sdc.py", line 5= 2, in getRealDomain<br>    return self._cache._realProduce(s= elf._sdUUID)<br>  File "/usr/share/vdsm/storage/sdc.py", line 122, in = _realProduce<br>    domain =3D self._findDomain(sdUUID)<br>&= nbsp; File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain<br>&n= bsp;   dom =3D findMethod(sdUUID)<br>  File "/usr/share/vdsm= /storage/sdc.py", line 171, in _findUnfetchedDomain<br>    r= aise se.StorageDomainDoesNotExist(sdUUID)<br>StorageDomainDoesNotExist: Sto= rage domain does not exist: ('b7663d70-e658-41fa-b9f0-8da83c9eddce',)<br><b= r></div></div></body></html> ------=_Part_12515_719070347.1405534873658--

2 3

Re: [ovirt-users] fileserver as a guest oVirt
by Karli Sjöberg 17 Jul '14

17 Jul '14

--_000_5F9E965F5A80BC468BE5F40576769F098C555F4Cexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTIganVsIDIwMTQgMjI6NDkgc2tyZXYgTmlrbGFzIEZvbmRiZXJnIDxuaWtsYXNAdmly ZW9uZS5jb20+Og0KPg0KPg0KPg0KPiBPbiAxMiBqdWwgMjAxNCwgYXQgMTY6NTcsICJLYXJsaSBT asO2YmVyZyIgPEthcmxpLlNqb2JlcmdAc2x1LnNlPiB3cm90ZToNCj4NCj4+DQo+PiBEZW4gMTIg anVsIDIwMTQgMTU6NDUgc2tyZXYgTmlrbGFzIEZvbmRiZXJnIDxuaWtsYXNAdmlyZW9uZS5jb20+ Og0KPj4gPg0KPj4gPiBIaSwNCj4+ID4NCj4+ID4gSeKAmW0gbmV3IHRvIG9WaXJ0IGJ1dCBJIG11 c3Qgc2F5IEkgYW0gaW1wcmVzc2VkIQ0KPj4gPiBJIGFtIHJ1bm5pbmcgaXQgb24gYSBIUCBETDM4 MCB3aXRoIGFuIGV4dGVybmFsIFNBUyBjaGFzc2kuDQo+PiA+IExpbnV4IGRpc3QgaXMgQ2VudG9z IDYuNSBhbmQgb1ZpcnQgaXMgMy40IHJ1bm5pbmcgYWxsLWluLW9uZSAoZm9yIG5vdyB1bnRpbCB3 ZSBuZWVkIHRvIGhhdmUgYSBzZWNvbmQgaG9zdCkuDQo+PiA+DQo+PiA+IE91ciBjb21wYW55ICh3 d3cudmlyZW9uZS5jb20pIGRlYWxzIHdpdGggc3lzdGVtIGFyY2hpdGVjdHVyZSBmb3IgbWFueSB0 ZWxjbyBhbmQgbWVkaWEgb3BlcmF0b3JzIGFuZCBpcyBub3cgc2V0dGluZyB1cCBhIHNtYWxsIG93 biBkYXRhY2VudGVyIGZvciBvdXIgaW50ZXJuYWwgdGVzdHMgYXMgd2VsbCBhcyBvdXIgSVQgaW5m cmFzdHJ1Y3R1cmUuDQo+PiA+IFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBpbnN0YWxsaW5nIFpl bnR5YWwgZm9yIHRoZSBTTUIgcHVycG9zZXMgb24gYSBndWVzdCBhbmQgaXQgd291bGQgYmUgZ3Jl YXQgdG8gaGF2ZSB0aGF0IGd1ZXN0IGFsc28gc2VydmluZyBhIGZzIHBhdGggZGlyZWN0b3J5IHdp dGggTkZTICsgU01CICh3aGljaCBpcyBzZW1pIGNyaXBwbGVkIG9uIHRoZSBob3N0IGFmdGVyIG9W aXJ0IGluc3RhbGxhdGlvbiB3aXRoIHZlcnNpb24gMyBldC5jLikuDQo+PiA+DQo+PiA+IERvZXMg YW55b25lIGhhdmUgYW4gaWRlYSBvZiBob3cgSSBjYW4gdGhyb3VnaCBvVmlydCAoc2VlbiBzZXZl cmFsIHNvbHV0aW9ucyB1c2luZyB2aXJzaCBhbmQga3ZtKSBsZXR0aW5nIG15IFplbnR5YWwgVWJ1 bnR1IGd1ZXN0IGhhdmUgYWNjZXNzIHRvIGEgaG9zdCBtb3VudCBwb2ludCBvciBpZiBuZWNlc3Nh cnkgKHNlY29uZCBiZXN0KSBhIHNlcGVyYXRlIHBhcnRpdGlvbj8NCj4+ID4NCj4+ID4gQmVzdCBy ZWdhcmRzDQo+PiA+IE5pa2xhcw0KPj4gPg0KPj4NCj4+IFdoeSBub3QganVzdCBnaXZlIHRoZSBn dWVzdCBhIHRoaW4gcHJvdmlzaW9uIHZpcnR1YWwgaGFyZCBkcml2ZSBhbmQgZXhwYW5kIGl0IG9u IGEgZGVtYW5kIGJhc2lzPw0KPj4NCj4+IC9LDQo+DQo+IFRoYW5rcyBmb3IgdGhlIGFkdmlzZSBi dXQgdGhpcyB3b3VsZCBub3Qgc3VpdGUgdXMgSSdtIGFmcmFpZC4gSXQgd291bGQgYmUgZGlmZmlj dWx0IHdydCBpbmNyZW1lbnRhbCBiYWNrdXBzIGFzIHdlbGwgYXMgaG9zdCBtYWNoaW5lIGZpbGUt cm91dGluZXMuDQo+DQo+DQoNCldlbGwsIGdvaW5nIGJ5IE9jY2FtJ3MgcmFpem9yOyB0aGUgc2lt cGxlc3QgYW5zd2VyIGlzIHVzdWFsbHkgY29ycmVjdC4gQ2FuJ3QgcmVhbGx5IHRlbGwgd2hhdCB5 b3UgbWVhbiBieSBmaWxlLXJvdXRpbmVzIGJ1dCBiYWNrdXBzIHdvdWxkIGJlIHdlbGwgc2VydmVk IGJ5IHNuYXBzaG90cyAoY2FuJ3QgZ2V0IG1vcmUgaW5jcmVtZW50YWwgdGhhbiB0aGF0KSBhbmQg ZGlzYXN0ZXIgcmVjb3ZlcnkgY291bGQgYmUgYXMgZWFzeSBhcyBhIHJzeW5jIGZyb20gaW5zaWRl IHRoZSBndWVzdCB0byBhIHJlbW90ZSBtYWNoaW5lLg0KDQpUaGUgYmlnZ2VzdCBwcm9zIGhlcmUg aXMgdGhlIGVhc2Ugb2YgYmVpbmcgYWJsZSB0byBzZXR1cCBhbiBleHBvcnQgZG9tYWluLCBhdHRh Y2gsIGV4cG9ydCB0aGUgVk0sIGRldGFjaCBkb21haW4sIGFuZCB0aGVuIGF0dGFjaCBhbmQgaW1w b3J0IHRvIGEgInJlYWwiIHNldHVwIHdoZW4gdGhlIEFJTyBzdGFydHMgZmVlbGluZyBjcm93ZGVk IGxhdGVyIG9uLiBUaGlua2luZyBhaGVhZCBpcyBuZXZlciBhIGJhZCB0aGluZywgbm8/DQoNCi9L DQo= --_000_5F9E965F5A80BC468BE5F40576769F098C555F4Cexchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <859545D6595E94408D29C283B48B6E99(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxMiBqdWwgMjAxNCAyMjo0OSBza3JldiBOaWtsYXMgRm9uZGJlcmcgJmx0O25p a2xhc0B2aXJlb25lLmNvbSZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBPbiAxMiBqdWwgMjAxNCwgYXQgMTY6NTcsICZxdW90O0thcmxpIFNqw7ZiZXJnJnF1b3Q7 ICZsdDtLYXJsaS5Tam9iZXJnQHNsdS5zZSZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgRGVuIDEyIGp1bCAyMDE0IDE1OjQ1IHNrcmV2IE5pa2xhcyBGb25k YmVyZyAmbHQ7bmlrbGFzQHZpcmVvbmUuY29tJmd0Ozo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0K Jmd0OyZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJ 4oCZbSBuZXcgdG8gb1ZpcnQgYnV0IEkgbXVzdCBzYXkgSSBhbSBpbXByZXNzZWQhJm5ic3A7PGJy Pg0KJmd0OyZndDsgJmd0OyBJIGFtIHJ1bm5pbmcgaXQgb24gYSBIUCBETDM4MCB3aXRoIGFuIGV4 dGVybmFsIFNBUyBjaGFzc2kuPGJyPg0KJmd0OyZndDsgJmd0OyBMaW51eCBkaXN0IGlzIENlbnRv cyA2LjUgYW5kIG9WaXJ0IGlzIDMuNCBydW5uaW5nIGFsbC1pbi1vbmUgKGZvciBub3cgdW50aWwg d2UgbmVlZCB0byBoYXZlIGEgc2Vjb25kIGhvc3QpLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IE91ciBjb21wYW55ICh3d3cudmlyZW9uZS5jb20pIGRlYWxzIHdpdGggc3lz dGVtIGFyY2hpdGVjdHVyZSBmb3IgbWFueSB0ZWxjbyBhbmQgbWVkaWEgb3BlcmF0b3JzIGFuZCBp cyBub3cgc2V0dGluZyB1cCBhIHNtYWxsIG93biBkYXRhY2VudGVyIGZvciBvdXIgaW50ZXJuYWwg dGVzdHMgYXMgd2VsbCBhcyBvdXIgSVQgaW5mcmFzdHJ1Y3R1cmUuPGJyPg0KJmd0OyZndDsgJmd0 OyBXZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgaW5zdGFsbGluZyBaZW50eWFsIGZvciB0aGUgU01C IHB1cnBvc2VzIG9uIGEgZ3Vlc3QgYW5kIGl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgdGhhdCBn dWVzdCBhbHNvIHNlcnZpbmcgYSBmcyBwYXRoIGRpcmVjdG9yeSB3aXRoIE5GUyAmIzQzOyBTTUIg KHdoaWNoIGlzIHNlbWkgY3JpcHBsZWQgb24gdGhlIGhvc3QgYWZ0ZXIgb1ZpcnQgaW5zdGFsbGF0 aW9uIHdpdGggdmVyc2lvbiAzIGV0LmMuKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZn dDsgJmd0OyBEb2VzIGFueW9uZSBoYXZlIGFuIGlkZWEgb2YgaG93IEkgY2FuIHRocm91Z2ggb1Zp cnQgKHNlZW4gc2V2ZXJhbCBzb2x1dGlvbnMgdXNpbmcgdmlyc2ggYW5kIGt2bSkgbGV0dGluZyBt eSBaZW50eWFsIFVidW50dSBndWVzdCBoYXZlIGFjY2VzcyB0byBhIGhvc3QgbW91bnQgcG9pbnQg b3IgaWYgbmVjZXNzYXJ5IChzZWNvbmQgYmVzdCkgYSBzZXBlcmF0ZSBwYXJ0aXRpb24/PGJyPg0K Jmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgQmVzdCByZWdhcmRzPGJyPg0KJmd0OyZn dDsgJmd0OyBOaWtsYXM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBXaHkgbm90IGp1c3QgZ2l2ZSB0aGUgZ3Vlc3QgYSB0aGluIHByb3Zpc2lvbiB2aXJ0dWFs IGhhcmQgZHJpdmUgYW5kIGV4cGFuZCBpdCBvbiBhIGRlbWFuZCBiYXNpcz88YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IC9LPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzIGZvciB0aGUgYWR2 aXNlIGJ1dCB0aGlzIHdvdWxkIG5vdCBzdWl0ZSB1cyBJJ20gYWZyYWlkLiBJdCB3b3VsZCBiZSBk aWZmaWN1bHQgd3J0IGluY3JlbWVudGFsIGJhY2t1cHMgYXMgd2VsbCBhcyBob3N0IG1hY2hpbmUg ZmlsZS1yb3V0aW5lcy4mbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OzwvcD4NCjxwIGRpcj0ibHRy Ij5XZWxsLCBnb2luZyBieSBPY2NhbSdzIHJhaXpvcjsgdGhlIHNpbXBsZXN0IGFuc3dlciBpcyB1 c3VhbGx5IGNvcnJlY3QuIENhbid0IHJlYWxseSB0ZWxsIHdoYXQgeW91IG1lYW4gYnkgZmlsZS1y b3V0aW5lcyBidXQgYmFja3VwcyB3b3VsZCBiZSB3ZWxsIHNlcnZlZCBieSBzbmFwc2hvdHMgKGNh bid0IGdldCBtb3JlIGluY3JlbWVudGFsIHRoYW4gdGhhdCkgYW5kIGRpc2FzdGVyIHJlY292ZXJ5 IGNvdWxkIGJlIGFzIGVhc3kNCiBhcyBhIHJzeW5jIGZyb20gaW5zaWRlIHRoZSBndWVzdCB0byBh IHJlbW90ZSBtYWNoaW5lLjwvcD4NCjxwIGRpcj0ibHRyIj5UaGUgYmlnZ2VzdCBwcm9zIGhlcmUg aXMgdGhlIGVhc2Ugb2YgYmVpbmcgYWJsZSB0byBzZXR1cCBhbiBleHBvcnQgZG9tYWluLCBhdHRh Y2gsIGV4cG9ydCB0aGUgVk0sIGRldGFjaCBkb21haW4sIGFuZCB0aGVuIGF0dGFjaCBhbmQgaW1w b3J0IHRvIGEgJnF1b3Q7cmVhbCZxdW90OyBzZXR1cCB3aGVuIHRoZSBBSU8gc3RhcnRzIGZlZWxp bmcgY3Jvd2RlZCBsYXRlciBvbi4gVGhpbmtpbmcgYWhlYWQgaXMgbmV2ZXIgYSBiYWQgdGhpbmcs IG5vPzwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F9E965F5A80BC468BE5F40576769F098C555F4Cexchange21_--

3 5

Can't create disks on gluster storage
by andreas.ewert＠cbc.de 17 Jul '14

17 Jul '14

Hi, Due creation of new disk in gluster-storage I got some errors. Finally the disk is not being created. engine.log says that there is no such file or directory, but the gluster domain (124e6273-c6f5-471f-88e7-e5d9d37d7385) is active: [root@ipet etc]# vdsClient -s 0 getStoragePoolInfo 5849b030-626e-47cb-ad90-3ce782d831b3 name = Test isoprefix = /rhev/data-center/mnt/mixcoatl:_srv_mirror_ISOs/c1582b82-9bfc-4e2b-ab2a-83551dcfba8f/images/11111111-1111-1111-1111-111111111111 pool_status = connected lver = 0 spm_id = 1 master_uuid = 54f86ad7-2c12-4322-b2d1-f129f3d20e57 version = 3 domains = 9bdf01bd-78d6-4408-b3a9-e05469004d78:Active,e4a3928d-0475-4b99-bfb8-86606931296a:Active,c1582b82-9bfc-4e2b-ab2a-83551dcfba8f:Active,124e6273-c6f5-471f-88e7-e5d9d37d7385:Active,54f86ad7-2c12-4322-b2d1-f129f3d20e57:Active type = FCP master_ver = 8 9bdf01bd-78d6-4408-b3a9-e05469004d78 = {'status': 'Active', 'diskfree': '1043408617472', 'isoprefix': '', 'alerts': [], 'disktotal': '1099108974592', 'version': 3} e4a3928d-0475-4b99-bfb8-86606931296a = {'status': 'Active', 'diskfree': '27244910346240', 'isoprefix': '', 'alerts': [], 'disktotal': '34573945667584', 'version': 3} 124e6273-c6f5-471f-88e7-e5d9d37d7385 = {'status': 'Active', 'diskfree': '12224677937152', 'isoprefix': '', 'alerts': [], 'disktotal': '16709735940096', 'version': 3} c1582b82-9bfc-4e2b-ab2a-83551dcfba8f = {'status': 'Active', 'diskfree': '115282018304', 'isoprefix': '/rhev/data-center/mnt/mixcoatl:_srv_mirror_ISOs/c1582b82-9bfc-4e2b-ab2a-83551dcfba8f/images/11111111-1111-1111-1111-111111111111', 'alerts': [], 'disktotal': '539016298496', 'version': 0} 54f86ad7-2c12-4322-b2d1-f129f3d20e57 = {'status': 'Active', 'diskfree': '148579024896', 'isoprefix': '', 'alerts': [], 'disktotal': '1197490569216', 'version': 3} [root@ipet etc]# ll /rhev/data-center/mnt/glusterSD/moly\:_repo1/ insgesamt 0 drwxr-xr-x 4 vdsm kvm 96 17. Apr 10:02 124e6273-c6f5-471f-88e7-e5d9d37d7385 -rwxr-xr-x 1 vdsm kvm 0 11. Feb 12:52 __DIRECT_IO_TEST__ [root@ipet etc]# ll /rhev/data-center/ insgesamt 12 drwxr-xr-x 2 vdsm kvm 4096 14. Jul 10:42 5849b030-626e-47cb-ad90-3ce782d831b3 drwxr-xr-x 2 vdsm kvm 4096 16. Dez 2013 hsm-tasks drwxr-xr-x 7 vdsm kvm 4096 14. Jul 10:24 mnt [root@ipet etc]# ll /rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/ insgesamt 16 lrwxrwxrwx 1 vdsm kvm 66 14. Jul 10:42 54f86ad7-2c12-4322-b2d1-f129f3d20e57 -> /rhev/data-center/mnt/blockSD/54f86ad7-2c12-4322-b2d1-f129f3d20e57 lrwxrwxrwx 1 vdsm kvm 66 14. Jul 10:42 9bdf01bd-78d6-4408-b3a9-e05469004d78 -> /rhev/data-center/mnt/blockSD/9bdf01bd-78d6-4408-b3a9-e05469004d78 lrwxrwxrwx 1 vdsm kvm 84 14. Jul 10:42 c1582b82-9bfc-4e2b-ab2a-83551dcfba8f -> /rhev/data-center/mnt/mixcoatl:_srv_mirror_ISOs/c1582b82-9bfc-4e2b-ab2a-83551dcfba8f lrwxrwxrwx 1 vdsm kvm 66 14. Jul 10:42 mastersd -> /rhev/data-center/mnt/blockSD/54f86ad7-2c12-4322-b2d1-f129f3d20e57 Here i miss the directory of the gluster domain 124e6273-c6f5-471f-88e7-e5d9d37d7385 and the symbolic link belonging to it. The directory is missed on every Host. What can I do to fix this issue? With best regards Andreas engine.log: 2014-07-17 05:30:33,347 INFO [org.ovirt.engine.core.bll.AddDiskCommand] (ajp--127.0.0.1-8702-7) [19404214] Running command: AddDiskCommand internal: false. Entities affected : ID: 124e6273-c6f5-471f-88e7-e5d9d37d7385 Type: Storage 2014-07-17 05:30:33,358 INFO [org.ovirt.engine.core.bll.AddImageFromScratchCommand] (ajp--127.0.0.1-8702-7) [3e7d9b07] Running command: AddImageFromScratchCommand internal: true. Entities affected : ID: 124e6273-c6f5-471f-88e7-e5d9d37d7385 Type: Storage 2014-07-17 05:30:33,364 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (ajp--127.0.0.1-8702-7) [3e7d9b07] START, CreateImageVDSCommand( storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, storageDomainId = 124e6273-c6f5-471f-88e7-e5d9d37d7385, imageGroupId = 7594000c-23a9-4941-8218-2c0654518a3d, imageSizeInBytes = 68719476736, volumeFormat = RAW, newImageId = c48e46cd-9dd5-4c52-94a4-db0378aecc3c, newImageDescription = ), log id: 642dadf4 2014-07-17 05:30:33,366 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (ajp--127.0.0.1-8702-7) [3e7d9b07] -- executeIrsBrokerCommand: calling 'createVolume' with two new parameters: description and UUID 2014-07-17 05:30:33,392 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.CreateImageVDSCommand] (ajp--127.0.0.1-8702-7) [3e7d9b07] FINISH, CreateImageVDSCommand, return: c48e46cd-9dd5-4c52-94a4-db0378aecc3c, log id: 642dadf4 2014-07-17 05:30:33,403 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (ajp--127.0.0.1-8702-7) [3e7d9b07] CommandAsyncTask::Adding CommandMultiAsyncTasks object for command 7429f506-e57d-45e7-bc66-42bbdc90174c 2014-07-17 05:30:33,404 INFO [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (ajp--127.0.0.1-8702-7) [3e7d9b07] CommandMultiAsyncTasks::AttachTask: Attaching task d957c5a9-518e-4668-b8cd-27a106952e7c to command 7429f506-e57d-45e7-bc66-42bbdc90174c. 2014-07-17 05:30:33,412 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (ajp--127.0.0.1-8702-7) [3e7d9b07] Adding task d957c5a9-518e-4668-b8cd-27a106952e7c (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters), polling hasn't started yet.. 2014-07-17 05:30:33,419 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-7) [3e7d9b07] Correlation ID: 19404214, Job ID: 18601b0b-5bbe-4fc3-91f8-8a8dff0974fc, Call Stack: null, Custom Event ID: -1, Message: Add-Disk operation of 're_Disk2' was initiated by EwertA. 2014-07-17 05:30:33,421 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (ajp--127.0.0.1-8702-7) [3e7d9b07] BaseAsyncTask::startPollingTask: Starting to poll task d957c5a9-518e-4668-b8cd-27a106952e7c. 2014-07-17 05:30:38,432 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (DefaultQuartzScheduler_Worker-70) Polling and updating Async Tasks: 1 tasks, 1 tasks to poll now 2014-07-17 05:30:38,445 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-70) Failed in HSMGetAllTasksStatusesVDS method 2014-07-17 05:30:38,450 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (DefaultQuartzScheduler_Worker-70) SPMAsyncTask::PollTask: Polling task d957c5a9-518e-4668-b8cd-27a106952e7c (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) returned status finished, result 'cleanSuccess'. 2014-07-17 05:30:38,467 ERROR [org.ovirt.engine.core.bll.SPMAsyncTask] (DefaultQuartzScheduler_Worker-70) BaseAsyncTask::LogEndTaskFailure: Task d957c5a9-518e-4668-b8cd-27a106952e7c (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) ended with failure: -- Result: cleanSuccess -- Message: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = [Errno 2] No such file or directory: '/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/124e6273-c6f5-471f-88e7-e5d9d37d7385/images/7594000c-23a9-4941-8218-2c0654518a3d', code = 100, -- Exception: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = [Errno 2] No such file or directory: '/rhev/data-center/5849b030-626e-47cb-ad90-3ce782d831b3/124e6273-c6f5-471f-88e7-e5d9d37d7385/images/7594000c-23a9-4941-8218-2c0654518a3d', code = 100 2014-07-17 05:30:38,485 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (DefaultQuartzScheduler_Worker-70) CommandAsyncTask::EndActionIfNecessary: All tasks of command 7429f506-e57d-45e7-bc66-42bbdc90174c has ended -> executing endAction 2014-07-17 05:30:38,487 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (DefaultQuartzScheduler_Worker-70) CommandAsyncTask::endAction: Ending action for 1 tasks (command ID: 7429f506-e57d-45e7-bc66-42bbdc90174c): calling endAction . 2014-07-17 05:30:38,489 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (org.ovirt.thread.pool-6-thread-42) CommandAsyncTask::EndCommandAction [within thread] context: Attempting to endAction AddDisk, executionIndex: 0 2014-07-17 05:30:38,517 ERROR [org.ovirt.engine.core.bll.AddDiskCommand] (org.ovirt.thread.pool-6-thread-42) [19404214] Ending command with failure: org.ovirt.engine.core.bll.AddDiskCommand 2014-07-17 05:30:38,519 ERROR [org.ovirt.engine.core.bll.AddImageFromScratchCommand] (org.ovirt.thread.pool-6-thread-42) [3e7d9b07] Ending command with failure: org.ovirt.engine.core.bll.AddImageFromScratchCommand 2014-07-17 05:30:38,616 WARN [org.ovirt.engine.core.bll.AddDiskCommand] (org.ovirt.thread.pool-6-thread-42) VmCommand::EndVmCommand: Vm is null - not performing endAction on Vm 2014-07-17 05:30:38,638 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-42) Correlation ID: 19404214, Job ID: 18601b0b-5bbe-4fc3-91f8-8a8dff0974fc, Call Stack: null, Custom Event ID: -1, Message: Operation Add-Disk failed to complete. 2014-07-17 05:30:38,645 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (org.ovirt.thread.pool-6-thread-42) CommandAsyncTask::HandleEndActionResult [within thread]: endAction for action type AddDisk completed, handling the result. 2014-07-17 05:30:38,652 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (org.ovirt.thread.pool-6-thread-42) CommandAsyncTask::HandleEndActionResult [within thread]: endAction for action type AddDisk succeeded, clearing tasks. 2014-07-17 05:30:38,663 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (org.ovirt.thread.pool-6-thread-42) SPMAsyncTask::ClearAsyncTask: Attempting to clear task d957c5a9-518e-4668-b8cd-27a106952e7c 2014-07-17 05:30:38,669 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (org.ovirt.thread.pool-6-thread-42) START, SPMClearTaskVDSCommand( storagePoolId = 5849b030-626e-47cb-ad90-3ce782d831b3, ignoreFailoverLimit = false, taskId = d957c5a9-518e-4668-b8cd-27a106952e7c), log id: f40f5de 2014-07-17 05:30:38,711 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (org.ovirt.thread.pool-6-thread-42) START, HSMClearTaskVDSCommand(HostName = ipet, HostId = ec83e4e0-40cf-49e4-94e3-5efc5ef6f2e2, taskId=d957c5a9-518e-4668-b8cd-27a106952e7c), log id: 71cdc9a4 2014-07-17 05:30:38,728 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (org.ovirt.thread.pool-6-thread-42) FINISH, HSMClearTaskVDSCommand, log id: 71cdc9a4 2014-07-17 05:30:38,733 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (org.ovirt.thread.pool-6-thread-42) FINISH, SPMClearTaskVDSCommand, log id: f40f5de 2014-07-17 05:30:38,741 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (org.ovirt.thread.pool-6-thread-42) BaseAsyncTask::RemoveTaskFromDB: Removed task d957c5a9-518e-4668-b8cd-27a106952e7c from DataBase 2014-07-17 05:30:38,747 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (org.ovirt.thread.pool-6-thread-42) CommandAsyncTask::HandleEndActionResult [within thread]: Removing CommandMultiAsyncTasks object for entity 7429f506-e57d-45e7-bc66-42bbdc90174c

1 0

oVirt Weekly Sync Meeting: July 16, 2014
by Brian Proffitt 17 Jul '14

17 Jul '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-16-14.05.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-16-14.05.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-16-14.05.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 14:05:27 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-07-16-14.05.log.html . Meeting summary --------------- * Agenda and Roll Call (bkp, 14:05:44) * infra update (bkp, 14:06:34) * 3.4.z updates (bkp, 14:06:34) * 3.5 status (bkp, 14:06:34) * conferences and workshops (bkp, 14:06:34) * other topics (bkp, 14:06:34) * infra update (bkp, 14:07:26) * infra phx lab still on the works (installed hosted engine though, but now they are setting up cables for the network) (bkp, 14:09:27) * infra Most of the 3.5 jobs have been added to jenkins, missing still a few (bkp, 14:09:27) * 3.4.z updates (bkp, 14:10:06) * 3.4.z updates Detailed status report at http://lists.ovirt.org/pipermail/users/2014-July/026028.html (bkp, 14:10:37) * 3.4.z updates No active blockers for 3.4.3 GA, 3 bugs (excluding node and documentation) still outstanding (bkp, 14:10:37) * 3.4.z updates 3.4.3 will start composing on 07-17-14 0800 UTC from 3.4.3 branch (bkp, 14:10:37) * 3.4.z updates Building engine in ~30 minutes so it will be ready for tomorrow morning composition and testing (bkp, 14:14:05) * 3.5 status (bkp, 14:14:41) * 3.5 status integration Detailed status at http://lists.ovirt.org/pipermail/users/2014-July/026029.html (bkp, 14:16:05) * 3.5 status integration 3.5.0 Second Beta will be composed on 07-21-14 0800 UTC; Be sure 3.5 snapshots are enabled to create VMs by 07-20-14 1500 UTC (bkp, 14:16:05) * 3.5 status integration Feature freeze in place, 3.5.0 branch has been created; All new patches must be backported to 3.5 branch too. (bkp, 14:16:05) * 3.5 status integration Six blockers are currently listed (2 infra, 1 integration, 2 network, and 1 virt) for 3.5.0 (bkp, 14:16:05) * 3.5 status integration Blocker Bug 1113974: Trying to reproduce issue, no ETA at this time. (bkp, 14:18:11) * 3.5 status network Blocker Bug 1115001 status: pending review (POST) (bkp, 14:25:30) * 3.5 status network Blocker Bug 1119019 status: pending review. Both blockers should be merged in next week's beta. (bkp, 14:26:48) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1119024 (danken, 14:27:35) * 3.5 status network Not an ovirt blocker yet, but bug 1119024 is a persistent vdsm regression affecting network. Patch made. (bkp, 14:29:08) * 3.5 status virt Blocker Bug 1110305 status: Almost in. ETA today. (bkp, 14:32:03) * 3.5 status infra Blocker Bug 1115044 status: In POST status unknown. (bkp, 14:36:40) * 3.5 status infra Blocker Bug 1115152 status: In POST status unknown. (bkp, 14:36:41) * 3.5 status infra No report this week. (bkp, 14:36:41) * LINK: http://gerrit.ovirt.org/#/c/28817/ is not yet ready (danken, 14:37:11) * 3.5 status infra http://gerrit.ovirt.org/#/c/28817/ is not yet ready, lastClientIface is not reported over jsonrpc. Should be set as a blocker (bkp, 14:38:08) * 3.5 status infra http://gerrit.ovirt.org/#/c/28817/ patch in progress, awaiting agreement on minor aspect. (bkp, 14:40:12) * 3.5 status storage Live Merge feature (http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:li…) not ready, still blocking for 3.5. No change in status, no ETA to report. (bkp, 14:46:18) * 3.5 status node Node is basically stabilizing. (bkp, 14:49:14) * 3.5 status node In testing mode, working out some build/automation problems. (Not 3.5-related) (bkp, 14:49:14) * 3.5 status sla Everything sla had for vdsm is in master now (bkp, 15:09:41) * 3.5 status sla iotune now needs to be merged to 3.5. Verified and unittests written. There are still strong concerns from danken. msivak to try to address and get this in the green. (bkp, 15:09:42) * 3.5 status sla optimizer now knows how to compute a solution for starting a vm, lacking ui, but that will take no time when vdsm is sorted out (bkp, 15:12:29) * 3.5 status sla hosted engine in good shape and with more stable state machine as far as starting the engine vm is concerned (bkp, 15:12:29) * 3.5 status vdsm dougsland to build vdsm 4.14.11 (bkp, 15:13:06) * 3.4.z updates vdsm dougsland to build vdsm 4.14.11 (bkp, 15:14:47) * 3.5 status vdsm Strong concerns about iotunes in SLA raised. (bkp, 15:17:26) * 3.5 status vdsm Also concerns about lastclientIface (bkp, 15:17:55) * ACTION: 3.5 status Appropriate owners, please address danken's concerns about sla, lastclientIface (bkp, 15:19:09) * 3.5 status ux Sorting is in 3.5 for all main tabs, except Volumes (gluster) that is only in 'master' ATM. Sorting is in 3.5 for most sub-tabs as well, except the ones in 'virt' main-tabs and Volumes. (bkp, 15:20:58) * 3.5 status ux full status is in: https://docs.google.com/spreadsheets/d/1S3qDYqv9OK5ruI41RpFpRAsLaojpGL-W6WY… (bkp, 15:20:58) * 3.5 status ux Italian translation in progress (currently in ~30% completion). (bkp, 15:20:58) * 3.5 status ux No blockers (bkp, 15:20:58) * Conferences and Workshops (bkp, 15:21:28) * Conferences and Workshops oVirt Workshop around KVM Forum is a go. Funding has been acquired for the one-day event around KVM Forum. Date/deadlines to follow. (bkp, 15:21:36) * Conferences and Workshops OSCON is next week, looking forward to seeing oVirt community members' presentations and at the Red Hat booth. (bkp, 15:21:37) * Conferences and Workshops No new information on "Red Hat Day" at Fossetcon in September. Will update. (bkp, 15:21:37) * Other Topics (bkp, 15:21:49) * Other Topics Documentation is ready for review/updating. See http://lists.ovirt.org/pipermail/users/2014-July/025900.html for details on how you can help! (bkp, 15:22:13) Meeting ended at 15:23:29 UTC. Action Items ------------ * 3.5 status Appropriate owners, please address danken's concerns about sla, lastclientIface Action Items, by person ----------------------- * danken * 3.5 status Appropriate owners, please address danken's concerns about sla, lastclientIface * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * bkp (128) * danken (53) * msivak (23) * urthmover (22) * sbonazzo (17) * lvernia (15) * tal (8) * awels (7) * SvenKieske (6) * fabiand (5) * dcaro (3) * dougsland (3) * mskrivanek (3) * itamar (3) * ovirtbot (3) * alonbl_ (3) * nsoffer (2) * pkliczew (1) * peetaur2 (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

2 1

3.5 thinks HA is already running
by Nathan Stratton 17 Jul '14

17 Jul '14

Trying to add new hosts to my pool, things work fine with 3.4, but 3.5 thinks that HA is already running (but it is not). 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel rhel.status:138 check service ovirt-ha-agent status 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:785 execute: ('/sbin/initctl', 'status', 'ovirt-ha-agent'), executabl e='None', cwd='None', env=None 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:803 execute-result: ('/sbin/initctl', 'status', 'ovirt-ha-agent'), rc =1 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:861 execute-output: ('/sbin/initctl', 'status', 'ovirt-ha-agent') stdout : 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:866 execute-output: ('/sbin/initctl', 'status', 'ovirt-ha-agent') stderr : initctl: Unknown job: ovirt-ha-agent 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:785 execute: ('/sbin/service', 'ovirt-ha-agent', 'status'), executabl e='None', cwd='None', env=None 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.executeRaw:803 execute-result: ('/sbin/service', 'ovirt-ha-agent', 'status'), rc =0 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:861 execute-output: ('/sbin/service', 'ovirt-ha-agent', 'status') stdout : ovirt-ha-agent is stopped 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel plugin.execute:866 execute-output: ('/sbin/service', 'ovirt-ha-agent', 'status') stderr : 2014-07-14 15:07:47 DEBUG otopi.plugins.otopi.services.rhel rhel.status:147 service ovirt-ha-agent status True 2014-07-14 15:07:47 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/ovirt-hosted-engine-setup/ha/ha_services.py", line 64, in _programs 'Hosted Engine HA services are already running on ' RuntimeError: Hosted Engine HA services are already running on this system. Hosted Engine cannot be deployed on a host already running those servic es. 2014-07-14 15:07:47 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Programs detection': Hosted Engine HA services are alre ady running on this system. Hosted Engine cannot be deployed on a host already running those services. 2014-07-14 15:07:47 DEBUG otopi.context context.dumpEnvironment:468 ENVIRONMENT DUMP - BEGIN ><> nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

2 1

python-pthreading for epel6.5
by lucas castro 17 Jul '14

17 Jul '14

It is already available the python-pthreading 0.1.3-3 for epel. And solving the problem with network installing new host. -- contatos: Celular: ( 99 ) 9143-5954 - Vivo skype: lucasd3castro msn: lucascastroborges(a)hotmail.com

1 0

change ovirt-engine's IP
by 力波王 16 Jul '14

16 Jul '14

> ŽËÓÊŒþÊ¹ÓÃ MIME žñÊœ¡£ÓÉÓÚÓÊŒþÔÄ¶Á³ÌÐò²»ÄÜÊ¶±ð ŽËžñÊœ£¬ÒòŽË£¬¿ÉÄÜÎÞ·šÊ¶±ðžÃÓÊŒþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3488370579_1249236 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Hi,all: How could I change overt-engine=A1=AFs IP and host=A1=AFs IP --B_3488370579_1249236 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s= pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:= 14px; font-family: =CB=CE=CC=E5, sans-serif;"><div>Hi,all:</div><div><br></div><div= ><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>How could I ch= ange overt-engine’s IP and host’s IP</div></body></html> --B_3488370579_1249236--

2 1

Removal of snapshot taking too long
by André Freitas 16 Jul '14

16 Jul '14

Hi, i don't know if its normal but i'm having situations where i have to wait almost 45 minutes to delete a live snapshot from a offline vm (my datastores are all NFS). Is there any way i can speed this? The problem is that i can't start the correspondent vm until the snapshot is deleted... Best regards, -- André Freitas André Freitas System & Network Administrator | (+351) 234 484 466 ISO 9001 CMMI Level 2 Ubiwhere Copyright © Ubiwhere. 2014. All rights reserved. Content for exclusive use of their rightful recipients. Dissemination, copy or use of information by third parties is prohibited. If you are not an authorised recipient and received this message, please notify the sender and then delete it without copying the text and attachments nor distributing or disclosing its contents.

3 2

VMs fail to start in Cluster
by Aslam, Usman 16 Jul '14

16 Jul '14

--_000_EAAAA4A70A749B408A0B58DBB9054353943949SSVMEXDAG01MB02tu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Guys, We have two Ovirt clusters setup in one datacenter. Dev and Prod. I have a situation where if I power off a VM in the Prod environment, it do= es not start up again. I get the following when trying to run it ... "Failed to run VM tuskweb-prod-02 (User: admin@internal)." "Error while executing action Run VM once: Network error during communicati= on with the Host." Odly enough, if I move the down VM to the Dev cluster and run it again, it = starts up fine. I've had this problem with 2 VMs this far (on different nodes in the cluste= r). Im afraid to bring any more VMs down as they may not start back up. Any help is appreciated. Thanks, Usman --_000_EAAAA4A70A749B408A0B58DBB9054353943949SSVMEXDAG01MB02tu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi Guys,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">We have two Ovirt clusters setup in one datacenter. = Dev and Prod.<o:p></o:p></p> <p class=3D"MsoNormal">I have a situation where if I power off a VM in the = Prod environment, it does not start up again.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I get the following when trying to run it …<o:= p></o:p></p> <p class=3D"MsoNormal">“Failed to run VM tuskweb-prod-02 (User: admin= @internal).”<o:p></o:p></p> <p class=3D"MsoNormal">“Error while executing action Run VM once: Net= work error during communication with the Host.”<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Odly enough, if I move the down VM to the Dev cluste= r and run it again, it starts up fine.<o:p></o:p></p> <p class=3D"MsoNormal">I’ve had this problem with 2 VMs this far (on = different nodes in the cluster). Im afraid to bring any more VMs down as th= ey may not start back up.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Any help is appreciated.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Thanks,<o:p></o:p></p> <p class=3D"MsoNormal">Usman<o:p></o:p></p> </div> </body> </html> --_000_EAAAA4A70A749B408A0B58DBB9054353943949SSVMEXDAG01MB02tu_--

2 2

USB Device selection
by Maurice James 16 Jul '14

16 Jul '14

------=_Part_11700_310264054.1405356888343 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Has anyone gotten the USB Device selection on the spice-viewer window to work? ------=_Part_11700_310264054.1405356888343 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Has anyone gotten the USB Device selection on the spice-viewer window to work?<br></div></div></body></html> ------=_Part_11700_310264054.1405356888343--

2 3

Guest VM Console Creation/Access using REST API and noVNC
by Shanil S 16 Jul '14

16 Jul '14

Hi All, We want to access vm console by using noVNC and Rest api. We are using websocket proxy on the same machine where engine runs and we try to get the console access from the another server that is outside from this cluster. But when we try to connect the vnc_auto.html from the server using host ip, port and the password which we get from the ticket creation… it shows a Failed to connect to server (code: 1006). The following are the codes which we use to create the ticket… host,port and the password will get from the ticket and with the same details (host,port & password) we are able to connect the console using the vnc clients(TigerVNC etc.) try { var host = WebUtil.getQueryVar('host', '<?php echo $host?>'); var port = WebUtil.getQueryVar('port', '<?php echo $port?>'); var path = WebUtil.getQueryVar('path', 'websockify'); var password = '<?php echo $password?>'; if ((!host) || (!port)) { updateState('failed', "Must specify host and port in URL"); return; } rfb = new RFB({'target': $D('noVNC_canvas'), 'encrypt': WebUtil.getQueryVar('encrypt', (window.location.protocol === "https:")), 'true_color': WebUtil.getQueryVar('true_color', true), 'local_cursor': WebUtil.getQueryVar('cursor', true), 'shared': WebUtil.getQueryVar('shared', true), 'view_only': WebUtil.getQueryVar('view_only', false), 'updateState': updateState, 'onPasswordRequired': passwordRequired}); rfb.connect(host, port, password, path); }catch(e) {alert(e); Could you please check if there any issues with it and guide me how to get rid of this failed to connect error? I have attached the screen shots for further reference… -- Regards Shanil

3 4

[QE][ACTION NEEDED] oVirt 3.5.0 Second Beta status
by Sandro Bonazzola 16 Jul '14

16 Jul '14

Hi, We're going to compose oVirt 3.5.0 Second Beta on Mon *2014-07-21 08:00 UTC*. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs before *2014-07-20 15:00 UTC* The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1115044 infra POST Host stuck in "Unassinged" state when using jsonrpc and disconnection from pool failed 1115152 infra POST Cannot edit or create block storage doamin when using jsonrpc 1113974 integration POST Hostname validation during all-in-one setup 1115001 network ASSIGNED Error code 23 when invoking Setup Networks 1119019 network POST Remove network with network custom properties from Host fails 1110305 virt POST BSOD - CLOCK_WATCHDOG_TIMEOUT_2 - Win 7SP1 guest, need to set hv_relaxed Feature freeze is now effective, and branch has been created. All new patches must be backported to 3.5 branch too. Features completed are marked in green on Features Status Table [2] There are still 412 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 364 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please check ensure that completed features are marked in green on Features Status Table [2] - Please remember to rebuild your packages before *2014-07-20 15:00* if needed, otherwise nightly snapshot will be taken. - Please be sure that 3.5 snapshot allow to create VMs before *2014-07-20 15:00 UTC* - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] - Please review and add test cases to oVirt 3.5 Second Test Day [6] Community: - save the date for second test day scheduled on 2014-07-24! - You're welcome to join us testing next beta release and getting involved in oVirt Quality Assurance[7]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_3.5_TestDay [7] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[QE][ACTION NEEDED] oVirt 3.4.3 GA status
by Sandro Bonazzola 16 Jul '14

16 Jul '14

Hi, We're going to start composing oVirt 3.4.3 GA tomorrow *2014-07-17 08:00 UTC* from 3.4.3 branch. The bug tracker [1] shows no open blocking bugs for the release There are still 10 bugs [2] targeted to 3.4.3. Excluding node and documentation bugs we still have 3 bugs [3] targeted to 3.4.3. Bug ID Status Whiteboard Severity Summary 1111655 NEW storage urgent Disks imported from Export Domain to Data Domain are converted to Preallocated after upgrade... 1059309 NEW sla high [events] 'Available memory of host $host (...) under defined threshold...' is logged only once 1048880 NEW network unspecified [vdsm][openstacknet] Migration fails for vNIC using OVS + security groups Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.3 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.3: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - Please build packages before today *2014-07-16 15:00 UTC*. Community: - If you're testing oVirt 3.4 nightly snapshot, please add yourself to the test page [5] [1] bugzilla.redhat.com/1107968 [2] http://red.ht/1lBAw2R [3] http://red.ht/1ly9hfA [4] http://www.ovirt.org/OVirt_3.4.3_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.3_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-users] Storage Domain used space strangeness
by urthmover 16 Jul '14

16 Jul '14

[root@jmini08 ~]# du -hs /data 3.3M /data -- urthmover On July 15, 2014 at 3:28:43 PM, Colby Westerburg (cwesterburg(a)gmail.com) wrote: [root@jmini08 ~]# zfs list -t snapshot no datasets available [root@jmini07 ~]# df -h Filesystem Size Used Avail Use% Mounted on 10.6.2.34:/data 914G 51G 864G 6% /rhev/data-center/mnt/10.6.2.34:_data [root@jmini08 ~]# ifconfig | grep "inet addr" inet addr:10.6.2.34 Bcast:10.6.15.255 Mask:255.255.240.0 -- Colby Westerburg cwesterburg(a)gmail.com On July 15, 2014 at 2:43:57 PM, Karli Sjöberg (karli.sjoberg(a)slu.se) wrote: Den 15 jul 2014 21:31 skrev urthmover <urthmover(a)gmail.com>: > > It might be a result of running the zfs filesystem on the disks that the storage domain is using. Any guidance is greatly appreciated. Snapshots? # zfs list -t snapshot What does the hosts that are mouting think? If you log into one of them and run: # df -h /K > > [root@jmini08 ~]# mount | grep data-pool > data-pool on /data type zfs (rw,xattr) > > [root@jmini08 ~]# df -h /data > Filesystem Size Used Avail Use% Mounted on > data-pool 914G 51G 864G 6% /data > > [root@jmini08 ~]# du -h /data > 17K /data/54ba461d-fbec-422e-9300-2f51640e5b2a/images > 2.1M /data/54ba461d-fbec-422e-9300-2f51640e5b2a/dom_md > 2.1M /data/54ba461d-fbec-422e-9300-2f51640e5b2a > 2.2M /data > > [root@jmini08 ~]# zpool status > pool: data-pool > state: ONLINE > scan: none requested > config: > > NAME STATE READ WRITE CKSUM > data-pool ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > sda ONLINE 0 0 0 > sdb ONLINE 0 0 0 > > errors: No known data errors > > -- > urthmover > > On July 15, 2014 at 12:29:12 PM, urthmover (urthmover(a)gmail.com) wrote: >> >> All, >> I have a storage domain that reports having 863G free. The Total Space is 913G. Currently, there are no virtual machines using this storage domain. When I ssh into the host there is 2.2M on the top level of that mount according to du. How do I account for and reclaim the mysterious space usage? >> >> -- >> urthmover

1 1

Re: [ovirt-users] Storage Domain used space strangeness
by Karli Sjöberg 16 Jul '14

16 Jul '14

--_000_5F9E965F5A80BC468BE5F40576769F098C558BF1exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTUganVsIDIwMTQgMjI6Mjggc2tyZXYgQ29sYnkgV2VzdGVyYnVyZyA8Y3dlc3RlcmJ1 cmdAZ21haWwuY29tPjoNCj4NCj4gW3Jvb3RAam1pbmkwOCB+XSMgemZzIGxpc3QgLXQgc25hcHNo b3QNCj4gbm8gZGF0YXNldHMgYXZhaWxhYmxlDQo+DQo+IFtyb290QGptaW5pMDcgfl0jIGRmIC1o DQo+IEZpbGVzeXN0ZW0gICAgICAgICAgICBTaXplICBVc2VkIEF2YWlsIFVzZSUgTW91bnRlZCBv bg0KPiAxMC42LjIuMzQ6L2RhdGEgICAgICAgOTE0RyAgIDUxRyAgODY0RyAgIDYlIC9yaGV2L2Rh dGEtY2VudGVyL21udC8xMC42LjIuMzQ6X2RhdGENCj4NCj4gW3Jvb3RAam1pbmkwOCB+XSMgaWZj b25maWcgfCBncmVwICJpbmV0IGFkZHIiDQo+ICAgICAgICAgICBpbmV0IGFkZHI6MTAuNi4yLjM0 ICBCY2FzdDoxMC42LjE1LjI1NSAgTWFzazoyNTUuMjU1LjI0MC4wDQo+DQo+IC0tDQo+IENvbGJ5 IFdlc3RlcmJ1cmcNCj4gY3dlc3RlcmJ1cmdAZ21haWwuY29tDQoNCk9LLCBzbyBldmVyeW9uZSBh dCBsZWFzdCBhZ3JlZXMgdGhhdCA1MEdCIHNlZW1zIHRvIGJlIHVzZWQuIEZyb20gdGhlIHN0b3Jh Z2UsIHJ1bjoNCiMgZHUgLWhzIC9kYXRhDQoNCi9LDQoNCj4NCj4gT24gSnVseSAxNSwgMjAxNCBh dCAyOjQzOjU3IFBNLCBLYXJsaSBTasO2YmVyZyAoa2FybGkuc2pvYmVyZ0BzbHUuc2UpIHdyb3Rl Og0KPj4NCj4+DQo+PiBEZW4gMTUganVsIDIwMTQgMjE6MzEgc2tyZXYgdXJ0aG1vdmVyIDx1cnRo bW92ZXJAZ21haWwuY29tPjoNCj4+ID4NCj4+ID4gSXQgbWlnaHQgYmUgYSByZXN1bHQgb2YgcnVu bmluZyB0aGUgemZzIGZpbGVzeXN0ZW0gb24gdGhlIGRpc2tzIHRoYXQgdGhlIHN0b3JhZ2UgZG9t YWluIGlzIHVzaW5nLiAgQW55IGd1aWRhbmNlIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQo+Pg0K Pj4gU25hcHNob3RzPw0KPj4gIyB6ZnMgbGlzdCAtdCBzbmFwc2hvdA0KPj4NCj4+IFdoYXQgZG9l cyB0aGUgaG9zdHMgdGhhdCBhcmUgbW91dGluZyB0aGluaz8gSWYgeW91IGxvZyBpbnRvIG9uZSBv ZiB0aGVtIGFuZCBydW46DQo+PiAjIGRmIC1oDQo+Pg0KPj4gL0sNCj4+DQo+PiA+DQo+PiA+IFty b290QGptaW5pMDggfl0jIG1vdW50IHwgZ3JlcCBkYXRhLXBvb2wNCj4+ID4gZGF0YS1wb29sIG9u IC9kYXRhIHR5cGUgemZzIChydyx4YXR0cikNCj4+ID4NCj4+ID4gW3Jvb3RAam1pbmkwOCB+XSMg ZGYgLWggL2RhdGENCj4+ID4gRmlsZXN5c3RlbSAgICAgIFNpemUgIFVzZWQgQXZhaWwgVXNlJSBN b3VudGVkIG9uDQo+PiA+IGRhdGEtcG9vbCAgICAgICA5MTRHICAgNTFHICA4NjRHICAgNiUgL2Rh dGENCj4+ID4NCj4+ID4gW3Jvb3RAam1pbmkwOCB+XSMgZHUgLWggL2RhdGENCj4+ID4gMTdLIC9k YXRhLzU0YmE0NjFkLWZiZWMtNDIyZS05MzAwLTJmNTE2NDBlNWIyYS9pbWFnZXMNCj4+ID4gMi4x TSAvZGF0YS81NGJhNDYxZC1mYmVjLTQyMmUtOTMwMC0yZjUxNjQwZTViMmEvZG9tX21kDQo+PiA+ IDIuMU0gL2RhdGEvNTRiYTQ2MWQtZmJlYy00MjJlLTkzMDAtMmY1MTY0MGU1YjJhDQo+PiA+IDIu Mk0gL2RhdGENCj4+ID4NCj4+ID4gW3Jvb3RAam1pbmkwOCB+XSMgenBvb2wgc3RhdHVzDQo+PiA+ ICAgcG9vbDogZGF0YS1wb29sDQo+PiA+ICBzdGF0ZTogT05MSU5FDQo+PiA+ICAgc2Nhbjogbm9u ZSByZXF1ZXN0ZWQNCj4+ID4gY29uZmlnOg0KPj4gPg0KPj4gPiBOQU1FICAgICAgICBTVEFURSAg ICAgUkVBRCBXUklURSBDS1NVTQ0KPj4gPiBkYXRhLXBvb2wgICBPTkxJTkUgICAgICAgMCAgICAg MCAgICAgMA0KPj4gPiAgbWlycm9yLTAgIE9OTElORSAgICAgICAwICAgICAwICAgICAwDQo+PiA+ ICAgIHNkYSAgICAgT05MSU5FICAgICAgIDAgICAgIDAgICAgIDANCj4+ID4gICAgc2RiICAgICBP TkxJTkUgICAgICAgMCAgICAgMCAgICAgMA0KPj4gPg0KPj4gPiBlcnJvcnM6IE5vIGtub3duIGRh dGEgZXJyb3JzDQo+PiA+DQo+PiA+IC0tDQo+PiA+IHVydGhtb3Zlcg0KPj4gPg0KPj4gPiBPbiBK dWx5IDE1LCAyMDE0IGF0IDEyOjI5OjEyIFBNLCB1cnRobW92ZXIgKHVydGhtb3ZlckBnbWFpbC5j b20pIHdyb3RlOg0KPj4gPj4NCj4+ID4+IEFsbCwNCj4+ID4+IEkgaGF2ZSBhIHN0b3JhZ2UgZG9t YWluIHRoYXQgcmVwb3J0cyBoYXZpbmcgODYzRyBmcmVlLiAgVGhlIFRvdGFsIFNwYWNlIGlzIDkx M0cuICBDdXJyZW50bHksIHRoZXJlIGFyZSBubyB2aXJ0dWFsIG1hY2hpbmVzIHVzaW5nIHRoaXMg c3RvcmFnZSBkb21haW4uICBXaGVuIEkgc3NoIGludG8gdGhlIGhvc3QgdGhlcmUgaXMgMi4yTSBv biB0aGUgdG9wIGxldmVsIG9mIHRoYXQgbW91bnQgYWNjb3JkaW5nIHRvIGR1LiAgSG93IGRvIEkg YWNjb3VudCBmb3IgYW5kIHJlY2xhaW0gdGhlIG15c3RlcmlvdXMgc3BhY2UgdXNhZ2U/DQo+PiA+ Pg0KPj4gPj4gLS0NCj4+ID4+IHVydGhtb3Zlcg0K --_000_5F9E965F5A80BC468BE5F40576769F098C558BF1exchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <5B5910D2BA8A4E419C86E5DE2E2A3654(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxNSBqdWwgMjAxNCAyMjoyOCBza3JldiBDb2xieSBXZXN0ZXJidXJnICZsdDtj d2VzdGVyYnVyZ0BnbWFpbC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IFtyb290QGptaW5p MDggfl0jIHpmcyBsaXN0IC10IHNuYXBzaG90PGJyPg0KJmd0OyBubyBkYXRhc2V0cyBhdmFpbGFi bGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBbcm9vdEBqbWluaTA3IH5dIyBkZiAtaDxicj4NCiZndDsg RmlsZXN5c3RlbSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NpemUg Jm5ic3A7VXNlZCBBdmFpbCBVc2UlIE1vdW50ZWQgb248YnI+DQomZ3Q7IDEwLjYuMi4zNDovZGF0 YSAmbmJzcDsgJm5ic3A7ICZuYnNwOyA5MTRHICZuYnNwOyA1MUcgJm5ic3A7ODY0RyAmbmJzcDsg NiUgL3JoZXYvZGF0YS1jZW50ZXIvbW50LzEwLjYuMi4zNDpfZGF0YTxicj4NCiZndDs8YnI+DQom Z3Q7IFtyb290QGptaW5pMDggfl0jIGlmY29uZmlnIHwgZ3JlcCAmcXVvdDtpbmV0IGFkZHImcXVv dDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW5ldCBhZGRy OjEwLjYuMi4zNCAmbmJzcDtCY2FzdDoxMC42LjE1LjI1NSAmbmJzcDtNYXNrOjI1NS4yNTUuMjQw LjA8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSZuYnNwOzxicj4NCiZndDsgQ29sYnkgV2VzdGVyYnVy Zzxicj4NCiZndDsgY3dlc3RlcmJ1cmdAZ21haWwuY29tPC9wPg0KPHAgZGlyPSJsdHIiPk9LLCBz byBldmVyeW9uZSBhdCBsZWFzdCBhZ3JlZXMgdGhhdCA1MEdCIHNlZW1zIHRvIGJlIHVzZWQuIEZy b20gdGhlIHN0b3JhZ2UsIHJ1bjo8YnI+DQojIGR1IC1ocyAvZGF0YTwvcD4NCjxwIGRpcj0ibHRy Ij4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyBPbiBKdWx5IDE1LCAyMDE0IGF0 IDI6NDM6NTcgUE0sIEthcmxpIFNqw7ZiZXJnIChrYXJsaS5zam9iZXJnQHNsdS5zZSkgd3JvdGU6 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IERlbiAxNSBqdWwgMjAx NCAyMTozMSBza3JldiB1cnRobW92ZXIgJmx0O3VydGhtb3ZlckBnbWFpbC5jb20mZ3Q7Ojxicj4N CiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEl0IG1pZ2h0IGJlIGEgcmVzdWx0IG9m IHJ1bm5pbmcgdGhlIHpmcyBmaWxlc3lzdGVtIG9uIHRoZSBkaXNrcyB0aGF0IHRoZSBzdG9yYWdl IGRvbWFpbiBpcyB1c2luZy4gJm5ic3A7QW55IGd1aWRhbmNlIGlzIGdyZWF0bHkgYXBwcmVjaWF0 ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBTbmFwc2hvdHM/PGJyPg0KJmd0OyZndDsg IyB6ZnMgbGlzdCAtdCBzbmFwc2hvdDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hhdCBk b2VzIHRoZSBob3N0cyB0aGF0IGFyZSBtb3V0aW5nIHRoaW5rPyBJZiB5b3UgbG9nIGludG8gb25l IG9mIHRoZW0gYW5kIHJ1bjo8YnI+DQomZ3Q7Jmd0OyAjIGRmIC1oPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsgW3Jvb3RAam1pbmkwOCB+XSMgbW91bnQgfCBncmVwIGRhdGEtcG9vbDxicj4NCiZn dDsmZ3Q7ICZndDsgZGF0YS1wb29sIG9uIC9kYXRhIHR5cGUgemZzIChydyx4YXR0cik8YnI+DQom Z3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBbcm9vdEBqbWluaTA4IH5dIyBkZiAtaCAv ZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsgRmlsZXN5c3RlbSAmbmJzcDsgJm5ic3A7ICZuYnNwO1Np emUgJm5ic3A7VXNlZCBBdmFpbCBVc2UlIE1vdW50ZWQgb248YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGRh dGEtcG9vbCAmbmJzcDsgJm5ic3A7ICZuYnNwOyA5MTRHICZuYnNwOyA1MUcgJm5ic3A7ODY0RyAm bmJzcDsgNiUgL2RhdGE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBbcm9v dEBqbWluaTA4IH5dIyBkdSAtaCAvZGF0YTxicj4NCiZndDsmZ3Q7ICZndDsgMTdLIC9kYXRhLzU0 YmE0NjFkLWZiZWMtNDIyZS05MzAwLTJmNTE2NDBlNWIyYS9pbWFnZXM8YnI+DQomZ3Q7Jmd0OyAm Z3Q7IDIuMU0gL2RhdGEvNTRiYTQ2MWQtZmJlYy00MjJlLTkzMDAtMmY1MTY0MGU1YjJhL2RvbV9t ZDxicj4NCiZndDsmZ3Q7ICZndDsgMi4xTSAvZGF0YS81NGJhNDYxZC1mYmVjLTQyMmUtOTMwMC0y ZjUxNjQwZTViMmE8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDIuMk0gL2RhdGE8YnI+DQomZ3Q7Jmd0OyAm Z3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBbcm9vdEBqbWluaTA4IH5dIyB6cG9vbCBzdGF0dXM8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyBwb29sOiBkYXRhLXBvb2w8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 ICZuYnNwO3N0YXRlOiBPTkxJTkU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyBzY2FuOiBub25l IHJlcXVlc3RlZDxicj4NCiZndDsmZ3Q7ICZndDsgY29uZmlnOjxicj4NCiZndDsmZ3Q7ICZndDs8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE5BTUUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U1RBVEUg Jm5ic3A7ICZuYnNwOyBSRUFEIFdSSVRFIENLU1VNPGJyPg0KJmd0OyZndDsgJmd0OyBkYXRhLXBv b2wgJm5ic3A7IE9OTElORSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAmbmJzcDsgMCAm bmJzcDsgJm5ic3A7IDA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZuYnNwO21pcnJvci0wICZuYnNwO09O TElORSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAmbmJzcDsgMCAmbmJzcDsgJm5ic3A7 IDA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtzZGEgJm5ic3A7ICZuYnNwOyBPTkxJ TkUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMCAmbmJzcDsgJm5ic3A7IDAgJm5ic3A7ICZuYnNwOyAw PGJyPg0KJmd0OyZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c2RiICZuYnNwOyAmbmJzcDsgT05MSU5F ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDAgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAmbmJzcDsgMDxi cj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGVycm9yczogTm8ga25vd24gZGF0 YSBlcnJvcnM8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyAtLSZuYnNwOzxi cj4NCiZndDsmZ3Q7ICZndDsgdXJ0aG1vdmVyPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsgT24gSnVseSAxNSwgMjAxNCBhdCAxMjoyOToxMiBQTSwgdXJ0aG1vdmVyICh1cnRo bW92ZXJAZ21haWwuY29tKSB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7ICZndDsmZ3Q7IEFsbCw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyBJIGhhdmUgYSBzdG9yYWdl IGRvbWFpbiB0aGF0IHJlcG9ydHMgaGF2aW5nIDg2M0cgZnJlZS4gJm5ic3A7VGhlIFRvdGFsIFNw YWNlIGlzIDkxM0cuICZuYnNwO0N1cnJlbnRseSwgdGhlcmUgYXJlIG5vIHZpcnR1YWwgbWFjaGlu ZXMgdXNpbmcgdGhpcyBzdG9yYWdlIGRvbWFpbi4gJm5ic3A7V2hlbiBJIHNzaCBpbnRvIHRoZSBo b3N0IHRoZXJlIGlzIDIuMk0gb24gdGhlIHRvcCBsZXZlbCBvZiB0aGF0IG1vdW50IGFjY29yZGlu ZyB0byBkdS4gJm5ic3A7SG93IGRvIEkgYWNjb3VudA0KIGZvciBhbmQgcmVjbGFpbSB0aGUgbXlz dGVyaW91cyBzcGFjZSB1c2FnZT88YnI+DQomZ3Q7Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7Jmd0OyAtLSZuYnNwOzxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7IHVydGhtb3Zl cjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5F9E965F5A80BC468BE5F40576769F098C558BF1exchange21_--

1 0

Log errors help
by Niklas Fondberg 15 Jul '14

15 Jul '14

Sorry for almost spamming the list but I sincerely have problemsŠ Could anyone help me with debugging some lines in my engine.log: Here they are: 2014-07-15 16:05:43,650 INFO [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (org.ovirt.thread.pool-6-thread-24) [797b0228] Running command: DeactivateStorageDomainCommand internal: true. Entities affected : ID: 5d6a9b56-e631-493b-8e71-569b5c8a193e Type: Storage 2014-07-15 16:05:43,657 INFO [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (org.ovirt.thread.pool-6-thread-24) [797b0228] Lock freed to object EngineLock [exclusiveLocks= key: 5d6a9b56-e631-493b-8e71-569b5c8a193e value: STORAGE , sharedLocks= ] 2014-07-15 16:05:43,685 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-24) [797b0228] Correlation ID: 797b0228, Job ID: 82089d0c-1956-474b-8b90-d24b3998e8b0, Call Stack: null, Custom Event ID: -1, Message: Storage Domain ISO_DOMAIN (Data Center local_datacenter) was deactivated by system because it's not visible by any of the hosts. 2014-07-15 16:05:43,695 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (org.ovirt.thread.pool-6-thread-23) starting processDomainRecovery for domain 6b08bd4d-b3dc-4cf7-8d61-06dfbb129172:IMPORT_EXPORT 2014-07-15 16:05:43,698 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (org.ovirt.thread.pool-6-thread-23) Domain 6b08bd4d-b3dc-4cf7-8d61-06dfbb129172:IMPORT_EXPORT was reported by all hosts in status UP as problematic. Moving the domain to NonOperational. 2014-07-15 16:04:45,773 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand ] (DefaultQuartzScheduler_Worker-74) HostName = local_host 2014-07-15 16:04:45,773 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand ] (DefaultQuartzScheduler_Worker-74) Command HSMGetAllTasksStatusesVDSCommand(HostName = local_host, HostId = 1d734ebb-f32f-41ca-8da8-86cfae93b1e6) execution failed. Exception: IRSNonOperationalException: IRSGenericException: IRSErrorException: IRSNonOperationalException: Not SPM: () 2014-07-15 16:04:45,782 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-74) hostFromVds::selectedVds - local_host, spmStatus Unknown_Pool, storage pool local_datacenter 2014-07-15 16:04:45,784 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-74) START, ConnectStoragePoolVDSCommand(HostName = local_host, HostId = 1d734ebb-f32f-41ca-8da8-86cfae93b1e6, storagePoolId = deb50055-1955-4993-bfcb-a642d71e84ce, vds_spm_id = 1, masterDomainId = c5ad71bf-e7a9-4ea0-b7a5-89afd5c2a61e, masterVersion = 1), log id: 4556b6d3 2014-07-15 16:04:50,747 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-74) Command org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand return value StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=304, mMessage=Cannot find master domain: 'spUUID=deb50055-1955-4993-bfcb-a642d71e84ce, msdUUID=c5ad71bf-e7a9-4ea0-b7a5-89afd5c2a61e']] 2014-07-15 16:04:50,747 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-74) HostName = local_host 2014-07-15 16:04:50,748 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-74) Command ConnectStoragePoolVDSCommand(HostName = local_host, HostId = 1d734ebb-f32f-41ca-8da8-86cfae93b1e6, storagePoolId = deb50055-1955-4993-bfcb-a642d71e84ce, vds_spm_id = 1, masterDomainId = c5ad71bf-e7a9-4ea0-b7a5-89afd5c2a61e, masterVersion = 1) execution failed. Exception: IRSNoMasterDomainException: IRSGenericException: IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: 'spUUID=deb50055-1955-4993-bfcb-a642d71e84ce, msdUUID=c5ad71bf-e7a9-4ea0-b7a5-89afd5c2a61e' 2014-07-15 16:04:50,749 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStoragePoolVDSCommand] (DefaultQuartzScheduler_Worker-74) FINISH, ConnectStoragePoolVDSCommand, log id: 4556b6d3 2014-07-15 16:04:50,749 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-74) IrsBroker::Failed::GetStoragePoolInfoVDS 2014-07-15 16:04:50,749 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-74) Exception: IRSGenericException: IRSErrorException: IRSNoMasterDomainException: Cannot find master domain: 'spUUID=deb50055-1955-4993-bfcb-a642d71e84ce, msdUUID=c5ad71bf-e7a9-4ea0-b7a5-89afd5c2a61e' If there are any expert companies that perform professional services I would be very grateful for links.

1 0

Re: [ovirt-users] Storage Domain used space strangeness
by Karli Sjöberg 15 Jul '14

15 Jul '14

--_000_5F9E965F5A80BC468BE5F40576769F098C558AB8exchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTUganVsIDIwMTQgMjE6MzEgc2tyZXYgdXJ0aG1vdmVyIDx1cnRobW92ZXJAZ21haWwu Y29tPjoNCj4NCj4gSXQgbWlnaHQgYmUgYSByZXN1bHQgb2YgcnVubmluZyB0aGUgemZzIGZpbGVz eXN0ZW0gb24gdGhlIGRpc2tzIHRoYXQgdGhlIHN0b3JhZ2UgZG9tYWluIGlzIHVzaW5nLiAgQW55 IGd1aWRhbmNlIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNClNuYXBzaG90cz8NCiMgemZzIGxp c3QgLXQgc25hcHNob3QNCg0KV2hhdCBkb2VzIHRoZSBob3N0cyB0aGF0IGFyZSBtb3V0aW5nIHRo aW5rPyBJZiB5b3UgbG9nIGludG8gb25lIG9mIHRoZW0gYW5kIHJ1bjoNCiMgZGYgLWgNCg0KL0sN Cg0KPg0KPiBbcm9vdEBqbWluaTA4IH5dIyBtb3VudCB8IGdyZXAgZGF0YS1wb29sDQo+IGRhdGEt cG9vbCBvbiAvZGF0YSB0eXBlIHpmcyAocncseGF0dHIpDQo+DQo+IFtyb290QGptaW5pMDggfl0j IGRmIC1oIC9kYXRhDQo+IEZpbGVzeXN0ZW0gICAgICBTaXplICBVc2VkIEF2YWlsIFVzZSUgTW91 bnRlZCBvbg0KPiBkYXRhLXBvb2wgICAgICAgOTE0RyAgIDUxRyAgODY0RyAgIDYlIC9kYXRhDQo+ DQo+IFtyb290QGptaW5pMDggfl0jIGR1IC1oIC9kYXRhDQo+IDE3SyAvZGF0YS81NGJhNDYxZC1m YmVjLTQyMmUtOTMwMC0yZjUxNjQwZTViMmEvaW1hZ2VzDQo+IDIuMU0gL2RhdGEvNTRiYTQ2MWQt ZmJlYy00MjJlLTkzMDAtMmY1MTY0MGU1YjJhL2RvbV9tZA0KPiAyLjFNIC9kYXRhLzU0YmE0NjFk LWZiZWMtNDIyZS05MzAwLTJmNTE2NDBlNWIyYQ0KPiAyLjJNIC9kYXRhDQo+DQo+IFtyb290QGpt aW5pMDggfl0jIHpwb29sIHN0YXR1cw0KPiAgIHBvb2w6IGRhdGEtcG9vbA0KPiAgc3RhdGU6IE9O TElORQ0KPiAgIHNjYW46IG5vbmUgcmVxdWVzdGVkDQo+IGNvbmZpZzoNCj4NCj4gTkFNRSAgICAg ICAgU1RBVEUgICAgIFJFQUQgV1JJVEUgQ0tTVU0NCj4gZGF0YS1wb29sICAgT05MSU5FICAgICAg IDAgICAgIDAgICAgIDANCj4gIG1pcnJvci0wICBPTkxJTkUgICAgICAgMCAgICAgMCAgICAgMA0K PiAgICBzZGEgICAgIE9OTElORSAgICAgICAwICAgICAwICAgICAwDQo+ICAgIHNkYiAgICAgT05M SU5FICAgICAgIDAgICAgIDAgICAgIDANCj4NCj4gZXJyb3JzOiBObyBrbm93biBkYXRhIGVycm9y cw0KPg0KPiAtLQ0KPiB1cnRobW92ZXINCj4NCj4gT24gSnVseSAxNSwgMjAxNCBhdCAxMjoyOTox MiBQTSwgdXJ0aG1vdmVyICh1cnRobW92ZXJAZ21haWwuY29tKSB3cm90ZToNCj4+DQo+PiBBbGws DQo+PiBJIGhhdmUgYSBzdG9yYWdlIGRvbWFpbiB0aGF0IHJlcG9ydHMgaGF2aW5nIDg2M0cgZnJl ZS4gIFRoZSBUb3RhbCBTcGFjZSBpcyA5MTNHLiAgQ3VycmVudGx5LCB0aGVyZSBhcmUgbm8gdmly dHVhbCBtYWNoaW5lcyB1c2luZyB0aGlzIHN0b3JhZ2UgZG9tYWluLiAgV2hlbiBJIHNzaCBpbnRv IHRoZSBob3N0IHRoZXJlIGlzIDIuMk0gb24gdGhlIHRvcCBsZXZlbCBvZiB0aGF0IG1vdW50IGFj Y29yZGluZyB0byBkdS4gIEhvdyBkbyBJIGFjY291bnQgZm9yIGFuZCByZWNsYWltIHRoZSBteXN0 ZXJpb3VzIHNwYWNlIHVzYWdlPw0KPj4NCj4+IC0tDQo+PiB1cnRobW92ZXINCg== --_000_5F9E965F5A80BC468BE5F40576769F098C558AB8exchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <B094105BEA254947BE6A89C9F9B0057C(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxNSBqdWwgMjAxNCAyMTozMSBza3JldiB1cnRobW92ZXIgJmx0O3VydGhtb3Zl ckBnbWFpbC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IG1pZ2h0IGJlIGEgcmVzdWx0 IG9mIHJ1bm5pbmcgdGhlIHpmcyBmaWxlc3lzdGVtIG9uIHRoZSBkaXNrcyB0aGF0IHRoZSBzdG9y YWdlIGRvbWFpbiBpcyB1c2luZy4gJm5ic3A7QW55IGd1aWRhbmNlIGlzIGdyZWF0bHkgYXBwcmVj aWF0ZWQuPC9wPg0KPHAgZGlyPSJsdHIiPlNuYXBzaG90cz88YnI+DQojIHpmcyBsaXN0IC10IHNu YXBzaG90PC9wPg0KPHAgZGlyPSJsdHIiPldoYXQgZG9lcyB0aGUgaG9zdHMgdGhhdCBhcmUgbW91 dGluZyB0aGluaz8gSWYgeW91IGxvZyBpbnRvIG9uZSBvZiB0aGVtIGFuZCBydW46PGJyPg0KIyBk ZiAtaDwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0 OyBbcm9vdEBqbWluaTA4IH5dIyBtb3VudCB8IGdyZXAgZGF0YS1wb29sPGJyPg0KJmd0OyBkYXRh LXBvb2wgb24gL2RhdGEgdHlwZSB6ZnMgKHJ3LHhhdHRyKTxicj4NCiZndDs8YnI+DQomZ3Q7IFty b290QGptaW5pMDggfl0jIGRmIC1oIC9kYXRhPGJyPg0KJmd0OyBGaWxlc3lzdGVtICZuYnNwOyAm bmJzcDsgJm5ic3A7U2l6ZSAmbmJzcDtVc2VkIEF2YWlsIFVzZSUgTW91bnRlZCBvbjxicj4NCiZn dDsgZGF0YS1wb29sICZuYnNwOyAmbmJzcDsgJm5ic3A7IDkxNEcgJm5ic3A7IDUxRyAmbmJzcDs4 NjRHICZuYnNwOyA2JSAvZGF0YTxicj4NCiZndDs8YnI+DQomZ3Q7IFtyb290QGptaW5pMDggfl0j IGR1IC1oIC9kYXRhPGJyPg0KJmd0OyAxN0sgL2RhdGEvNTRiYTQ2MWQtZmJlYy00MjJlLTkzMDAt MmY1MTY0MGU1YjJhL2ltYWdlczxicj4NCiZndDsgMi4xTSAvZGF0YS81NGJhNDYxZC1mYmVjLTQy MmUtOTMwMC0yZjUxNjQwZTViMmEvZG9tX21kPGJyPg0KJmd0OyAyLjFNIC9kYXRhLzU0YmE0NjFk LWZiZWMtNDIyZS05MzAwLTJmNTE2NDBlNWIyYTxicj4NCiZndDsgMi4yTSAvZGF0YTxicj4NCiZn dDs8YnI+DQomZ3Q7IFtyb290QGptaW5pMDggfl0jIHpwb29sIHN0YXR1czxicj4NCiZndDsgJm5i c3A7IHBvb2w6IGRhdGEtcG9vbDxicj4NCiZndDsgJm5ic3A7c3RhdGU6IE9OTElORTxicj4NCiZn dDsgJm5ic3A7IHNjYW46IG5vbmUgcmVxdWVzdGVkPGJyPg0KJmd0OyBjb25maWc6PGJyPg0KJmd0 Ozxicj4NCiZndDsgTkFNRSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTVEFURSAmbmJzcDsg Jm5ic3A7IFJFQUQgV1JJVEUgQ0tTVU08YnI+DQomZ3Q7IGRhdGEtcG9vbCAmbmJzcDsgT05MSU5F ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDAgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAmbmJzcDsgMDxi cj4NCiZndDsgJm5ic3A7bWlycm9yLTAgJm5ic3A7T05MSU5FICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDAgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAmbmJzcDsgMDxicj4NCiZndDsgJm5ic3A7ICZuYnNw O3NkYSAmbmJzcDsgJm5ic3A7IE9OTElORSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAwICZuYnNwOyAm bmJzcDsgMCAmbmJzcDsgJm5ic3A7IDA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtzZGIgJm5ic3A7 ICZuYnNwOyBPTkxJTkUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMCAmbmJzcDsgJm5ic3A7IDAgJm5i c3A7ICZuYnNwOyAwPGJyPg0KJmd0Ozxicj4NCiZndDsgZXJyb3JzOiBObyBrbm93biBkYXRhIGVy cm9yczxicj4NCiZndDs8YnI+DQomZ3Q7IC0tJm5ic3A7PGJyPg0KJmd0OyB1cnRobW92ZXI8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPbiBKdWx5IDE1LCAyMDE0IGF0IDEyOjI5OjEyIFBNLCB1cnRobW92 ZXIgKHVydGhtb3ZlckBnbWFpbC5jb20pIHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgQWxsLDxicj4NCiZndDsmZ3Q7IEkgaGF2ZSBhIHN0b3JhZ2UgZG9tYWluIHRoYXQgcmVwb3J0 cyBoYXZpbmcgODYzRyBmcmVlLiAmbmJzcDtUaGUgVG90YWwgU3BhY2UgaXMgOTEzRy4gJm5ic3A7 Q3VycmVudGx5LCB0aGVyZSBhcmUgbm8gdmlydHVhbCBtYWNoaW5lcyB1c2luZyB0aGlzIHN0b3Jh Z2UgZG9tYWluLiAmbmJzcDtXaGVuIEkgc3NoIGludG8gdGhlIGhvc3QgdGhlcmUgaXMgMi4yTSBv biB0aGUgdG9wIGxldmVsIG9mIHRoYXQgbW91bnQgYWNjb3JkaW5nIHRvIGR1LiAmbmJzcDtIb3cg ZG8gSSBhY2NvdW50DQogZm9yIGFuZCByZWNsYWltIHRoZSBteXN0ZXJpb3VzIHNwYWNlIHVzYWdl Pzxicj4NCiZndDsmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7IC0tJm5ic3A7PGJyPg0KJmd0OyZn dDsgdXJ0aG1vdmVyPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5F9E965F5A80BC468BE5F40576769F098C558AB8exchange21_--

1 0