- Users - oVirt List Archives

Postponing oVirt 3.6.0 alpha to tomorrow
by Sandro Bonazzola 19 May '15

19 May '15

Hi, due to outage on the copr repository not providing patternfly rpms, we need to postpone the alpha to tomorrow in order to properly test it before releasing. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt user permissions for fence_rhevm
by Rik Theys 19 May '15

19 May '15

Hi, I've created a user in AD that should only be able to power off/on a specific VM in oVirt. I've granted this user UserRole permission on this specific VM. If I log into the user portal with these credentials I can see the VM and power it off/on. When I use the fence_rhevm agent it fails to find the correct "plug". I fixed this by adding the "Filter: true" header to the fence_rhevm script. When running manually, fence_rhevm can show me the status of the plug and can power it on/off. When I try to integrate this into a pacemaker cluster (on Debian 7) using the fence_rhevm resource agent it reboots the VM on every monitor action. Has anyone succeeded in using fence_rhevm with oVirt on pacemaker 1.1? Are there any additional oVirt permissions the user needs to make this work? I don't want to make this fence user an admin for my entire ovirt datacenter. The stonith primitive is configured: primitive p_fence_vm1 stonith:fence_rhevm \ params port="vm1" login="fence-vm1(a)mydomain.ad" ipaddr="ovirt-engine.mydomain" ipport="443" ssl="1" passwd="secret" verbose="1" pcmk_host_list="vm1" pcmk_host_check="static-list" \ op monitor interval="15m" Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 ---------------------------------------------------------------- <<Any errors in spelling, tact or fact are transmission errors>>

2 1

VM-Affinity [keeping 2 servers from running om the same hosts]
by Stein van Broekhoven 19 May '15

19 May '15

------=_Part_53616_1768657351.1432037377799 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear List, We have a few virtual machines that we want to keep separated as much as possible. I've created negative hard enforcing affinity groups with multiple servers in it. Some of them are on the same Hyper-visor but the aren't migrating to other machines. Do I need to trigger a scheduler? Is this functionality possible? Kind Regards, Stein van Broekhoven cloud.nl ------=_Part_53616_1768657351.1432037377799 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Dear List,</div><div><br data-mce-bogus="1"></div><div>We have a few virtual machines that we want to keep separated as much as possible.</div><div>I've created negative hard enforcing affinity groups with multiple servers in it.</div><div>Some of them are on the same Hyper-visor but the aren't migrating to other machines.</div><div>Do I need to trigger a scheduler?</div><div>Is this functionality possible?</div><div><br data-mce-bogus="1"></div><div>Kind Regards,</div><div><br data-mce-bogus="1"></div><div>Stein van Broekhoven</div><div>cloud.nl</div></div></body></html> ------=_Part_53616_1768657351.1432037377799--

2 1

Ovirt node or Linux standard
by Kevin C 19 May '15

19 May '15

Hi all, There is any reason to choose to install a CentOS 6/7 and add it to oVirt Manager instead of an oVirt Node ? It's just for managability or there is other technical reasons ? Thanks -- Kevin

4 4

3.5 all in one
by Grant Pasley 19 May '15

19 May '15

hi guys, is it possible with 3.5 to run everything on a single server the way earlier versions did? cannot seem to find much on it other than using a live cd which is not what i am wanting, trying to install on top of centos 6.6 minimal install. -- thanks and regards, grant pasley. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

3 4

vdsm storage problem - maybe cache problem?
by ml＠ohnewald.net 19 May '15

19 May '15

