- Users - oVirt List Archives

Re: [ovirt-users] missing disk after storage domain expansion [SOLVED]
by Andrea Ghelardi 20 May '15

20 May '15

Thanks for all your information. I created a linux script as per details below. Attached to this email (some info purged) Gentlemen, we have a disk now! I'm marking the post as solved ... even though we do not know where the disk gone in these weeks yet. Probably unexpected vacation @Cuba? This disk won't reclaim expenses though I will create a test VM and perform some tests in the future with the expansion feature Thank you for all your support More cats: https://www.youtube.com/watch?v=cWKmorjUzF0 AG -----Original Message----- From: Juan Hernández [mailto:jhernand@redhat.com] Sent: Wednesday, May 20, 2015 10:37 AM To: Maor Lipchuk; Andrea Ghelardi Cc: users(a)ovirt.org Subject: Re: [ovirt-users] missing disk after storage domain expansion On 05/19/2015 06:23 PM, Maor Lipchuk wrote: > Hi Andrea, > > I'm using "postman" chrome-extension to execute my REST requests. > > For firefox the rest-client add-on you can use is > https://addons.mozilla.org/de/firefox/addon/restclient/ > > Juan, do we have a wiki for step by step instructions of REST > > Regards, > Maor > I'd suggest to try a command line client, as it is easier to share the results and check what is going wrong. You can use the "curl" command, for example. Assuming that you already know the identifiers of the storage domain and of the disk to register it should be something like this: ---8<--- #!/bin/sh -ex url="https://yourengine/ovirt-engine/api" user="your user" password="your password" storage_domain_id="the storage domain id" disk_id="the disk id" curl \ --verbose \ --insecure \ --user "${user}:${password}" \ --request POST \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data " <disk id=\"${disk_id}\"/> " \ "${url}/storagedomains/${storage_domain_id}/disks;unregistered" --->8--- > > ----- Original Message ----- >> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >> Cc: users(a)ovirt.org >> Sent: Tuesday, May 19, 2015 4:46:09 PM >> Subject: RE: [ovirt-users] missing disk after storage domain >> expansion >> >> I got an error but I'm not 100% sure I did everything correctly Error >> below: >> <html><head><title>JBoss Web/7.0.13.Final - Error >> report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot >> consume content type</h1><HR size="1" >> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> >> <u>Cannot consume content type</u></p><p><b>description</b> <u>The >> server refused this request because the request entity is in a format >> not supported by the requested resource for the requested method >> (Cannot consume content type).</u></p><HR size="1" >> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> >> >> Actions: >> Used RESTclient 2.3.0 for Firefox to POST this body <disk >> id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> >> >> I think I need a step by step guide about how to use the REST client >> to POST commands to ovirt service remotely >> >> Cheers >> AG >> >> -----Original Message----- >> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >> Sent: Monday, May 18, 2015 4:50 PM >> To: Andrea Ghelardi >> Subject: Re: [ovirt-users] missing disk after storage domain >> expansion >> >> I've went through the logs, though I didn't noticed any special >> information. >> Please let me know how the registration of the disk went. >> >> Regards, >> Maor >> >> >> >> ----- Original Message ----- >>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>> Sent: Monday, May 18, 2015 4:35:30 PM >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Here the full set of logs as promised. >>> >>> Unfortunately, I do not think I have vdsm logs pointing to that date >>> (logs rotated already). >>> I tried to search for >>> xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but >>> nothing found >>> >>> cheers >>> AG >>> >>> -----Original Message----- >>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>> Sent: Monday, May 18, 2015 3:30 PM >>> To: 'Maor Lipchuk' >>> Cc: 'users(a)ovirt.org' >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Maor, >>> >>> 1) disk creation: ok >>> 2) no free space at the moment of creation: this is very strange! >>> Are you sure? I assure you the disk was working, exported to VM >>> which formatted and wrote data on it >>> 3) no disk removal mention: this is the very issue I'm facing. In >>> fact disk disappeared with no notification, no logs, nothing. I'm >>> forwarding you full set of engine.log separately. If you need >>> vdsm.logs just tell me from which server you need it as I have >>> several cluster. >>> 4) I have not yet tried to register using the procedure you provided >>> me earlier. I'll try tomorrow. >>> >>> Thanks >>> AG >>> >>> >>> -----Original Message----- >>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>> Sent: Monday, May 18, 2015 1:15 PM >>> To: Andrea Ghelardi >>> Cc: users(a)ovirt.org >>> Subject: Re: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Andrea, >>> >>> I guessed I missed those logs, I found it now, thanks. >>> >>> I do see the disk creation in the log from 20150501, I can also see >>> that the Storage Domain hertz-dstore2 has 0 GB of free space at the >>> moment of >>> creation: >>> 2015-05-01 03:30:05,801 ERROR >>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirecto >>> r] >>> (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: >>> null, Custom Event ID: -1, Message: Critical, Low disk space. >>> hertz-dstore2 domain has 0 GB of free space >>> >>> though, I don't see any indication of the removed disks from the engine. >>> I have also noticed a gap from the first log which finished at >>> 2015-05-01 >>> 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. >>> >>> Did you try to register the disk as described in the wiki? >>> >>> Regards, >>> Maor >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>> Cc: users(a)ovirt.org >>>> Sent: Monday, May 18, 2015 12:10:55 PM >>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Maor, >>>> I already added logs in my previous email, did you received them? >>>> I'm sending them again, but only privately to you not to burden the >>>> mailing list (or let me know if you prefer otherwise). >>>> >>>> Cheers >>>> AG >>>> >>>> >>>> -----Original Message----- >>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>> Sent: Saturday, May 16, 2015 10:03 AM >>>> To: Andrea Ghelardi >>>> Cc: users(a)ovirt.org >>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Andrea, >>>> >>>> The OVF_STORE disks are disks which mainly being used internally in >>>> the engine to store VMs' and Templates' OVFs, you can disregard >>>> them for now. >>>> >>>> The behavior you mentioned, that suddenly the disk has disappeared >>>> from the setup, sounds very weird and I would like to investigate >>>> this a bit more. >>>> if you can please add the engine and vdsm logs, I can know what >>>> made the disk get removed from the setup, at the first place. >>>> Could it be that some one accessed the data base by any chance? >>>> >>>> Regarding the disk registration, basically it should not create any >>>> problems unless, if your disk was deleted manually form the DB, and >>>> there are still leftovers related to the disk in some of the tables. >>>> Once the disk is registered to the setup, you can try to attach it >>>> to the VM, and try to run it. >>>> >>>> >>>> Regards, >>>> Maor >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>>> Cc: users(a)ovirt.org >>>>> Sent: Friday, May 15, 2015 4:54:25 PM >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> After querying the hosted engine with the suggested command >>>>> https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 >>>>> 6- >>>>> 21 12-40a4-814f-24d74c760b2d/disks;unregistered >>>>> >>>>> Indeed shows a (unregistered?) disk >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> >>>>> <disk >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" >>>>> id="16736ce0-a9df-410f-9f29-3a28364cdd41"> >>>>> <actions> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" >>>>> rel="export"/> >>>>> </actions> >>>>> <name>hertz_disk5</name> >>>>> <description>disk for SYBASE installation, on SAN shared >>>>> storage</description> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" >>>>> rel="permissions"/> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" >>>>> rel="statistics"/> >>>>> <alias>hertz_disk5</alias> >>>>> <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> >>>>> <storage_domain >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" >>>>> id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> <storage_domains> >>>>> <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> </storage_domains> >>>>> <size>225485783040</size> >>>>> <provisioned_size>225485783040</provisioned_size> >>>>> <actual_size>225485783040</actual_size> >>>>> <status> >>>>> <state>ok</state> >>>>> </status> >>>>> <interface>ide</interface> >>>>> <format>raw</format> >>>>> <sparse>false</sparse> >>>>> <bootable>false</bootable> >>>>> <shareable>false</shareable> >>>>> <wipe_after_delete>false</wipe_after_delete> >>>>> <propagate_errors>false</propagate_errors> >>>>> </disk> >>>>> </disks> >>>>> >>>>> I'm waiting for any comments on the two OVF disk or any advice >>>>> before proceeding with the registering command (test in production >>>>> environment hmmmmm) >>>>> >>>>> Cheers >>>>> AG >>>>> >>>>> -----Original Message----- >>>>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>>>> Sent: Friday, May 15, 2015 12:30 PM >>>>> To: Maor Lipchuk >>>>> Cc: users(a)ovirt.org >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Thank you for your reply! >>>>> I'm unsure if the disk contained any snapshots. I do not think so. >>>>> Is the register action a safe one to do in production system? I >>>>> wouldn't mess any of my existing running servers. >>>>> >>>>> Here the relevant logs from the date >>>>> ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation >>>>> ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) >>>>> ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last >>>>> occurrence of the imageid >>>>> >>>>> Please note from >>>>> ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of >>>>> two disk OVF store (??) on the same storage domain >>>>> 7a48fe46-2112-40a4-814f-24d74c760b2d >>>>> right after the volume expansion >>>>> >>>>> In the instructions.txt what I did to enlarge the volume (and >>>>> lose the >>>>> disk) (the guides is informational only, I followed the steps on a >>>>> different >>>>> server) >>>>> >>>>> Here some cats to thank you in advance >>>>> https://www.youtube.com/watch?v=nfTY41-zC7Y >>>> >>>> >>>> lol :) >>>> Nice cats >>>> >>>>> AG >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>>> Sent: Wednesday, May 13, 2015 11:02 PM >>>>> To: Andrea Ghelardi >>>>> Cc: users(a)ovirt.org >>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Hi Andrea, >>>>> >>>>> First of all, the issue sounds quite severe, can u please attach >>>>> the engine logs so we can try to figure out how that happened. >>>>> second, does this disk contained any snapshots? >>>>> If not, can you try to register it back (see >>>>> http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre >>>>> gi >>>>> st >>>>> ered_disk) >>>>> >>>>> >>>>> Regards, >>>>> Maor >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>>> To: users(a)ovirt.org >>>>>> Sent: Monday, May 11, 2015 12:01:17 AM >>>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>>> expansion >>>>>> >>>>>> >>>>>> >>>>>> Ok, so, >>>>>> >>>>>> After _ a lot _ of unsuccessful approach, I finally connected to >>>>>> postegre DB directly. >>>>>> >>>>>> Browsing the tables I found “unregistered_ovf_of_entities” where >>>>>> there is a reference of the missing disk >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 >>>>>> >>>>>> @ovf:size:210 >>>>>> >>>>>> @ovf:actual_size:210 >>>>>> >>>>>> @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 >>>>>> >>>>>> @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- >>>>>> 45 >>>>>> 2d >>>>>> -8 >>>>>> 521-4ff0b004aef3 >>>>>> >>>>>> @ovf:format: >>>>>> http://www.vmware.com/specifications/vmdk.html#sparse >>>>>> >>>>>> @ovf:volume-format:RAW >>>>>> >>>>>> @ovf:volume-type:Preallocated >>>>>> >>>>>> @ovf:disk-interface:VirtIO >>>>>> >>>>>> @ovf:boot:false >>>>>> >>>>>> @ovf:disk-alias:hertz_disk5 >>>>>> >>>>>> @ovf:disk-description:disk for SYBASE installation, on SAN shared >>>>>> storage >>>>>> >>>>>> @ovf:wipe-after-delete:false >>>>>> >>>>>> >>>>>> >>>>>> However, I’ve been unable to find any other helpful details. >>>>>> >>>>>> I guess the disk is not recoverable at this point? >>>>>> >>>>>> Any guru who has a good ovirt DB kwnoledge willing to give me >>>>>> some advice? >>>>>> >>>>>> >>>>>> >>>>>> Thanks as usual >>>>>> >>>>>> AG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] >>>>>> Sent: Thursday, May 07, 2015 6:08 PM >>>>>> To: ' users(a)ovirt.org ' >>>>>> Subject: missing disk after storage domain expansion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi gentlemen, >>>>>> >>>>>> >>>>>> >>>>>> I recently found an error on 1 of my storages: it was complaining >>>>>> about no free space but the VM was running and disk operational. >>>>>> >>>>>> Since I needed to perform some maintenance on the VM, I shut it >>>>>> down and at restart VM couldn’t boot up properly. >>>>>> >>>>>> Checked VM via console and a disk was missing. Edited fstab >>>>>> (luckily this disk was not root but heck! It had a Sybase DB on >>>>>> it!) and restarted VM this time ok. >>>>>> >>>>>> >>>>>> >>>>>> Since the disk resides on the dstore with no space, I expanded >>>>>> the iSCSI LUN, then refreshed multipath on hosts, then resized >>>>>> PVs and now ovirt is showing the correct size (logs do not >>>>>> complain anymore on no free space). >>>>>> >>>>>> >>>>>> >>>>>> BUUUT >>>>>> >>>>>> >>>>>> >>>>>> Now disk is missing. It is not shown anymore on Disks tab nor >>>>>> anywhere else. >>>>>> >>>>>> Problem is that storage shows 214GB occupancy (size of the >>>>>> missing >>>>>> disk) so data is there but cannot find it anymore. >>>>>> >>>>>> >>>>>> >>>>>> Logs show original disk creation, errors from the lack of space, >>>>>> refresh of the storage size and then.... no more references on >>>>>> the disk. >>>>>> >>>>>> >>>>>> >>>>>> What can I do to find those missing ~210GBs? >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Andrea Ghelardi >>>>>> -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

1 0

Huge, unrotated /var/log/glusterfs/cli.log
by Ernest Beinrohr 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------050503090908010601040603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Does anyone else has these on their HVs? I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster. -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------050503090908010601040603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Does anyone else has these on their HVs?<br> <br> I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster.<br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" width="1" height="1"> </div> </body> </html> --------------050503090908010601040603--

2 1

Re: [ovirt-users] missing disk after storage domain expansion
by Andrea Ghelardi 20 May '15

20 May '15

I got an error but I'm not 100% sure I did everything correctly Error below: <html><head><title>JBoss Web/7.0.13.Final - Error report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot consume content type</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>Cannot consume content type</u></p><p><b>description</b> <u>The server refused this request because the request entity is in a format not supported by the requested resource for the requested method (Cannot consume content type).</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> Actions: Used RESTclient 2.3.0 for Firefox to POST this body <disk id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> I think I need a step by step guide about how to use the REST client to POST commands to ovirt service remotely Cheers AG -----Original Message----- From: Maor Lipchuk [mailto:mlipchuk@redhat.com] Sent: Monday, May 18, 2015 4:50 PM To: Andrea Ghelardi Subject: Re: [ovirt-users] missing disk after storage domain expansion I've went through the logs, though I didn't noticed any special information. Please let me know how the registration of the disk went. Regards, Maor ----- Original Message ----- > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > Sent: Monday, May 18, 2015 4:35:30 PM > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Here the full set of logs as promised. > > Unfortunately, I do not think I have vdsm logs pointing to that date > (logs rotated already). > I tried to search for > xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but > nothing found > > cheers > AG > > -----Original Message----- > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > Sent: Monday, May 18, 2015 3:30 PM > To: 'Maor Lipchuk' > Cc: 'users(a)ovirt.org' > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Hi Maor, > > 1) disk creation: ok > 2) no free space at the moment of creation: this is very strange! Are > you sure? I assure you the disk was working, exported to VM which > formatted and wrote data on it > 3) no disk removal mention: this is the very issue I'm facing. In fact > disk disappeared with no notification, no logs, nothing. I'm > forwarding you full set of engine.log separately. If you need > vdsm.logs just tell me from which server you need it as I have several > cluster. > 4) I have not yet tried to register using the procedure you provided > me earlier. I'll try tomorrow. > > Thanks > AG > > > -----Original Message----- > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > Sent: Monday, May 18, 2015 1:15 PM > To: Andrea Ghelardi > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] missing disk after storage domain expansion > > Hi Andrea, > > I guessed I missed those logs, I found it now, thanks. > > I do see the disk creation in the log from 20150501, I can also see > that the Storage Domain hertz-dstore2 has 0 GB of free space at the > moment of > creation: > 2015-05-01 03:30:05,801 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: > null, Custom Event ID: -1, Message: Critical, Low disk space. > hertz-dstore2 domain has 0 GB of free space > > though, I don't see any indication of the removed disks from the engine. > I have also noticed a gap from the first log which finished at > 2015-05-01 > 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. > > Did you try to register the disk as described in the wiki? > > Regards, > Maor > > > > > ----- Original Message ----- > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > Cc: users(a)ovirt.org > > Sent: Monday, May 18, 2015 12:10:55 PM > > Subject: RE: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Maor, > > I already added logs in my previous email, did you received them? > > I'm sending them again, but only privately to you not to burden the > > mailing list (or let me know if you prefer otherwise). > > > > Cheers > > AG > > > > > > -----Original Message----- > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > Sent: Saturday, May 16, 2015 10:03 AM > > To: Andrea Ghelardi > > Cc: users(a)ovirt.org > > Subject: Re: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Andrea, > > > > The OVF_STORE disks are disks which mainly being used internally in > > the engine to store VMs' and Templates' OVFs, you can disregard them > > for now. > > > > The behavior you mentioned, that suddenly the disk has disappeared > > from the setup, sounds very weird and I would like to investigate > > this a bit more. > > if you can please add the engine and vdsm logs, I can know what made > > the disk get removed from the setup, at the first place. > > Could it be that some one accessed the data base by any chance? > > > > Regarding the disk registration, basically it should not create any > > problems unless, if your disk was deleted manually form the DB, and > > there are still leftovers related to the disk in some of the tables. > > Once the disk is registered to the setup, you can try to attach it > > to the VM, and try to run it. > > > > > > Regards, > > Maor > > > > > > > > ----- Original Message ----- > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > Cc: users(a)ovirt.org > > > Sent: Friday, May 15, 2015 4:54:25 PM > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > After querying the hosted engine with the suggested command > > > https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 > > > 6- > > > 21 12-40a4-814f-24d74c760b2d/disks;unregistered > > > > > > Indeed shows a (unregistered?) disk > > > > > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> > > > <disk > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" > > > id="16736ce0-a9df-410f-9f29-3a28364cdd41"> > > > <actions> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" > > > rel="export"/> > > > </actions> > > > <name>hertz_disk5</name> > > > <description>disk for SYBASE installation, on SAN shared > > > storage</description> <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" > > > rel="permissions"/> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" > > > rel="statistics"/> > > > <alias>hertz_disk5</alias> > > > <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> > > > <storage_domain > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" > > > id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > <storage_domains> > > > <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > </storage_domains> > > > <size>225485783040</size> > > > <provisioned_size>225485783040</provisioned_size> > > > <actual_size>225485783040</actual_size> > > > <status> > > > <state>ok</state> > > > </status> > > > <interface>ide</interface> > > > <format>raw</format> > > > <sparse>false</sparse> > > > <bootable>false</bootable> > > > <shareable>false</shareable> > > > <wipe_after_delete>false</wipe_after_delete> > > > <propagate_errors>false</propagate_errors> > > > </disk> > > > </disks> > > > > > > I'm waiting for any comments on the two OVF disk or any advice > > > before proceeding with the registering command (test in production > > > environment hmmmmm) > > > > > > Cheers > > > AG > > > > > > -----Original Message----- > > > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > > > Sent: Friday, May 15, 2015 12:30 PM > > > To: Maor Lipchuk > > > Cc: users(a)ovirt.org > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Thank you for your reply! > > > I'm unsure if the disk contained any snapshots. I do not think so. > > > Is the register action a safe one to do in production system? I > > > wouldn't mess any of my existing running servers. > > > > > > Here the relevant logs from the date > > > ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation > > > ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) > > > ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last > > > occurrence of the imageid > > > > > > Please note from > > > ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of > > > two disk OVF store (??) on the same storage domain > > > 7a48fe46-2112-40a4-814f-24d74c760b2d > > > right after the volume expansion > > > > > > In the instructions.txt what I did to enlarge the volume (and > > > lose the > > > disk) (the guides is informational only, I followed the steps on a > > > different > > > server) > > > > > > Here some cats to thank you in advance > > > https://www.youtube.com/watch?v=nfTY41-zC7Y > > > > > > lol :) > > Nice cats > > > > > AG > > > > > > > > > -----Original Message----- > > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > > Sent: Wednesday, May 13, 2015 11:02 PM > > > To: Andrea Ghelardi > > > Cc: users(a)ovirt.org > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Hi Andrea, > > > > > > First of all, the issue sounds quite severe, can u please attach > > > the engine logs so we can try to figure out how that happened. > > > second, does this disk contained any snapshots? > > > If not, can you try to register it back (see > > > http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre > > > gi > > > st > > > ered_disk) > > > > > > > > > Regards, > > > Maor > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > > To: users(a)ovirt.org > > > > Sent: Monday, May 11, 2015 12:01:17 AM > > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > > expansion > > > > > > > > > > > > > > > > Ok, so, > > > > > > > > After _ a lot _ of unsuccessful approach, I finally connected to > > > > postegre DB directly. > > > > > > > > Browsing the tables I found “unregistered_ovf_of_entities” where > > > > there is a reference of the missing disk > > > > > > > > > > > > > > > > > > > > > > > > @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 > > > > > > > > @ovf:size:210 > > > > > > > > @ovf:actual_size:210 > > > > > > > > @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 > > > > > > > > @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- > > > > 45 > > > > 2d > > > > -8 > > > > 521-4ff0b004aef3 > > > > > > > > @ovf:format: > > > > http://www.vmware.com/specifications/vmdk.html#sparse > > > > > > > > @ovf:volume-format:RAW > > > > > > > > @ovf:volume-type:Preallocated > > > > > > > > @ovf:disk-interface:VirtIO > > > > > > > > @ovf:boot:false > > > > > > > > @ovf:disk-alias:hertz_disk5 > > > > > > > > @ovf:disk-description:disk for SYBASE installation, on SAN > > > > shared storage > > > > > > > > @ovf:wipe-after-delete:false > > > > > > > > > > > > > > > > However, I’ve been unable to find any other helpful details. > > > > > > > > I guess the disk is not recoverable at this point? > > > > > > > > Any guru who has a good ovirt DB kwnoledge willing to give me > > > > some advice? > > > > > > > > > > > > > > > > Thanks as usual > > > > > > > > AG > > > > > > > > > > > > > > > > > > > > From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] > > > > Sent: Thursday, May 07, 2015 6:08 PM > > > > To: ' users(a)ovirt.org ' > > > > Subject: missing disk after storage domain expansion > > > > > > > > > > > > > > > > > > > > Hi gentlemen, > > > > > > > > > > > > > > > > I recently found an error on 1 of my storages: it was > > > > complaining about no free space but the VM was running and disk > > > > operational. > > > > > > > > Since I needed to perform some maintenance on the VM, I shut it > > > > down and at restart VM couldn’t boot up properly. > > > > > > > > Checked VM via console and a disk was missing. Edited fstab > > > > (luckily this disk was not root but heck! It had a Sybase DB on > > > > it!) and restarted VM this time ok. > > > > > > > > > > > > > > > > Since the disk resides on the dstore with no space, I expanded > > > > the iSCSI LUN, then refreshed multipath on hosts, then resized > > > > PVs and now ovirt is showing the correct size (logs do not > > > > complain anymore on no free space). > > > > > > > > > > > > > > > > BUUUT > > > > > > > > > > > > > > > > Now disk is missing. It is not shown anymore on Disks tab nor > > > > anywhere else. > > > > > > > > Problem is that storage shows 214GB occupancy (size of the > > > > missing > > > > disk) so data is there but cannot find it anymore. > > > > > > > > > > > > > > > > Logs show original disk creation, errors from the lack of space, > > > > refresh of the storage size and then.... no more references on > > > > the disk. > > > > > > > > > > > > > > > > What can I do to find those missing ~210GBs? > > > > > > > > > > > > > > > > Cheers > > > > > > > > Andrea Ghelardi > > > > > > > > > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > >

3 2

Gluster and Export Storage
by ml＠ohnewald.net 20 May '15

20 May '15

Hello List, i have a GlusterFS Data (Master) Storage and a NFS Export Storage. Now my NFS Export Storage is broken. Does this also put my GlusterFS Data Storage into Unknown status? I think my GlusterFS Storage is totally fine, but it wont come up. :-( ° No Split Brain ° Peers are there ° everything is online Its related to this: http://lists.ovirt.org/pipermail/users/2015-May/032889.html It would be cool to get my GlusterFS Up and Running again in order to migrate the vms onto one host and then reboot my empty one. Here is some more gluster info: http://fpaste.org/223283/03230114/ Any ideas? Does the NFS Export Problem really block my GlusterData Domain?! Thanks, Mario

2 1

Half Upgraded ovirt packages - to 3.5.2.1
by Soeren Malchow 20 May '15

20 May '15

--_000_826AB8E6591441BFAAE82DEB951200D3mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgZ290IGEgcGFydGlhbGx5IHVwZ3JhZGVkIGhvc3RlZCBlbmdpbmUsIHNv bWUgb2YgdGhlIHBhY2thZ2VzIGFyZSB1cGdyYWRlZCB0byAzLjUuMi4xIGFuZCBzb21lIGFyZSBu b3QsIGkgY2FuIG5vdCBldmVuIHVwZ3JhZGUgYWZ0ZXJ3YXJkcw0KDQpQYWNrYWdlIGxpc3Q6DQoN Cm92aXJ0LWVuZ2luZS1zZGstcHl0aG9uLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdp bmUtbGliLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2luLW92 aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYnNvY2tldC1w cm94eS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtaW1hZ2UtdXBsb2FkZXItMy41LjEtMS5l bDYubm9hcmNoDQpvdmlydC1lbmdpbmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0DQpvdmly dC1ob3N0LWRlcGxveS1qYXZhLTEuMy4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTMuNS4x LjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3Zp cnQtaG9zdC1kZXBsb3ktMS4zLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtYmFz ZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2Nr ZXQtcHJveHktMy41LjIuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LXJlbGVhc2UzNS0wMDQtMS5ub2Fy Y2gNCm92aXJ0LWVuZ2luZS1jbGktMy41LjAuNS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1i YWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtdXNlcnBvcnRhbC0zLjUu MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWRic2NyaXB0cy0zLjUuMS4xLTEuZWw2Lm5v YXJjaA0Kb3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1pc28t dXBsb2FkZXItMy41LjItMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtcmVwb3J0cy1zZXR1cC0z LjUuMi0wLjMuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2 Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1l bmdpbmUtZXh0ZW5zaW9ucy1hcGktaW1wbC0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5n aW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoDQpvdmlydC1ndWVzdC10b29scy0zLjUuMC0w LjUubWFzdGVyLm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWV4dGVuc2lvbi1hYWEtbGRhcC0xLjAuMi0x LmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1v bi0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYmFkbWluLXBvcnRhbC0zLjUu MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXJlc3RhcGktMy41LjEuMS0xLmVsNi5ub2Fy Y2gNCm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJjaA0KDQpJZiBpIHF1ZXJ5 IHRoZSByZXBvIHdpdGggInJlcG9xdWVyeSAtLXNob3ctZHVwZXMgb3ZpcnQtZW5naW5l4oCdIGkg Z2V0IGEgY29tcGxldGUgbGlzdCBpbmNsdWRpbmcgdGhlIDMuNS4yLjEgcGFja2FnZXMgYnV0IHdp dGggeXVtIGkgZ2V0IG5vdGhpbmcNCg0Kb3ZpcnQtZW5naW5lLTA6My41LjAuMS0xLmVsNi5ub2Fy Y2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTA6My41 LjEuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4yLTEuZWw2Lm5vYXJjaA0Kb3Zp cnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2gNCg0KVW5mb3J0dW5hdGVseSBpIGhhdmUg bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0Lg0KDQpEb2Vz IGFueWJvZHkgaGF2ZSBhbiBpZGVhID8NCg0KUmVnYXJkcw0KU29lcmVuDQoNCg== --_000_826AB8E6591441BFAAE82DEB951200D3mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <AFA5AB1434BE0E4F8A5E360150369FCE(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBnb3QgYSBwYXJ0 aWFsbHkgdXBncmFkZWQgaG9zdGVkIGVuZ2luZSwgc29tZSBvZiB0aGUgcGFja2FnZXMgYXJlIHVw Z3JhZGVkIHRvIDMuNS4yLjEgYW5kIHNvbWUgYXJlIG5vdCwgaSBjYW4gbm90IGV2ZW4gdXBncmFk ZSBhZnRlcndhcmRzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYWNrYWdlIGxpc3Q6 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNkay1w eXRob24tMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLWxpYi0z LjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2lu LW92aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp bmUtd2Vic29ja2V0LXByb3h5LTMuNS4yLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0 LWltYWdlLXVwbG9hZGVyLTMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp bmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0PC9kaXY+DQo8ZGl2Pm92aXJ0LWhvc3QtZGVw bG95LWphdmEtMS4zLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS0zLjUu MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2 Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1ob3N0LWRlcGxveS0xLjMuMS0xLmVsNi5ub2FyY2g8 L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLWJhc2UtMy41LjIuMS0xLmVsNi5ub2FyY2g8 L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2NrZXQtcHJveHktMy41 LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtcmVsZWFzZTM1LTAwNC0xLm5vYXJj aDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtY2xpLTMuNS4wLjUtMS5lbDYubm9hcmNoPC9kaXY+ DQo8ZGl2Pm92aXJ0LWVuZ2luZS1iYWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8 ZGl2Pm92aXJ0LWVuZ2luZS11c2VycG9ydGFsLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8 ZGl2Pm92aXJ0LWVuZ2luZS1kYnNjcmlwdHMtMy41LjEuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxk aXY+b3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92 aXJ0LWlzby11cGxvYWRlci0zLjUuMi0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5n aW5lLXJlcG9ydHMtc2V0dXAtMy41LjItMC4zLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQt ZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1l bmdpbmUtc2V0dXAtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5l LWV4dGVuc2lvbnMtYXBpLWltcGwtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3Zp cnQtZW5naW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1 ZXN0LXRvb2xzLTMuNS4wLTAuNS5tYXN0ZXIubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2lu ZS1leHRlbnNpb24tYWFhLWxkYXAtMS4wLjItMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0 LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1vbi0zLjUuMi4xLTEuZWw2Lm5v YXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtd2ViYWRtaW4tcG9ydGFsLTMuNS4xLjEtMS5l bDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS1yZXN0YXBpLTMuNS4xLjEtMS5lbDYu bm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJj aDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBpIHF1ZXJ5IHRoZSBy ZXBvIHdpdGggJnF1b3Q7cmVwb3F1ZXJ5IC0tc2hvdy1kdXBlcyBvdmlydC1lbmdpbmXigJ0gaSBn ZXQgYSBjb21wbGV0ZSBsaXN0IGluY2x1ZGluZyB0aGUgMy41LjIuMSBwYWNrYWdlcyBidXQgd2l0 aCB5dW0gaSBnZXQgbm90aGluZzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pm92aXJ0LWVuZ2luZS0wOjMuNS4wLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVu Z2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUu MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUuMi0xLmVsNi5u b2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2g8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VW5mb3J0dW5hdGVseSBpIGhhdmUg bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0LiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9lcyBhbnlib2R5IGhhdmUgYW4gaWRlYSA/ PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJl biZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VU TE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_826AB8E6591441BFAAE82DEB951200D3mconnet_--

3 3

Re: [ovirt-users] Backup through export and clone
by Soeren Malchow 20 May '15

20 May '15

--_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRo ZSBsb2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRv bWFpbiwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQN Cg0KRnJvbTogPHVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnPG1haWx0bzp1c2Vycy1ib3VuY2VzQG92 aXJ0Lm9yZz4+IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdw0KRGF0ZTogV2VkbmVzZGF5IDIw IE1heSAyMDE1IDAwOjE5DQpUbzogInVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnNAb3ZpcnQu b3JnPiINClN1YmplY3Q6IFtvdmlydC11c2Vyc10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBj bG9uZQ0KDQpEZWFyIGFsbCwNCg0KSSBhbSBubyBweXRob24gZGV2ZWxvcGVyIChiYXNpY2FsbHkg bm8gZGV2ZWxvcGVyIGF0IGFsbCkgYnV0IGkgc3RydWdnbGVkIHdpdGggdGhlIGJhY2t1cCBmb3Ig YSB3aGlsZSBidXQgZmluYWxseSBpIGhhdmUgYSBzY3JpcHQgYWxtb3N0IE9LIGZvciB0aGUgYmFj a3VwLg0KDQpEdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGUg4oCcc25hcHNob3QgLT4gZXhwb3J04oCd IGZlYXR1cmUgaXMgY29taW5nIGFzIGl0IHNlZW1zIGluIDMuNiB3ZSBzdGlsbCBuZWVkIHRvIGNs b25lIGFuZCB0aGVuIGV4cG9ydC4NCg0KVGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFj a3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1 dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNr dXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFn ZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKA nSB0byBhIHNlcGFyYXRlIGludGVybWVkaWF0ZSBzdG9yYWdlIGFscmVhZHksIGNhbiBhbnlib2R5 IGhlbHAgbWUgd2l0aCB0aGF0ID8gKHNvbWV3aGVyZSBhcm91bmQgbGluZSA3MCkNClRoZSBjbG9u aW5nIGNhbiBob3BlZnVsbHkgZ28gYXdheSBpbiBTZXB0ZW1iZXIgd2l0aCAzLjYgYnV0IHVudGls IHRoZW4gd2Ugc3RpbGwgbmVlZCB0aGF0Lg0KDQpBbnkgb3RoZXIgaW1wcm92ZW1lbnRzIGFyZSBt b3JlIHRoYW4gd2VsY29tZSDigJMgcGxlYXNlIGtlZXAgaW4gbWluZCBpIGFtIG5vdCBhIGRldmVs b3BlciBhbmQgSSBvbmx5IHRyaWVkIG15IHZlcnkgYmVzdCB0byB3cml0ZSBhIGRlY2VudCBzY3Jp cHQuDQoNCkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJlIHdl IGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/DQoNCkkgYW0gcHJldHR5IHN1cmUg dGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBwZXJzb24gb3V0IHRoZXJlIGxvb2tpbmcgZm9yIHNvbWV0 aGluZyBsaWtlIHRoYXQgKGF0IGxlYXN0IGkgaG9wZSA6LSkgKQ0KDQpSZWdhcmRzDQpTb2VyZW4N Cg0K --_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <FD072BC5D8B01A458711015AE4BE1137(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+T25l IHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRoZSBs b2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRvbWFp biwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQmbmJz cDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEy cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyI+dXNlcnMtYm91bmNlc0BvdmlydC5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3c8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAyMCBNYXkgMjAxNSAwMDoxOTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT4mcXVvdDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltvdmlydC11c2Vy c10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBjbG9uZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVsb3Bl ciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUgYnV0 IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZSDigJxzbmFw c2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21pbmcgYXMgaXQgc2VlbXMgaW4gMy42 IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhwb3J0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFja3VwcyBvZiAz IFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1dGUgc2VydmVy IHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNrdXBzIG9mIDMg Vk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFnZSBzZXJ2ZXJz LCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKAnQ0KIHRvIGEg c2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFkeSwgY2FuIGFueWJvZHkgaGVscCBt ZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5lIDcwKTwvZGl2Pg0KPGRpdj5UaGUg Y2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1 bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lIOKAkyBwbGVh c2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVyIGFuZCBJIG9ubHkgdHJpZWQgbXkg dmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJl IHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgcGVy c29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSB0aGF0IChhdCBsZWFzdCBp IGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4N CjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_--

1 0

Backup through export and clone
by Soeren Malchow 20 May '15

20 May '15

--_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: multipart/alternative; boundary="_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_" --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVs b3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUg YnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC4NCg0K RHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIOKAnHNuYXBzaG90IC0+IGV4cG9ydOKAnSBmZWF0dXJl IGlzIGNvbWluZyBhcyBpdCBzZWVtcyBpbiAzLjYgd2Ugc3RpbGwgbmVlZCB0byBjbG9uZSBhbmQg dGhlbiBleHBvcnQuDQoNClRoaXMgc2NyaXB0IGlzIHRocmVhZGVkIHRvIGRvIGJhY2t1cHMgb2Yg MyBWbXMgY29uY3VycmVudGx5LCBob3dldmVyLCBpbiBvdXIgc2V0dXAgKCBjb21wdXRlIHNlcnZl ciB3aXRoIDMgc2VwYXJhdGUgZ2x1c3RlciBtYWNoaW5lcykgcGFyYWxsZWwgYmFja3VwcyBvZiAz IFZNUyBjcmVhdGUgdmVyeSBoZWF2eSBsb2FkIG9uIHRoZSBnbHVzdGVyIHN0b3JhZ2Ugc2VydmVy cywgYW5kIGkgd291bGQgbGlrZSB0byBkbyB0aGUg4oCcY2xvbmUgc25hcHNob3TigJ0gdG8gYSBz ZXBhcmF0ZSBpbnRlcm1lZGlhdGUgc3RvcmFnZSBhbHJlYWR5LCBjYW4gYW55Ym9keSBoZWxwIG1l IHdpdGggdGhhdCA/IChzb21ld2hlcmUgYXJvdW5kIGxpbmUgNzApDQpUaGUgY2xvbmluZyBjYW4g aG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdl IHN0aWxsIG5lZWQgdGhhdC4NCg0KQW55IG90aGVyIGltcHJvdmVtZW50cyBhcmUgbW9yZSB0aGFu IHdlbGNvbWUg4oCTIHBsZWFzZSBrZWVwIGluIG1pbmQgaSBhbSBub3QgYSBkZXZlbG9wZXIgYW5k IEkgb25seSB0cmllZCBteSB2ZXJ5IGJlc3QgdG8gd3JpdGUgYSBkZWNlbnQgc2NyaXB0Lg0KDQpB bHNvOiBkbyB3ZSBoYXZlIGEgcGxhY2UgKGdpdCByZXBvIG9yIHNvKSB3aGVyZSB3ZSBjYW4gcHV0 IHRoaXMgc2NyaXB0IGZvciBldmVyeWJvZHkgPw0KDQpJIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlz IG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlr ZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICkNCg0KUmVnYXJkcw0KU29lcmVuDQoNCg== --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <B23104407061FD47B920E44171210E96(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAo YmFzaWNhbGx5IG5vIGRldmVsb3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBi YWNrdXAgZm9yIGEgd2hpbGUgYnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBm b3IgdGhlIGJhY2t1cC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUg ZmFjdCB0aGF0IHRoZSDigJxzbmFwc2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21p bmcgYXMgaXQgc2VlbXMgaW4gMy42IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhw b3J0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFk ZWQgdG8gZG8gYmFja3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBz ZXR1cCAoIGNvbXB1dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBw YXJhbGxlbCBiYWNrdXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGds dXN0ZXIgc3RvcmFnZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9u ZSBzbmFwc2hvdOKAnQ0KIHRvIGEgc2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFk eSwgY2FuIGFueWJvZHkgaGVscCBtZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5l IDcwKTwvZGl2Pg0KPGRpdj5UaGUgY2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2Vw dGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUg dGhhbiB3ZWxjb21lIOKAkyBwbGVhc2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVy IGFuZCBJIG9ubHkgdHJpZWQgbXkgdmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAo Z2l0IHJlcG8gb3Igc28pIHdoZXJlIHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9k eSA/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJl IGlzIG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcg bGlrZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_-- --_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/x-python-script; name="backup-queue.py" Content-Description: backup-queue.py Content-Disposition: attachment; filename="backup-queue.py"; size=5249; creation-date="Tue, 19 May 2015 22:19:10 GMT"; modification-date="Tue, 19 May 2015 22:19:10 GMT" Content-ID: <786F63264519A449B193A37F1DC80C77(a)liquidcampaign.com> Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9weXRob24KCmltcG9ydCBRdWV1ZQppbXBvcnQgdGhyZWFkaW5nCmltcG9ydCB0 aW1lCmZyb20gb3ZpcnRzZGsuYXBpIGltcG9ydCBBUEkKZnJvbSBvdmlydHNkay54bWwgaW1wb3J0 IHBhcmFtcwppbXBvcnQgc3lzCmltcG9ydCBkYXRldGltZQppbXBvcnQgc210cGxpYgpmcm9tIGVt YWlsLm1pbWUudGV4dCBpbXBvcnQgTUlNRVRleHQKCgpnbG9iYWwgU05BUFNIT1RfTkFNRQoKVkVS U0lPTiAgICAgICAgICAgICA9IHBhcmFtcy5WZXJzaW9uKG1ham9yPSczJywgbWlub3I9JzAnKQpF TkdJTkVfU0VSVkVSICAgICAgID0gJycKRU5HSU5FX1VTRVIgICAgICAgICA9ICdhZG1pbkBpbnRl cm5hbCcKRU5HSU5FX1BBU1NXT1JEICAgICA9ICcnCkVOR0lORV9DRVJUICAgICAgICAgPSAnJwpO T1cgICAgICAgICAgICAgICAgID0gZGF0ZXRpbWUuZGF0ZXRpbWUubm93KCkKU05BUFNIT1RfTkFN RSAgICAgICA9ICdCQUNLVVBfJyArIE5PVy5zdHJmdGltZSgiJVktJW0tJWQtJUglTSIpCkRBWV9P Rl9XRUVLICAgICAgICAgPSBOT1cuc3RyZnRpbWUoIiV3IikKQkFDS1VQICAgICAgICAgICAgICA9 ICJGVUxMIgoKZXhpdEZsYWcgPSAwCgpjbGFzcyBteVRocmVhZCAodGhyZWFkaW5nLlRocmVhZCk6 CiAgICBkZWYgX19pbml0X18oc2VsZiwgdGhyZWFkSUQsIG5hbWUsIHEpOgogICAgICAgIHRocmVh ZGluZy5UaHJlYWQuX19pbml0X18oc2VsZikKICAgICAgICBzZWxmLnRocmVhZElEID0gdGhyZWFk SUQKICAgICAgICBzZWxmLm5hbWUgPSBuYW1lCiAgICAgICAgc2VsZi5xID0gcQogICAgICAgIHNl bGYuYXBpID0gYXBpCiAgICAgICAgZ2xvYmFsIG1lc3NhZ2UKICAgIGRlZiBydW4oc2VsZik6CiAg ICAgICAgcHJpbnQgIlN0YXJ0aW5nICIgKyBzZWxmLm5hbWUKICAgICAgICBwcm9jZXNzX2RhdGEo c2VsZi5uYW1lLCBzZWxmLnEpCiAgICAgICAgcHJpbnQgIkV4aXRpbmcgIiArIHNlbGYubmFtZQoK ZGVmIHByb2Nlc3NfZGF0YSh0aHJlYWROYW1lLCBxKToKICAgIHdoaWxlIG5vdCBleGl0RmxhZzoK ICAgICAgICBxdWV1ZUxvY2suYWNxdWlyZSgpCiAgICAgICAgaWYgbm90IHdvcmtRdWV1ZS5lbXB0 eSgpOgogICAgICAgICAgICBkYXRhID0gcS5nZXQoKQogICAgICAgICAgICBxdWV1ZUxvY2sucmVs ZWFzZSgpCiAgICAgICAgICAgIHByaW50ICIlcyBwcm9jZXNzaW5nICVzIiAlICh0aHJlYWROYW1l LCBkYXRhLm5hbWUpCiAgICAgICAgICAgIHZtID0gYXBpLnZtcy5nZXQobmFtZT1kYXRhLm5hbWUp CiAgICAgICAgICAgIHZtbmFtZSA9IGRhdGEubmFtZSArIl8iCiAgICAgICAgICAgIG5ld3ZtbmFt ZSA9IHZtbmFtZSArIFNOQVBTSE9UX05BTUUKICAgICAgICAgICAgY2x1c3RlciA9IGFwaS5jbHVz dGVycy5nZXQoaWQ9dm0uY2x1c3Rlci5pZCkKICAgICAgICAgICAgZGMgPSBhcGkuZGF0YWNlbnRl cnMuZ2V0KGlkPWNsdXN0ZXIuZGF0YV9jZW50ZXIuaWQpCiAgICAgICAgICAgIGV4cG9ydCA9IE5v bmUKICAgICAgICAgICAgZm9yIHNkIGluIGRjLnN0b3JhZ2Vkb21haW5zLmxpc3QoKToKICAgICAg ICAgICAgICAgIGlmIHNkLnR5cGVfID09ICJleHBvcnQiOgogICAgICAgICAgICAgICAgICAgIGV4 cG9ydCA9IHNkCiAgICAgICAgICAgIGlmIG5vdCBleHBvcnQ6CiAgICAgICAgICAgICAgICBwcmlu dCgiRXhwb3J0IGRvbWFpbiByZXF1aXJlZCwgYW5kIG5vbmUgZm91bmQsIGV4aXR0aW5nLi4uXG4i KQogICAgICAgICAgICAgICAgc3lzLmV4aXQoMSkKCiAgICAgICAgICAgIGlmIHZtLm5hbWUgIT0g Ikhvc3RlZEVuZ2luZSI6CiAgICAgICAgICAgICAgICB2bS5zbmFwc2hvdHMuYWRkKHBhcmFtcy5T bmFwc2hvdChkZXNjcmlwdGlvbj1TTkFQU0hPVF9OQU1FLCB2bT12bSApKQogICAgICAgICAgICAg ICAgc25hcCA9IHZtLnNuYXBzaG90cy5saXN0KGRlc2NyaXB0aW9uPVNOQVBTSE9UX05BTUUpWzBd CiAgICAgICAgICAgICAgICB3aGlsZSB2bS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXAuaWQpLnNuYXBz aG90X3N0YXR1cyA9PSAibG9ja2VkIjoKICAgICAgICAgICAgICAgICAgICBwcmludCgiJXMgV2Fp dGluZyBmb3Igc25hcHNob3Qgb2YgJXMgdG8gZmluaXNoIikgJSAodGhyZWFkTmFtZSwgdm0ubmFt ZSkKICAgICAgICAgICAgICAgICAgICB0aW1lLnNsZWVwKDEwKQogICAgICAgICAgICAgICAgcHJp bnQoIiVzIFNuYXBzaG90dGluZyAlcyBpcyBkb25lIikgJSAodGhyZWFkTmFtZSx2bS5uYW1lKQog ICAgICAgICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgIHNuYXBzaG90cyA9IHBhcmFt cy5TbmFwc2hvdHMoc25hcHNob3Q9W3BhcmFtcy5TbmFwc2hvdChpZD1zbmFwLmlkKV0pCiAgICAg ICAgICAgICAgICAgICAgYXBpLnZtcy5hZGQocGFyYW1zLlZNKG5hbWU9bmV3dm1uYW1lLCBzbmFw c2hvdHM9c25hcHNob3RzLCBjbHVzdGVyPWNsdXN0ZXIsIHRlbXBsYXRlPWFwaS50ZW1wbGF0ZXMu Z2V0KG5hbWU9IkJsYW5rIikpKQogICAgICAgICAgICAgICAgICAgIHdoaWxlIGFwaS52bXMuZ2V0 KG5hbWU9bmV3dm1uYW1lKS5zdGF0dXMuc3RhdGUgPT0gImltYWdlX2xvY2tlZCI6CiAgICAgICAg ICAgICAgICAgICAgICAgIHByaW50KCIlcyBXYWl0aW5nIGZvciBjbG9uZSBvZiAlcyB0byBmaW5p c2giKSAlICh0aHJlYWROYW1lLCB2bS5uYW1lKQogICAgICAgICAgICAgICAgICAgICAgICB0aW1l LnNsZWVwKDYwKQogICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBDbG9uaW5nIG9mICVzICBk b25lIikgJSAodGhyZWFkTmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1z LmdldChuYW1lPW5ld3ZtbmFtZSkuZXhwb3J0KHBhcmFtcy5BY3Rpb24oc3RvcmFnZV9kb21haW49 ZXhwb3J0KSkKICAgICAgICAgICAgICAgICAgICB3aGlsZSBhcGkudm1zLmdldChuYW1lPW5ld3Zt bmFtZSkuc3RhdHVzLnN0YXRlID09ICJpbWFnZV9sb2NrZWQiOgogICAgICAgICAgICAgICAgICAg ICAgICBwcmludCgiJXMgV2FpdGluZyBmb3IgZXhwb3J0IG9mICVzIGZpbmlzaCIpICUgKHRocmVh ZE5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoNjApCiAg ICAgICAgICAgICAgICAgICAgcHJpbnQoIiVzIEV4cG9ydGluZyAlcyBkb25lIikgJSAodGhyZWFk TmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1zLmdldChuYW1lPW5ld3Zt bmFtZSkuZGVsZXRlKCkKICAgICAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRpb24gYXMgZToKICAg ICAgICAgICAgICAgICAgICBwcmludCAoIlNvbWV0aGluZyB3ZW50IHdyb25nIHdpdGggdGhlIGNv bGluZyBvciBleHBvcnRpbmdcbiVzIikgJSBzdHIoZSkKICAgICAgICAgICAgICAgIHNuYXBzaG90 bGlzdCA9IHZtLnNuYXBzaG90cy5saXN0KCkKICAgICAgICAgICAgICAgIGZvciBzbmFwc2hvdCBp biBzbmFwc2hvdGxpc3Q6CiAgICAgICAgICAgICAgICAgICAgaWYgc25hcHNob3QuZGVzY3JpcHRp b24gIT0gIkFjdGl2ZSBWTSI6CiAgICAgICAgICAgICAgICAgICAgICAgIHNuYXBzaG90LmRlbGV0 ZSgpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoMykKICAgICAgICAgICAgICAg ICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpbGUgYXBpLnZtcy5n ZXQobmFtZT12bS5uYW1lKS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXBzaG90LmlkKS5zbmFwc2hvdF9z dGF0dXMgPT0gImxvY2tlZCI6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQo IiVzIFdhaXRpbmcgZm9yIHNuYXBzaG90ICVzIG9uICVzIGRlbGV0aW9uIHRvIGZpbmlzaCIpICUg KHRocmVhZE5hbWUsIHNuYXBzaG90Lm5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGltZS5zbGVlcCgxMCkKICAgICAgICAgICAgICAgICAgICAgICAgZXhjZXB0 IEV4Y2VwdGlvbiBhcyBlOgogICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQgKCIlcyBT bmFwc2hvdCBzdGF0dXMgcmVxdWVzdCBtaWdodCBoYXZlIGZhaWxlZCwgdGhpcyB1c3VhbGx5IG1l YW5zIHRoYXQgdGhlIHNucGFzaG90IHdhcyBkZWxldGVkIHByb3Blcmx5IikgJSB0aHJlYWROYW1l CiAgICAgICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBEZWxldGluZyBzbmFwc2hvdCAlcyBv biAlcyBkb25lIikgJSAodGhyZWFkTmFtZSwgc25hcHNob3QubmFtZSwgdm0ubmFtZSkKCiAgICAg ICAgZWxzZToKICAgICAgICAgICAgcXVldWVMb2NrLnJlbGVhc2UoKQogICAgICAgIHRpbWUuc2xl ZXAoMSkKCnRocmVhZExpc3QgPSBbIkJhY2t1cC1UaHJlYWQtMSIsICJCYWNrdXAtVGhyZWFkLTIi LCAiQmFja3VwLVRocmVhZC0zIl0KCmRlZiBDb25uZWN0KCk6CiAgICBnbG9iYWwgYXBpCiAgICBh cGkgPSBBUEkodXJsPUVOR0lORV9TRVJWRVIsIHVzZXJuYW1lPUVOR0lORV9VU0VSLCBwYXNzd29y ZD1FTkdJTkVfUEFTU1dPUkQsIGNhX2ZpbGU9RU5HSU5FX0NFUlQpCgpkZWYgRGlzY29ubmVjdChl eGl0Y29kZSk6CiAgICBhcGkuZGlzY29ubmVjdCgpCiAgICBzeXMuZXhpdChleGl0Y29kZSkKCnRy eToKICAgIENvbm5lY3QoKQogICAgdm1zID0gYXBpLnZtcy5saXN0KCkKCmV4Y2VwdCBFeGNlcHRp b24gYXMgZToKICAgIHByaW50ICdGYWlsZWQ6XG4lcycgJSBzdHIoZSkKCm5hbWVMaXN0ID0gdm1z IApxdWV1ZUxvY2sgPSB0aHJlYWRpbmcuTG9jaygpCndvcmtRdWV1ZSA9IFF1ZXVlLlF1ZXVlKDAp CnRocmVhZHMgPSBbXQp0aHJlYWRJRCA9IDEKCiMgQ3JlYXRlIG5ldyB0aHJlYWRzCmZvciB0TmFt ZSBpbiB0aHJlYWRMaXN0OgogICAgdGhyZWFkID0gbXlUaHJlYWQodGhyZWFkSUQsIHROYW1lLCB3 b3JrUXVldWUpCiAgICB0aHJlYWQuc3RhcnQoKQogICAgdGhyZWFkcy5hcHBlbmQodGhyZWFkKQog ICAgdGhyZWFkSUQgKz0gMQoKIyBGaWxsIHRoZSBxdWV1ZQpxdWV1ZUxvY2suYWNxdWlyZSgpCmZv ciB3b3JkIGluIG5hbWVMaXN0OgogICAgd29ya1F1ZXVlLnB1dCh3b3JkKQpxdWV1ZUxvY2sucmVs ZWFzZSgpCgojIFdhaXQgZm9yIHF1ZXVlIHRvIGVtcHR5CndoaWxlIG5vdCB3b3JrUXVldWUuZW1w dHkoKToKICAgIHBhc3MKCiMgTm90aWZ5IHRocmVhZHMgaXQncyB0aW1lIHRvIGV4aXQKZXhpdEZs YWcgPSAxCgojIFdhaXQgZm9yIGFsbCB0aHJlYWRzIHRvIGNvbXBsZXRlCmZvciB0IGluIHRocmVh ZHM6CiAgICB0LmpvaW4oKQpwcmludCAiRXhpdGluZyBNYWluIFRocmVhZCIKYXBpLmRpc2Nvbm5l Y3QoKQo= --_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_--

1 0

ReferenceError: WebUtil is not defined => novnc console broken after yum update (on centos 6.6?)
by ml＠ohnewald.net 19 May '15

19 May '15

Hello, i think i ran into this bug: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1202356 I can not use my novnc console anymore. Does anyone have a fix for this (on centos 6.6?) Thanks, Mario

3 2

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

Presentation
by NUNIN Roberto 18 May '15

18 May '15

--_000_8C2CD99696B62B409EBEBFDF87C83FBF59B5526D59DENU1XMAIL02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I'm Roberto Nunin, responsible for Infrastructure in an Italian Company, pa= rt of multi-national group. I'm really interested in oVirt technology and it's future developments. Currently we are running a PoC of three clusters, 6 hosts, with an issue I'= ve already submitted to the community. Hope to find inside community answers, solutions, suggestions related to th= e product. Will try to enhance my knowledge about it. Have a nice day Roberto Nunin RHCE#110-006-970 ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B5526D59DENU1XMAIL02p_ 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"IT" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hello <o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I’m Roberto Nunin, respon= sible for Infrastructure in an Italian Company, part of multi-national grou= p.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I’m really interested in = oVirt technology and it’s future developments.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Currently we are running a PoC = of three clusters, 6 hosts, with an issue I’ve already submitted to t= he community.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hope to find inside community a= nswers, solutions, suggestions related to the product.<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span lang=3D"EN-US">Will try to enhance my knowledg= e about it.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Have a nice day<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Roberto Nunin<o:p><= /o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">RHCE#110-006-970&nb= sp;   <o:p></o:p></span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <br> <hr> <font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br> <br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br> </font> </body> </html> --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B5526D59DENU1XMAIL02p_--

2 1

missing disk after storage domain expansion
by Andrea Ghelardi 18 May '15

18 May '15

Hi gentlemen, I recently found an error on 1 of my storages: it was complaining about no free space but the VM was running and disk operational. Since I needed to perform some maintenance on the VM, I shut it down and at restart VM couldn’t boot up properly. Checked VM via console and a disk was missing. Edited fstab (luckily this disk was not root but heck! It had a Sybase DB on it!) and restarted VM this time ok. Since the disk resides on the dstore with no space, I expanded the iSCSI LUN, then refreshed multipath on hosts, then resized PVs and now ovirt is showing the correct size (logs do not complain anymore on no free space). BUUUT Now disk is missing. It is not shown anymore on Disks tab nor anywhere else. Problem is that storage shows 214GB occupancy (size of the missing disk) so data is there but cannot find it anymore. Logs show original disk creation, errors from the lack of space, refresh of the storage size and then.... no more references on the disk. What can I do to find those missing ~210GBs? Cheers Andrea Ghelardi

2 8

oVirt newbie
by Fábio Coelho 18 May '15

18 May '15

------=_Part_1122235_111346377.1431721634636 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXZlcnlvbmUsIAoKbCdtIGEgU3lzQWRtaW4sIG9sZCB2bXdhcmUgdXNlciwgd2lsbGluZyB0 byBhZHZhbmNlIGluIG9wZW4gc291cmNlIGFsdGVybmF0aXZlcy4gSSBob3BlIEkgY2FuIGhlbHAg YW5kIGJlIGhlbHBlZCBmb3IgaGVyZSA6RC4gCgpDdXJyZW50bHksIEknbSB0ZXN0aW5nIGEgc2V0 dXAgd2l0aCBvdmlydC1ub2RlLWVsNyBhbmQgYSBjZW50b3M2IGVuZ2luZS1zZXJ2ZXIsIGFuZCBh dCB0aGUgbW9tZW50LCBhbGwgaXMgZ29pbmcgZmluZSEgCgpDaGVlcnMsIAoKRsOhYmlvIENvZWxo byAKCgpBdmlzbyBMZWdhbAoKQSBpbmZvcm1hw6fDo28gY29udGlkYSBuZXN0ZSBlLW1haWwgZSBl bSBzZXVzIGFuZXhvcyBwb2RlIHNlciByZXN0cml0YSwgc2VuZG8gbyBlbWl0ZW50ZSBkZXN0ZSBy ZXNwb25zw6F2ZWwgcG9yIHNldSBjb250ZcO6ZG8gZSBlbmRlcmXDp2FtZW50by4gU2Ugdm9jw6og bsOjbyBmb3IgYSBwZXNzb2EgYXV0b3JpemFkYSBhIHJlY2ViZXIgZXN0YSBtZW5zYWdlbSBlIHRl bmRvIHJlY2ViaWRvIGEgbWVzbWEgcG9yIGVuZ2FubywgZmF2b3IgYXBhZ8OhLWxhIGltZWRpYXRh bWVudGUuIEEgSkZTQyBjb25zaWRlcmEgb3BpbmnDtWVzLCBjb25jbHVzw7VlcyBlIG91dHJhcyBp bmZvcm1hw6fDtWVzIG7Do28gb2ZpY2lhaXMgZGUgcmVzcG9uc2FiaWxpZGFkZSBkbyB1c3XDoXJp byBkZXN0ZSBzZXJ2acOnby4K ------=_Part_1122235_111346377.1431721634636 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXYgZGF0YS1tYXJrZXI9 Il9fUVVPVEVEX1RFWFRfXyI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xl LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1z dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48ZGl2PkhpIEV2ZXJ5b25lLDxicj48L2Rpdj48YnI+PGRp dj5sJ20mbmJzcDsgYSBTeXNBZG1pbiwgb2xkIHZtd2FyZSB1c2VyLCB3aWxsaW5nIHRvIGFkdmFu Y2UgaW4gb3BlbiBzb3VyY2UgYWx0ZXJuYXRpdmVzLiBJIGhvcGUgSSBjYW4gaGVscCBhbmQgYmUg aGVscGVkIGZvciBoZXJlIDpELjxicj48L2Rpdj48YnI+PGRpdj5DdXJyZW50bHksIEknbSB0ZXN0 aW5nIGEgc2V0dXAgd2l0aCBvdmlydC1ub2RlLWVsNyBhbmQgYSBjZW50b3M2IGVuZ2luZS1zZXJ2 ZXIsIGFuZCBhdCB0aGUgbW9tZW50LCBhbGwgaXMgZ29pbmcgZmluZSE8YnI+PC9kaXY+PGJyPjxk aXY+Q2hlZXJzLDxicj48L2Rpdj48YnI+PGRpdj5Gw6FiaW8gQ29lbGhvPC9kaXY+PC9kaXY+PC9k aXY+PGJyPjwvZGl2PjxwPjxicj4KQXZpc28gTGVnYWw8L3A+Cgo8cD5BIGluZm9ybWHDp8OjbyBj b250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5leG9zIHBvZGUgc2VyIHJlc3RyaXRhLCBz ZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZlbCBwb3Igc2V1IGNvbnRlw7pkbyBlIGVu ZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBhIHBlc3NvYSBhdXRvcml6YWRhIGEgcmVj ZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJpZG8gYSBtZXNtYSBwb3IgZW5nYW5vLCBm YXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBKRlNDIGNvbnNpZGVyYSBvcGluacO1ZXMs IGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1ZXMgbsOjbyBvZmljaWFpcyBkZSByZXNw b25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNlcnZpw6dvLjwvcD48L2JvZHk+PC9odG1s Pg== ------=_Part_1122235_111346377.1431721634636--

3 4

Invito aggiornato: oVirt 3.6.0 Alpha Release Test Day - mer 2015-05-27 (oVirt schedule)
by sandro.bonazzola＠gmail.com 18 May '15

18 May '15

L'evento è stato modificato. Titolo: oVirt 3.6.0 Alpha Release Test Day Quando: mer 2015-05-27 (modificato) Calendario: oVirt schedule Chi: * Sandro Bonazzola- autore * infra(a)ovirt.org * devel(a)ovirt.org * users(a)ovirt.org Dettagli evento: https://www.google.com/calendar/event?action=VIEW&eid=YWkyYWEzMWUwMnFhajAyZ… Invito da Google Calendar: https://www.google.com/calendar/ Hai ricevuto questo messaggio email di cortesia all'account users(a)ovirt.org perché sei uno dei partecipanti a questo evento. Per disattivare la ricezione di aggiornamenti futuri per questo evento, rifiuta l'evento. In alternativa, puoi registrarti per un account Google in https://www.google.com/calendar/ e verificare le impostazioni di notifica per l'intero calendario.

1 0

oVirt Test Day next week on May 27th
by Sandro Bonazzola 18 May '15

18 May '15

Hi, Just a reminder that next week we're going to have a Test Day on May 27 (postponed 1 day due to collision with 3.5.3 RC2 release). Maintainers: please update the test day page[1] Testers: be sure to get your systems ready! [1] http://www.ovirt.org/OVirt_3.6_Test_Day -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Possible SELinux problems with ovirt syncronizing networks
by Jeremy Utley 18 May '15

18 May '15

Hello all! Running ovirt 3.5 on CentOS 7 currently, and running into a little problem. All my nodes are currently showing the ovirtmgmt network as unsyncronized. When I try to force them to sync, it fails. Looking at the /var/log/vdsm/supervdsm.log file on one of the nodes, it looks like it has to do with SELinux. See: http://pastebin.com/NX7yetVW Which contains a dump of the supervdsm.log file when I tried to force syncronization. Judging from what I'm seeing, after VDSM writes the new network configuration files to /etc/sysconfig/network-scripts/ifcfg-*, it attempts to run a selinux.restorecon function against those files. Since we disable SELinux by default on all our servers, this action is failing with Errno 61 (see lines 66-71 and 86-91 in the above-mentioned pastebin). Is this normal? Is ovirt expecting to run with SELinux enabled? Or am I mis-interpreting this log output? Thanks for any help or advice you can give me! Jeremy

2 1

My feedback on network setting after installing OVirt
by John Joseph 18 May '15

18 May '15

Hi All, Like to give my feedback about how the network interface behaved after OVirt I have used CentOS 6.6 64 bit, updated Ovirt stable from the repo Now after the installation, and configuration you get "ovirtmgmt" interface and "ovirtmgmt" interface gets the IP address and everything is fine . Now reboot it result is that when you give ifconfig , eth0 is not displayed and "ovirtmgmt" do not have IP address This stage solved by giving ifconfig eth0 up and restarting the network, it will give "ovirtmgmt" an IP now I tested it using different installation, with DHCP or manual configuration for eth0 , in both the case the same experience Giving my feedback, thanks

4 5

ovirt-agent: is it possible to run specific actions when taking snapshots?
by Ernest Beinrohr 17 May '15

17 May '15

This is a multi-part message in MIME format. --------------000401040808070400080406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit It would be nice, if ovirt snapshots were more safe. When a VM has the ovirt-agent installed, ovirt could tell the agent to run site-speficic actions. What I have in mind is: linux vms: - sync - echo 3 > /proc/sys/vm/drop_caches - zerofill empty space (this takes long but saves precious backup space) databases: - prepare databases for snapshot (flush,write-lock) - send snapshot-complete and unlock -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------000401040808070400080406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> It would be nice, if ovirt snapshots were more safe. When a VM has the ovirt-agent installed, ovirt could tell the agent to run site-speficic actions. What I have in mind is:<br> <br> linux vms:<br> - sync<br> - echo 3 > /proc/sys/vm/drop_caches<br> - zerofill empty space (this takes long but saves precious backup space)<br> <br> databases:<br> - prepare databases for snapshot (flush,write-lock)<br> - send snapshot-complete and unlock<br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" height="1" width="1"> </div> </body> </html> --------------000401040808070400080406--

3 2

When can we expect updated packages for Venom Vulnerability
by Tim Macy 17 May '15

17 May '15

https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/

2 1

Live migration qemu 2.1.2 -> 2.1.3: Unknown savevm section
by Markus Stockhausen 15 May '15

15 May '15

------=_NextPartTM-000-9231d65f-462b-4e82-9556-148b260cc199 Content-Type: multipart/alternative; boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_" --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, don't know what will be the best place for the following question. So starting with the OVirt mailing list. We are using OVirt with FC20 nodes with enabled virt-preview. Thus we are running qemu 2.1.2. Everything is working smoothly including live merge. For testing purposes we compiled qemu 2.1.3 from Fedora koji and updated one of the hosts. Trying to migrate a running VM to the new host fails with the message Unknown savevm section or instance 'kvm-tpr-opt' 0 I guess some incompatibility between the versions. But qemu git history between 2.1.2 and 2.1.3 gives no hints about the reason. Any ideas - or is that migration scenario not supported at all? Markus P.S. start parameters are: LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AU= DIO_DRV=3Dspice SPICE_DEBUG_ALLOW_MC=3D1 /usr/bin/qemu-kvm -name vm60 -S -m= achine pc-1.0,accel=3Dkvm,usb=3Doff -cpu Nehalem,hv_relaxed -m 4096 -realtime mlock=3Doff -smp 2,maxcpus=3D160,= sockets=3D160,cores=3D1,threads=3D1 -uuid d2d8bdfd-99a6-41c0-84e7-26e1d6a60= 57b -smbios type=3D1,manufacturer=3DoVirt,product=3DoVirt Node,version=3D20= -3,serial=3D49434D53-0200-48D6-3000-D6483000EEC8,uuid=3Dd2d8bdfd-99a6-41c0-= 84e7-26e1d6a6057b -no-user-config -nodefaults -chardev socket,id=3Dcharmoni= tor,path=3D/var/lib/libvirt/qemu/vm60.monitor,server,nowait -mon chardev=3D= charmonitor,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2014-12-11T16:09:44,dri= ftfix=3Dslew -global kvm-pit.lost_tick_policy=3Ddiscard -no-shutdown -boot = strict=3Don -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -dev= ice virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x5 -device virtio-serial= -pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x6 -drive if=3Dnone,id=3Ddrive= -ide0-1-0,readonly=3Don,format=3Draw,serial=3D -device ide-cd,bus=3Dide.1,u= nit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive file=3D/rhev/data-cente= r/94ed7a19-fade-4bd6-83f2-2cbb2f730b95/965ca3b6-4f9c-4e81-b6e8-5ed4a9e58545= /images/422a4486-6642-41ae-bb1d-b6a955550689/26b4c1e3-faf8-4fb3-b662-da6a55= a3d8f2,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Draw,serial=3D422a4486-664= 2-41ae-bb1d-b6a955550689,cache=3Dnone,werror=3Dstop,rerror=3Dstop,aio=3Dthr= eads -device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x7,drive=3Ddrive= -virtio-disk0,id=3Dvirtio-disk0,bootindex=3D1 -netdev tap,fd=3D29,id=3Dhost= net0,vhost=3Don,vhostfd=3D30 -device virtio-net-pci,netdev=3Dhostnet0,id=3D= net0,mac=3D00:0c:29:7a:94:f1,bus=3Dpci.0,addr=3D0x3,bootindex=3D2 -chardev = socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/d2d8bdfd-99a= 6-41c0-84e7-26e1d6a6057b.com.redhat.rhevm.vdsm,server,nowait -device virtse= rialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchannel0= ,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/var= /lib/libvirt/qemu/channels/d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b.org.qemu.gu= est_agent.0,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr= =3D2,chardev=3Dcharchannel1,id=3Dchannel1,name=3Dorg.qemu.guest_agent.0 -ch= ardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device virtserialport,bus= =3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3Dchannel2,name=3Dcom.= redhat.spice.0 -spice tls-port=3D5901,addr=3DA.B.C.D,x509-dir=3D/etc/pki/vd= sm/libvirt-spice,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinp= uts,tls-channel=3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-ch= annel=3Dsmartcard,tls-channel=3Dusbredir,seamless-migration=3Don -k de -dev= ice qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,bus=3Dpci.= 0,addr=3D0x2 -device intel-hda,id=3Dsound0,bus=3Dpci.0,addr=3D0x4 -device h= da-duplex,id=3Dsound0-codec0,bus=3Dsound0.0,cad=3D0 -incoming tcp:[::]:4915= 2 -msg timestamp=3Don --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Hi, <div><br> </div> <div>don't know what will be the best place for the following question.&nbs= p;</div> <div>So starting with the OVirt mailing list. </div> <div><br> </div> <div>We are using OVirt with FC20 nodes with enabled virt-preview.</div> <div><span style=3D"font-size: 10pt;">Thus we are running qemu 2.1.2. = </span><span style=3D"font-size: 13.3333330154419px;">Everything is working= smoothly </span></div> <div><span style=3D"font-size: 13.3333330154419px;">including live merge. &= nbsp;</span></div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div><span style=3D"font-size: 10pt;">For testing purposes we compiled&nbsp= ;</span><span style=3D"font-size: 10pt;">qemu 2.1.3 from Fedora koji</span>= </div> <div><span style=3D"font-size: 10pt;">and updated one of the hosts. Trying = to migrate a running VM to</span></div> <div><span style=3D"font-size: 10pt;">the new host fails with the message</= span></div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div> <div>Unknown savevm section or instance 'kvm-tpr-opt' 0</div> <div style=3D"font-size: 10pt;"><br> </div> </div> <div style=3D"font-size: 10pt;">I guess some incompatibility between the ve= rsions. But qemu git</div> <div style=3D"font-size: 10pt;">history between 2.1.2 and 2.1.3 gives no hi= nts about the reason.</div> <div style=3D"font-size: 10pt;"><br> </div> <div style=3D"font-size: 10pt;">Any ideas - or is that migration scenario n= ot supported at all?</div> <div style=3D"font-size: 10pt;"><br> </div> <div style=3D"font-size: 10pt;">Markus</div> <div style=3D"font-size: 10pt;"><br> </div> <div style=3D"font-size: 10pt;">P.S. start parameters are:</div> <div style=3D"font-size: 10pt;"><br> </div> <div style=3D"font-size: 10pt;"> <div style=3D"font-size: 10pt;">LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/loca= l/bin:/usr/sbin:/usr/bin <span style=3D"font-size: 10pt;">QEMU_AUDIO_D= RV=3Dspice SPICE_DEBUG_ALLOW_MC=3D1 </span><span style=3D"font-size: 1= 0pt;">/usr/bin/qemu-kvm -name vm60 -S -machine pc-1.0,accel=3Dkvm,usb=3Doff=  </span></div> <div style=3D"font-size: 10pt;">-cpu Nehalem,hv_relaxed -m 4096 -realtime m= lock=3Doff <span style=3D"font-size: 10pt;">-smp 2,maxcpus=3D160,socke= ts=3D160,cores=3D1,threads=3D1 </span><span style=3D"font-size: 10pt;"= >-uuid d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b </span><span style=3D"font= -size: 10pt;">-smbios type=3D1,manufacturer=3DoVirt,product=3DoVirt Node,</span><span style=3D"f= ont-size: 10pt;">version=3D20-3,serial=3D49434D53-0200-48D6-3000-D6483000EE= C8,uuid=3Dd2d8bdfd-99a6-41c0-84e7-26e1d6a6057b -no-user-config -nodefaults = -chardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/vm60.monitor,= server,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2014-12= -11T16:09:44,driftfix=3Dslew -global kvm-pit.lost_tick_policy=3Ddiscard -no= -shutdown -boot strict=3Don -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,add= r=3D0x1.0x2 -device virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x5 -device virtio-serial-pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x6 -driv= e if=3Dnone,id=3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -devic= e ide-cd,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive f= ile=3D/rhev/data-center/94ed7a19-fade-4bd6-83f2-2cbb2f730b95/965ca3b6-4f9c-= 4e81-b6e8-5ed4a9e58545/images/422a4486-6642-41ae-bb1d-b6a955550689/26b4c1e3= -faf8-4fb3-b662-da6a55a3d8f2,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Draw= ,serial=3D422a4486-6642-41ae-bb1d-b6a955550689,cache=3Dnone,werror=3Dstop,r= error=3Dstop,aio=3Dthreads -device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x7,drive=3Ddrive-vir= tio-disk0,id=3Dvirtio-disk0,bootindex=3D1 -netdev tap,fd=3D29,id=3Dhostnet0= ,vhost=3Don,vhostfd=3D30 -device virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0= ,mac=3D00:0c:29:7a:94:f1,bus=3Dpci.0,addr=3D0x3,bootindex=3D2 -chardev socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/d2d8bdfd-99= a6-41c0-84e7-26e1d6a6057b.com.redhat.rhevm.vdsm,server,nowait -device virts= erialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchannel= 0,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/va= r/lib/libvirt/qemu/channels/d2d8bdfd-99a6-41c0-84e7-26e1d6a6057b.org.qemu.g= uest_agent.0,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel= 1,id=3Dchannel1,name=3Dorg.qemu.guest_agent.0 -chardev spicevmc,id=3Dcharch= annel2,name=3Dvdagent -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,= chardev=3Dcharchannel2,id=3Dchannel2,name=3Dcom.redhat.spice.0 -spice tls-port=3D5901,addr=3DA.B.C.D,x509-dir=3D/etc/pki/vdsm/libvirt-spi= ce,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinputs,tls-channe= l=3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-channel=3Dsmartc= ard,tls-channel=3Dusbredir,seamless-migration=3Don -k de -device qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D33554432,bus= =3Dpci.0,addr=3D0x2 -device intel-hda,id=3Dsound0,bus=3Dpci.0,addr=3D0x4 -d= evice hda-duplex,id=3Dsound0-codec0,bus=3Dsound0.0,cad=3D0 -incoming tcp:[:= :]:49152 -msg timestamp=3Don</span></div> <div><br> </div> </div> </div> </body> </html> --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735FC90819EXCHANGEcollogi_-- ------=_NextPartTM-000-9231d65f-462b-4e82-9556-148b260cc199 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-9231d65f-462b-4e82-9556-148b260cc199--

1 1

status of ovirt 3.5.1 with centos 7.1
by Jason Keltz 15 May '15

15 May '15

Hi. I wanted to check on the status of ovirt 3.5.1 with CentOS 7.1. I'm pretty sure the current 3.5.1 engine has problems with CentOS 7.1 (?), but not sure about vdsm? I know that 3.5.2 will resolve issues with engine... (I'm asking because I've kickstarted CentOS 7.1 as a host, and am having a few problems (eg. unable to talk to power management) and want to avoid debugging if it's already known to be broken... :) Thanks! Jason.

4 7

Problems with installing second host with hosted engine
by Tigran Baluyan 15 May '15

15 May '15

Hi, I've stumbled across a very strange bug and been trying to work around it for a couple of days with no luck. So my setup is: Host 1: centos 6.6 with ovirt 3.5 deployed as hosted engine. Had a few problems while deploying it, but eventually got it up and running. Host 2: same centos 6.6, same hardware. While executing hosted-engine --deploy, I am getting this error: [ INFO ] Stage: Setup validation [WARNING] Host name hyp-A2 has no domain suffix [WARNING] Failed to resolve hyp-A2 using DNS, it can be resolved only locally [ ERROR ] Failed to execute stage 'Setup validation': [Errno 2] No such file or directory: '/rhev/data-center/mnt/192.168.1.59: _media_ssd__raid10_ovirt_data__fast/f617dfce-4ac8-495b-a0f3-4f85ce39df27/ha_agent/hosted-engine.metadata' My storage machine is a separate host running RHEL 6.4. /etc/exports looks like this: /media/ssd_raid10/ *(rw,sync,all_squash) /media/ssd_raid10/ovirt *(rw,sync,no_subtree_check,anonuid=36,anongid=36,all_squash) *some other shares* Now here is the strange part: after repeatedly bashing my head against the wall I finally noticed the difference: on the first host it mounts as: 192.168.1.59:/media/ssd_raid10/ovirt/data_fast on /rhev/data-center/mnt/192.168.1.59:_media_ssd__raid10_ovirt_data__fast_ While on the second host it mounts as: 192.168.1.59:/media/ssd_raid10/ovirt/data_fast on /rhev/data-center/mnt/192.168.1.59:_media_ssd__raid10_ovirt_data__fast (note the lack of underscore in the end) That is what caused the problem - this "hosted-engine.metadata" file is actually a symlink. And because of different mount points on the second host it was pointing to nowhere. So I figured, maybe I should add / to the end of the nfs path. So I tried it like this: Please specify the storage you would like to use (iscsi, nfs3, nfs4)[nfs3]: Please specify the full shared storage connection path to use (example: host:/path): 192.168.1.59:/media/ssd_raid10/ovirt/data_fast/ [ INFO ] Installing on first host Please provide storage domain name. [hosted_storage]: As you can see, in this case it doesn't detect that it already has a hosted engine installed. So, I'm out of ideas how to make it work. There is clearly something unstable in the installation scripts, but does anyone have any idea how to make it work? PS: Sorry for my crude English, not really a native speaker. Thanks, Tigran.

4 3

[ANN] oVirt 3.5.3 First Release Candidate is now available for testing
by Sandro Bonazzola 14 May '15

14 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt team is pleased to announce that the 3.5.3 First Release Candidate is now available for testing as of May 14th 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). This release of oVirt includes numerous bug fixes and one CVE fix for the VENOM Vulnerability. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO is already available as well[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVVJ8bAAoJEHw3u57E4QAOWM4QANhbVRc7B31I09ULaddX9jGj qYadnleCE5jWapTh0W5k1E0gTE4mCxHiEJwkqpPj7ji8C5HfBmLXz2HZ5AFr7HyV SKqDJdBDvM50sLz6iRKbU22+tUpZBemlwqZKXG3mKF6SuwSKiOM3ld+xCQ/rSBSL we/IWGwlUr1o5gE5UeAX8kNMux8pfi2zJgtRZ4KD2ZqGA/6s6r5mCpvJgjxBkjt3 aq+XhPaIQU3pDti2qCeK23sgvio78c4b+BWV5F3LHCSNe6/VUedTpCljMl9ef1hV M33PD3HRDEv92kTesrQDPbMg9GkafQuRRh5FH541xwJvGvlTO67g8b37f6L8J0aa HjUxp0XurUttokZ+1KoxHJ+WvddKak4UPmIJUTdQxz5ThnazKbYFlnr9RtnmDBNH f52kGWevJQwQm6XKpJe+uJQl7xsyIkaOY0XpJBaaMxlLJdgPzuwJmayESsZ93/fZ AX8G7kz1vYd99I8tE+FZQiNcT+MOzEah5ocs+zvyZLWZxZtldZxA+Uzgt01UVxZe Z48ZG2xhWbQkvQ3OGeE4f5A7OgobESPNfUMHA3fog3SI9c/pErXkYpg+4U4BmwtI O9AxTwN51cCsY0jwMO0bAiYOPOR7jmdXATQy0IEs2xOz0oxvBQ95pom1/eXcdt/T Ii4SKOuQf8eYrW4JDTPU =LT/5 -----END PGP SIGNATURE-----

1 0

[QE][ACTION REQUIRED] oVirt 3.5.3 status
by Sandro Bonazzola 13 May '15

13 May '15

Hi, We have no blockers for 3.5.3[1] and no blocking dependencies. We still have 18 bugs in MODIFIED and 2 on QA[2]: MODIFIED ON_QA Total external 1 0 1 gluster 1 0 1 infra 5 1 6 integration 2 1 3 network 1 0 1 sla 1 0 1 storage 5 0 5 Total 16 2 18 ACTION: Testers: you're welcome to verify bugs currently ON_QA. ACTION: Testers: please add yourself to the test page [5] We have 3 bugs currently targeted to 3.5.3[3]: Whiteboard NEW POST Total external 1 0 1 infra 0 1 1 network 0 1 1 Total 1 2 3 ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 and mark them as blockers or postpone to 3.5.4. ACTION: Maintainers: to fill release notes for 3.5.3, the page has been created and updated here [4] A release management entry has been added for tracking the schedule of 3.5.3[6] and tentative schedule has been proposed as follow: 2015-05-27 Release candidate 2015-06-09 General availability [1] https://bugzilla.redhat.com/1198142 [2] http://goo.gl/WqkJnn [3] https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20targe… [4] http://www.ovirt.org/OVirt_3.5.3_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.3_Testing [6] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.3 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 1

Greetings from Argentina
by javier coscia 13 May '15

13 May '15

Hey guys, my name is Javier and I'm currently working for Red Hat Argentina as technical support for the LATAM GEO. I've been working @ RH for 2 years now and in the virtualization team. I'm looking forward to learn more on the upstream project and contribute as I can. Cheers!!

2 1

Re: [ovirt-users] messages from journal in centos7 hosts
by Nicolas Ecarnot 13 May '15

13 May '15

Hello list, Coming from : https://www.mail-archive.com/users@ovirt.org/msg24878.html I'm also being disturb by this ennoyance. Is there a workaround? (oVirt 3.5.1, CentOS 7 hosts, iSCSI storage) -- Nicolas ECARNOT > Vadq Thu, 19 Feb 2015 06:24:57 -0800 > > Hi, > > ovirt 3.5.1, engine on centos7 + storage type iscsi( using LIO™ on one of the > vdsm host) + four hosts on centos7 > > > After installation of vdsm at all cenos7 hosts in cluster in /var/log/messages > every few seconds have such record > > Feb 19 16:47:08 kvm05 journal: metadata not found: Requested metadata element > is not present > Feb 19 16:47:19 kvm05 journal: metadata not found: Requested metadata element > is not present > Feb 19 16:47:23 kvm05 journal: metadata not found: Requested metadata element > is not present > Feb 19 16:47:34 kvm05 journal: metadata not found: Requested metadata element > is not present > Feb 19 16:47:38 kvm05 journal: metadata not found: Requested metadata element > is not present > > is it possible to fix this without disabling systemd-journald? > > > -- > Thanks, > Vadim

2 2

Unable to Delete a VM snapshot .
by Kumar R, Prashanth (Prashanth) 13 May '15

13 May '15

--_000_04352BA62627804FA4254F7542A9CF375C77E45BAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I am facing issue in deleting a VM snapshot. I am using ovirt-engine-sdk-java-3.5.0.5.jar According to the SDK API,I can delete a VM using : api.getVMs().get(vmName).getSnapshots().getById(snapshotId).delete(); But there is no way to fetch the snapshot ID of a particular snapshot. Or List<VMSnapshot> vmSnapshots =3D api.getVMs().get(vmName).getSnapshots().li= st(); for (VMSnapshot vmSnapshot : vmSnapshots) { if(vmSnapshot.getDescription() =3D=3D snapshotdescription){ vmSnapshot.delete(); } I cannot use the above snippet of code to delete a snapshot,but the multipl= e snapshots for a vm can be created with the same description. So is there a way to create a snapshot with a snapshot name assigned to it. SO that delete,restore opeartions can be performed based on the snapshot na= me . Thanks, Prashanth R --_000_04352BA62627804FA4254F7542A9CF375C77E45BAZFFEXMB04globa_ 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 All,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I am facing issue in deleting a VM snapshot.<o:p></o= :p></p> <p class=3D"MsoNormal">I am using ovirt-engine-sdk-java-3.5.0.5.jar <o:p></= o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">According to the SDK API,I can delete a VM using :<o= :p></o:p></p> <p class=3D"MsoNormal">api.getVMs().get(vmName).getSnapshots().getById(snap= shotId).delete();<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">But there is no way to fetch the snapshot ID of a pa= rticular snapshot.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"text-autospace:none">Or <o:p></o:p></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><o:p> </o:p></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;color:black">List<VMSnapshot> vmSnapsh= ots =3D api.getVMs().get(vmName).getSnapshots().list();</span><span style= =3D"font-size:10.0pt;font-family:Consolas"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;color:black">     </span><b><span style=3D"font-size:10.0pt;font-family:Consolas;color:#7F005= 5">for</span></b><span style=3D"font-size:10.0pt;font-family:Consolas;color= :black"> (VMSnapshot vmSnapshot : vmSnapshots) {</span><span style=3D"font-= size:10.0pt;font-family:Consolas"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;color:black">      </span><b><span style=3D"font-size:10.0pt;font-family:Consolas;color:#7F005= 5">if</span></b><span style=3D"font-size:10.0pt;font-family:Consolas;color:= black">(vmSnapshot.getDescription() =3D=3D <u>snapshotdescription</u>){</span><span style=3D"font-size:10.0pt;font-fam= ily:Consolas"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;color:black">     &= nbsp;   vmSnapshot.delete();</span><span style=3D"font-size:10.0p= t;font-family:Consolas"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:Consolas= ;color:black">      }</span><o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">I cannot use the above snippet of code to delete a s= napshot,but the multiple snapshots for a vm can be created with the same de= scription.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">So is there a way to create a snapshot with a snapsh= ot name assigned to it.<o:p></o:p></p> <p class=3D"MsoNormal">SO that delete,restore opeartions can be performed b= ased on the snapshot name .<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">Prashanth R<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_04352BA62627804FA4254F7542A9CF375C77E45BAZFFEXMB04globa_--

2 1

HE setup failing: Cannot set temporary password for console connection
by Daniel Helgenberger 13 May '15

13 May '15

Hello, a week ago I set up a HE (3.5.2) with no problems; now this fails. 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::(_monitorDomain) 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.30:_volumes_ovirt_engine/2f83ea82-e110-465d-a2a6-ac30534a9f6a/dom_md/ids: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.30:_volumes_ovirt_engine/2f83ea82-e110-465d-a2a6-ac30534a9f6a/dom_md/ids: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 www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767

3 3

[ACTION NEEDED][QE] oVirt 3.6.0 status
by Sandro Bonazzola 13 May '15

13 May '15

Hi, here's an update on 3.6 status on integration / rel-eng side The tracker bug for 3.6.0 [1] currently shows 2 blockers: Bug ID Whiteboard Status Summary 1119225 integration POST [engine-setup] 'Execution of setup failed' message is odd if only nfs start failed 1220142 virt POST Fail to create a VM through the webadmin ACTION: maintainers to provide an ETA for above bugs For integration, 1119225 should be merged by the end of the week. Alpha release has been postponed to 2015-05-19 ACTION: maintainers to fix blocking bugs and ensure that a VM can be created through the webadmin interface before 2015-05-19. And 3 blocking dependencies: Product Bug ID Status Target Release Summary Fedora 1066959 ASSIGNED --- nfs-server.service needs to be started twice RHEL 7 1171603 NEW --- Require rpcbind.service in nfs-server.service rather than rpcbind.target GlusterFS 1218990 ASSIGNED --- failing installation of glusterfs-server-3.7.0beta1-0.14.git09bbd5c.el7.centos.x86_64 Repository closure is currently broken on Fedora 20 and CentOS 6 due to a missing required dependency on recent libvirt and vdsm rpm dropping el6 support. VDSM builds for EL6 are no more available on master snapshot. ACTION: jenkins job owners: please review jenkins jobs relying on VDSM to be available on EL6. There are 543 bugs [2] targeted to 3.6.0. NEW ASSIGNED POST Total docs 10 0 0 10 external 0 1 0 1 gluster 30 25 34 89 i18n 2 0 0 2 infra 51 4 7 62 integration 35 3 7 45 network 46 1 5 52 node 25 2 3 30 ppc 1 0 0 1 sla 48 3 1 52 spice 1 0 0 1 storage 74 4 5 83 ux 26 0 2 28 virt 70 5 12 87 Total 419 48 76 543 Features submission is now CLOSED as per current release schedule. ACTION: review features tracked in the google doc[3] Features freeze is scheduled for next month on 2015-06-15 ACTION: maintainers to finalize features proposed for 3.6 inclusion before 2015-06-15 According to current approved release process[6] you can ask for an exception until one week before feature freeze (2015-06-08). Public vote is required for exception approval before 2015-06-15. Incomplete features without an approved exception will be reverted according to their contingency plan. On Integration side: * Merged pending Hosted Engine HC patches (single brick on first host provisioning) * Merged Glance and Cinder oVirt Engine setup integration * Worked on streamlining Hosted Engine setup using oVirt Appliance and Cloud Init. On Release engineering side: * Working with infra team fixing jenkins issues * Composed 3.6.0 Alpha second re-spin and tested it for sanity; postponed by one week hitting Bug #1220142 * Prepared release notes for oVirt 3.6.0 alpha, prepared test day wiki pages ACTION: community members are welcome to join QE effort[4] by testing nightly master snapshot[5] on test systems [1] https://bugzilla.redhat.com/1155425 [2] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6.0%… [3] http://goo.gl/9X3G49 [4] http://www.ovirt.org/OVirt_Quality_Assurance [5] http://www.ovirt.org/Install_nightly_snapshot [6] http://www.ovirt.org/Release_process -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

updated qemu-kvm for EL7
by Paul Jansen 13 May '15

13 May '15

------=_Part_1219101_1981507402.1431488928600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello.I'm just following up on an mailing list exchange from earlier in the= month that was asking about the possibility of an updated libvirt for EL7.= Sandro mentioned that this was being talked about but that the vdsm team ha= d worked around the issue and could do what they needed with the existing s= upplied libvirt on EL7.I've used a different subject this time to keep the = topic more obvious to where the discussion has evolved to. Sandro mentioned that the qemu-kvm-ev that is being built - and available o= n the cbs.centos.org - would be used in master and also 3.5.x to fix a bug = present in the currently used qemu-kvm under certain circumstances.=C2=A0 A= question was asked about live-merge functionality on EL7, and apparently t= his was being investigated.My initial thought is that if we are already goi= ng to a newer version of qemu-kvm than the distro supplied version, then wh= y wouldn't ovirt want to try and be fairly current with the version they us= e/consume?=C2=A0 Why not provide live snapshot merging on this platform?=C2= =A0 Why push users over to Fedora?=C2=A0 Many potential users won't want to= use Fedora on their hosts for a number of reasons.We currently provide qem= u-kvm-ev-2.1.2-23.el7.1 on cbs.centos.org.=C2=A0 Qemu 2.3 was released earl= ier this month. Are there any plans to bump the qemu-kvm version we currently consume?=C2= =A0 It would be interesting to hear the rationale around what version we us= e/should be using. Thanks,Paul ------=_Part_1219101_1981507402.1431488928600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,= Lucida Grande, Sans-Serif;font-size:16px"><div id=3D"yui_3_16_0_1_14313982= 17104_101458">Hello.</div><div id=3D"yui_3_16_0_1_1431398217104_101400">I'm= just following up on an mailing list exchange from earlier in the month th= at was asking about the possibility of an updated libvirt for EL7.</div><di= v id=3D"yui_3_16_0_1_1431398217104_101343">Sandro mentioned that this was b= eing talked about but that the vdsm team had worked around the issue and co= uld do what they needed with the existing supplied libvirt on EL7.</div><di= v>I've used a different subject this time to keep the topic more obvious to= where the discussion has evolved to.<br></div><div id=3D"yui_3_16_0_1_1431= 398217104_101369"><br></div><div id=3D"yui_3_16_0_1_1431398217104_101401">S= andro mentioned that the qemu-kvm-ev that is being built - and available on= the cbs.centos.org - would be used in master and also 3.5.x to fix a bug p= resent in the currently used qemu-kvm under certain circumstances.  A = question was asked about live-merge functionality on EL7, and apparently th= is was being investigated.</div><div dir=3D"ltr" id=3D"yui_3_16_0_1_1431398= 217104_101413">My initial thought is that if we are already going to a newe= r version of qemu-kvm than the distro supplied version, then why wouldn't o= virt want to try and be fairly current with the version they use/consume?&n= bsp; Why not provide live snapshot merging on this platform?  Why push= users over to Fedora?  Many potential users won't want to use Fedora = on their hosts for a number of reasons.</div><div id=3D"yui_3_16_0_1_143139= 8217104_101459" dir=3D"ltr">We currently provide <a id=3D"yui_3_16_0_1_1431= 398217104_101522" style=3D"" class=3D"" href=3D"http://cbs.centos.org/repos= /virt7-testing/x86_64/os/Packages/qemu-kvm-ev-2.1.2-23.el7.1.x86_64.rpm">qe= mu-kvm-ev-2.1.2-23.el7.1</a> on cbs.centos.org.  Qemu 2.3 was released= earlier this month.</div><div id=3D"yui_3_16_0_1_1431398217104_101605" dir= =3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1431398217104_101606" dir=3D"ltr= ">Are there any plans to bump the qemu-kvm version we currently consume?&nb= sp; It would be interesting to hear the rationale around what version we us= e/should be using.</div><div id=3D"yui_3_16_0_1_1431398217104_101610" dir= =3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1431398217104_101609" dir=3D"ltr= ">Thanks,</div><div id=3D"yui_3_16_0_1_1431398217104_101608" dir=3D"ltr">Pa= ul</div><div id=3D"yui_3_16_0_1_1431398217104_101607" dir=3D"ltr"><br></div= ></div></body></html> ------=_Part_1219101_1981507402.1431488928600--

1 0

Re: [ovirt-users] [ovirt-devel] [SOLVED] vdsClient getVGList returned Empty
by like.ma＠cs2c.com.cn 13 May '15

13 May '15

This is a multi-part message in MIME format. ------=_001_NextPart535338448774_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIHByb2JsZW0gaGFzIGJlZW4gc29sdmVkLiBUaGUgcmVhc29uIHRoYXQgdmRzbSBjYW5ub3Qg c2VlIHRoZSB2Z3MgaXMgdGhlIHBlcm1pc3Npb24gb2Ygc3Vkb2VycyBoYWQgYmVlbiBjaGFuZ2Vk IGJ5IHNvbWVib2R5IHdobyBoYWNrZWQgaW50byBvdXIgc3lzdGVtLiBBZnRlciByZXN0b3Jpbmcg dGhlIHBlcm1pc3Npb24gb2Ygc3Vkb2VycyBldmVyeXRpbmcgaXMgZmluZS4NCg0KDQoNCmxpa2Uu bWFAY3MyYy5jb20uY24NCiANCkZyb206IGxpa2UubWFAY3MyYy5jb20uY24NCkRhdGU6IDIwMTUt MDUtMDcgMjA6MDENClRvOiBOaXIgU29mZmVyDQpTdWJqZWN0OiBSZTogUmU6IFtvdmlydC1kZXZl bF0gdmRzQ2xpZW50IGdldFZHTGlzdCByZXR1cm5lZCBFbXB0eQ0KVGhhbmsgeW91IGZvciB5b3Vy IHJlcGx5LiANCg0KRm9sbG93aW5nIGlzIHRoZSBvdXRwdXQ6DQoNCiBbcm9vdEBqempkdmUgfl0j IHB2c2NhbiAtLWNhY2hlICYmIGx2cyAtbyBhbGx8bW9yZQ0KICBMViBVVUlEICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBMViAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UGENCnRoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXR0DQpyICAgICAgIEFjdGl2ZSBNYWogTWluIFJhaGVh ZCBLTWFqIEtNaW4gS1JhaGVhZCBMU2l6ZSAgIE1TaXplICAjU2VnIE9yaWdpbiBPU2l6ZQ0KIERh dGElICBTbmFwJSAgTWV0YSUgIENweSVTeW5jIENweSVTeW5jIE1pc21hdGNoZXMgU3luY0FjdGlv biBXQmVoaW5kIE1pblN5bmMgTWENCnhTeW5jIE1vdmUgQ29udmVydCBMb2cgRGF0YSBNZXRhIFBv b2wgTFYgVGFncw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBM UHJvZmlsZSBUaW1lDQpIb3N0ICAgICAgIE1vZHVsZXMgRm10ICBWRyBVVUlEICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBWRw0KICAgICAgICAgICAgICAgICAgICBBdHRyICAgVlNpemUg ICBWRnJlZSAgIFNZUyBJRCBFeHQgICAgICNFeHQgIEZyZWUgTWF4TFYgTWF4UFYNCiAjUFYgI0xW ICNTTiBTZXEgVkcgVGFncw0KDQpSSUNDRiAyMDE1LzUvNyAxOTo1MjozMA0KDQoNCg0KDQoNCg0K DQoNCg0KDQogICAgIFZQcm9maWxlICNWTWRhICNWTWRhVXNlIFZNZGFGcmVlICBWTWRhU2l6ZSAg I1ZNZGFDcHMNCiAgcTJHMFpWLXZrbHAtNExiRi1vWWlTLTIycW8tMDJXYi1DcVMxWTUgMWU5NGQy YjYtNzk1Ni00YmVjLTg2YmMtODMyMjExZDM2ZDZmIC9kDQpldi9lZGUzN2E4OS01YzFiLTRkNTMt YWQwNy04YTExYmEyMDlmNjEvMWU5NGQyYjYtNzk1Ni00YmVjLTg2YmMtODMyMjExZDM2ZDZmIC13 aQ0KLWEtLS0tLSBhY3RpdmUgIC0xICAtMSAgIGF1dG8gMjUzICAxNyAgIDUxMi4wMGsgICAxLjAw dCAgICAgICAgICAgMQ0KDQpSSUNDRiAyMDE1LzUvNyAxOTo1MzowOQ0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1EXzE1LFBVXzAwMDAwMDAwLTAwMDAtMDAwMC0wMDAw LTAwMDAwMDAwMA0KMDAwLElVX2QwZDg4OTM1LWM4YTQtNDU2My05NDFkLTc3NWJjMDg1Y2MyZCAg ICAgICAgICAyMDE1LTA0LTE5IDE2OjE4OjIzICswODAwDQpqempkdmUuY29tICAgICAgICAgbHZt MiBodm81bFItYWJnYS1YdjJ2LXR4QVQtNVREVC0wdjg3LVd5N2JBRSBlZGUzN2E4OS01YzFiLTRk NQ0KMy1hZDA3LThhMTFiYTIwOWY2MSB3ei0tbi0gICA0LjAwdCA3MzcuMDBnICAgICAgICAxMjgu MDBtIDMyNzY1IDU4OTYgICAgIDAgICAgIDANCiAgIDEgIDI1ICAgMCAxOTMgTURUX0xFQVNFVElN RVNFQz02MCxNRFRfQ0xBU1M9RGF0YSxNRFRfVkVSU0lPTj0zLE1EVF9MT0dCTEtTSVpFDQo9NTEy LE1EVF9WR1VVSUQ9aHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUsTURUX1BW MD1wdjozNmUwOTc5NjEwMGI2YQ0KYjlkMDAwZDM4MzQwMDAwMDAwMiY0NCZ1dWlkOkQwQjE4di1u YXVsLXFTck4tRUFyMy15MjdTLTF3dHItY2VHOXFGJjQ0JnBlc3RhcnQ6MCYNCjQ0JnBlY291bnQ6 MzI3NjUmNDQmbWFwb2Zmc2V0OjAsTURUX0RFU0NSSVBUSU9OPXZlX3N0b3JhZ2UsTURUX0xFQVNF UkVUUklFUz0zLE1EDQpUX0lPT1BUSU1FT1VUU0VDPTEwLE1EVF9MT0NLUkVORVdBTElOVEVSVkFM U0VDPTUsTURUX1BIWUJMS1NJWkU9NTEyLE1EVF9UWVBFPUZDUA0KLE1EVF9MT0NLUE9MSUNZPSxN RFRfU0RVVUlEPWVkZTM3YTg5LTVjMWItNGQ1My1hZDA3LThhMTFiYTIwOWY2MSxSSEFUX3N0b3Jh Z2VfZG8NCm1haW4sTURUX1BPT0xfVVVJRD01ODQ5YjAzMC02MjZlLTQ3Y2ItYWQ5MC0zY2U3ODJk ODMxYjMsTURUX1BPT0xfREVTQ1JJUFRJT049RGVmDQphdWx0LE1EVF9ST0xFPU1hc3RlcixNRFRf TUFTVEVSX1ZFUlNJT049MSxNRFRfUE9PTF9ET01BSU5TPWVkZTM3YTg5LTVjMWItNGQ1My1hZA0K MDctOGExMWJhMjA5ZjYxOkFjdGl2ZSY0NCY2Y2RjMTVmYi05NzRjLTQ0MDctOWI0Mi02NWI2Zjk5 YjE5ZjU6QWN0aXZlLE1EVF9QT09MX1MNClBNX0lEPTEsTURUX19TSEFfQ0tTVU09NTU3ZmNiYjcy ODMzYjlmMmY0ODU1YmJmY2NhOTI5MDhjMWIzMzFhNCxNRFRfUE9PTF9TUE1fTFZFDQpSPTE0ICAg ICAgICAgICAgICAyICAgICAgICAyICAgIDYzLjk5bSAgIDEyOC4wMG0gdW5tYW5hZ2VkDQogIGxq MGpoVC10R3FSLWMwSGktcUdxUy01WEYxLVByUlYtWk9rRU04IDFmMzc5MjJmLTNkMTEtNDgwOS1h NWRiLWNiMmU5NjVhODBmOCAvZA0KZXYvZWRlMzdhODktNWMxYi00ZDUzLWFkMDctOGExMWJhMjA5 ZjYxLzFmMzc5MjJmLTNkMTEtNDgwOS1hNWRiLWNiMmU5NjVhODBmOCAtd2kNCi1hLS0tLS0gYWN0 aXZlICAtMSAgLTEgICBhdXRvIDI1MyAgMjcgICA1MTIuMDBrIDkwMC4wMGcgICAgICAgICAgIDEN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNRF8yNSxQVV8wMDAwMDAw MC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDANCjAwMCxJVV81YzVjOTEyMS0zZjBhLTQwM2MtYWU1 My00NjM1MGJmZjZhY2EgICAgICAgICAgMjAxNS0wNC0yMCAxOToyMjowOSArMDgwMA0KanpqZHZl LmNvbSAgICAgICAgIGx2bTIgaHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUg ZWRlMzdhODktNWMxYi00ZDUNCjMtYWQwNy04YTExYmEyMDlmNjEgd3otLW4tICAgNC4wMHQgNzM3 LjAwZyAgICAgICAgMTI4LjAwbSAzMjc2NSA1ODk2ICAgICAwICAgICAwDQoNClJJQ0NGIDIwMTUv NS83IDE5OjUzOjM4DQoNCiAgIDEgIDI1ICAgMCAxOTMgTURUX0xFQVNFVElNRVNFQz02MCxNRFRf Q0xBU1M9RGF0YSxNRFRfVkVSU0lPTj0zLE1EVF9MT0dCTEtTSVpFDQo9NTEyLE1EVF9WR1VVSUQ9 aHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUsTURUX1BWMD1wdjozNmUwOTc5 NjEwMGI2YQ0KYjlkMDAwZDM4MzQwMDAwMDAwMiY0NCZ1dWlkOkQwQjE4di1uYXVsLXFTck4tRUFy My15MjdTLTF3dHItY2VHOXFGJjQ0JnBlc3RhcnQ6MCYNCjQ0JnBlY291bnQ6MzI3NjUmNDQmbWFw b2Zmc2V0OjAsTURUX0RFU0NSSVBUSU9OPXZlX3N0b3JhZ2UsTURUX0xFQVNFUkVUUklFUz0zLE1E DQpUX0lPT1BUSU1FT1VUU0VDPTEwLE1EVF9MT0NLUkVORVdBTElOVEVSVkFMU0VDPTUsTURUX1BI WUJMS1NJWkU9NTEyLE1EVF9UWVBFPUZDUA0KLE1EVF9MT0NLUE9MSUNZPSxNRFRfU0RVVUlEPWVk ZTM3YTg5LTVjMWItNGQ1My1hZDA3LThhMTFiYTIwOWY2MSxSSEFUX3N0b3JhZ2VfZG8NCm1haW4s TURUX1BPT0xfVVVJRD01ODQ5YjAzMC02MjZlLTQ3Y2ItYWQ5MC0zY2U3ODJkODMxYjMsTURUX1BP T0xfREVTQ1JJUFRJT049RGVmDQphdWx0LE1EVF9ST0xFPU1hc3RlcixNRFRfTUFTVEVSX1ZFUlNJ T049MSxNRFRfUE9PTF9ET01BSU5TPWVkZTM3YTg5LTVjMWItNGQ1My1hZA0KMDctOGExMWJhMjA5 ZjYxOkFjdGl2ZSY0NCY2Y2RjMTVmYi05NzRjLTQ0MDctOWI0Mi02NWI2Zjk5YjE5ZjU6QWN0aXZl LE1EVF9QT09MX1MNClBNX0lEPTEsTURUX19TSEFfQ0tTVU09NTU3ZmNiYjcyODMzYjlmMmY0ODU1 YmJmY2NhOTI5MDhjMWIzMzFhNCxNRFRfUE9PTF9TUE1fTFZFDQpSPTE0ICAgICAgICAgICAgICAy ICAgICAgICAyICAgIDYzLjk5bSAgIDEyOC4wMG0gdW5tYW5hZ2VkDQogIDE2c0VOMi13bUZDLXlq d04tTndnbS1yWDVBLXBLbVItQTVVSWhJIDJkYzcyZjlkLWUxNzAtNGY4ZC1iNDE1LWFjNGRjNjkx NDE5MSAvZA0KZXYvZWRlMzdhODktNWMxYi00ZDUzLWFkMDctOGExMWJhMjA5ZjYxLzJkYzcyZjlk LWUxNzAtNGY4ZC1iNDE1LWFjNGRjNjkxNDE5MSAtd2kNCi1hLS0tLS0gYWN0aXZlICAtMSAgLTEg ICBhdXRvIDI1MyAgMTIgICA1MTIuMDBrIDMwMC4wMGcgICAgICAgICAgIDENCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJVV83NmM4YTYyMi00NmY3LTRkZWYtYTRmYS0w Yjc0ZDU4MWU1NjQsUFUNCl8wMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAwMDAsTURf MTAgICAgICAgICAgMjAxNS0wMy0yNCAxMjoxMzoxMyArMDgwMA0KanpqZHZlLmNvbSAgICAgICAg IGx2bTIgaHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUgZWRlMzdhODktNWMx Yi00ZDUNCjMtYWQwNy04YTExYmEyMDlmNjEgd3otLW4tICAgNC4wMHQgNzM3LjAwZyAgICAgICAg MTI4LjAwbSAzMjc2NSA1ODk2ICAgICAwICAgICAwDQogICAxICAyNSAgIDAgMTkzIE1EVF9MRUFT RVRJTUVTRUM9NjAsTURUX0NMQVNTPURhdGEsTURUX1ZFUlNJT049MyxNRFRfTE9HQkxLU0laRQ0K PTUxMixNRFRfVkdVVUlEPWh2bzVsUi1hYmdhLVh2MnYtdHhBVC01VERULTB2ODctV3k3YkFFLE1E VF9QVjA9cHY6MzZlMDk3OTYxMDBiNmENCmI5ZDAwMGQzODM0MDAwMDAwMDImNDQmdXVpZDpEMEIx OHYtbmF1bC1xU3JOLUVBcjMteTI3Uy0xd3RyLWNlRzlxRiY0NCZwZXN0YXJ0OjAmDQo0NCZwZWNv dW50OjMyNzY1JjQ0Jm1hcG9mZnNldDowLE1EVF9ERVNDUklQVElPTj12ZV9zdG9yYWdlLE1EVF9M RUFTRVJFVFJJRVM9MyxNRA0KMTk6NTQ6MTQNClJJQ0NGIDIwMTUvNS83IDE5OjU0OjE0DQoNClRf SU9PUFRJTUVPVVRTRUM9MTAsTURUX0xPQ0tSRU5FV0FMSU5URVJWQUxTRUM9NSxNRFRfUEhZQkxL U0laRT01MTIsTURUX1RZUEU9RkNQDQosTURUX0xPQ0tQT0xJQ1k9LE1EVF9TRFVVSUQ9ZWRlMzdh ODktNWMxYi00ZDUzLWFkMDctOGExMWJhMjA5ZjYxLFJIQVRfc3RvcmFnZV9kbw0KbWFpbixNRFRf UE9PTF9VVUlEPTU4NDliMDMwLTYyNmUtNDdjYi1hZDkwLTNjZTc4MmQ4MzFiMyxNRFRfUE9PTF9E RVNDUklQVElPTj1EZWYNCmF1bHQsTURUX1JPTEU9TWFzdGVyLE1EVF9NQVNURVJfVkVSU0lPTj0x LE1EVF9QT09MX0RPTUFJTlM9ZWRlMzdhODktNWMxYi00ZDUzLWFkDQowNy04YTExYmEyMDlmNjE6 QWN0aXZlJjQ0JjZjZGMxNWZiLTk3NGMtNDQwNy05YjQyLTY1YjZmOTliMTlmNTpBY3RpdmUsTURU X1BPT0xfUw0KUE1fSUQ9MSxNRFRfX1NIQV9DS1NVTT01NTdmY2JiNzI4MzNiOWYyZjQ4NTViYmZj Y2E5MjkwOGMxYjMzMWE0LE1EVF9QT09MX1NQTV9MVkUNClI9MTQgICAgICAgICAgICAgIDIgICAg ICAgIDIgICAgNjMuOTltICAgMTI4LjAwbSB1bm1hbmFnZWQNCiAgY2hRTkhnLThrT2otaWhGTC1V SFpvLVJDUFctUndVai1jUUVWb2YgNDA2NThiZjQtZGIyYi00ZmE3LWJiMGYtNmQ1NGFiMDIyMzM4 IC9kDQpldi9lZGUzN2E4OS01YzFiLTRkNTMtYWQwNy04YTExYmEyMDlmNjEvNDA2NThiZjQtZGIy Yi00ZmE3LWJiMGYtNmQ1NGFiMDIyMzM4IC13aQ0KLWEtLS0tLSBhY3RpdmUgIC0xICAtMSAgIGF1 dG8gMjUzICAxOCAgIDUxMi4wMGsgICAxLjAwZyAgICAgICAgICAgMQ0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE1EXzE2LFBVX2I3MjJmZTQ5LWYwNGEtNDk1OC04N2Ex LTgzYzAyOTlkNw0KYjEzLElVXzgxZTM2NjM5LTNhMTUtNGZlNy05ZGJmLTdlZDEyYzU2YWJiNiAg ICAgICAgICAyMDE1LTA0LTE5IDE2OjE5OjQxICswODAwDQpqempkdmUuY29tICAgICAgICAgbHZt MiBodm81bFItYWJnYS1YdjJ2LXR4QVQtNVREVC0wdjg3LVd5N2JBRSBlZGUzN2E4OS01YzFiLTRk NQ0KMy1hZDA3LThhMTFiYTIwOWY2MSB3ei0tbi0gICA0LjAwdCA3MzcuMDBnICAgICAgICAxMjgu MDBtIDMyNzY1IDU4OTYgICAgIDAgICAgIDANCiAgIDEgIDI1ICAgMCAxOTMgTURUX0xFQVNFVElN RVNFQz02MCxNRFRfQ0xBU1M9RGF0YSxNRFRfVkVSU0lPTj0zLE1EVF9MT0dCTEtTSVpFDQo9NTEy LE1EVF9WR1VVSUQ9aHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUsTURUX1BW MD1wdjozNmUwOTc5NjEwMGI2YQ0KYjlkMDAwZDM4MzQwMDAwMDAwMiY0NCZ1dWlkOkQwQjE4di1u YXVsLXFTck4tRUFyMy15MjdTLTF3dHItY2VHOXFGJjQ0JnBlc3RhcnQ6MCYNCjQ0JnBlY291bnQ6 MzI3NjUmNDQmbWFwb2Zmc2V0OjAsTURUX0RFU0NSSVBUSU9OPXZlX3N0b3JhZ2UsTURUX0xFQVNF UkVUUklFUz0zLE1EDQpUX0lPT1BUSU1FT1VUU0VDPTEwLE1EVF9MT0NLUkVORVdBTElOVEVSVkFM U0VDPTUsTURUX1BIWUJMS1NJWkU9NTEyLE1EVF9UWVBFPUZDUA0KLE1EVF9MT0NLUE9MSUNZPSxN RFRfU0RVVUlEPWVkZTM3YTg5LTVjMWItNGQ1My1hZDA3LThhMTFiYTIwOWY2MSxSSEFUX3N0b3Jh Z2VfZG8NCm1haW4sTURUX1BPT0xfVVVJRD01ODQ5YjAzMC02MjZlLTQ3Y2ItYWQ5MC0zY2U3ODJk ODMxYjMsTURUX1BPT0xfREVTQ1JJUFRJT049RGVmDQphdWx0LE1EVF9ST0xFPU1hc3RlcixNRFRf TUFTVEVSX1ZFUlNJT049MSxNRFRfUE9PTF9ET01BSU5TPWVkZTM3YTg5LTVjMWItNGQ1My1hZA0K DQpSSUNDRiAyMDE1LzUvNyAxOTo1NDo0Ng0KDQowNy04YTExYmEyMDlmNjE6QWN0aXZlJjQ0JjZj ZGMxNWZiLTk3NGMtNDQwNy05YjQyLTY1YjZmOTliMTlmNTpBY3RpdmUsTURUX1BPT0xfUw0KUE1f SUQ9MSxNRFRfX1NIQV9DS1NVTT01NTdmY2JiNzI4MzNiOWYyZjQ4NTViYmZjY2E5MjkwOGMxYjMz MWE0LE1EVF9QT09MX1NQTV9MVkUNClI9MTQgICAgICAgICAgICAgIDIgICAgICAgIDIgICAgNjMu OTltICAgMTI4LjAwbSB1bm1hbmFnZWQNCiAgNkFlTUhmLU5hWnEtWjRMdi1CSGFhLW8waVUtbFA4 Yi1qM1UwY0sgNDA3ZTRjY2ItZGQ1Ni00ZDQ1LThmZDgtNDMxNjI2OTA3OTRlIC9kDQpldi9lZGUz N2E4OS01YzFiLTRkNTMtYWQwNy04YTExYmEyMDlmNjEvNDA3ZTRjY2ItZGQ1Ni00ZDQ1LThmZDgt NDMxNjI2OTA3OTRlIC13aQ0KLWEtLS0tLSBhY3RpdmUgIC0xICAtMSAgIGF1dG8gMjUzICAyNCAg IDUxMi4wMGsgICAxLjAwZyAgICAgICAgICAgMQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFBVXzAwMDAwMDAwLTAwMDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCxNRA0K XzIwLElVX2RmMzBhMzI1LWU3YjItNDczNC05NzgzLWZkYzQ2OWQyYWFmNiAgICAgICAgICAyMDE1 LTA0LTE5IDE2OjU3OjE1ICswODAwDQpqempkdmUuY29tICAgICAgICAgbHZtMiBodm81bFItYWJn YS1YdjJ2LXR4QVQtNVREVC0wdjg3LVd5N2JBRSBlZGUzN2E4OS01YzFiLTRkNQ0KMy1hZDA3LThh MTFiYTIwOWY2MSB3ei0tbi0gICA0LjAwdCA3MzcuMDBnICAgICAgICAxMjguMDBtIDMyNzY1IDU4 OTYgICAgIDAgICAgIDANCiAgIDEgIDI1ICAgMCAxOTMgTURUX0xFQVNFVElNRVNFQz02MCxNRFRf Q0xBU1M9RGF0YSxNRFRfVkVSU0lPTj0zLE1EVF9MT0dCTEtTSVpFDQo9NTEyLE1EVF9WR1VVSUQ9 aHZvNWxSLWFiZ2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUsTURUX1BWMD1wdjozNmUwOTc5 NjEwMGI2YQ0KYjlkMDAwZDM4MzQwMDAwMDAwMiY0NCZ1dWlkOkQwQjE4di1uYXVsLXFTck4tRUFy My15MjdTLTF3dHItY2VHOXFGJjQ0JnBlc3RhcnQ6MCYNCjQ0JnBlY291bnQ6MzI3NjUmNDQmbWFw b2Zmc2V0OjAsTURUX0RFU0NSSVBUSU9OPXZlX3N0b3JhZ2UsTURUX0xFQVNFUkVUUklFUz0zLE1E DQpUX0lPT1BUSU1FT1VUU0VDPTEwLE1EVF9MT0NLUkVORVdBTElOVEVSVkFMU0VDPTUsTURUX1BI WUJMS1NJWkU9NTEyLE1EVF9UWVBFPUZDUA0KLE1EVF9MT0NLUE9MSUNZPSxNRFRfU0RVVUlEPWVk ZTM3YTg5LTVjMWItNGQ1My1hZDA3LThhMTFiYTIwOWY2MSxSSEFUX3N0b3JhZ2VfZG8NCm1haW4s TURUX1BPT0xfVVVJRD01ODQ5YjAzMC02MjZlLTQ3Y2ItYWQ5MC0zY2U3ODJkODMxYjMsTURUX1BP T0xfREVTQ1JJUFRJT049RGVmDQphdWx0LE1EVF9ST0xFPU1hc3RlcixNRFRfTUFTVEVSX1ZFUlNJ T049MSxNRFRfUE9PTF9ET01BSU5TPWVkZTM3YTg5LTVjMWItNGQ1My1hZA0KMDctOGExMWJhMjA5 ZjYxOkFjdGl2ZSY0NCY2Y2RjMTVmYi05NzRjLTQ0MDctOWI0Mi02NWI2Zjk5YjE5ZjU6QWN0aXZl LE1EVF9QT09MX1MNClBNX0lEPTEsTURUX19TSEFfQ0tTVU09NTU3ZmNiYjcyODMzYjlmMmY0ODU1 YmJmY2NhOTI5MDhjMWIzMzFhNCxNRFRfUE9PTF9TUE1fTFZFDQpSPTE0ICAgICAgICAgICAgICAy ICAgICAgICAyICAgIDYzLjk5bSAgIDEyOC4wMG0gdW5tYW5hZ2VkDQoxOTo1NzoxMw0KUklDQ0Yg MjAxNS81LzcgMTk6NTc6MTMNCg0KbHYgaXMgdG9vIG11Y2gsIGFib3ZlIGlzIGp1c3QgYSBwYXJ0 IG9mIG91dHB1dA0KDQpbcm9vdEBqempkdmUgfl0jIHB2c2NhbiAtLWNhY2hlICYmIHZncyAtbyBh bGwNCiAgRm10ICBWRyBVVUlEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWRyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXR0ciAgIFZTaXplICAgVkZyZWUgICBTWVMg SUQgRXh0ICAgICAjRXh0ICBGcmVlIE1heExWIE1heFBWICNQViAjTFYgI1NOIFNlcSBWRyBUYWdz ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZQcm9maWxlICNWTWRhICNW TWRhVXNlIFZNZGFGcmVlICBWTWRhU2l6ZSAgI1ZNZGFDcHMNCiAgbHZtMiBodm81bFItYWJnYS1Y djJ2LXR4QVQtNVREVC0wdjg3LVd5N2JBRSBlZGUzN2E4OS01YzFiLTRkNTMtYWQwNy04YTExYmEy MDlmNjEgd3otLW4tICAgNC4wMHQgNzM3LjAwZyAgICAgICAgMTI4LjAwbSAzMjc2NSA1ODk2ICAg ICAwICAgICAwICAgMSAgMjUgICAwIDE5MyBNRFRfTEVBU0VUSU1FU0VDPTYwLE1EVF9DTEFTUz1E YXRhLE1EVF9WRVJTSU9OPTMsTURUX0xPR0JMS1NJWkU9NTEyLE1EVF9WR1VVSUQ9aHZvNWxSLWFi Z2EtWHYydi10eEFULTVURFQtMHY4Ny1XeTdiQUUsTURUX1BWMD1wdjozNmUwOTc5NjEwMGI2YWI5 ZDAwMGQzODM0MDAwMDAwMDImNDQmdXVpZDpEMEIxOHYtbmF1bC1xU3JOLUVBcjMteTI3Uy0xd3Ry LWNlRzlxRiY0NCZwZXN0YXJ0OjAmNDQmcGVjb3VudDozMjc2NSY0NCZtYXBvZmZzZXQ6MCxNRFRf REVTQ1JJUFRJT049dmVfc3RvcmFnZSxNRFRfTEVBU0VSRVRSSUVTPTMsTURUX0lPT1BUSU1FT1VU U0VDPTEwLE1EVF9MT0NLUkVORVdBTElOVEVSVkFMU0VDPTUsTURUX1BIWUJMS1NJWkU9NTEyLE1E VF9UWVBFPUZDUCxNRFRfTE9DS1BPTElDWT0sTURUX1NEVVVJRD1lZGUzN2E4OS01YzFiLTRkNTMt YWQwNy04YTExYmEyMDlmNjEsUkhBVF9zdG9yYWdlX2RvbWFpbixNRFRfUE9PTF9VVUlEPTU4NDli MDMwLTYyNmUtNDdjYi1hZDkwLTNjZTc4MmQ4MzFiMyxNRFRfUE9PTF9ERVNDUklQVElPTj1EZWZh dWx0LE1EVF9ST0xFPU1hc3RlcixNRFRfTUFTVEVSX1ZFUlNJT049MSxNRFRfUE9PTF9ET01BSU5T PWVkZTM3YTg5LTVjMWItNGQ1My1hZDA3LThhMTFiYTIwOWY2MTpBY3RpdmUmNDQmNmNkYzE1ZmIt OTc0Yy00NDA3LTliNDItNjViNmY5OWIxOWY1OkFjdGl2ZSxNRFRfUE9PTF9TUE1fSUQ9MSxNRFRf X1NIQV9DS1NVTT01NTdmY2JiNzI4MzNiOWYyZjQ4NTViYmZjY2E5MjkwOGMxYjMzMWE0LE1EVF9Q T09MX1NQTV9MVkVSPTE0ICAgICAgICAgICAgICAyICAgICAgICAyICAgIDYzLjk5bSAgIDEyOC4w MG0gdW5tYW5hZ2VkDQogIGx2bTIgcG9wYzdDLVNoQmotNWE1SC1TOVd5LVRMMFctS1g0bi1oOGdt TWMgdmdfZ3pqZHZlICAgICAgICAgICAgICAgICAgICAgICAgICAgIHd6LS1uLSA1NTguMzhnICAg ICAgMCAgICAgICAgICA2NC4wMG0gIDg5MzQgICAgMCAgICAgMCAgICAgMCAgIDEgICAzICAgMCAg IDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgMSAgIDUwNy41MGsgIDEwMjAuMDBrIHVubWFuYWdlZA0KDQoNCg0KbGlr ZS5tYUBjczJjLmNvbS5jbg0KIA0KRnJvbTogTmlyIFNvZmZlcg0KRGF0ZTogMjAxNS0wNS0wNyAx OTo0NQ0KVG86IGxpa2UgbWENCkNDOiB1c2VyczsgZGV2ZWwNClN1YmplY3Q6IFJlOiBbb3ZpcnQt ZGV2ZWxdIHZkc0NsaWVudCBnZXRWR0xpc3QgcmV0dXJuZWQgRW1wdHkNCj4gSGksIGd1eXMNCj4g SSBoYXZlIGEgdmRzbSBob3N0LCB3aGVuIGkgdXNlICJ2Z3MiIGNvbW1hbmQsIGl0IHdpbGwgZGlz cGxheSAyIHZvbHVtZSBncm91cA0KPiB3aGljaCBhbHJlYWR5IGV4aXN0LiBCdXQgd2hlbiBpIHVz ZSAidmRzQ2xpZW50IC1zIDAgZ2V0VkdMaXN0IiwgaXQgZGlzcGxheXMNCj4gbm90aGluZy4gVGhh dCBtZWFucyB2ZHNtIGNhbm5vdCBzZWUgdGhlIGV4aXN0ZWQgdmcuIFdoeT8gRG9lcyBhbnlib2R5 IGhhdmUNCj4gYW55IGlkZWE/DQo+IA0KPiBQLlMuIEluIGZhY3QsIGkgYW0gdHJ5aW5nIHRvIHJl c29sdmUgdGhlIHByb2JsZW0gb2YgIkNhbm5vdCBmaW5kIG1hc3Rlcg0KPiBkb21haW4iDQogDQpD YW4geW91IHNoYXJlZCB0aGUgb3V0cHV0IG9mOg0KIA0KcHZzY2FuIC0tY2FjaGUgJiYgbHZzIC1v IGFsbA0KcHZzY2FuIC0tY2FjaGUgJiYgdmdzIC1vIGFsbA0KIA0KTmlyDQo= ------=_001_NextPart535338448774_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DUTF-8"><style>body { line-height: 1.5; }blockquote { margin-top: 0px; = margin-bottom: 0px; margin-left: 0.5em; }div.foxdiv20150513085609433047 { = }body { font-size: 10.5pt; font-family: =E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB= =91; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><body>=0A<div>= <span></span>The problem has been solved. The reason that vdsm cannot see = the vgs is the permission of sudoers had been changed by somebody who hack= ed into our system. After restoring the permission of sudoers everyting is= fine.</div>=0A<div><br></div><hr style=3D"width: 210px; height: 1px;" col= or=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><span><div style=3D"MARGI= N: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"><div>like.ma(a)cs2c.com.cn</= div></div></span></div>=0A<blockquote style=3D"margin-top: 0px; margin-bot= tom: 0px; margin-left: 0.5em;"><div> </div><div style=3D"border:none;= border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PA= DDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;CO= LOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><= div><b>From:</b> <a href=3D"mailto:like.ma@cs2c.com.cn">like.ma(a)cs2c.= com.cn</a></div><div><b>Date:</b> 2015-05-07 20:01</div><div><b>= To:</b> <a href=3D"mailto:nsoffer@redhat.com">Nir Soffer</a></div><di= v><b>Subject:</b> Re: Re: [ovirt-devel] vdsClient getVGList returned = Empty</div></div></div><div><div class=3D"FoxDiv20150513085609433047">=0A<= div><span></span><div>Thank you for your reply. </div><div><br></div>= <div>Following is the output:</div><div><br></div><div> [root@jzjdve&= nbsp;~]# pvscan --cache && lvs -o al= l|more<br>  LV UUID      &nbs= p;            =             &n= bsp;LV           &n= bsp;           &nbs= p;           Pa<br>= th            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p; Att<br>r       Active Maj&= nbsp;Min Rahead KMaj KMin KRahead LSize &nbs= p; MSize  #Seg Origin OSize<br> Data% &= nbsp;Snap%  Meta%  Cpy%Sync Cpy%Sync Mismatc= hes SyncAction WBehind MinSync Ma<br>xSync Move&n= bsp;Convert Log Data Meta Pool LV Tags<br>&n= bsp;           &nbs= p;            =             &n= bsp;      LProfile Time<br>Host &n= bsp;     Modules Fmt  VG UUID=             &n= bsp;           &nbs= p;       VG<br>    =             &n= bsp;   Attr   VSize   VFree&n= bsp;  SYS ID Ext     #Ext&nbs= p; Free MaxLV MaxPV<br> #PV #LV #SN Seq=  VG Tags<br><br>RICCF 2015/5/7 19:52:30<br><br><br><br= ><br><br><br><br><br><br><br>     VProfile #= VMda #VMdaUse VMdaFree  VMdaSize  #VMdaCps<b= r>  q2G0ZV-vklp-4LbF-oYiS-22qo-02Wb-CqS1Y5 1e94d2b6-7956-4b= ec-86bc-832211d36d6f /d<br>ev/ede37a89-5c1b-4d53-ad07-8a11ba209f61/1e= 94d2b6-7956-4bec-86bc-832211d36d6f -wi<br>-a----- active &n= bsp;-1  -1   auto 253  17 &nb= sp; 512.00k   1.00t     &nbsp= ;     1<br><br>RICCF 2015/5/7 19:53:09<= br><br>           &= nbsp;           &nb= sp;           &nbsp= ;  MD_15,PU_00000000-0000-0000-0000-000000000<br>000,IU_d0d88935= -c8a4-4563-941d-775bc085cc2d       &nbs= p;  2015-04-19 16:18:23 +0800<br>jzjdve.com &nbsp= ;       lvm2 hvo5lR-abga-Xv2v-txAT= -5TDT-0v87-Wy7bAE ede37a89-5c1b-4d5<br>3-ad07-8a11ba209f61 wz--n= -   4.00t 737.00g      &= nbsp; 128.00m 32765 5896     0&nbs= p;    0<br>   1  25 &nbs= p; 0 193 MDT_LEASETIMESEC=3D60,MDT_CLASS=3DData,MDT_VERSION= =3D3,MDT_LOGBLKSIZE<br>=3D512,MDT_VGUUID=3Dhvo5lR-abga-Xv2v-txAT-5TDT-0v87= -Wy7bAE,MDT_PV0=3Dpv:36e09796100b6a<br>b9d000d383400000002&44&uuid= :D0B18v-naul-qSrN-EAr3-y27S-1wtr-ceG9qF&44&pestart:0&<br>44&am= p;pecount:32765&44&mapoffset:0,MDT_DESCRIPTION=3Dve_storage,MDT_LE= ASERETRIES=3D3,MD<br>T_IOOPTIMEOUTSEC=3D10,MDT_LOCKRENEWALINTERVALSEC=3D5,= MDT_PHYBLKSIZE=3D512,MDT_TYPE=3DFCP<br>,MDT_LOCKPOLICY=3D,MDT_SDUUID=3Dede= 37a89-5c1b-4d53-ad07-8a11ba209f61,RHAT_storage_do<br>main,MDT_POOL_UUID=3D= 5849b030-626e-47cb-ad90-3ce782d831b3,MDT_POOL_DESCRIPTION=3DDef<br>ault,MD= T_ROLE=3DMaster,MDT_MASTER_VERSION=3D1,MDT_POOL_DOMAINS=3Dede37a89-5c1b-4d= 53-ad<br>07-8a11ba209f61:Active&44&6cdc15fb-974c-4407-9b42-65b6f99= b19f5:Active,MDT_POOL_S<br>PM_ID=3D1,MDT__SHA_CKSUM=3D557fcbb72833b9f2f485= 5bbfcca92908c1b331a4,MDT_POOL_SPM_LVE<br>R=3D14    &nb= sp;         2  &nbs= p;     2    63.99m &nbsp= ; 128.00m unmanaged<br>  lj0jhT-tGqR-c0Hi-qGqS-5XF1-Pr= RV-ZOkEM8 1f37922f-3d11-4809-a5db-cb2e965a80f8 /d<br>ev/ede37a89= -5c1b-4d53-ad07-8a11ba209f61/1f37922f-3d11-4809-a5db-cb2e965a80f8 -wi= <br>-a----- active  -1  -1   auto&= nbsp;253  27   512.00k 900.00g  &n= bsp;        1<br><br>  &= nbsp;           &nb= sp;           &nbsp= ;           MD_25,P= U_00000000-0000-0000-0000-000000000<br>000,IU_5c5c9121-3f0a-403c-ae53-4635= 0bff6aca          2015-0= 4-20 19:22:09 +0800<br>jzjdve.com     &= nbsp;   lvm2 hvo5lR-abga-Xv2v-txAT-5TDT-0v87-Wy7bAE&nb= sp;ede37a89-5c1b-4d5<br>3-ad07-8a11ba209f61 wz--n-   4= .00t 737.00g        128.00m&n= bsp;32765 5896     0    =  0<br><br>RICCF 2015/5/7 19:53:38<br><br>   = 1  25   0 193 MDT_LEASETIMESEC=3D60,MDT= _CLASS=3DData,MDT_VERSION=3D3,MDT_LOGBLKSIZE<br>=3D512,MDT_VGUUID=3Dhvo5lR= -abga-Xv2v-txAT-5TDT-0v87-Wy7bAE,MDT_PV0=3Dpv:36e09796100b6a<br>b9d000d383= 400000002&44&uuid:D0B18v-naul-qSrN-EAr3-y27S-1wtr-ceG9qF&44&am= p;pestart:0&<br>44&pecount:32765&44&mapoffset:0,MDT_DESCRI= PTION=3Dve_storage,MDT_LEASERETRIES=3D3,MD<br>T_IOOPTIMEOUTSEC=3D10,MDT_LO= CKRENEWALINTERVALSEC=3D5,MDT_PHYBLKSIZE=3D512,MDT_TYPE=3DFCP<br>,MDT_LOCKP= OLICY=3D,MDT_SDUUID=3Dede37a89-5c1b-4d53-ad07-8a11ba209f61,RHAT_storage_do= <br>main,MDT_POOL_UUID=3D5849b030-626e-47cb-ad90-3ce782d831b3,MDT_POOL_DES= CRIPTION=3DDef<br>ault,MDT_ROLE=3DMaster,MDT_MASTER_VERSION=3D1,MDT_POOL_D= OMAINS=3Dede37a89-5c1b-4d53-ad<br>07-8a11ba209f61:Active&44&6cdc15= fb-974c-4407-9b42-65b6f99b19f5:Active,MDT_POOL_S<br>PM_ID=3D1,MDT__SHA_CKS= UM=3D557fcbb72833b9f2f4855bbfcca92908c1b331a4,MDT_POOL_SPM_LVE<br>R=3D14&n= bsp;           &nbs= p; 2        2  &nbs= p; 63.99m   128.00m unmanaged<br>  16sE= N2-wmFC-yjwN-Nwgm-rX5A-pKmR-A5UIhI 2dc72f9d-e170-4f8d-b415-ac4dc69141= 91 /d<br>ev/ede37a89-5c1b-4d53-ad07-8a11ba209f61/2dc72f9d-e170-4f8d-b= 415-ac4dc6914191 -wi<br>-a----- active  -1  = -1   auto 253  12   512.00k&n= bsp;300.00g          &nb= sp;1<br><br>          &n= bsp;           &nbs= p;            =    IU_76c8a622-46f7-4def-a4fa-0b74d581e564,PU<br>_00000000-= 0000-0000-0000-000000000000,MD_10      &nbsp= ;   2015-03-24 12:13:13 +0800<br>jzjdve.com =         lvm2 hvo5lR-abga-Xv2v= -txAT-5TDT-0v87-Wy7bAE ede37a89-5c1b-4d5<br>3-ad07-8a11ba209f61 = wz--n-   4.00t 737.00g     &n= bsp;  128.00m 32765 5896     = 0     0<br>   1  25&nbsp= ;  0 193 MDT_LEASETIMESEC=3D60,MDT_CLASS=3DData,MDT_VE= RSION=3D3,MDT_LOGBLKSIZE<br>=3D512,MDT_VGUUID=3Dhvo5lR-abga-Xv2v-txAT-5TDT= -0v87-Wy7bAE,MDT_PV0=3Dpv:36e09796100b6a<br>b9d000d383400000002&44&amp= ;uuid:D0B18v-naul-qSrN-EAr3-y27S-1wtr-ceG9qF&44&pestart:0&<br>= 44&pecount:32765&44&mapoffset:0,MDT_DESCRIPTION=3Dve_storage,M= DT_LEASERETRIES=3D3,MD<br>19:54:14<br>RICCF 2015/5/7 19:54:14<br= ><br>T_IOOPTIMEOUTSEC=3D10,MDT_LOCKRENEWALINTERVALSEC=3D5,MDT_PHYBLKSIZE= =3D512,MDT_TYPE=3DFCP<br>,MDT_LOCKPOLICY=3D,MDT_SDUUID=3Dede37a89-5c1b-4d5= 3-ad07-8a11ba209f61,RHAT_storage_do<br>main,MDT_POOL_UUID=3D5849b030-626e-= 47cb-ad90-3ce782d831b3,MDT_POOL_DESCRIPTION=3DDef<br>ault,MDT_ROLE=3DMaste= r,MDT_MASTER_VERSION=3D1,MDT_POOL_DOMAINS=3Dede37a89-5c1b-4d53-ad<br>07-8a= 11ba209f61:Active&44&6cdc15fb-974c-4407-9b42-65b6f99b19f5:Active,M= DT_POOL_S<br>PM_ID=3D1,MDT__SHA_CKSUM=3D557fcbb72833b9f2f4855bbfcca92908c1= b331a4,MDT_POOL_SPM_LVE<br>R=3D14      &nbsp= ;       2     =    2    63.99m   128.00m=  unmanaged<br>  chQNHg-8kOj-ihFL-UHZo-RCPW-RwUj-cQEVof&nbsp= ;40658bf4-db2b-4fa7-bb0f-6d54ab022338 /d<br>ev/ede37a89-5c1b-4d53-ad0= 7-8a11ba209f61/40658bf4-db2b-4fa7-bb0f-6d54ab022338 -wi<br>-a-----&nb= sp;active  -1  -1   auto 253 =  18   512.00k   1.00g   =         1<br><br>  &nbsp= ;            &= nbsp;           &nb= sp;          MD_16,PU_b7= 22fe49-f04a-4958-87a1-83c0299d7<br>b13,IU_81e36639-3a15-4fe7-9dbf-7ed12c56= abb6          2015-04-19=  16:19:41 +0800<br>jzjdve.com     &nbsp= ;   lvm2 hvo5lR-abga-Xv2v-txAT-5TDT-0v87-Wy7bAE e= de37a89-5c1b-4d5<br>3-ad07-8a11ba209f61 wz--n-   4.00t=  737.00g        128.00m = 32765 5896     0    &nbs= p;0<br>   1  25   0 193 = MDT_LEASETIMESEC=3D60,MDT_CLASS=3DData,MDT_VERSION=3D3,MDT_LOGBLKSIZE<br>= =3D512,MDT_VGUUID=3Dhvo5lR-abga-Xv2v-txAT-5TDT-0v87-Wy7bAE,MDT_PV0=3Dpv:36= e09796100b6a<br>b9d000d383400000002&44&uuid:D0B18v-naul-qSrN-EAr3-= y27S-1wtr-ceG9qF&44&pestart:0&<br>44&pecount:32765&44&= amp;mapoffset:0,MDT_DESCRIPTION=3Dve_storage,MDT_LEASERETRIES=3D3,MD<br>T_= IOOPTIMEOUTSEC=3D10,MDT_LOCKRENEWALINTERVALSEC=3D5,MDT_PHYBLKSIZE=3D512,MD= T_TYPE=3DFCP<br>,MDT_LOCKPOLICY=3D,MDT_SDUUID=3Dede37a89-5c1b-4d53-ad07-8a= 11ba209f61,RHAT_storage_do<br>main,MDT_POOL_UUID=3D5849b030-626e-47cb-ad90= -3ce782d831b3,MDT_POOL_DESCRIPTION=3DDef<br>ault,MDT_ROLE=3DMaster,MDT_MAS= TER_VERSION=3D1,MDT_POOL_DOMAINS=3Dede37a89-5c1b-4d53-ad<br><br>RICCF&nbsp= ;2015/5/7 19:54:46<br><br>07-8a11ba209f61:Active&44&6cdc15fb-= 974c-4407-9b42-65b6f99b19f5:Active,MDT_POOL_S<br>PM_ID=3D1,MDT__SHA_CKSUM= =3D557fcbb72833b9f2f4855bbfcca92908c1b331a4,MDT_POOL_SPM_LVE<br>R=3D14&nbs= p;            =  2        2   =  63.99m   128.00m unmanaged<br>  6AeMHf= -NaZq-Z4Lv-BHaa-o0iU-lP8b-j3U0cK 407e4ccb-dd56-4d45-8fd8-43162690794e=  /d<br>ev/ede37a89-5c1b-4d53-ad07-8a11ba209f61/407e4ccb-dd56-4d45-8fd= 8-43162690794e -wi<br>-a----- active  -1  -1=    auto 253  24   512.00k&nbs= p;  1.00g         &= nbsp; 1<br><br>         =             &n= bsp;           &nbs= p;    PU_00000000-0000-0000-0000-000000000000,MD<br>_2= 0,IU_df30a325-e7b2-4734-9783-fdc469d2aaf6     &nb= sp;    2015-04-19 16:57:15 +0800<br>jzjdve.c= om         lvm2 hvo5lR-a= bga-Xv2v-txAT-5TDT-0v87-Wy7bAE ede37a89-5c1b-4d5<br>3-ad07-8a11ba209f= 61 wz--n-   4.00t 737.00g    =     128.00m 32765 5896   &nbs= p; 0     0<br>   1 &nbsp= ;25   0 193 MDT_LEASETIMESEC=3D60,MDT_CLASS=3DDat= a,MDT_VERSION=3D3,MDT_LOGBLKSIZE<br>=3D512,MDT_VGUUID=3Dhvo5lR-abga-Xv2v-t= xAT-5TDT-0v87-Wy7bAE,MDT_PV0=3Dpv:36e09796100b6a<br>b9d000d383400000002&am= p;44&uuid:D0B18v-naul-qSrN-EAr3-y27S-1wtr-ceG9qF&44&pestart:0&= amp;<br>44&pecount:32765&44&mapoffset:0,MDT_DESCRIPTION=3Dve_s= torage,MDT_LEASERETRIES=3D3,MD<br>T_IOOPTIMEOUTSEC=3D10,MDT_LOCKRENEWALINT= ERVALSEC=3D5,MDT_PHYBLKSIZE=3D512,MDT_TYPE=3DFCP<br>,MDT_LOCKPOLICY=3D,MDT= _SDUUID=3Dede37a89-5c1b-4d53-ad07-8a11ba209f61,RHAT_storage_do<br>main,MDT= _POOL_UUID=3D5849b030-626e-47cb-ad90-3ce782d831b3,MDT_POOL_DESCRIPTION=3DD= ef<br>ault,MDT_ROLE=3DMaster,MDT_MASTER_VERSION=3D1,MDT_POOL_DOMAINS=3Dede= 37a89-5c1b-4d53-ad<br>07-8a11ba209f61:Active&44&6cdc15fb-974c-4407= -9b42-65b6f99b19f5:Active,MDT_POOL_S<br>PM_ID=3D1,MDT__SHA_CKSUM=3D557fcbb= 72833b9f2f4855bbfcca92908c1b331a4,MDT_POOL_SPM_LVE<br>R=3D14  &n= bsp;           2&nb= sp;       2    63.9= 9m   128.00m unmanaged<br>19:57:13<br>RICCF 2015/= 5/7 19:57:13<br><br><font color=3D"#ff0000">lv is too much, above is = just a part of output</font><br><br>[root@jzjdve ~]# pvscan&nbsp= ;--cache && vgs -o all<br>  Fmt&nbsp= ; VG UUID         &= nbsp;           &nb= sp;          VG &nb= sp;           &nbsp= ;            &= nbsp;        Attr  &nbsp= ;VSize   VFree   SYS ID Ext &= nbsp;   #Ext  Free MaxLV MaxPV #PV=  #LV #SN Seq VG Tags    &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           &nbsp= ;            &= nbsp;           &nb= sp;           VProf= ile #VMda #VMdaUse VMdaFree  VMdaSize  = #VMdaCps<br>  lvm2 hvo5lR-abga-Xv2v-txAT-5TDT-0v87-Wy7bAE&n= bsp;ede37a89-5c1b-4d53-ad07-8a11ba209f61 wz--n-   4.00= t 737.00g        128.00m&nbsp= ;32765 5896     0    &nb= sp;0   1  25   0 193 MDT= _LEASETIMESEC=3D60,MDT_CLASS=3DData,MDT_VERSION=3D3,MDT_LOGBLKSIZE=3D512,M= DT_VGUUID=3Dhvo5lR-abga-Xv2v-txAT-5TDT-0v87-Wy7bAE,MDT_PV0=3Dpv:36e0979610= 0b6ab9d000d383400000002&44&uuid:D0B18v-naul-qSrN-EAr3-y27S-1wtr-ce= G9qF&44&pestart:0&44&pecount:32765&44&mapoffset:0,= MDT_DESCRIPTION=3Dve_storage,MDT_LEASERETRIES=3D3,MDT_IOOPTIMEOUTSEC=3D10,= MDT_LOCKRENEWALINTERVALSEC=3D5,MDT_PHYBLKSIZE=3D512,MDT_TYPE=3DFCP,MDT_LOC= KPOLICY=3D,MDT_SDUUID=3Dede37a89-5c1b-4d53-ad07-8a11ba209f61,RHAT_storage_= domain,MDT_POOL_UUID=3D5849b030-626e-47cb-ad90-3ce782d831b3,MDT_POOL_DESCR= IPTION=3DDefault,MDT_ROLE=3DMaster,MDT_MASTER_VERSION=3D1,MDT_POOL_DOMAINS= =3Dede37a89-5c1b-4d53-ad07-8a11ba209f61:Active&44&6cdc15fb-974c-44= 07-9b42-65b6f99b19f5:Active,MDT_POOL_SPM_ID=3D1,MDT__SHA_CKSUM=3D557fcbb72= 833b9f2f4855bbfcca92908c1b331a4,MDT_POOL_SPM_LVER=3D14   &n= bsp;          2 &nb= sp;      2    63.99m&nbs= p;  128.00m unmanaged<br>  lvm2 popc7C-ShBj-= 5a5H-S9Wy-TL0W-KX4n-h8gmMc vg_gzjdve     &nb= sp;           &nbsp= ;          wz--n- 5= 58.38g      0     &= nbsp;    64.00m  8934   &nbsp= ;0     0     0 &nbs= p; 1   3   0   4 &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;           1&nbsp= ;       1   507.50k&nbsp= ; 1020.00k unmanaged<br></div></div>=0A<div><br></div><hr style= =3D"width: 210px; height: 1px;" color=3D"#b5c4df" size=3D"1" align=3D"left= ">=0A<div><span><div style=3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZ= E: 10pt"><div>like.ma(a)cs2c.com.cn</div></div></span></div>=0A<blockquote s= tyle=3D"margin-top: 0px; margin-bottom: 0px; margin-left: 0.5em;"><div>&nb= sp;</div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:= 3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FO= NT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDI= NG-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From:</b> <a href=3D"mailto= :nsoffer@redhat.com">Nir Soffer</a></div><div><b>Date:</b> 2015-05-07=  19:45</div><div><b>To:</b> <a href=3D"mailto:like.ma@cs2c.com.c= n">like ma</a></div><div><b>CC:</b> <a href=3D"mailto:users@ovirt.org= ">users</a>; <a href=3D"mailto:devel@ovirt.org">devel</a></div><div><b>Sub= ject:</b> Re: [ovirt-devel] vdsClient getVGList returned Empty</div><= /div></div><div><div>> Hi, guys</div>=0A<div>> I have a vdsm host, w= hen i use "vgs" command, it will display 2 volume group</div>=0A<div>> = which already exist. But when i use "vdsClient -s 0 getVGList", it display= s</div>=0A<div>> nothing. That means vdsm cannot see the existed vg. Wh= y? Does anybody have</div>=0A<div>> any idea?</div>=0A<div>> </div>= =0A<div>> P.S. In fact, i am trying to resolve the problem of "Cannot f= ind master</div>=0A<div>> domain"</div>=0A<div> </div>=0A<div>Can = you shared the output of:</div>=0A<div> </div>=0A<div>pvscan --cache = && lvs -o all</div>=0A<div>pvscan --cache && vgs -o all</d= iv>=0A<div> </div>=0A<div>Nir</div>=0A</div></blockquote>=0A</div></d= iv></blockquote>=0A</body></html> ------=_001_NextPart535338448774_=------

1 0

Windows Internet connection issue
by gefter chongong - NOAA Affiliate 12 May '15

12 May '15

We are running oVirt Engine Version: 3.5.0.1-1.el6, this is running on Super micros. We have 5 hosts in a cluster on VMs built on this. Hosts Network interfaces are bonded and mode 4 (LACP). On the bonds we have VLANS for different networks, and all linux vms built on these hosts work and can access the internet. We are having issues with windows VMs. They cannot access the internet. Pings to external sites work, no failures, DNS not an issue but when browsing pages, the page keeps spinning and would not open... Anybody experience this issue, would be greatful for any pointers. thanks

2 1

Gluster command [<UNKNOWN>] failed on server
by suporte＠logicworks.pt 12 May '15

12 May '15

------=_Part_495943_1653700285.1431343853244 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I'm testing ovirt 3.5.1, with hosted engine, using centos7.1. Have installed some VMs, no problem. I needed to shutdown the computer machines (follow this procedure: http://lists.ovirt.org/pipermail/users/2014-April/023861.html ), after rebooting could not get it working again, when trying to activate the hosts this message come up: Gluster command [<UNKNOWN>] failed on server I have tried a lot of things, including update it to Version 3.5.2-1.el7.centos, but no success. Gluster version: glusterfs-3.6.3-1.el7.x86_64 glusterfs-libs-3.6.3-1.el7.x86_64 glusterfs-fuse-3.6.3-1.el7.x86_64 glusterfs-cli-3.6.3-1.el7.x86_64 glusterfs-rdma-3.6.3-1.el7.x86_64 glusterfs-api-3.6.3-1.el7.x86_64 Any help? -- Jose Ferradeira http://www.logicworks.pt ------=_Part_495943_1653700285.1431343853244 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Times New Roman; font-size: 10pt; co= lor: #000000"><div><div>Hi,</div><div><br></div><div>I'm testing ovirt 3.5.= 1, with hosted engine, using centos7.1. Have installed some VMs, no problem= . I needed to shutdown the computer machines (follow this procedure: <span = class=3D"Object" id=3D"OBJ_PREFIX_DWT216_com_zimbra_url"><span class=3D"Obj= ect" id=3D"OBJ_PREFIX_DWT218_com_zimbra_url"><a href=3D"http://lists.ovirt.= org/pipermail/users/2014-April/023861.html" target=3D"_blank" data-mce-href= =3D"http://lists.ovirt.org/pipermail/users/2014-April/023861.html">http://l= ists.ovirt.org/pipermail/users/2014-April/023861.html</a></span></span> ), = after rebooting could not get it <br>working again, when trying to activate= the hosts this message come up: Gluster command [<UNKNOWN>] failed o= n server</div><div>I have tried a lot of things, including update it to <sp= an class=3D"version-text">Version 3.5.2-1.el7.centos, but no success.</span= ></div><div><span class=3D"version-text">Gluster version:<br></span></div><= div><span class=3D"version-text">glusterfs-3.6.3-1.el7.x86_64<br>glusterfs-= libs-3.6.3-1.el7.x86_64<br>glusterfs-fuse-3.6.3-1.el7.x86_64<br>glusterfs-c= li-3.6.3-1.el7.x86_64<br>glusterfs-rdma-3.6.3-1.el7.x86_64<br>glusterfs-api= -3.6.3-1.el7.x86_64<br><br></span></div><span class=3D"version-text">Any he= lp?</span></div><div><br></div><div>-- <br></div><div><span name=3D"x"></sp= an><hr style=3D"width: 100%; height: 2px;" data-mce-style=3D"width: 100%; h= eight: 2px;">Jose Ferradeira<br>http://www.logicworks.pt<br><span name=3D"x= "></span><br></div></div></body></html> ------=_Part_495943_1653700285.1431343853244--

4 8

Vdsm Disk Images - preallocation vs thin provision
by ml＠ohnewald.net 12 May '15

12 May '15

Hello List, i read http://www.ovirt.org/Vdsm_Disk_Images, however i am missing the information if thin provision will also take care if the max storage size? E.g. If i have 1000GB total storage. Will then ovirt save me from creating 11x 100GB Disks? 11x100GB Full Disks >= 1000GB Total storage. Thanks, Mario

2 1

Re: [ovirt-users] [SOLVED] Problem with a second host: Exit message: internal error: Cannot find suitable CPU model for given data.
by Julián Tete 12 May '15

12 May '15

Hi Friends of oVirt I talked with the network administrator and remove the proxy rules to a range of IP's, installed oVirt with hosted engine on CentOS 7.1 and everything run just fine. Previously I set the enviroment settings to include the include proxy and proxy exceptions for the all the users of the system with a file in /etc/profile.d/ directory. I used to do this and always works. It's a bug in oVirt ? My ovirt-image-repository it's working now and with IP's behind the proxy doesn't. oVirt doesn't play nice behind a web proxy ? ovirt-image-repository ------------------------------ This article originally appeared on community.redhat.com. Follow the community on Twitter at @redhatopen <https://twitter.com/redhatopen>, and find us on Facebook <https://www.facebook.com/redhatopen> and Goo <https://plus.google.com/u/0/b/113258037797946990391/113258037797946990391/p…> 2015-04-29 2:58 GMT-05:00 Yedidyah Bar David <didi(a)redhat.com>: > ----- Original Message ----- > > From: "Yedidyah Bar David" <didi(a)redhat.com> > > To: "Julián Tete" <danteconrad14(a)gmail.com> > > Cc: users(a)ovirt.org > > Sent: Wednesday, April 29, 2015 10:51:48 AM > > Subject: Re: [ovirt-users] Problem with a second host: Exit message: > internal error: Cannot find suitable CPU model > > for given data. > > > > ----- Original Message ----- > > > From: "Julián Tete" <danteconrad14(a)gmail.com> > > > To: "Yedidyah Bar David" <didi(a)redhat.com> > > > Cc: users(a)ovirt.org > > > Sent: Wednesday, April 29, 2015 7:20:34 AM > > > Subject: Re: [ovirt-users] Problem with a second host: Exit message: > > > internal error: Cannot find suitable CPU model > > > for given data. > > > > > > Hi > > > > > > Thanks for advices. :) > > > > > > I reinstalled the Second Host, Installed QEMU/KVM with virt-manager, > > > created virtual machines, no hassle. > > > > > > I don't think in BIOS problem, beacuse are new machines and I didn't > touch > > > anything. > > > > Please double check that, also compare with the working host. > > See also: > > https://bugzilla.redhat.com/show_bug.cgi?id=1103672 > > Best, > > > > > > > > > Yesterday I did format the Second Host and try the Server-World > aproach on > > > CentOS 7: > > > > > > http://www.server-world.info/en/note?os=CentOS_6&p=ovirt&f=2 > > > > > > Didn't work > > > > > > Today i'm going to format the machine and try to install a hosted > engine on > > > the Second Host. > > > > > > I'm listening suggestions. > > > > I don't have many more, sorry. > > > > If BIOS Setup is exactly the same, I suggest to ask this in a libvirt > mailing > > list. > > > > Best, > > > > > > > > > > > > > > 2015-04-28 1:03 GMT-05:00 Yedidyah Bar David <didi(a)redhat.com>: > > > > > > > ----- Original Message ----- > > > > > From: "Julián Tete" <danteconrad14(a)gmail.com> > > > > > To: "Yedidyah Bar David" <didi(a)redhat.com> > > > > > Cc: users(a)ovirt.org > > > > > Sent: Tuesday, April 28, 2015 12:32:37 AM > > > > > Subject: Re: [ovirt-users] Problem with a second host: Exit > message: > > > > internal error: Cannot find suitable CPU model > > > > > for given data. > > > > > > > > > > Check this out: > > > > > > > > > > First Host; > > > > > > > > > > Input: > > > > > > > > > > systemctl status libvirtd.service -l > > > > > > > > > > Output: > > > > > > > > > > libvirtd.service - Virtualization daemon > > > > > Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; > enabled) > > > > > Active: active (running) since vie 2015-04-24 20:28:11 COT; 2 > days > > > > > ago > > > > > Docs: man:libvirtd(8) > > > > > http://libvirt.org > > > > > Main PID: 26351 (libvirtd) > > > > > CGroup: /system.slice/libvirtd.service > > > > > └─26351 /usr/sbin/libvirtd --listen > > > > > > > > > > abr 27 16:29:08 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:29:23 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:29:38 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:29:53 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:30:08 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:30:23 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:30:38 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:30:53 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:31:08 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > abr 27 16:31:23 patascoy.udistritaloas.edu.co libvirtd[26351]: > metadata > > > > not > > > > > found: Requested metadata element is not present > > > > > > > > > > Second Host: > > > > > > > > > > Input: > > > > > > > > > > systemctl status libvirtd.service -l > > > > > > > > > > Output: > > > > > > > > > > libvirtd.service - Virtualization daemon > > > > > Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; > enabled) > > > > > Active: active (running) since lun 2015-04-27 12:37:37 COT; 3h > 54min > > > > ago > > > > > Docs: man:libvirtd(8) > > > > > http://libvirt.org > > > > > Main PID: 1875 (libvirtd) > > > > > CGroup: /system.slice/libvirtd.service > > > > > └─1875 /usr/sbin/libvirtd --listen > > > > > > > > > > abr 27 15:28:12 sotara.udistritaloas.edu.co libvirtd[1875]: > Preferred > > > > CPU > > > > > model SandyBridge not allowed by hypervisor; closest supported > model > > > > > will > > > > > be used > > > > > abr 27 15:28:12 sotara.udistritaloas.edu.co libvirtd[1875]: > internal > > > > error: > > > > > Cannot find suitable CPU model for given data > > > > > > > > Well, you can search for these messages on the net... > > > > > > > > Are BIOS Setup settings identical between them? > > > > > > > > > abr 27 15:46:57 sotara.udistritaloas.edu.co libvirtd[1875]: > Preferred > > > > CPU > > > > > model Westmere not allowed by hypervisor; closest supported model > will > > > > > be > > > > > used > > > > > abr 27 15:46:57 sotara.udistritaloas.edu.co libvirtd[1875]: > internal > > > > error: > > > > > Cannot find suitable CPU model for given data > > > > > abr 27 15:48:17 sotara.udistritaloas.edu.co libvirtd[1875]: > Preferred > > > > CPU > > > > > model Westmere not allowed by hypervisor; closest supported model > will > > > > > be > > > > > used > > > > > abr 27 15:48:17 sotara.udistritaloas.edu.co libvirtd[1875]: > internal > > > > error: > > > > > Cannot find suitable CPU model for given data > > > > > abr 27 16:00:12 sotara.udistritaloas.edu.co libvirtd[1875]: > Preferred > > > > CPU > > > > > model Westmere not allowed by hypervisor; closest supported model > will > > > > > be > > > > > used > > > > > abr 27 16:00:12 sotara.udistritaloas.edu.co libvirtd[1875]: > internal > > > > error: > > > > > Cannot find suitable CPU model for given data > > > > > abr 27 16:07:52 sotara.udistritaloas.edu.co libvirtd[1875]: > Preferred > > > > CPU > > > > > model Westmere not allowed by hypervisor; closest supported model > will > > > > > be > > > > > used > > > > > abr 27 16:07:52 sotara.udistritaloas.edu.co libvirtd[1875]: > internal > > > > error: > > > > > Cannot find suitable CPU model for given data > > > > > > > > > > > > > > > > > > > > El lun., 27 abr. 2015 a las 16:19, Julián Tete > > > > > (<danteconrad14(a)gmail.com > > > > >) > > > > > escribió: > > > > > > > > > > > Hi Didi > > > > > > > > > > > > Thanks for your help > > > > > > > > > > > > It's the same hardware (IBM HS23) on all the machines > (SandyBridge > > > > CPU's) > > > > > > > > > > > > The first Host contains the Engine (It's Hosted-Engine) > > > > > > > > > > > > The Virtual machine works on the first host but doesn't on the > > > > > > second. > > > > > > (The State are Up in Both Hosts) > > > > > > > > > > > > I changed the number of CPUs on the virtual machine and nothing > > > > happens. > > > > > > > > > > > > Basic First Host Information: > > > > > > > > > > > > http://pastebin.com/TG7LVLVs > > > > > > > > > > > > First Host Relevant oVirt Information: > > > > > > > > > > > > http://pastebin.com/XAdf7Mt5 > > > > > > > > > > > > I don't undestand: "try to copy/paste the generated domain xml > from > > > > > > vdsm.log and use that with virsh cpu-compare?" > > > > > > > > > > > > Thanks in Advance > > > > > > > > > > > > El lun., 27 abr. 2015 a las 1:47, Yedidyah Bar David > > > > > > (<didi(a)redhat.com > > > > >) > > > > > > escribió: > > > > > > > > > > > >> ----- Original Message ----- > > > > > >> > From: "Julián Tete" <danteconrad14(a)gmail.com> > > > > > >> > To: users(a)ovirt.org > > > > > >> > Sent: Sunday, April 26, 2015 5:41:30 PM > > > > > >> > Subject: [ovirt-users] Problem with a second host: Exit > message: > > > > > >> internal error: Cannot find suitable CPU model for > > > > > >> > given data. > > > > > >> > > > > > > >> > Hello Friends of oVirt > > > > > >> > > > > > > >> > I'd setup a oVirt enviroment (hosted-engine) on BladeCenter > HS23 > > > > Blades > > > > > >> > > > > > > >> > All the machines are CentOS 7.1 > > > > > >> > > > > > > >> > Engine FQDN: ovirt.udistritaloas.edu.co > > > > > >> > Second Host FQDN: sotara.udistritaloas.edu.co > > > > > >> > FQDN Host with the Host-Engine and with the Data Master > Storage: > > > > > >> > patascoy.udistritaloas.edu.co > > > > > >> > > > > > > >> > When I try to start a Virtual Machine on a second Host I get: > > > > > >> > > > > > > >> > VM PrimeraMaquinaCentOS7 is down with error. Exit message: > > > > > >> > internal > > > > > >> error: > > > > > >> > Cannot find suitable CPU model for given data. > > > > > >> > > > > > > >> > Failed to run VM PrimeraMaquinaCentOS7 on Host > > > > > >> sotara.udistritaloas.edu.co . > > > > > >> > > > > > > >> > Failed to run VM PrimeraMaquinaCentOS7 (User: admin@internal > ). > > > > > >> > > > > > > >> > Packages in the second Host: > > > > > >> > > > > > > >> > vdsm-jsonrpc-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-gluster-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-python-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-4.16.10-8.gitc937927.el7.x86_64 > > > > > >> > vdsm-xmlrpc-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-cli-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-yajsonrpc-4.16.10-8.gitc937927.el7.noarch > > > > > >> > vdsm-python-zombiereaper-4.16.10-8.gitc937927.el7.noarch > > > > > >> > libvirt-daemon-driver-storage-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-kvm-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-driver-secret-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-python-1.2.8-7.el7_1.1.x86_64 > > > > > >> > libvirt-gobject-0.1.7-3.el7.x86_64 > > > > > >> > libvirt-glib-0.1.7-3.el7.x86_64 > > > > > >> > libvirt-daemon-driver-network-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-client-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-lock-sanlock-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-gconfig-0.1.7-3.el7.x86_64 > > > > > >> > libvirt-daemon-driver-nodedev-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-driver-interface-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-driver-qemu-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-driver-nwfilter-1.2.8-16.el7_1.2.x86_64 > > > > > >> > libvirt-daemon-config-nwfilter-1.2.8-16.el7_1.2.x86_64 > > > > > >> > qemu-kvm-common-rhev-1.5.3-60.el7_0.2.x86_64 > > > > > >> > libvirt-daemon-kvm-1.2.8-16.el7_1.2.x86_64 > > > > > >> > qemu-kvm-rhev-1.5.3-60.el7_0.2.x86_64 > > > > > >> > qemu-kvm-tools-rhev-1.5.3-60.el7_0.2.x86_64 > > > > > >> > ovirt-engine-sdk-python-3.5.1.0-1.el7.centos.noarch > > > > > >> > ovirt-hosted-engine-setup-1.2.2-1.el7.centos.noarch > > > > > >> > ovirt-hosted-engine-ha-1.2.5-1.el7.centos.noarch > > > > > >> > ovirt-release35-002-1.noarch > > > > > >> > ovirt-host-deploy-1.3.1-1.el7.noarch > > > > > >> > > > > > > >> > Basic Second Host Information: > > > > > >> > > > > > > >> > http://pastebin.com/KFWWtD9v > > > > > >> > > > > > > >> > Second Host Relevant oVirt Information: > > > > > >> > > > > > > >> > http://pastebin.com/Rvm9kNph > > > > > >> > > > > > > >> > Engine Log: > > > > > >> > > > > > > >> > http://pastebin.com/p7UK787e > > > > > >> > > > > > >> Some random things to check/post: > > > > > >> > > > > > >> Does this same VM work on the first host? Can you then > > > > > >> post relevant data on this first host? > > > > > >> > > > > > >> Did you try changing the number of cpus allocated to it? > > > > > >> > > > > > >> Can you try to copy/paste the generated domain xml from > > > > > >> vdsm.log and use that with virsh cpu-compare? > > > > > >> > > > > > >> Thanks, > > > > > >> -- > > > > > >> Didi > > > > > >> > > > > > > > > > > > > > > > > > > > -- > > > > Didi > > > > > > > > > > > > > > > -- > > Didi > > > > > > -- > Didi > >

2 3

[QE][ACTION REQUIRED] oVirt 3.6.0 alpha not passing basic sanity test - postponig by 1 week
by Sandro Bonazzola 12 May '15

12 May '15

Hi, we were supposed to release oVirt 3.6.0 Alpha release today but after repository composition it didn't pass basic sanity test, hitting Bug 1220772 - [Admin Portal] Can't create a VM using New Virtual Machine dialog Postponing oVirt 3.6.0 Alpha by one week[1]. Maintainers: please ensure that a basic operation like creating a vm will be possible before 2015-05-19 [1] http://www.ovirt.org/OVirt_3.6_Release_Management#Key_Milestones Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Problems with ISCSI storagedomain
by Luciano Natale 12 May '15

12 May '15

Hello everyone! I'm running oVirt 3.5, and recently had an issue with a split brain situation in the hosted engine's image. After solving that, I got the engine up an running, but something went wrong with my main storage. I have a datacenter with main storage being ISCSI, called vms-main-storage. This storagedomain is marked as inactive. The only action I can attemp to do to it is activate it. But it won't. It just fails and no reason is given in the web ui. I also tried activating it through the cli, and result is status 400, reason bad request, detail internal engine error. Strange thing is that VM's are still running with their images in this storage and they are running with no problem at all! How can I have this storagedomain again in a healthy state??? Thanks! -- Luciano Natale

2 1

Delete snapshot
by Johan Kooijman 12 May '15

12 May '15

Hi all, I created a snapshot on a VM, which I'd like to delete. No further snapshots were made, only this single only. The button delete is greyed out though, untill I power off the VM. I thought with live merge this wasn't needed any more, or am I mistaken? Engine running on CentOS 6 x64, latest stable versions of all packages. Am I missing something? -- Met vriendelijke groeten / With kind regards, Johan Kooijman

2 1

overt node el6 to el7 upgrade
by Charles Weber 12 May '15

12 May '15

Hi everyone I have been using node el6 with fiber channel multipathing and multiple NICS. Works fine. Obviously after 3.6.1 or .2 is out I will want to upgrade. How well do the nodes handle upgrading from el6 to el7? Has anyone done this? Thanks, Chuck

4 3

Hosted engine on iscsi and data domain on GFS2
by Sherif Nagy 11 May '15

11 May '15

HI, I have centos 7.1 latest update for hosts and VM that hosts the hosted engine, the hosted engine uses iSCSI storage and so far it is working correctly *as expected* , I have 1 shared DC, 1 Cluster and trying to add GFS2 storage as a master data domain, I am using corosync , pacemaker , pcs to manage the DLM and cLVM that is also working as expected, however whenever I try to add the GFS2 storage I get the following error message from VDSM.log ————— Thread-884::ERROR::2015-05-08 11:45:59,291::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) looking for domain 2435cdc4-61eb-4ad6-9669-e900f13b7f1d Thread-884::DEBUG::2015-05-08 11:45:59,291::lvm::371::Storage.OperationMutex::(_reloadvgs) Operation 'lvm reload operation' got the operation mutex Thread-884::DEBUG::2015-05-08 11:45:59,295::lvm::291::Storage.Misc.excCmd::(cmd) /usr/bin/sudo -n /sbin/lvm vgs --config ' devices { preferred_names = ["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_co unt=3 obtain_device_list_from_udev=0 filter = [ '\''a|/dev/mapper/CETUSRAID1E0A04V01|/dev/mapper/CETUSRAID1E0A04V02|/dev/mapper/CETUSRAID3E0A01V01|'\'', '\''r|.*|'\'' ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks =1 use_lvmetad=0 } backup { retain_min = 50 retain_days = 0 } ' --noheadings --units b --nosuffix --separator '|' --ignoreskippedcluster -o uuid,name,attr,size,free,extent_size,extent_count,free_count,tags,vg_mda_size,vg_mda_free,lv_c ount,pv_count,pv_name 2435cdc4-61eb-4ad6-9669-e900f13b7f1d (cwd None) Thread-884::DEBUG::2015-05-08 11:45:59,397::lvm::291::Storage.Misc.excCmd::(cmd) FAILED: <err> = ' Volume group "2435cdc4-61eb-4ad6-9669-e900f13b7f1d" not found\n Cannot process volume group 2435cdc4-61eb-4ad6-9669-e900f13b7f1d\n'; <rc> = 5 Thread-884::WARNING::2015-05-08 11:45:59,400::lvm::376::Storage.LVM::(_reloadvgs) lvm vgs failed: 5 [] [' Volume group "2435cdc4-61eb-4ad6-9669-e900f13b7f1d" not found', ' Cannot process volume group 2435cdc4-61eb-4ad6-9669-e900f13b7f1d '] Thread-884::DEBUG::2015-05-08 11:45:59,401::lvm::416::Storage.OperationMutex::(_reloadvgs) Operation 'lvm reload operation' released the operation mutex Thread-885::DEBUG::2015-05-08 11:45:59,403::__init__::298::IOProcessClient::(_run) Starting IOProcess... Thread-884::ERROR::2015-05-08 11:45:59,420::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 2435cdc4-61eb-4ad6-9669-e900f13b7f1d not found Traceback (most recent call last): 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: (u'2435cdc4-61eb-4ad6-9669-e900f13b7f1d',) Thread-884::INFO::2015-05-08 11:45:59,421::nfsSD::69::Storage.StorageDomain::(create) sdUUID=2435cdc4-61eb-4ad6-9669-e900f13b7f1d domainName=imagesGFS remotePath=/dev/mapper/gfs2_imgs-gfs2_imgs_lvm domClass=1 Thread-884::DEBUG::2015-05-08 11:45:59,434::__init__::298::IOProcessClient::(_run) Starting IOProcess... Thread-884::ERROR::2015-05-08 11:45:59,446::task::866::Storage.TaskManager.Task::(_setError) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Unexpected error Traceback (most recent call last): File "/usr/share/vdsm/storage/task.py", line 873, in _run return fn(*args, **kargs) File "/usr/share/vdsm/logUtils.py", line 45, in wrapper res = f(*args, **kwargs) File "/usr/share/vdsm/storage/hsm.py", line 2691, in createStorageDomain domVersion) File "/usr/share/vdsm/storage/nfsSD.py", line 80, in create version) File "/usr/share/vdsm/storage/nfsSD.py", line 49, in _preCreateValidation fileSD.validateFileSystemFeatures(sdUUID, domPath) File "/usr/share/vdsm/storage/fileSD.py", line 88, in validateFileSystemFeatures oop.getProcessPool(sdUUID).directTouch(testFilePath) File "/usr/share/vdsm/storage/outOfProcess.py", line 351, in directTouch ioproc.touch(path, flags, mode) File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 507, in touch self.timeout) File "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 391, in _sendCommand raise OSError(errcode, errstr) OSError: [Errno 13] Permission denied Thread-884::DEBUG::2015-05-08 11:45:59,447::task::885::Storage.TaskManager.Task::(_run) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Task._run: b574d8c6-af2b-4909-be53-248a5caff1c1 (6, u'2435cdc4-61eb-4ad6-9669-e900f13b7f1d', u'imagesGFS' , u'/dev/mapper/gfs2_imgs-gfs2_imgs_lvm', 1, u'3') {} failed - stopping task Thread-884::DEBUG::2015-05-08 11:45:59,447::task::1217::Storage.TaskManager.Task::(stop) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::stopping in state preparing (force False) Thread-884::DEBUG::2015-05-08 11:45:59,448::task::993::Storage.TaskManager.Task::(_decref) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::ref 1 aborting True Thread-884::INFO::2015-05-08 11:45:59,448::task::1171::Storage.TaskManager.Task::(prepare) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::aborting: Task is aborted: u'[Errno 13] Permission denied' - code 100 Thread-884::DEBUG::2015-05-08 11:45:59,448::task::1176::Storage.TaskManager.Task::(prepare) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Prepare: aborted: [Errno 13] Permission denied Thread-884::DEBUG::2015-05-08 11:45:59,449::task::993::Storage.TaskManager.Task::(_decref) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::ref 0 aborting True Thread-884::DEBUG::2015-05-08 11:45:59,449::task::928::Storage.TaskManager.Task::(_doAbort) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Task._doAbort: force False Thread-884::DEBUG::2015-05-08 11:45:59,449::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-884::DEBUG::2015-05-08 11:45:59,449::task::595::Storage.TaskManager.Task::(_updateState) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::moving from state preparing -> state aborting Thread-884::DEBUG::2015-05-08 11:45:59,448::task::993::Storage.TaskManager.Task::(_decref) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::ref 1 aborting True Thread-884::INFO::2015-05-08 11:45:59,448::task::1171::Storage.TaskManager.Task::(prepare) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::aborting: Task is aborted: u'[Errno 13] Permission denied' - code 100 Thread-884::DEBUG::2015-05-08 11:45:59,448::task::1176::Storage.TaskManager.Task::(prepare) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Prepare: aborted: [Errno 13] Permission denied Thread-884::DEBUG::2015-05-08 11:45:59,449::task::993::Storage.TaskManager.Task::(_decref) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::ref 0 aborting True Thread-884::DEBUG::2015-05-08 11:45:59,449::task::928::Storage.TaskManager.Task::(_doAbort) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::Task._doAbort: force False Thread-884::DEBUG::2015-05-08 11:45:59,449::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-884::DEBUG::2015-05-08 11:45:59,449::task::595::Storage.TaskManager.Task::(_updateState) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::moving from state preparing -> state aborting Thread-884::DEBUG::2015-05-08 11:45:59,450::task::550::Storage.TaskManager.Task::(__state_aborting) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::_aborting: recover policy none Thread-884::DEBUG::2015-05-08 11:45:59,450::task::595::Storage.TaskManager.Task::(_updateState) Task=`b574d8c6-af2b-4909-be53-248a5caff1c1`::moving from state aborting -> state failed Thread-884::DEBUG::2015-05-08 11:45:59,450::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-884::DEBUG::2015-05-08 11:45:59,450::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-884::ERROR::2015-05-08 11:45:59,451::dispatcher::79::Storage.Dispatcher::(wrapper) [Errno 13] Permission denied Traceback (most recent call last): File "/usr/share/vdsm/storage/dispatcher.py", line 71, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/share/vdsm/storage/task.py", line 103, in wrapper return m(self, *a, **kw) File "/usr/share/vdsm/storage/task.py", line 1179, in prepare raise self.error OSError: [Errno 13] Permission denied Thread-884::DEBUG::2015-05-08 11:45:59,452::stompReactor::163::yajsonrpc.StompServer::(send) Sending response JsonRpc (StompReactor)::DEBUG::2015-05-08 11:45:59,918::stompReactor::98::Broker.StompAdapter::(handle_frame) Handling message <StompFrame command='SEND'> JsonRpcServer::DEBUG::2015-05-08 11:45:59,920::__init__::506::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-887::DEBUG::2015-05-08 11:45:59,920::__init__::469::jsonrpc.JsonRpcServer::(_serveRequest) Calling 'StoragePool.disconnectStorageServer' in bridge with {u'connectionParams': [{u'password': u'', u'id': u'a52aaa59-a449-4158-bece-2e0a 0916dc78', u'connection': u'/dev/mapper/gfs2_imgs-gfs2_imgs_lvm', u'mnt_options': u'noatime,nodiratime', u'user': u'', u'tpgt': u'1', u'vfs_type': u'gfs2', u'iqn': u'', u'port': u''}], u'storagepoolID': u'00000000-0000-0000-0000-000000000 000', u'domainType': 6} Thread-887::DEBUG::2015-05-08 11:45:59,924::task::595::Storage.TaskManager.Task::(_updateState) Task=`dacc3945-1a0d-4b80-9e0b-dd0050179001`::moving from state init -> state preparing Thread-887::INFO::2015-05-08 11:45:59,925::logUtils::44::dispatcher::(wrapper) Run and protect: disconnectStorageServer(domType=6, spUUID=u'00000000-0000-0000-0000-000000000000', conList=[{u'iqn': u'', u'port': u'', u'connection': u'/dev/ mapper/gfs2_imgs-gfs2_imgs_lvm', u'mnt_options': u'noatime,nodiratime', u'user': u'', u'tpgt': u'1', u'vfs_type': u'gfs2', u'password': '******', u'id': u'a52aaa59-a449-4158-bece-2e0a0916dc78'}], options=None) Thread-887::DEBUG::2015-05-08 11:45:59,926::mount::227::Storage.Misc.excCmd::(_runcmd) /usr/bin/sudo -n /usr/bin/umount -f -l /rhev/data-center/mnt/_dev_mapper_gfs2__imgs-gfs2__imgs__lvm (cwd None) Thread-887::DEBUG::2015-05-08 11:45:59,995::misc::741::Storage.SamplingMethod::(__call__) Trying to enter sampling method (storage.sdc.refreshStorage) Thread-887::DEBUG::2015-05-08 11:45:59,997::misc::743::Storage.SamplingMethod::(__call__) Got in to sampling method ———— Any idea what that might be ? Thank You Sherif

1 1

HE: changing engine storage connection's interface
by Daniel Helgenberger 11 May '15

11 May '15

Hello, I have just deployed my new hosted engine (3.5.2). Now, after some basic infra is running, I want to change the NFS connection vdsm is using for HE's vm. Please advice me on this procedure: 1. set global maint. 2. shutdown HE and all VMs 3. stop engine-ha 4. stop vdsm 5. unmount engine domain 6. hosted-engine.conf storage= stection 7. start vdsm 8. start engine-ha 9. reconnect storage 10. -- repeat step 3 - 9 for all ha hosts Thanks! -- 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 www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767

1 0

[ANN] Async release for ovirt-engine is now available.
by Sandro Bonazzola 11 May '15

11 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The oVirt Team has just released a new version of ovirt-engine package for 3.5.2.1 that fixes a severe issue introduced in 3.5.2[1]. We recommend to all users who have already upgraded to 3.5.2 to update to this package. Thanks, [1] https://bugzilla.redhat.com/1214408 - Importing storage domains into an uninitialized datacenter leads to duplicate OVF_STORE disks being created, and can cause catastrophic loss of VM configuration data - -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVUK6QAAoJEHw3u57E4QAOLo0QALoe0zgCFSCOBScWGOJHAeXT 06ZnW0mObmWwM2T5n7VptVhhT/hES7hj5QfDdF666JKEsHKlkR71YewFqvRrn/6o ErkRmSo+yrBNSL1se1KQn3k/jLY9RGzF/1tjxc2jaWovA98ULNLXwgDRS+jBNvu2 lSvrCOAO8u5dSZnKl5oZTUN8vqWlzMB1TqbeV0/T7uuhTPwXeo/azLMtxdrLVecg t+zfFTcT3/BP+eVv0qr8lCxIo3UtjDN11H4VBzfb7cgP7Lg6D16MC7bawcYyuxIE waGfBFW1CtoeEWEQjic7Cti5j8pgxEc+bljw2PI09IPwEnMnBoqk1fwLg5LLCnnC eSkyoYN1vxo6ea2HF+Nm9lQ4uolkF3LUlC2017Jb4tYuhuF0ukTkUSEwBi8nfZzL 0/e08i4eglW3g01nIGRRQXq+kohClTWxLyVIUKgWlJ5RlHYooEMYV7qOYjFo/q3y 2ukMGrUZ27rokI/za3/5LkDUMizwh+XNzbO4qCeMd8UcHtsgs2vkElxJBVZ56nx8 EYIi7Mb1dogWtlcd1CE35h6FwnuqDdu/4iYJksH5vMa8aq411Ub65j4fgf4Xjy7D 1o51DuucZoasIkSuP1JiNc2HVOFZJ0hdsOkdLO9+oQ4tB84lMWe28OaRbIP0AV/u W6jpgUUcS+DPhBfkq0UI =zYZs -----END PGP SIGNATURE-----

4 3