Hello List, i did a simple update in my CentOS 6.6 Engine (3.5) and then i rebootet it. After that i ran into trouble. My NFS mounts from my clients to my engine got stuck. So i unmounted them manually with: umount -f -l <path to my mount point> Which worked. I hoped vdsm would remount it again. With no luck. So i deleted the nfs export and iso domain from the cluster. Now i am getting this error in my vdsm log: 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,682::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,683::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,717::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,717::sp::329::Storage.StoragePool::(startSpm) Unexpected error 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,717::sp::330::Storage.StoragePool::(startSpm) failed: Storage domain does not exist: ('036b5575-51fa-4f14-8b05-890d7807894c',) 2c6b4422-7faa-4847-ab30-fc713d7012af::ERROR::2015-05-18 13:13:25,928::task::866::TaskManager.Task::(_setError) Task=`2c6b4422-7faa-4847-ab30-fc713d7012af`::Unexpected error Thread-37::ERROR::2015-05-18 13:13:35,683::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:35,683::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:35,720::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found Thread-37::ERROR::2015-05-18 13:13:35,720::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c monitoring information Thread-482::ERROR::2015-05-18 13:13:40,062::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-482::ERROR::2015-05-18 13:13:40,063::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-482::ERROR::2015-05-18 13:13:40,147::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,149::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,152::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,191::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,191::sp::288::Storage.StoragePool::(startSpm) Backup domain validation failed 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,193::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,193::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,228::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,228::sp::329::Storage.StoragePool::(startSpm) Unexpected error 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,228::sp::330::Storage.StoragePool::(startSpm) failed: Storage domain does not exist: ('036b5575-51fa-4f14-8b05-890d7807894c',) 3140b81f-a434-4877-9a34-3923505e4a1f::ERROR::2015-05-18 13:13:40,932::task::866::TaskManager.Task::(_setError) Task=`3140b81f-a434-4877-9a34-3923505e4a1f`::Unexpected error Thread-37::ERROR::2015-05-18 13:13:45,721::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:45,721::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:45,757::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found Thread-37::ERROR::2015-05-18 13:13:45,758::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c monitoring information Thread-501::ERROR::2015-05-18 13:13:54,714::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-501::ERROR::2015-05-18 13:13:54,715::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-501::ERROR::2015-05-18 13:13:54,751::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,751::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,752::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,787::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,788::sp::288::Storage.StoragePool::(startSpm) Backup domain validation failed 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,790::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,790::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,824::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,824::sp::329::Storage.StoragePool::(startSpm) Unexpected error 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,824::sp::330::Storage.StoragePool::(startSpm) failed: Storage domain does not exist: ('036b5575-51fa-4f14-8b05-890d7807894c',) 5893d839-b69b-4d25-816a-67f2c9f24e12::ERROR::2015-05-18 13:13:54,937::task::866::TaskManager.Task::(_setError) Task=`5893d839-b69b-4d25-816a-67f2c9f24e12`::Unexpected error Thread-37::ERROR::2015-05-18 13:13:55,758::sdc::137::Storage.StorageDomainCache::(_findDomain) looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:55,759::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 036b5575-51fa-4f14-8b05-890d7807894c Thread-37::ERROR::2015-05-18 13:13:55,794::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 036b5575-51fa-4f14-8b05-890d7807894c not found Thread-37::ERROR::2015-05-18 13:13:55,795::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c monitoring information In older engine logs i was able to find out what id 036b5575-51fa-4f14-8b05-890d7807894c is: ---------------------------- 2015-05-18 10:58:55,397 WARN [org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxyData] (org.ovirt.thread.pool-8-thread-43) domain 036b5575-51fa-4f14-8b05-890d7807894c:EXPORT2 in problem. vds: ovirt-node01.stuttgart.imos.net Now my Question: Why does the vdsm node not know that i deleted the storage? Has the vdsm cached this mount informations? Why does it still try to access 036b5575-51fa-4f14-8b05-890d7807894c? I can NOT reboot my node because i have active running vms on it. Thanks, Mario

3 6

Re: [ovirt-users] Bad performance with Windows 2012 guests
by Doron Fediuck 19 May '15

19 May '15

On Apr 30, 2015 14:03, Martijn Grendelman <martijn.grendelman(a)isaac.nl> wrote: > > Hi, > > Ever since our first Windows Server 2012 deployment on oVirt (3.4 back > then, now 3.5.1), I have noticed that working on these VMs via RDP or on > the console via VNC is noticeably slower than on Windows 2008 guests on > the same oVirt environment. > > Basic things like starting an application (even the Server Manager that > get started automatically on login) take a very long time, sometimes > minutes. Everything is just... slow. > > We have recently deployed Microsoft Exchange on a Windows Server 2012 > guest on RHEV, and it doesn't perform well at all. > > I haven't been able to find the cause for this slowness; CPU usage is > not excessive and it doesn't seem I/O related. Moreover, other types of > guests (Linux and even Windows 2008) do not have this problem. > > We have 3 different environments: > - oVirt 3.5.1, on old Dell servers with Penryn Family CPUs with fairly > slow storage on replicated GlusterFS, running CentOS 6.6 > - oVirt 3.5.1, on modern 6-core SandyBridge servers with local storage > via NFS, running CentOS 7.0) > - RHEV 3.4.4 on modern 10-core SandyBridge servers with an iSCSI SAN > behind it, running on RHEV Hypervisor 6.5 > > All of these -very different- environments expose the same behaviour: > Linux, Windows 2008 fast (or as fast as can be expected given the > hardware), Windows 2012 painfully slow. > > All Windows 2012 servers use VirtIO disk and network. I think all > drivers are from the virtio-win-0.1-74 ISO. > > Does anyone share this experience? > Any idea why this could happen and how it can be fixed? > Any other information I should share to get a better idea? > > Btw, for the guests on the RHEV environment, we have a case with RedHat > support, but that doesn't seem to lead to a quick solution, hence I'm > writing here, too. > > Thanks for any help. > > Regards, > Martijn Grendelman Hi Martijn, Can you please provide the QEMU command line, together with kvm and qemu version? This information will be helpful for reproducing the problem. However, if the problem is not reproducible on a local setup, we will probably need to ask collecting some performance information with xperf tool. Doron

3 8

Team a NIC and add to ovirtmgmt vNIC
by Christophe TREFOIS 19 May '15

19 May '15

--_000_80CE715F2FC040FFAB9D475043C5E97Dunilu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkhvdyBJIHdvdWxkIGdvIGFib3V0IGluIGFuIGV4aXN0aW5nIHNldHVwIHdp dGggMSBOSUMgYW5kIDEgdk5JQyBvdmlydG1nbXQsIHRvIGFkZCBhIHNlY29uZCBOSUMsIHRlYW0g dGhlbSB1cCAoYm9uZGluZykgYW5kIHRoZW4gYXNzaWduIHRoYXQgb25lIHRvIG92aXJ0bWdtdCB3 aXRob3V0IHRvbyBtdWNoIGRvd250aW1lPw0KDQpEb2VzIGFueWJvZHkgaGF2ZSBzb21lIGV4cGVy aWVuY2Ugb24gdGhhdD8NCg0KVGhhbmsgeW91IGZvciB5b3VyIGhlbHAsDQoNCuKAlA0KQ2hyaXN0 b3BoZQ0KDQpEciBDaHJpc3RvcGhlIFRyZWZvaXMsIERpcGwuLUluZy4NClRlY2huaWNhbCBTcGVj aWFsaXN0IC8gUG9zdC1Eb2MNCg0KVU5JVkVSU0lUw4kgRFUgTFVYRU1CT1VSRw0KDQpMVVhFTUJP VVJHIENFTlRSRSBGT1IgU1lTVEVNUyBCSU9NRUlESU5DRQ0KQ2FtcHVzIEJlbHZhbCB8IEhvdXNl IG9mIEJpb21lZGljaW5lDQo3LCBhdmVudWUgZGVzIEhhdXRzLUZvdXJuZWF1eA0KTC00MzYyIEVz Y2gtc3VyLUFsemV0dGUNClQ6ICszNTIgNDYgNjYgNDQgNjEyNA0KRjogKzM1MiA0NiA2NiA0NCA2 OTQ5DQpodHRwOi8vd3d3LnVuaS5sdS9sY3NiDQoNCltGYWNlYm9va108aHR0cHM6Ly93d3cuZmFj ZWJvb2suY29tL3RyZWZleD4gW1R3aXR0ZXJdIDxodHRwczovL3R3aXR0ZXIuY29tL1RyZWZleD4g IFtHb29nbGUgUGx1c10gPGh0dHBzOi8vcGx1cy5nb29nbGUuY29tLytDaHJpc3RvcGhlVHJlZm9p cy8+ICBbTGlua2VkaW5dIDxodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vdHJlZm9pc2Nocmlz dG9waGU+ICBbc2t5cGVdIDxodHRwOi8vc2t5cGU6VHJlZmV4P2NhbGw+DQoNCi0tLS0NClRoaXMg bWVzc2FnZSBpcyBjb25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24uDQpJdCBpcyBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5Lg0KSWYg eW91IHJlY2VpdmUgaXQgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSBtZSBhbmQgcGVybWFuZW50bHkg ZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlIGFuZCBhbnkgY29waWVzLg0KLS0tLQ0KDQoNCg0K --_000_80CE715F2FC040FFAB9D475043C5E97Dunilu_ Content-Type: text/html; charset="utf-8" Content-ID: <4B8C465BD1B0174792FD3A43F5248D24(a)uni.lux> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBhbGwsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Ib3cgSSB3b3VsZCBnbyBh Ym91dCBpbiBhbiBleGlzdGluZyBzZXR1cCB3aXRoIDEgTklDIGFuZCAxIHZOSUMgb3ZpcnRtZ210 LCB0byBhZGQgYSBzZWNvbmQgTklDLCB0ZWFtIHRoZW0gdXAgKGJvbmRpbmcpIGFuZCB0aGVuIGFz c2lnbiB0aGF0IG9uZSB0byBvdmlydG1nbXQgd2l0aG91dCB0b28gbXVjaCBkb3dudGltZT88L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRv ZXMgYW55Ym9keSBoYXZlIHNvbWUgZXhwZXJpZW5jZSBvbiB0aGF0PzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmsgeW91IGZvciB5 b3VyIGhlbHAsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj7igJQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2hyaXN0b3BoZTwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8bWV0YSBuYW1lPSJmb3JtYXQtZGV0ZWN0aW9u IiBjb250ZW50PSJ0ZWxlcGhvbmU9bm8iIGNsYXNzPSIiPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0OyBsaW5lLWhlaWdodDogMTZweDsg Y29sb3I6IHJnYigzMywgMzMsIDMzKTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OiBib2xkOyBjb2xvcjogcmdiKDYxLCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IiBjbGFz cz0iIj5EciBDaHJpc3RvcGhlIFRyZWZvaXMsIERpcGwuLUluZy48L3NwYW4+DQo8c3BhbiBzdHls ZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDYxLCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IGZvbnQtc2l6 ZTo3LjVwdDsiIGNsYXNzPSIiPlRlY2huaWNhbCBTcGVjaWFsaXN0IC8gUG9zdC1Eb2M8L3NwYW4+ DQo8L3A+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNp emU6IDcuNXB0OyBsaW5lLWhlaWdodDogMTZweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OiBib2xkOyBjb2xvcjogcmdiKDYxLCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7 IiBjbGFzcz0iIj5VTklWRVJTSVTDiSBEVSBMVVhFTUJPVVJHPC9zcGFuPjxiciBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyBjb2xvcjogcmdiKDYxLCA1OSwg NTkpOyBkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj5MVVhFTUJPVVJHIENFTlRSRSBGT1IgU1lT VEVNUyBCSU9NRUlESU5DRTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IHJnYig2MSwgNTksIDU5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+Q2FtcHVzIEJlbHZh bCB8IEhvdXNlIG9mIEJpb21lZGljaW5lDQo8YnIgY2xhc3M9IiI+DQo3LCBhdmVudWUgZGVzIEhh dXRzLUZvdXJuZWF1eCA8YnIgY2xhc3M9IiI+DQpMLTQzNjIgRXNjaC1zdXItQWx6ZXR0ZSA8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRp c3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPlQ6IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJn Yig2MSwgNTksIDU5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+JiM0MzszNTIgNDYgNjYg NDQgNjEyNDwvc3Bhbj4NCjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDYx LCA1OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj5GOiA8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPiYj NDM7MzUyIDQ2IDY2IDQ0IDY5NDk8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZGlzcGxheTogaW5saW5l OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5p Lmx1L2xjc2IiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDEwOSwgMTg5KTsgZGlzcGxheTogaW5saW5l OyIgY2xhc3M9IiI+aHR0cDovL3d3dy51bmkubHUvbGNzYjwvYT4NCjwvcD4NCjxwIHN0eWxlPSJm b250LWZhbWlseTogIEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVp Z2h0OiAxNnB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9vay5jb20v dHJlZmV4IiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PGltZyB3aWR0aD0iMjQi IGhlaWdodD0iMjQiIGRhdGEtZmlsZW5hbWU9ImZhY2Vib29rLnBuZyIgc3JjPSJodHRwczovL3Mz LmFtYXpvbmF3cy5jb20vaHRtbHNpZy1hc3NldHMvcm91bmRlZC9mYWNlYm9vay5wbmciIGFsdD0i RmFjZWJvb2siIGNsYXNzPSIiPjwvYT4NCjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vVHJl ZmV4IiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PGltZyB3aWR0aD0iMjQiIGhl aWdodD0iMjQiIGRhdGEtZmlsZW5hbWU9InR3aXR0ZXIucG5nIiBzcmM9Imh0dHBzOi8vczMuYW1h em9uYXdzLmNvbS9odG1sc2lnLWFzc2V0cy9yb3VuZGVkL3R3aXR0ZXIucG5nIiBhbHQ9IlR3aXR0 ZXIiIGNsYXNzPSIiPjwvYT4NCjxhIGhyZWY9Imh0dHBzOi8vcGx1cy5nb29nbGUuY29tLyYjNDM7 Q2hyaXN0b3BoZVRyZWZvaXMvIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+DQo8 aW1nIHdpZHRoPSIyNCIgaGVpZ2h0PSIyNCIgZGF0YS1maWxlbmFtZT0iZ29vZ2xlcGx1cy5wbmci IHNyYz0iaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL2h0bWxzaWctYXNzZXRzL3JvdW5kZWQvZ29v Z2xlcGx1cy5wbmciIGFsdD0iR29vZ2xlIFBsdXMiIGNsYXNzPSIiPjwvYT4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi90cmVmb2lzY2hyaXN0b3BoZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiIGNsYXNzPSIiPg0KPGltZyB3aWR0aD0iMjQiIGhlaWdodD0iMjQiIGRhdGEt ZmlsZW5hbWU9ImxpbmtlZGluLnBuZyIgc3JjPSJodHRwczovL3MzLmFtYXpvbmF3cy5jb20vaHRt bHNpZy1hc3NldHMvcm91bmRlZC9saW5rZWRpbi5wbmciIGFsdD0iTGlua2VkaW4iIGNsYXNzPSIi PjwvYT4NCjxhIGhyZWY9Imh0dHA6Ly9za3lwZTpUcmVmZXg/Y2FsbCIgc3R5bGU9ImRpc3BsYXk6 IGlubGluZTsiIGNsYXNzPSIiPjxpbWcgd2lkdGg9IjI0IiBoZWlnaHQ9IjI0IiBkYXRhLWZpbGVu YW1lPSJza3lwZS5wbmciIHNyYz0iaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL2h0bWxzaWctYXNz ZXRzL3JvdW5kZWQvc2t5cGUucG5nIiBhbHQ9InNreXBlIiBjbGFzcz0iIj48L2E+DQo8L3A+DQo8 cCBjbGFzcz0iYmFubmVyLWNvbnRhaW5lciIgc3R5bGU9ImZvbnQtZmFtaWx5OiAgQXJpYWwsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1oZWlnaHQ6MTZweDsiPg0KPC9wPg0KPHAg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig2MSwgNTks IDU5KTsgZm9udC1zaXplOiA5cHg7IGxpbmUtaGVpZ2h0OiAxNnB4OyIgY2xhc3M9IiI+DQotLS0t PGJyIGNsYXNzPSIiPg0KVGhpcyBtZXNzYWdlIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRh aW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gPGJyIGNsYXNzPSIiPg0KSXQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4gPGJyIGNsYXNzPSIiPg0KSWYgeW91IHJlY2Vp dmUgaXQgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSBtZSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRo ZSBvcmlnaW5hbCBtZXNzYWdlIGFuZCBhbnkgY29waWVzLg0KPGJyIGNsYXNzPSIiPg0KLS0tLTxi ciBjbGFzcz0iIj4NCjwvcD4NCiZuYnNwOyA8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_80CE715F2FC040FFAB9D475043C5E97Dunilu_--

2 1

Re: [ovirt-users] Unable to Delete a VM snapshot . (Juan Hern?ndez)
by Kumar R, Prashanth (Prashanth) 18 May '15

18 May '15

Hi Juan Hern?ndez , RE:Unable to Delete a VM snapshot . Do you mean that there is no unique identifier for a VM snapshot.? The only way out is from my java client ,I have to take care of creating a snapshot with unique description. SO that I can delete/restore a snapshot based on the unique description. Thanks, Prashanth R -----Original Message----- From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request(a)ovirt.org Sent: Wednesday, May 13, 2015 2:06 PM To: users(a)ovirt.org Subject: Users Digest, Vol 44, Issue 61 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ovirt.org_mailman… or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: HE setup failing: Cannot set temporary password for console connection (Daniel Helgenberger) 2. Re: messages from journal in centos7 hosts (Nicolas Ecarnot) 3. Re: engine-reports portal and cpu cores (Shirly Radco) 4. Re: engine-reports portal and cpu cores (Alexandr Krivulya) 5. Re: messages from journal in centos7 hosts (Francesco Romani) 6. Re: Unable to Delete a VM snapshot . (Juan Hern?ndez) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 May 2015 07:29:24 +0000 From: Daniel Helgenberger <daniel.helgenberger(a)m-box.de> To: Yedidyah Bar David <didi(a)redhat.com> Cc: "users(a)ovirt.org" <users(a)ovirt.org> Subject: Re: [ovirt-users] HE setup failing: Cannot set temporary password for console connection Message-ID: <8569C17008504C42.643F5ABB-0F2D-445E-8665-0D736F998CDC(a)mail.outlook.com> Content-Type: text/plain; charset="iso-8859-1" Hello Didi, this is a clean install of the first host. (I am trying a disaster scenario and will later restore the backup) -- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22<tel:+49/30/2408781-22> F: +49/30/2408781-10<tel:+49/30/2408781-10> ACKERSTR. 19 D-10115 BERLIN www.m-box.de<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.m-2Dbox.de&d=AwICAg… > www.monkeymen.tv<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.monkeymen.tv&d=AwIC… > Gesch?ftsf?hrer: Martin Retschitzegger / Michaela G?llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767 On Wed, May 13, 2015 at 12:22 AM -0700, "Yedidyah Bar David" <didi(a)redhat.com<mailto:didi@redhat.com>> wrote: ----- Original Message ----- > From: "Daniel Helgenberger" <daniel.helgenberger(a)m-box.de> > To: users(a)ovirt.org > Sent: Tuesday, May 12, 2015 8:48:42 PM > Subject: [ovirt-users] HE setup failing: Cannot set temporary password > for console connection > > Hello, > > a week ago I set up a HE (3.5.2) with no problems; now this fails. You mean you re-deploy the same host (clean setup), or adding another host? > I > suspect storage trouble but cannot pinpoint it. Did someth. change > there with the recent async release? > > The storage domain is NFS3 via a 1G link to a ZFS storage appliance. > The export is working quite fast; tested with iozone running for over > 24h without problems. > > It starts with the "Verifying sanlock lockspace initialization" phase; > which lasts about 7min (!). > > In the end it seems sanlock is locking the domain down. I can only get > it back by stopping sanlock and vdsm. > > Attached is the full vdsm lock. > > > Thanks! > > vdsm: > > Thread-27::ERROR::2015-05-12 > 19:17:51,470::domainMonitor::256::Storage.DomainMonitorThread::(_monit > orDomain) Error while collecting domain > 2f83ea82-e110-465d-a2a6-ac30534a9f6a > monitoring information > Traceback (most recent call last): > File "/usr/share/vdsm/storage/domainMonitor.py", line 232, in > _monitorDomain > self.domain.selftest() > File "/usr/share/vdsm/storage/sdc.py", line 49, in __getattr__ > return getattr(self.getRealDomain(), attrName) > 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/nfsSD.py", line 122, in findDomain > return NfsStorageDomain(NfsStorageDomain.findDomainPath(sdUUID)) > File "/usr/share/vdsm/storage/nfsSD.py", line 112, in findDomainPath > raise se.StorageDomainDoesNotExist(sdUUID) > StorageDomainDoesNotExist: Storage domain does not exist: > ('2f83ea82-e110-465d-a2a6-ac30534a9f6a',) > > > Detector thread::DEBUG::2015-05-12 > 19:24:33,163::BindingXMLRPC::1173::XmlDetector::(handleSocket) xml > over http detected from ('127.0.0.1', 47076) > Thread-93::DEBUG::2015-05-12 > 19:24:33,166::BindingXMLRPC::1133::vds::(wrapper) client > [127.0.0.1]::call vmSetTicket with > ('e3d350c5-6254-4908-99e9-d60ca2e046f7', '5435uOVP', '10800', > 'disconnect', {}) {} > Thread-93::ERROR::2015-05-12 > 19:24:33,166::BindingXMLRPC::1152::vds::(wrapper) unexpected error > Traceback (most recent call last): > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 1136, in wrapper > res = f(*args, **kwargs) > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 383, in vmSetTicket > return vm.setTicket(password, ttl, existingConnAction, params) > File "/usr/share/vdsm/API.py", line 642, in setTicket > return v.setTicket(password, ttl, existingConnAction, params) > File "/usr/share/vdsm/virt/vm.py", line 4834, in setTicket > graphics = _domParseStr(self._dom.XMLDesc(0)).childNodes[0]. \ > AttributeError: 'NoneType' object has no attribute 'XMLDesc' > > and: > > Thread-91::DEBUG::2015-05-12 > 19:25:15,152::libvirtconnection::143::root::(wrapper) Unknown libvirterror: > ecode: 38 edom: 42 level: 2 message: Failed to acquire lock: No space > left on device > Thread-91::DEBUG::2015-05-12 > 19:25:15,154::vm::2294::vm.Vm::(_startUnderlyingVm) > vmId=`e3d350c5-6254-4908-99e9-d60ca2e046f7`::_ongoingCreations > released > Thread-91::ERROR::2015-05-12 > 19:25:15,154::vm::2331::vm.Vm::(_startUnderlyingVm) > vmId=`e3d350c5-6254-4908-99e9-d60ca2e046f7`::The vm start process > failed Traceback (most recent call last): > File "/usr/share/vdsm/virt/vm.py", line 2271, in _startUnderlyingVm > self._run() > File "/usr/share/vdsm/virt/vm.py", line 3335, in _run > self._connection.createXML(domxml, flags), > File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line > 111, in wrapper > ret = f(*args, **kwargs) > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3427, in > createXML > if ret is None:raise libvirtError('virDomainCreateXML() failed', > conn=self) > libvirtError: Failed to acquire lock: No space left on device > > sanlock: > 2015-05-12 19:11:27+0200 4338 [708]: s2 lockspace > 2f83ea82-e110-465d-a2a6-ac30534a9f6a:1:/rhev/data-center/mnt/10.11.0.3 > 0:_volumes_ovirt_engine/2f83ea82-e110-465d-a2a6-ac30534a9f6a/dom_md/id > s:0 > 2015-05-12 19:11:48+0200 4359 [702]: s2 host 1 1 4338 > 9f9fb274-9ae8-490e-bfba-72a743b0ebb2.hv01.sec.i > 2015-05-12 19:11:48+0200 4359 [702]: s2 host 250 1 0 > 9f9fb274-9ae8-490e-bfba-72a743b0ebb2.hv01.sec.i > 2015-05-12 19:11:48+0200 4359 [707]: s2:r2 resource > 2f83ea82-e110-465d-a2a6-ac30534a9f6a:SDM:/rhev/data-center/mnt/10.11.0 > .30:_volumes_ovirt_engine/2f83ea82-e110-465d-a2a6-ac30534a9f6a/dom_md/ > leases:1048576 > for 3,11,4167 > 2015-05-12 19:23:26+0200 5057 [708]: s3 lockspace > 2f83ea82-e110-465d-a2a6-ac30534a9f6a:1:/rhev/data-center/mnt/10.11.0.3 > 0:_volumes_ovirt_engine/2f83ea82-e110-465d-a2a6-ac30534a9f6a/dom_md/id > s:0 > 2015-05-12 19:23:48+0200 5079 [702]: s3 host 1 2 5058 > 9f9fb274-9ae8-490e-bfba-72a743b0ebb2.hv01.sec.i > 2015-05-12 19:23:48+0200 5079 [702]: s3 host 250 1 0 > 9f9fb274-9ae8-490e-bfba-72a743b0ebb2.hv01.sec.i > 2015-05-12 19:24:53+0200 5144 [702]: cmd 9 target pid 4893 not found > 2015-05-12 19:25:14+0200 5165 [708]: r3 cmd_acquire 2,9,4893 invalid > lockspace found -1 failed 0 name 2f83ea82-e110-465d-a2a6-ac30534a9f6a > > -- > Daniel Helgenberger > m box bewegtbild GmbH > > P: +49/30/2408781-22 > F: +49/30/2408781-10 > > ACKERSTR. 19 > D-10115 BERLIN > > > www.m-box.de<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.m > -2Dbox.de&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=3rKe7gJAcRh5l-S9dbWM0T_M > bQbahl-YIetIBtIOxuo&m=vJx9-3POXYltD2YEW2fW50XHKsdm3Gvkd_piyvR7ubU&s=_1 > Z5ydGAROY0UwBcDL9Pc2PWpf2DLJxYwp5B6AV_M20&e= > > www.monkeymen.tv<https://urldefense.proofpoint.com/v2/url?u=http-3A__w > ww.monkeymen.tv&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=3rKe7gJAcRh5l-S9db > WM0T_MbQbahl-YIetIBtIOxuo&m=vJx9-3POXYltD2YEW2fW50XHKsdm3Gvkd_piyvR7ub > U&s=HsaNw9tst2q6vdxtHWMmXSNzuKAi-tqf0Tst3JJb9ck&e= > > > Gesch?ftsf?hrer: Martin Retschitzegger / Michaela G?llner > Handeslregister: Amtsgericht Charlottenburg / HRB 112767 > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ovirt.org_ma > ilman_listinfo_users&d=AwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=3rKe7gJAcRh5l > -S9dbWM0T_MbQbahl-YIetIBtIOxuo&m=vJx9-3POXYltD2YEW2fW50XHKsdm3Gvkd_piy > vR7ubU&s=qy3j1dASDjNv3QfyFirDEiNgyTqTDHR6lsngzMWtBUQ&e= > -- Didi

1 0

Why so long to add virtual HDD?
by Alan Murrell 18 May '15

18 May '15

Hello, I am wondering why it takes so long to provision a HDD for a VM? I typically do full provision (as opposed to "thin" provision) and while I have never sat there and timed it, it takes at least ten minutes to provision a 32GB HDD. I provisioned a 100GB HDD earlier today and even after 45 minutes it was not complete. I am from the VMware world where it takes less than a minute (usually more like 30 seconds or so) to provision a VM, regardless of HDD assigned. My host's physical HDD's are 2x2TB SATA drives in a hardware RAID1. oVirt storage is an NFS pool connecting to my host machine (for all intents and purposes, local storage) I wonder if I have things mis-configured? Is it normal for provisioning to take that long? Thanks! :-) -Alan

2 2