September 2014 - Users - oVirt List Archives

Can't understand Template Sub Version
by John Xue 15 Sep '14

15 Sep '14

Sorry, add the email title. On Mon, Sep 15, 2014 at 3:43 PM, John Xue <xgxjohn(a)gmail.com> wrote: > Hi, All > > I'm using oVirt Engine Version: 3.4.3-1.el6, but I can't > understand this function. I have 3 question: > > 1 How to change a vm to use other template sub version? > I don't want to build a new vm from new template version. > 2 How to update a pool to use other template sub version? > I'm using non latest version, and shutdown all vm of this pool, > but I still can't change template version. > 3 How to create a pool with disable stateless function? > In the property of template vm, I'm sure I don't enable > "stateless". But in the testing, I found all the vm are stateless vm. > How to disable it, or I'll lost all config and personal data. > > Thank you very much! > > -- > Regards, > John Xue -- Regards, John Xue

1 0

ovirt 3.5 rc2 duplicate id (was Re: Duplicate ID 'drive-ide0-1-0' for drive .)
by Gianluca Cecchi 15 Sep '14

15 Sep '14

On Wed, Sep 10, 2014 at 7:01 PM, Dan Kenigsberg <danken(a)redhat.com> wrote: > On Wed, Sep 10, 2014 at 05:17:35PM +0200, Sven Kieske wrote: > > > > > > On 10/09/14 17:05, Nathanaël Blanchet wrote: > > > Hello everyone, > > > > > > I experiment the same error with all of my host with vdsm 4.14.11.2 > since I upgraded to engine 3.4.x. > > > I can't boot any new VMs, and the issue is about the duplicate ID > drive. > > > If I run once instead of "run", the vm boots fine. > > > I've tested the suggested workaround and it works but it is not > comfortable... > > > What about this nasty bug? will it be resolved with 3.4.4? > > > Thanks. > > > > I'm not aware of this bug reported at bugzilla.redhat.com > > > > I may have missed it because there are plenty of bugs, but if you > > don't report the bug there it's not very likely to get fixed. > > I'm not 100% that it's the same issue, but I have cloned > > Bug 1140323 - fails to run VM - duplicate ID > > to 3.4.4. Let's see if what virt developers say. > BTW: the same problem is still present in 3.5. rc2 I just tried with a centos 6.5 iso image. if you "erroneously" (?) attach cd iso during VM initial creation phase and you start VM you get the same problem. Then you use the run once and you are able to install os. But then you continue to have the same problem, even if you modify the VM and you say no cd is present at all. Only able to start it again with run once method. Instead if you create VM without specifying any cd and then you use the run once method to connect the iso and install the VM you get no problem at all with cd isos afterwards. It is quite annoying not being able to recover the situation. In engine.log 2014-09-16 00:22:49,683 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-17) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM c65 is down with error. Exit message: internal error process exited while connecting to monitor: qemu-kvm: -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=: Duplicate ID 'drive-ide0-1-0' for drive . 2014-09-16 00:22:49,684 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-17) Running on vds during rerun failed vm: null 2014-09-16 00:22:49,691 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-17) VM c65 (a858f04a-e4f4-49e8-a097-8ba8390b4d25) is running in db and not running in VDS ovnode04 2014-09-16 00:22:49,710 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-17) Rerun vm a858f04a-e4f4-49e8-a097-8ba8390b4d25. Called from vds ovnode04 2014-09-16 00:22:49,717 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-12) Correlation ID: 7599780, Job ID: 8d63e66b-b26b-4344-85e0-ab72bf53fa1d, Call Stack: null, Custom Event ID: -1, Message: Failed to run VM c65 on Host ovnode04. 2014-09-16 00:22:49,722 INFO [org.ovirt.engine.core.bll.RunVmCommand] (org.ovirt.thread.pool-8-thread-12) Lock Acquired to object EngineLock [exclusiveLocks= key: a858f04a-e4f4-49e8-a097-8ba8390b4d25 value: VM , sharedLocks= ] In VM.log on hypervisor under /var/log/libvirt/qemu/vm.log 2014-09-15 22:22:49.358+0000: starting up LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -na me c65 -S -M rhel6.5.0 -cpu Nehalem -enable-kvm -m 2048 -realtime mlock=off -smp 2,maxcpus =32,sockets=16,cores=2,threads=1 -uuid a858f04a-e4f4-49e8-a097-8ba8390b4d25 -smbios type=1 ,manufacturer=oVirt,product=oVirt Node,version=6-5.el6.centos.11.2,serial=9B1B2F84-3CB9-11 DE-B5A1-001517B493E8,uuid=a858f04a-e4f4-49e8-a097-8ba8390b4d25 -nodefconfig -nodefaults -c hardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/c65.monitor,server,nowait -mon cha rdev=charmonitor,id=monitor,mode=control -rtc base=2014-09-16T00:22:49,driftfix=slew -no-k vm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -devi ce virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/4512e567-f94e-476a-a050-6cd0a15e260a/346732c8-e1e9-49de-9ca4-63f4477ef6dd/images/c0a1e1a3-af66-482b-96b4-e8ec928053f7/c968201d-d3fe-4c29-904e-554004a43e3e,if=none,id=drive-scsi0-0-0-0,format=raw,serial=c0a1e1a3-af66-482b-96b4-e8ec928053f7,cache=none,werror=stop,rerror=stop,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:01:a4:a3:42:00,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/a858f04a-e4f4-49e8-a097-8ba8390b4d25.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/a858f04a-e4f4-49e8-a097-8ba8390b4d25.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -spice port=5902,tls-port=5903,addr=192.168.1.74,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k en-us -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 qemu-kvm: -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=: Duplicate ID 'drive-ide0-1-0' for drive 2014-09-15 22:22:49.633+0000: shutting down In vdsm.log Thread-159167::ERROR::2014-09-16 00:22:49,849::vm::2326::vm.Vm::(_startUnderlyingVm) vmId=`a858f04a-e4f4-49e8-a097-8ba8390b4d25`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 2266, in _startUnderlyingVm self._run() File "/usr/share/vdsm/virt/vm.py", line 3368, in _run self._connection.createXML(domxml, flags), File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: internal error process exited while connecting to monitor: qemu-kvm: -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=: Duplicate ID 'drive-ide0-1-0' for drive Thread-159167::DEBUG::2014-09-16 00:22:49,851::vm::2838::vm.Vm::(setDownStatus) vmId=`a858f04a-e4f4-49e8-a097-8ba8390b4d25`::Changed state to Down: internal error process exited while connecting to monitor: qemu-kvm: -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial=: Duplicate ID 'drive-ide0-1-0' for drive (code=1) JsonRpc (StompReactor)::DEBUG::2014-09-16 00:22:50,554::stompReactor::98::Broker.StompAdapter::(handle_frame) Handling message <StompFrame command='SEND'> JsonRpcServer::DEBUG::2014-09-16 00:22:50,556::__init__::504::jsonrpc.JsonRpcServer::(serve_requests) Waiting for request Thread-159169::DEBUG::2014-09-16 00:22:50,559::task::595::Storage.TaskManager.Task::(_updateState) Task=`ae3d407b-6c40-455e-a2d7-5ef55d95d1c5`::moving from state init -> state preparing Thread-159169::INFO::2014-09-16 00:22:50,559::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-159169::INFO::2014-09-16 00:22:50,559::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {u'3b23161a-18a3-4cfa-bc78-f4fe2052b19e': {'code': 0, 'version': 0, 'acquired': True, 'delay': '0.000441651', 'lastCheck': '8.2', 'valid': True}, '346732c8-e1e9-49de-9ca4-63f4477ef6dd': {'code': 0, 'version': 3, 'acquired': True, 'delay': '0.000640336', 'lastCheck': '3.5', 'valid': True}} Thread-159169::DEBUG::2014-09-16 00:22:50,559::task::1191::Storage.TaskManager.Task::(prepare) Task=`ae3d407b-6c40-455e-a2d7-5ef55d95d1c5`::finished: {u'3b23161a-18a3-4cfa-bc78-f4fe2052b19e': {'code': 0, 'version': 0, 'acquired': True, 'delay': '0.000441651', 'lastCheck': '8.2', 'valid': True}, '346732c8-e1e9-49de-9ca4-63f4477ef6dd': {'code': 0, 'version': 3, 'acquired': True, 'delay': '0.000640336', 'lastCheck': '3.5', 'valid': True}} Thread-159169::DEBUG::2014-09-16 00:22:50,559::task::595::Storage.TaskManager.Task::(_updateState) Task=`ae3d407b-6c40-455e-a2d7-5ef55d95d1c5`::moving from state preparing -> state finished Thread-159169::DEBUG::2014-09-16 00:22:50,559::resourceManager::940::Storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-159169::DEBUG::2014-09-16 00:22:50,559::resourceManager::977::Storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-159169::DEBUG::2014-09-16 00:22:50,560::task::993::Storage.TaskManager.Task::(_decref) Task=`ae3d407b-6c40-455e-a2d7-5ef55d95d1c5`::ref 0 aborting False Thread-159169::DEBUG::2014-09-16 00:22:50,563::stompReactor::163::yajsonrpc.StompServer::(send) Sending response ... Gianluca

1 0

Real time network usages and IO usages of VM
by Shanil S 15 Sep '14

15 Sep '14

Hi All, Is there any api methods to get the real time network usages and IO usages os of each vm ? I tried it by using api/vms/$id/statistics but its not getting the network and IO usages. Is it possible to get these details using the api calls ? -- Regards Shanil

4 3

Job Opening: Linux/oVirt Systems Administrator, London
by Jim Rippon 15 Sep '14

15 Sep '14

--=_f3eaf24f9c97e4bd44448bb357a58257 Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi List, I have an immediate start job role available in Notting Hill, London for a Linux Systems Administrator, ideally with experience of CentOS and oVirt and comfortable with common web hosting technologies and development tools. Please find a brief job description on our website at http://www.fanatix.com/jobs (look for "Systems Administrator") and submit any applications to jobs(a)fanatix.com or come back to me directly with any questions. All the best, Jim Rippon Senior Systems Administrator fanatix --=_f3eaf24f9c97e4bd44448bb357a58257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"> <html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri= f'> <p>Hi List,</p> <p>I have an immediate start job role available in Notting Hill, London for= a Linux Systems Administrator, ideally with experience of CentOS and oVirt= and comfortable with common web hosting technologies and development tools= =2E</p> <p>Please find a brief job description on our website at http://www.fanatix= =2Ecom/jobs (look for "Systems Administrator") and submit any applications = to jobs(a)fanatix.com or come back to me directly with any questions.</p> <p>All the best,</p> <p>Jim Rippon</p> <p>Senior Systems Administrator</p> <p>fanatix</p> <div> </div> </body></html> --=_f3eaf24f9c97e4bd44448bb357a58257--

1 0

[ANN] oVirt 3.5 Third Test Day - Wed Sep 17th
by Sandro Bonazzola 15 Sep '14

15 Sep '14

Hi all, On Wed Sep 17th (instead of Sep 16th) we'll have oVirt 3.5.0 third test day. On this day all relevant engineers will be online ready to support any issues you find during install / operating this new release. Just make sure you have 1 host or more to test drive the new release. If you're curious to see how it works, this is your chance. Thanks again for everyone who will join us tomorrow! Location #ovirt irc channel Please communicate here to allow others to see any issues What In this test day you have a license to kill ;) Follow the documentation to setup your environment, and test drive the new features. Please remember we expect to see some issues, and anything you come up with will save you when you'll install final release Remember to try daily tasks you'd usually do in the engine, to see there are no regressions. Write down the configuration you used (HW, console, etc) in the report etherpad[1]. Documentation Release notes: http://www.ovirt.org/OVirt_3.5_Release_Notes Features pages links: http://bit.ly/17qBn6F If you find errors in the wiki please annotate it as well in report etherpad [1] Prerequisites / recommendations Use CentOS or RHEL 6.5 only. 6.4 is unsupported due to various issues (sanlock, libvirt, etc). Use Fedora 19 or 20. Latest RPMs repository to be enabled for testing the release are listed in the release notes page [2]. NEW issues / reports For any new issue, please update the reports etherpad [1] Feature owners, please make sure: your feature is updated and referenced on release page [2]. you have testing instruction for your feature either on test day page [3] or in your feature page. your team regression testing section is organized and up to date on test day page [3]. [1] http://etherpad.ovirt.org/p/3.5-testday-3 [2] http://www.ovirt.org/OVirt_3.5_Release_Notes [3] http://www.ovirt.org/OVirt_3.5_TestDay Thanks. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-users] [RFI] oVirt 3.6 Planning
by Jorick Astrego 15 Sep '14

15 Sep '14

On 09/15/2014 02:54 PM, Itamar Heim wrote: > On 09/12/2014 09:51 PM, Jorick Astrego wrote: >> Seperation of user/admin front end and engine is on our list. >> >> Currently we have the websocketproxy on a different host option and a >> user/admin gui on a different host option would be nice to have. > > juan was kind enough to wikify. something like this? > http://www.ovirt.org/Squid_Reverse_Proxy > > (please cc mailing list in replies. thanks) Ah yes, that will do fine. Why I didn't think of that..... Thanks! Jorick Astrego Netbulae

1 0

Installing 3.4.3 Centos 6.5
by Neil 15 Sep '14

15 Sep '14

Hi guys, Please could someone assist me, I'm trying to install ovirt 3.4.3 so I can move my current ovirt engine from one server to another. I've done a minimal install of Centos 6.5, did a yum update, then I've added in the repo and when I run engine-setup and go through all the options, it eventually errors out with the following error... [ ERROR ] Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute I've tried removing everything and starting from scratch as well as trying various other options without any luck. Attached is the full install log. Any help is greatly appreciated. Thanks. Regards. Neil Wilson.

3 5

no console connections
by Jim Kinney 15 Sep '14

15 Sep '14

Hi, I have a fresh install of 3.4 on centOS 6.5 with a centOS 6.5-based host (not an all-in-one). When trying to do a first test install of CentOS 7 (or 6.5 or RHEL or...) I can't get a spice console screen to connect. The error message is "Can't connect to graphics server (null)". I doubt it's an issue on my desktop as I have another ovirt 3.4 install that I can connect to from my desktop. This is a new one that will take over from an all-in-one test system. All the server system have proper DNS entries and can be reached directly from my desktop. Could this be related to the websocket proxy server? I get the same results with the proxy off or on (it's not configured beyond basic install from engine-setup). -- -- James P. Kinney III Every time you stop a school, you will have to build a jail. What you gain at one end you lose at the other. It's like feeding a dog on his own tail. It won't fatten the dog. - Speech 11/23/1900 Mark Twain *http://heretothereideas.blogspot.com/ <http://heretothereideas.blogspot.com/>*

2 3

How to tell ovirt engine to use a proxy for openstack image repository
by Michael Keller 15 Sep '14

15 Sep '14

This is an S/MIME signed message ------2CFD5ABECBB14AB33F267698120C8541 Content-Type: multipart/mixed; boundary="----=_Part_17607_1632397503.1410767397121" ------=_Part_17607_1632397503.1410767397121 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, I'm using ovirt 3.4 on CentOS. My engine needs to use a proxy to go to the internet. How is the engine configured to use a proxy for the openstack image repo? Regards Michael ------=_Part_17607_1632397503.1410767397121 Content-Type: application/octet-stream; name="mkeller(a)psi.de-certificate-1.pem" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mkeller(a)psi.de-certificate-1.pem" -----BEGIN CERTIFICATE----- MIIGTDCCBTSgAwIBAgIDAKVcMA0GCSqGSIb3DQEBBQUAMH8xCzAJBgNVBAYTAkRF MSswKQYDVQQKEyJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMSYw JAYDVQQLEx1UcnVzdCBDZW50ZXIgRGV1dHNjaGUgVGVsZWtvbTEbMBkGA1UEAxMS U2hhcmVkIEJ1c2luZXNzIENBMB4XDTEyMDgwODA4MDU0M1oXDTE1MDgwODIzNTk1 OVowgaUxCzAJBgNVBAYTAkRFMR8wHQYDVQQKExZQU0kgQWt0aWVuZ2VzZWxsc2No YWZ0MQ8wDQYDVQQLEwZwc2kuZGUxCzAJBgNVBAsTAmVlMRMwEQYDVQQLEwpCZXJl aWNoIEVFMRcwFQYDVQQDEw5NaWNoYWVsIEtlbGxlcjEdMBsGCSqGSIb3DQEJARYO bWtlbGxlckBwc2kuZGUxCjAIBgNVBAUTATIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCLR8e+J7peLjLWJHMFoMHho/rK1RDhjS0pFyujRmnXhIoqEr8M 4iTDRwbPeYCxfiUS2JFtELM/P3pTuN1kW0j6uHaFX7jqsmBbQiZ5oR296fwZcMgS hesp+qTX31s44Q0hZPn2orQb9/9imoYCnkH9X3H7PBdN05WXM8gOYpwcE5pklngP xM3asN+cwlPvbleWxKQQXspN20f3N6zkqNAiYAR8HNv6zSyrqTuExhSxxAUIzU1p QPwiN+Jx+44E2uRom2yHRzgJZY458L4NputDdLnQtyJoJUORgXUwP64zzghUHmQY Cuzcs7sPuaxJT/HS2DgLc7JZtytIdhIljpFLAgMBAAGjggKoMIICpDAfBgNVHSME GDAWgBSaD4bGTt5QFh199EME4JcpB64e+DAdBgNVHQ4EFgQUwx8MA7olRrpthohY Z7PbBexnRmQwDgYDVR0PAQH/BAQDAgWgME0GA1UdIARGMEQwQgYJKwYBBAG9Rw0Z MDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly9zYmNhLnRlbGVzZWMuZGUvZG93bmxvYWQv Y3BzLnBkZjAJBgNVHRMEAjAAMIIBnAYDVR0fBIIBkzCCAY8wgdqggdeggdSGgdFo dHRwOi8vc2JjYS50ZWxlc2VjLmRlL3NiY2EvZG93bmxvYWQvZG93bmxvYWQuY3Js P3BhdGg9Q04lM0RTaGFyZWQlMjBCdXNpbmVzcyUyMENBJTJDT1UlM0RUcnVzdCUy MENlbnRlciUyMERldXRzY2hlJTIwVGVsZWtvbSUyQ08lM0RULVN5c3RlbXMlMjBF bnRlcnByaXNlJTIwU2VydmljZXMlMjBHbWJIJTJDQyUzRERFJTNGQ2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdDCBr6CBrKCBqYaBpmxkYXA6Ly9sZGFwLnNiY2EudGVs ZXNlYy5kZS9DTj1TaGFyZWQlMjBCdXNpbmVzcyUyMENBLE9VPVRydXN0JTIwQ2Vu dGVyJTIwRGV1dHNjaGUlMjBUZWxla29tLE89VC1TeXN0ZW1zJTIwRW50ZXJwcmlz ZSUyMFNlcnZpY2VzJTIwR21iSCxDPURFP0NlcnRpZmljYXRlUmV2b2NhdGlvbkxp c3QwPQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5zYmNh LnRlbGVzZWMuZGUvb2NzcHIwGQYDVR0RBBIwEIEObWtlbGxlckBwc2kuZGUwDQYJ KoZIhvcNAQEFBQADggEBADhxWiQFZsRNNmDSc6lQaF40EQgWTJXu92RJUKyp3HuW FxY5Y6PdjMZUaUBGIWCiQpO5lJBz4JZxNafCJ24hLZwe1EtZJe9C9fER0hTL2osr 6PuWIc2OTPjnhEHjk2FmW24rXnMYq9fkJDpIj6dHxV/by7b77f8rD8F7vpWK67sq SRhFLGOETB4cMOJ3d0LF9OgC8XcAtjaXLiBeUkqhj0Wc5CusU/zeIfCUkjYPOaZh hnf58T8SX0JA3Qap9501nRALAkvw4yRGDWdFWcIOR9sJM9cDewheVBnntVrKIL5v Lo6QiX8dPePDTg7ALYAgQvVoaifhnyPzNq4BB2vvwrw= -----END CERTIFICATE----- ------=_Part_17607_1632397503.1410767397121-- ------2CFD5ABECBB14AB33F267698120C8541 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOlwYJKoZIhvcNAQcCoIIOiDCCDoQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCC/0wggZMMIIFNKADAgECAgMApVwwDQYJKoZIhvcNAQEFBQAwfzELMAkG A1UEBhMCREUxKzApBgNVBAoTIlQtU3lzdGVtcyBFbnRlcnByaXNlIFNlcnZpY2Vz IEdtYkgxJjAkBgNVBAsTHVRydXN0IENlbnRlciBEZXV0c2NoZSBUZWxla29tMRsw GQYDVQQDExJTaGFyZWQgQnVzaW5lc3MgQ0EwHhcNMTIwODA4MDgwNTQzWhcNMTUw ODA4MjM1OTU5WjCBpTELMAkGA1UEBhMCREUxHzAdBgNVBAoTFlBTSSBBa3RpZW5n ZXNlbGxzY2hhZnQxDzANBgNVBAsTBnBzaS5kZTELMAkGA1UECxMCZWUxEzARBgNV BAsTCkJlcmVpY2ggRUUxFzAVBgNVBAMTDk1pY2hhZWwgS2VsbGVyMR0wGwYJKoZI hvcNAQkBFg5ta2VsbGVyQHBzaS5kZTEKMAgGA1UEBRMBMjCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAItHx74nul4uMtYkcwWgweGj+srVEOGNLSkXK6NG adeEiioSvwziJMNHBs95gLF+JRLYkW0Qsz8/elO43WRbSPq4doVfuOqyYFtCJnmh Hb3p/BlwyBKF6yn6pNffWzjhDSFk+faitBv3/2KahgKeQf1fcfs8F03TlZczyA5i nBwTmmSWeA/Ezdqw35zCU+9uV5bEpBBeyk3bR/c3rOSo0CJgBHwc2/rNLKupO4TG FLHEBQjNTWlA/CI34nH7jgTa5GibbIdHOAlljjnwvg2m60N0udC3ImglQ5GBdTA/ rjPOCFQeZBgK7Nyzuw+5rElP8dLYOAtzslm3K0h2EiWOkUsCAwEAAaOCAqgwggKk MB8GA1UdIwQYMBaAFJoPhsZO3lAWHX30QwTglykHrh74MB0GA1UdDgQWBBTDHwwD uiVGum2GiFhns9sF7GdGZDAOBgNVHQ8BAf8EBAMCBaAwTQYDVR0gBEYwRDBCBgkr BgEEAb1HDRkwNTAzBggrBgEFBQcCARYnaHR0cDovL3NiY2EudGVsZXNlYy5kZS9k b3dubG9hZC9jcHMucGRmMAkGA1UdEwQCMAAwggGcBgNVHR8EggGTMIIBjzCB2qCB 16CB1IaB0Wh0dHA6Ly9zYmNhLnRlbGVzZWMuZGUvc2JjYS9kb3dubG9hZC9kb3du bG9hZC5jcmw/cGF0aD1DTiUzRFNoYXJlZCUyMEJ1c2luZXNzJTIwQ0ElMkNPVSUz RFRydXN0JTIwQ2VudGVyJTIwRGV1dHNjaGUlMjBUZWxla29tJTJDTyUzRFQtU3lz dGVtcyUyMEVudGVycHJpc2UlMjBTZXJ2aWNlcyUyMEdtYkglMkNDJTNEREUlM0ZD ZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0MIGvoIGsoIGphoGmbGRhcDovL2xkYXAu c2JjYS50ZWxlc2VjLmRlL0NOPVNoYXJlZCUyMEJ1c2luZXNzJTIwQ0EsT1U9VHJ1 c3QlMjBDZW50ZXIlMjBEZXV0c2NoZSUyMFRlbGVrb20sTz1ULVN5c3RlbXMlMjBF bnRlcnByaXNlJTIwU2VydmljZXMlMjBHbWJILEM9REU/Q2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnNiY2EudGVsZXNlYy5kZS9vY3NwcjAZBgNVHREEEjAQgQ5ta2VsbGVyQHBz aS5kZTANBgkqhkiG9w0BAQUFAAOCAQEAOHFaJAVmxE02YNJzqVBoXjQRCBZMle73 ZElQrKnce5YXFjljo92MxlRpQEYhYKJCk7mUkHPglnE1p8InbiEtnB7US1kl70L1 8RHSFMvaiyvo+5YhzY5M+OeEQeOTYWZbbitecxir1+QkOkiPp0fFX9vLtvvt/ysP wXu+lYrruypJGEUsY4RMHhww4nd3QsX06ALxdwC2NpcuIF5SSqGPRZzkK6xT/N4h 8JSSNg85pmGGd/nxPxJfQkDdBqn3nTWdEAsCS/DjJEYNZ0VZwg5H2wkz1wN7CF5U Gee1Wsogvm8ujpCJfx0948NODsAtgCBC9WhqJ+GfI/M2rgEHa+/CvDCCBakwggSR oAMCAQICAgEKMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3Qg Q2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0w NzEwMjMxNDA0NDZaFw0xNTEwMjMyMzU5NTlaMH8xCzAJBgNVBAYTAkRFMSswKQYD VQQKEyJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMSYwJAYDVQQL Ex1UcnVzdCBDZW50ZXIgRGV1dHNjaGUgVGVsZWtvbTEbMBkGA1UEAxMSU2hhcmVk IEJ1c2luZXNzIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxOdg 0yE0xMQRRDQYjheDNRImAW3iz3+kzmPZp7ZhLVaarqj9enN5MP3PaoJjwt7mJaf2 rstLo4U57HJwMJNlVHHdgGcTt+QUrUdWg/VCC+n8ZkCZ10SHlhymB48anxZVAy1X /u3WPYdqswY/SApOn+HgsIs4T/4HixnutQ1K/Gq1RMIALWTqLHyUPLovqbwJZuGD LwvlxmH5dQCu8k7AEBsn4DYFplPNYCJOZyXWj024faFbah/dRhiTAKt1hjox5/rk c5RM91gQ7/m6TSl+YxKB5pppDhl16iiVGz/10JEk/tnp67o+WRAMwc2n+TwHud+2 6+B/gJMOyDIQDoftvQIDAQABo4ICOzCCAjcwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBSaD4bGTt5QFh199EME4JcpB64e+DAfBgNVHSMEGDAWgBQxw3kbuvVT1xfg iXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgEBMFEGA1UdIARKMEgwRgYJKwYB BAG9Rw0ZMDkwNwYIKwYBBQUHAgEWK2h0dHA6Ly9zYmNhLnRlbGVzZWMuZGUvc2Jj YS9kb3dubG9hZC9jcC5wZGYwggF8BgNVHR8EggFzMIIBbzCByqCBx6CBxIaBwWh0 dHA6Ly9zYmNhLnRlbGVzZWMuZGUvc2JjYS9kb3dubG9hZC9kb3dubG9hZC5jcmw/ cGF0aD1DTiUzRERldXRzY2hlJTIwVGVsZWtvbSUyMFJvb3QlMjBDQSUyMDIlMkNP VSUzRFQtVGVsZVNlYyUyMFRydXN0JTIwQ2VudGVyJTJDTyUzRERldXRzY2hlJTIw VGVsZWtvbSUyMEFHJTJDQyUzRERFJTNGQXV0aG9yaXR5UmV2b2NhdGlvbkxpc3Qw gZ+ggZyggZmGgZZsZGFwOi8vbGRhcC5zYmNhLnRlbGVzZWMuZGUvQ049RGV1dHNj aGUlMjBUZWxla29tJTIwUm9vdCUyMENBJTIwMixPVT1ULVRlbGVTZWMlMjBUcnVz dCUyMENlbnRlcixPPURldXRzY2hlJTIwVGVsZWtvbSUyMEFHLEM9REU/QXV0aG9y aXR5UmV2b2NhdGlvbkxpc3QwDQYJKoZIhvcNAQEFBQADggEBACRFpaojJR2JCRY5 0Em9NfGLX7VUfk5yqzQ4OaglTDuMg9zdiNX3dLcurqVdagHWiOMz4PjhokzSf2ft 3udBI5QqcMoIfDlQ/4otlY3eDrmSjWdR39xsCGfkzLZEagZ1YFC3CHKLVB9fnyP2 W4sRfyg2pODi/9LoWoQOVuuqtmJAIQKKz4ZA2+JFN0GVIXnCMBenNR3Xl1921Mq7 bmvzrZ3nh3+JTIba+PvpZ9DTUonBEa1t3v0btKp4qiZDWEWqoN/DeOacveRlUAKv aFJgNgZ2sSPbMfu158p8qvu+oKSGr6Z+GyZ/GfH+CEOKJRExLJTBSrsADC46622P A5rRAV8xggJiMIICXgIBATCBhjB/MQswCQYDVQQGEwJERTErMCkGA1UEChMiVC1T eXN0ZW1zIEVudGVycHJpc2UgU2VydmljZXMgR21iSDEmMCQGA1UECxMdVHJ1c3Qg Q2VudGVyIERldXRzY2hlIFRlbGVrb20xGzAZBgNVBAMTElNoYXJlZCBCdXNpbmVz cyBDQQIDAKVcMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQwOTE1MDc0OTU3WjAjBgkqhkiG9w0BCQQxFgQU cOszcvTXjNFuMhR3jw9p9W7cxbEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAB2CmbEz7frNYtaVHKWWyHAGu1eJY rLRNLcHyqUv+SemhWfEJGR2fzx6uDJQv3sDhTNGfqIJD2kTnowehj046npur1foE 1B0X9gRqyjwO6aEVV+9S3q4lcS2C2UyObtkizrrZDWTXoPYyb+DpicPDRE34dcUZ 3QJ5bm8kqMu9WTctfUzN7+Y/Bdqy1Hv6Xtlj4CQELzM479scBB0RwXv2mw9NEBrK 6F0HgMuZR3Js9vZqqv3/qBSPVZwuCQ+4K3Zpl+27pBXSXwg+j8Uasg77pyUsilkn vXu2JEyUQ75kxbWtkws4bN+dy5NXOJ5QLc10kjXdNpXYBcOcSz+k1BKMDw== ------2CFD5ABECBB14AB33F267698120C8541--

1 0

Latest 3.5 - No "Enable Gluster Service" check box.
by Nathan Stratton 15 Sep '14

15 Sep '14

Latest 3.5 install as of today, I already have gluster up and running on all host and I am trying to import my gluster volume into ovirt. When I go to edit the cluster I have "Enable Gluster Service" but there is no check box next to it to check or uncheck. If I look at the host under Hosts, I do see: GlusterFS Version: glusterfs-3.5.2-1.el6 ><> nathan stratton | vp technology | broadsoft, inc | +1-240-404-6580 | www.broadsoft.com

3 3

Should we add 'cow' format disk in file domains in frontend UI ?
by plysan 14 Sep '14

14 Sep '14

Hello, We had experience that if we clone vm from snapshot with sprase raw disk in file domains, the process would get very slow if the disk defined virtual size is big but actual size is small, so i popose the frontend UI to be able to add caw disk in file domains. And I'm happy to implement it. I want to know if there is any problem with my theory, I'm not so experienced in storage. And I created a more detailed expanation to address this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1117219 thanks.

3 2

multipath: error getting device
by Jorick Astrego 14 Sep '14

14 Sep '14

This is a multi-part message in MIME format. --------------040308090200020008010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm seeing a continuous stream of multipath errors on my Centos 7 hosts with ovirt 3.5 rc1.1. Can't find a bug for it except https://bugzilla.redhat.com/show_bug.cgi?id=675366 Sep 8 11:34:13 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:13 host1 kernel: device-mapper: ioctl: error adding target to table Sep 8 11:34:13 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:13 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:23 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:23 host1 kernel: device-mapper: ioctl: error adding target to table Sep 8 11:34:23 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:23 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:33 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:33 host1 kernel: device-mapper: ioctl: error adding target to table We don't use multipath, but it's a bit annoying as it's filling up the console and logs..... Kind regards, Jorick Astrego Netbulae B.V. --------------040308090200020008010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I'm seeing a continuous stream of multipath errors on my Centos 7 hosts with ovirt 3.5 rc1.1.<br> <br> Can't find a bug for it except <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=675366">https://bugzilla.redhat.com/show_bug.cgi?id=675366</a><br> <br> <blockquote>Sep  8 11:34:13 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:13 host1 kernel: device-mapper: ioctl: error adding target to table<br> Sep  8 11:34:13 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:13 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:23 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:23 host1 kernel: device-mapper: ioctl: error adding target to table<br> Sep  8 11:34:23 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:23 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:33 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:33 host1 kernel: device-mapper: ioctl: error adding target to table<br> </blockquote> We don't use multipath, but it's a bit annoying as it's filling up the console and logs.....<br> <br> Kind regards,<br> <br> Jorick Astrego<br> Netbulae B.V.<br> </body> </html> --------------040308090200020008010208--

3 2

ODP: ovirt 3.5 rc2 and iscsi error with chap enabled during discovery
by Piotr Kliczewski 14 Sep '14

14 Sep '14

----_com.android.email_563997694433680 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWxsb24sCgpJdCBsb29rcyBsaWtlIHdlIHBhc3MgbW9yZSBhcmd1bWVudHMgdGhhbiByZXFpcmVk LiBXaWxsIGZpeC4gUGxlYXNlIG9wZW4gYSBidWcuCgoKVGhhbmtzLApQaW90cgoKPGRpdj4tLS0t LS0tLSBPcnlnaW5hbG5hIHdpYWRvbW/Fm8SHIC0tLS0tLS0tPC9kaXY+PGRpdj5PZDogQWxsb24g TXVyZWluaWsgPGFtdXJlaW5pQHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+RGF0YToxNC4wOS4yMDE0 ICAwOToyOCAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5EbzogUGlvdHIgS2xpY3pld3NraSA8cGts aWN6ZXdAcmVkaGF0LmNvbT4gPC9kaXY+PGRpdj5EVzogdXNlcnMgPHVzZXJzQG92aXJ0Lm9yZz4s R2lhbmx1Y2EgQ2VjY2hpIDxnaWFubHVjYS5jZWNjaGlAZ21haWwuY29tPixPdmVkIE91cmZhbGkg PG92ZWRvQHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+VGVtYXQ6IFJlOiBbb3ZpcnQtdXNlcnNdIG92 aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hhcCBlbmFibGVkCWR1cmluZyBkaXNj b3ZlcnkgPC9kaXY+PGRpdj4KPC9kaXY+UGlvdHIsIHRoaXMgbG9va3MgbGlrZSBKU09OLVJQQyBt aXNoYXAuCkNhbiB5b3UgdGFrZSBhIGxvb2sgcGxlYXNlPwoKRnJvbTogIkdpYW5sdWNhIENlY2No aSIgPGdpYW5sdWNhLmNlY2NoaUBnbWFpbC5jb20+ClRvOiAidXNlcnMiIDx1c2Vyc0BvdmlydC5v cmc+ClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTQgMToxNTo1MCBBTQpTdWJqZWN0 OiBbb3ZpcnQtdXNlcnNdIG92aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hhcCBl bmFibGVkICAgICAgICBkdXJpbmcgZGlzY292ZXJ5CgpIZWxsbywKdHJ5aW5nIHRvIGNvbmZpZ3Vy ZSBpU0NTSSBzdG9yYWdlIGRvbWFpbi4KCkkgaGF2ZSBjb25maWd1cmVkIGEgQ2VudE9TIDYuNSBz ZXJ2ZXIgYXMgc3cgaVNDU0kgdGFyZ2V0IHdpdGggY2hhcCBhdXRoZW50aWNhdGlvbi4KcG9ydCAz MjYwIGlzIG9wZW4gZm9yIHRjcCBjb25uZWN0aW9ucy4KSSBoYXZlIGFuIG9WaXJ0IGhvc3QgdGhh dCBpcyBDZW50T1MgNi41IGFuZCB3aGVuIHRyeWluZyB0byBkaXNjb3ZlciB0YXJnZXRzIEkgZ2V0 IGluIC92YXIvbG9nL21lc3NhZ2VzIAoKU2VwIDEyIDIzOjUwOjE5IG92bm9kZTA0IHZkc20ganNv bnJwYy5Kc29uUnBjU2VydmVyIEVSUk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJh Y2sgKG1vc3QgcmVjZW50IGNhbGwgbGFzdCk6IzAxMiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42 L3NpdGUtcGFja2FnZXMveWFqc29ucnBjL19faW5pdF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2 ZVJlcXVlc3QjMDEyIHJlcyA9IG1ldGhvZCgqKnBhcmFtcykjMDEyICBGaWxlICIvdXNyL3NoYXJl L3Zkc20vcnBjL0JyaWRnZS5weSIsIGxpbmUgMjY0LCBpbiBfZHluYW1pY01ldGhvZCMwMTIgICAg cmFpc2UgSW52YWxpZENhbGwoZm4sIG1ldGhvZEFyZ3MsIGUpIzAxMkludmFsaWRDYWxsOiBBdHRl bXB0IHRvIGNhbGwgZnVuY3Rpb246IDxib3VuZCBtZXRob2QgSVNDU0lDb25uZWN0aW9uLmRpc2Nv dmVyU2VuZFRhcmdldHMgb2YgPEFQSS5JU0NTSUNvbm5lY3Rpb24gb2JqZWN0IGF0IDB4N2YwYTQ4 MTQ1MTUwPj4gd2l0aCBhcmd1bWVudHM6ICh1J2lzY3NpdXNlcicsIHUnaXNjc2lwd2QnKSBlcnJv cjogZGlzY292ZXJTZW5kVGFyZ2V0cygpIHRha2VzIGV4YWN0bHkgMSBhcmd1bWVudCAoMyBnaXZl bikKU2VwIDEyIDIzOjUwOjIyIG92bm9kZTA0IHZkc20ganNvbnJwYy5Kc29uUnBjU2VydmVyIEVS Uk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwg bGFzdCk6IzAxMiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42L3NpdGUtcGFja2FnZXMveWFqc29u cnBjL19faW5pdF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2ZVJlcXVlc3QjMDEyIHJlcyA9IG1l dGhvZCgqKnBhcmFtcykjMDEyICBGaWxlICIvdXNyL3NoYXJlL3Zkc20vcnBjL0JyaWRnZS5weSIs IGxpbmUgMjY0LCBpbiBfZHluYW1pY01ldGhvZCMwMTIgICAgcmFpc2UgSW52YWxpZENhbGwoZm4s IG1ldGhvZEFyZ3MsIGUpIzAxMkludmFsaWRDYWxsOiBBdHRlbXB0IHRvIGNhbGwgZnVuY3Rpb246 IDxib3VuZCBtZXRob2QgSVNDU0lDb25uZWN0aW9uLmRpc2NvdmVyU2VuZFRhcmdldHMgb2YgPEFQ SS5JU0NTSUNvbm5lY3Rpb24gb2JqZWN0IGF0IDB4N2YwYTQ4MGU1YWQwPj4gd2l0aCBhcmd1bWVu dHM6ICh1J2lzY3NpdXNlcicsIHUnaXNjc2lwd2QnKSBlcnJvcjogZGlzY292ZXJTZW5kVGFyZ2V0 cygpIHRha2VzIGV4YWN0bHkgMSBhcmd1bWVudCAoMyBnaXZlbikKCnNjcmVlbnNob3QgdGhhdCBy ZXR1cm5zIG5vIG5ldyBkZXZpY2VzIGZvdW5kIGlzIGhlcmU6Cmh0dHBzOi8vZHJpdmUuZ29vZ2xl LmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmJWbHljbkpDVFdKdE5YYy9lZGl0P3VzcD1zaGFyaW5n CgpCVFc6IGNoYXAgdXNlciBhbmQgcGFzc3dvcmQgaW5wdXQgZmllbGRzIGNvdWxkIGJlIHdpZGVy LCBzbyB0aGF0IHRoZSB3aG9sZSB3b3JkcyBpbnB1dCBjYW4gc2VlbiBvbiB0aGUgc2NyZWVuLiB0 aGVyZSBpcyBwbGVudHkgb2Ygc3BhY2UuLi4gQWxzbyBwYXNzd29yZCBmaWVsZCBzaG91bGQgbm90 IGJlIGluIGNsZWFyIHRleHQgYXMgaXQgaXMgbm93CgpUaGUgYXBwcm9hY2ggdG8gc3VjY2Vzc2Z1 bGx5IGNvbm5lY3QgdGhlIExVTiBzZWVtcyB0byBiZToKMSkgbWFrZSBkaXNjb3ZlcnkgYnV0IHdp dGggY2hhcCB1bmNoZWNrZWQKMikgdGhlIHRhcmdldCB0aGVuIHNob3dzIHVwIApzZWUgCmh0dHBz Oi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmIxcEVUM1ZOTVdKdVJVay9l ZGl0P3VzcD1zaGFyaW5nCjMpIG5vdyBjaGVjayB0aGUgYm94IGZvciBjaGFwIGF1dGhlbnRpY2F0 aW9uIGFuZCBzZWxlY3QgbG9naW4gYWxsCnlvdSBub3cgZ2V0IHRoZSBsdW5zCmh0dHBzOi8vZHJp dmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmVFeFJNek4xWjBSdFIxay9lZGl0P3Vz cD1zaGFyaW5nCjQpIHRoZW4gc2VsZWN0IHRoZSBsdW4ocykgZGVzaXJlZCBhbmQgc2VsZWN0IE9L CgppcyB0aGlzIGNvcnJlY3Q/IEluIGNhc2UgSSB0aGluayBpdCBzaG91bGQgYmUgZGlzYWJsZWQg dGhlIGNoYXAgb3B0aW9uIGR1cmluZyBkaXNjb3ZlcnkgcGhhc2UuLi4Kb3RoZXJ3aXNlIEkgaGF2 ZSBub3QgY29uZmlndXJlZCBjb3JyZWN0bHkgbXkgaXNjc2kgdGFyZ2V0IHBlcmhhcHMuCm92aXJ0 IGhvc3QgbmV0d29yayBpcCBpcyAxMC4xMC4xLjYxCgp0Z3RhZG0gLS1sbGQgaXNjc2kgLS1tb2Rl IHRhcmdldCAtLW9wIHNob3cKVGFyZ2V0IDE6IGlxbi4yMDE0LTA3LmxvY2FsLmxvY2FsZG9tYWlu OnN0b3JlMQogICAgU3lzdGVtIGluZm9ybWF0aW9uOgogICAgICAgIERyaXZlcjogaXNjc2kKICAg ICAgICBTdGF0ZTogcmVhZHkKICAgIElfVCBuZXh1cyBpbmZvcm1hdGlvbjoKICAgICAgICBJX1Qg bmV4dXM6IDEKICAgICAgICAgICAgSW5pdGlhdG9yOiBpcW4uMTk5NC0wNS5jb20ucmVkaGF0OjVk OWIzMTMxOWE4ZQogICAgICAgICAgICBDb25uZWN0aW9uOiAwCiAgICAgICAgICAgICAgICBJUCBB ZGRyZXNzOiAxMC4xMC4xLjYxCiAgICBMVU4gaW5mb3JtYXRpb246CiAgICAgICAgTFVOOiAwCiAg ICAgICAgICAgIFR5cGU6IGNvbnRyb2xsZXIKICAgICAgICAgICAgU0NTSSBJRDogSUVUICAgICAw MDAxMDAwMAogICAgICAgICAgICBTQ1NJIFNOOiBiZWFmMTAKICAgICAgICAgICAgU2l6ZTogMCBN QiwgQmxvY2sgc2l6ZTogMQogICAgICAgICAgICBPbmxpbmU6IFllcwogICAgICAgICAgICBSZW1v dmFibGUgbWVkaWE6IE5vCiAgICAgICAgICAgIFByZXZlbnQgcmVtb3ZhbDogTm8KICAgICAgICAg ICAgUmVhZG9ubHk6IE5vCiAgICAgICAgICAgIEJhY2tpbmcgc3RvcmUgdHlwZTogbnVsbAogICAg ICAgICAgICBCYWNraW5nIHN0b3JlIHBhdGg6IE5vbmUKICAgICAgICAgICAgQmFja2luZyBzdG9y ZSBmbGFnczogCiAgICAgICAgTFVOOiAxCiAgICAgICAgICAgIFR5cGU6IGRpc2sKICAgICAgICAg ICAgU0NTSSBJRDogcF9pc2NzaV9zdG9yZTFfbAogICAgICAgICAgICBTQ1NJIFNOOiA2NjY2NmE0 MQogICAgICAgICAgICBTaXplOiAyMTQ3MzggTUIsIEJsb2NrIHNpemU6IDUxMgogICAgICAgICAg ICBPbmxpbmU6IFllcwogICAgICAgICAgICBSZW1vdmFibGUgbWVkaWE6IE5vCiAgICAgICAgICAg IFByZXZlbnQgcmVtb3ZhbDogTm8KICAgICAgICAgICAgUmVhZG9ubHk6IE5vCiAgICAgICAgICAg IEJhY2tpbmcgc3RvcmUgdHlwZTogcmR3cgogICAgICAgICAgICBCYWNraW5nIHN0b3JlIHBhdGg6 IC9kZXYvZHJiZC9ieS1yZXMvaXNjc2loYQogICAgICAgICAgICBCYWNraW5nIHN0b3JlIGZsYWdz OiAKICAgIEFjY291bnQgaW5mb3JtYXRpb246CiAgICAgICAgaXNjc2l1c2VyCiAgICBBQ0wgaW5m b3JtYXRpb246CiAgICAgICAgMTAuMTAuMS42MQogICAgICAgIDEwLjEwLjEuNjIKICAgICAgICAx MC4xMC4xLjYzCgpHaWFubHVjYQoKICAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fClVzZXJzIG1haWxpbmcgbGlzdApVc2Vyc0BvdmlydC5vcmcKaHR0cDov L2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzCgo= ----_com.android.email_563997694433680 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5BbGxvbiw8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pkl0IGxvb2tzIGxpa2Ugd2UgcGFzcyBtb3JlIGFyZ3VtZW50cyB0aGFu IHJlcWlyZWQuIFdpbGwgZml4LiBQbGVhc2Ugb3BlbiBhIGJ1Zy48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6OXB4Ij5UaGFua3MsPC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1zaXplOjlweCI+UGlvdHI8L2Rpdj48YnI+PGJyPjxkaXY+LS0tLS0t LS0gT3J5Z2luYWxuYSB3aWFkb21vxZvEhyAtLS0tLS0tLTwvZGl2PjxkaXY+T2Q6IEFsbG9uIE11 cmVpbmlrIDxhbXVyZWluaUByZWRoYXQuY29tPiA8L2Rpdj48ZGl2PkRhdGE6MTQuMDkuMjAxNCAg MDk6MjggIChHTVQrMDE6MDApIDwvZGl2PjxkaXY+RG86IFBpb3RyIEtsaWN6ZXdza2kgPHBrbGlj emV3QHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+RFc6IHVzZXJzIDx1c2Vyc0BvdmlydC5vcmc+LEdp YW5sdWNhIENlY2NoaSA8Z2lhbmx1Y2EuY2VjY2hpQGdtYWlsLmNvbT4sT3ZlZCBPdXJmYWxpIDxv dmVkb0ByZWRoYXQuY29tPiA8L2Rpdj48ZGl2PlRlbWF0OiBSZTogW292aXJ0LXVzZXJzXSBvdmly dCAzLjUgcmMyIGFuZCBpc2NzaSBlcnJvciB3aXRoIGNoYXAgZW5hYmxlZAlkdXJpbmcgZGlzY292 ZXJ5IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBu ZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMw MDAwMDAiPjxkaXY+UGlvdHIsIHRoaXMgbG9va3MgbGlrZSBKU09OLVJQQyBtaXNoYXAuPC9kaXY+ PGRpdj5DYW4geW91IHRha2UgYSBsb29rIHBsZWFzZT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48aHIg aWQ9Inp3Y2hyIj48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6MnB4IHNvbGlkICMxMDEw RkY7bWFyZ2luLWxlZnQ6NXB4O3BhZGRpbmctbGVmdDo1cHg7Y29sb3I6IzAwMDtmb250LXdlaWdo dDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1mYW1p bHk6SGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7Ij48Yj5Gcm9tOiA8 L2I+IkdpYW5sdWNhIENlY2NoaSIgJmx0O2dpYW5sdWNhLmNlY2NoaUBnbWFpbC5jb20mZ3Q7PGJy PjxiPlRvOiA8L2I+InVzZXJzIiAmbHQ7dXNlcnNAb3ZpcnQub3JnJmd0Ozxicj48Yj5TZW50OiA8 L2I+U2F0dXJkYXksIFNlcHRlbWJlciAxMywgMjAxNCAxOjE1OjUwIEFNPGJyPjxiPlN1YmplY3Q6 IDwvYj5bb3ZpcnQtdXNlcnNdIG92aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hh cCBlbmFibGVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZHVyaW5nIGRpc2NvdmVyeTxicj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48ZGl2Pkhl bGxvLDxicj50cnlpbmcgdG8gY29uZmlndXJlIGlTQ1NJIHN0b3JhZ2UgZG9tYWluLjxicj48ZGl2 Pjxicj48L2Rpdj48L2Rpdj48ZGl2PkkgaGF2ZSBjb25maWd1cmVkIGEgQ2VudE9TIDYuNSBzZXJ2 ZXIgYXMgc3cgaVNDU0kgdGFyZ2V0IHdpdGggY2hhcCBhdXRoZW50aWNhdGlvbi48YnI+PC9kaXY+ PGRpdj5wb3J0IDMyNjAgaXMgb3BlbiBmb3IgdGNwIGNvbm5lY3Rpb25zLjxicj48L2Rpdj48ZGl2 PkkgaGF2ZSBhbiBvVmlydCBob3N0IHRoYXQgaXMgQ2VudE9TIDYuNSBhbmQgd2hlbiB0cnlpbmcg dG8gZGlzY292ZXIgdGFyZ2V0cyBJIGdldCBpbiAvdmFyL2xvZy9tZXNzYWdlcyA8YnI+PGRpdj48 YnI+PC9kaXY+U2VwIDEyIDIzOjUwOjE5IG92bm9kZTA0IHZkc20ganNvbnJwYy5Kc29uUnBjU2Vy dmVyIEVSUk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJhY2sgKG1vc3QgcmVjZW50 IGNhbGwgbGFzdCk6IzAxMiZuYnNwOyBGaWxlICIvdXNyL2xpYi9weXRob24yLjYvc2l0ZS1wYWNr YWdlcy95YWpzb25ycGMvX19pbml0X18ucHkiLCBsaW5lIDQ4NiwgaW4gX3NlcnZlUmVxdWVzdCMw MTImbmJzcDsmbmJzcDsmbmJzcDsgcmVzID0gbWV0aG9kKCoqcGFyYW1zKSMwMTImbmJzcDsgRmls ZSAiL3Vzci9zaGFyZS92ZHNtL3JwYy9CcmlkZ2UucHkiLCBsaW5lIDI2NCwgaW4gX2R5bmFtaWNN ZXRob2QjMDEyJm5ic3A7Jm5ic3A7Jm5ic3A7IHJhaXNlIEludmFsaWRDYWxsKGZuLCBtZXRob2RB cmdzLCBlKSMwMTJJbnZhbGlkQ2FsbDogQXR0ZW1wdCB0byBjYWxsIGZ1bmN0aW9uOiAmbHQ7Ym91 bmQgbWV0aG9kIElTQ1NJQ29ubmVjdGlvbi5kaXNjb3ZlclNlbmRUYXJnZXRzIG9mICZsdDtBUEku SVNDU0lDb25uZWN0aW9uIG9iamVjdCBhdCAweDdmMGE0ODE0NTE1MCZndDsmZ3Q7IHdpdGggYXJn dW1lbnRzOiAodSdpc2NzaXVzZXInLCB1J2lzY3NpcHdkJykgZXJyb3I6IGRpc2NvdmVyU2VuZFRh cmdldHMoKSB0YWtlcyBleGFjdGx5IDEgYXJndW1lbnQgKDMgZ2l2ZW4pPGJyPlNlcCAxMiAyMzo1 MDoyMiBvdm5vZGUwNCB2ZHNtIGpzb25ycGMuSnNvblJwY1NlcnZlciBFUlJPUiBJbnRlcm5hbCBz ZXJ2ZXIgZXJyb3IjMDEyVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOiMwMTImbmJz cDsgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42L3NpdGUtcGFja2FnZXMveWFqc29ucnBjL19faW5p dF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2ZVJlcXVlc3QjMDEyJm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlcyA9IG1ldGhvZCgqKnBhcmFtcykjMDEyJm5ic3A7IEZpbGUgIi91c3Ivc2hhcmUvdmRzbS9y cGMvQnJpZGdlLnB5IiwgbGluZSAyNjQsIGluIF9keW5hbWljTWV0aG9kIzAxMiZuYnNwOyZuYnNw OyZuYnNwOyByYWlzZSBJbnZhbGlkQ2FsbChmbiwgbWV0aG9kQXJncywgZSkjMDEySW52YWxpZENh bGw6IEF0dGVtcHQgdG8gY2FsbCBmdW5jdGlvbjogJmx0O2JvdW5kIG1ldGhvZCBJU0NTSUNvbm5l Y3Rpb24uZGlzY292ZXJTZW5kVGFyZ2V0cyBvZiAmbHQ7QVBJLklTQ1NJQ29ubmVjdGlvbiBvYmpl Y3QgYXQgMHg3ZjBhNDgwZTVhZDAmZ3Q7Jmd0OyB3aXRoIGFyZ3VtZW50czogKHUnaXNjc2l1c2Vy JywgdSdpc2NzaXB3ZCcpIGVycm9yOiBkaXNjb3ZlclNlbmRUYXJnZXRzKCkgdGFrZXMgZXhhY3Rs eSAxIGFyZ3VtZW50ICgzIGdpdmVuKTxicj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2PnNjcmVl bnNob3QgdGhhdCByZXR1cm5zIG5vIG5ldyBkZXZpY2VzIGZvdW5kIGlzIGhlcmU6PGJyPjxhIGhy ZWY9Imh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmJWbHljbkpD VFdKdE5YYy9lZGl0P3VzcD1zaGFyaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kcml2ZS5n b29nbGUuY29tL2ZpbGUvZC8wQndvUGJjck12OG12YlZseWNuSkNUV0p0TlhjL2VkaXQ/dXNwPXNo YXJpbmc8L2E+PGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+QlRXOiBjaGFwIHVzZXIgYW5k IHBhc3N3b3JkIGlucHV0IGZpZWxkcyBjb3VsZCBiZSB3aWRlciwgc28gdGhhdCB0aGUgd2hvbGUg d29yZHMgaW5wdXQgY2FuIHNlZW4gb24gdGhlIHNjcmVlbi4gdGhlcmUgaXMgcGxlbnR5IG9mIHNw YWNlLi4uIEFsc28gcGFzc3dvcmQgZmllbGQgc2hvdWxkIG5vdCBiZSBpbiBjbGVhciB0ZXh0IGFz IGl0IGlzIG5vdzxicj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2PlRoZSBhcHByb2FjaCB0byBz dWNjZXNzZnVsbHkgY29ubmVjdCB0aGUgTFVOIHNlZW1zIHRvIGJlOjxicj48L2Rpdj48ZGl2PjEp IG1ha2UgZGlzY292ZXJ5IGJ1dCB3aXRoIGNoYXAgdW5jaGVja2VkPGJyPjwvZGl2PjxkaXY+Mikg dGhlIHRhcmdldCB0aGVuIHNob3dzIHVwIDxicj48L2Rpdj48ZGl2PnNlZSA8YnI+PGEgaHJlZj0i aHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2ZpbGUvZC8wQndvUGJjck12OG12YjFwRVQzVk5NV0p1 UlVrL2VkaXQ/dXNwPXNoYXJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RyaXZlLmdvb2ds ZS5jb20vZmlsZS9kLzBCd29QYmNyTXY4bXZiMXBFVDNWTk1XSnVSVWsvZWRpdD91c3A9c2hhcmlu ZzwvYT48YnI+PC9kaXY+PGRpdj4zKSBub3cgY2hlY2sgdGhlIGJveCBmb3IgY2hhcCBhdXRoZW50 aWNhdGlvbiBhbmQgc2VsZWN0IGxvZ2luIGFsbDxicj55b3Ugbm93IGdldCB0aGUgbHVuczxicj48 YSBocmVmPSJodHRwczovL2RyaXZlLmdvb2dsZS5jb20vZmlsZS9kLzBCd29QYmNyTXY4bXZlRXhS TXpOMVowUnRSMWsvZWRpdD91c3A9c2hhcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZHJp dmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmVFeFJNek4xWjBSdFIxay9lZGl0P3Vz cD1zaGFyaW5nPC9hPjxicj48L2Rpdj48ZGl2PjQpIHRoZW4gc2VsZWN0IHRoZSBsdW4ocykgZGVz aXJlZCBhbmQgc2VsZWN0IE9LPGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+aXMgdGhpcyBj b3JyZWN0PyBJbiBjYXNlIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGRpc2FibGVkIHRoZSBjaGFwIG9w dGlvbiBkdXJpbmcgZGlzY292ZXJ5IHBoYXNlLi4uPGJyPjwvZGl2PjxkaXY+b3RoZXJ3aXNlIEkg aGF2ZSBub3QgY29uZmlndXJlZCBjb3JyZWN0bHkgbXkgaXNjc2kgdGFyZ2V0IHBlcmhhcHMuPGJy Pm92aXJ0IGhvc3QgbmV0d29yayBpcCBpcyAxMC4xMC4xLjYxPGJyPjxkaXY+PGJyPjwvZGl2PnRn dGFkbSAtLWxsZCBpc2NzaSAtLW1vZGUgdGFyZ2V0IC0tb3Agc2hvdzxicj5UYXJnZXQgMTogaXFu LjIwMTQtMDcubG9jYWwubG9jYWxkb21haW46c3RvcmUxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBT eXN0ZW0gaW5mb3JtYXRpb246PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBEcml2ZXI6IGlzY3NpPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTdGF0ZTogcmVhZHk8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElfVCBuZXh1cyBp bmZvcm1hdGlvbjo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElfVCBuZXh1czogMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5pdGlhdG9yOiBpcW4uMTk5NC0wNS5jb20ucmVk aGF0OjVkOWIzMTMxOWE4ZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29ubmVjdGlvbjogMDxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVAgQWRkcmVzczogMTAuMTAuMS42MTxicj4mbmJzcDsm bmJzcDsmbmJzcDsgTFVOIGluZm9ybWF0aW9uOjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgTFVOOiAwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlOiBjb250cm9sbGVyPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTQ1NJIElEOiBJRVQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDAwMTAwMDA8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFNDU0kgU046IGJlYWYxMDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2l6ZTogMCBNQiwgQmxv Y2sgc2l6ZTogMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT25saW5lOiBZZXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlbW92YWJs ZSBtZWRpYTogTm88YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByZXZlbnQgcmVtb3ZhbDogTm88YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJlYWRvbmx5OiBObzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFja2luZyBzdG9yZSB0eXBlOiBudWxsPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBCYWNraW5nIHN0b3JlIHBhdGg6IE5vbmU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcgc3Rv cmUgZmxhZ3M6IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TFVOOiAxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlOiBkaXNrPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTQ1NJIElEOiBwX2lz Y3NpX3N0b3JlMV9sPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTQ1NJIFNOOiA2NjY2NmE0MTxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2l6ZTogMjE0NzM4IE1CLCBCbG9jayBzaXplOiA1MTI8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9ubGluZTogWWVz PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSZW1vdmFibGUgbWVkaWE6IE5vPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQcmV2ZW50IHJl bW92YWw6IE5vPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWFkb25seTogTm88YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcg c3RvcmUgdHlwZTogcmR3cjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFja2luZyBzdG9yZSBwYXRoOiAvZGV2L2Ry YmQvYnktcmVzL2lzY3NpaGE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcgc3RvcmUgZmxhZ3M6IDxicj4m bmJzcDsmbmJzcDsmbmJzcDsgQWNjb3VudCBpbmZvcm1hdGlvbjo8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzY3NpdXNlcjxicj4mbmJzcDsmbmJzcDsmbmJz cDsgQUNMIGluZm9ybWF0aW9uOjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42MTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42Mjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42Mzxicj48L2Rpdj48YnI+PGRpdj5HaWFubHVjYTxicj48ZGl2Pjxi cj48L2Rpdj4mbmJzcDsgPGJyPjwvZGl2PjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+VXNlcnMgbWFpbGluZyBsaXN0PGJyPlVzZXJz QG92aXJ0Lm9yZzxicj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNl cnM8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT4= ----_com.android.email_563997694433680--

2 1

An error occurring in the OVirt_Engine_Development_Environment
by Xie, Chao 14 Sep '14

14 Sep '14

--_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: multipart/alternative; boundary="_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_" --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksYWxsDQogICAgICAgICBJIHRyaWVkIHRvIGJ1bGlkIGEgT1ZpcnRfRW5naW5lX0RldmVsb3Bt ZW50X0Vudmlyb25tZW50IGZvbGxvd2luZyB0aGUgaHR0cDovL3dpa2kub3ZpcnQub3JnL09WaXJ0 X0VuZ2luZV9EZXZlbG9wbWVudF9FbnZpcm9ubWVudC4NCiAgICAgICAgIFdoZW4gSSBwcmVwYXJl ZCB0aGUgc291cmNlIGNvZGUgYW5kIGVudmlyb25tZW50ICwgSSBleGVjdXRlIKGwbWFrZSBpbnN0 YWxsLWRldiBQUkVGSVg9IiRIT01FL292aXJ0LWVuZ2luZSIgYW5kIGFuIGVycm9yIHdhcyBwcm9t cHRlZCBhcyBiZWxvdy4NCg0KPT09PT09PT09PT09PT09PQ0KaWYgWyAiMSIgIT0gMCBdOyB0aGVu IFwNCiAgICAgICAgICAgICAgICAgICBidWlsZC9zaGVsbC1jaGVjay5zaCAmJiBcDQogICAgICAg ICAgICAgICAgICAgYnVpbGQvcHl0aG9uLWNoZWNrLnNoICYmIFwNCiAgICAgICAgICAgICAgICAg ICBidWlsZC9kYnNjcmlwdHMtZHVwbGljYXRlX3VwZ3JhZGVfc2NyaXB0cy5zaDsgXA0KICAgICAg ICAgZmkNCnBhY2thZ2luZy9iaW4vcGtpLWNvbW1vbi5zaDogMzM6IFN5bnRheCBlcnJvcjogZW5k IG9mIGZpbGUgdW5leHBlY3RlZCAoZXhwZWN0aW5nICJ0aGVuIikNCjogTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeTU3OiAvYmluL3NoDQpwYWNrYWdpbmcvYmluL2VuZ2luZS1wcm9sb2cuc2g6IDE5 OiBTeW50YXggZXJyb3I6IHdvcmQgdW5leHBlY3RlZCAoZXhwZWN0aW5nICJkbyIpDQo6IE5vIHN1 Y2ggZmlsZSBvciBkaXJlY3Rvcnk1NzogL2Jpbi9zaA0KOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5NTc6IC9iaW4vc2gNCjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTU3OiAvYmluL3NoDQo6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk1NzogL2Jpbi9zaA0KOiBObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5NTc6IC9iaW4vc2gNCm1ha2VbMV06ICoqKiBbdmFsaWRhdGlvbnNdIEVycm9yIDEN Cm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9vbmx5ZWxsb3cvb3ZpcnQtZW5naW5l Jw0KbWFrZTogKioqIFthbGwtZGV2XSBFcnJvciAyDQoNCj09PT09PT09PT09PT09PT09PT09PT0N Cg0KSSBjaGVjayB0aGUgobBwYWNrYWdpbmcvYmluL3BraS1jb21tb24uc2ihsSBhbmQgZmluZCBp dCBzZWVtcyB3ZWxsICh0aGUgYXR0ZW5kbWVudCkuIERvZXMgYW55Ym9keSBoYXZlIHRoZSBzYW1l IHByb2JsZW0/DQo= --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: text/html; charset="gb2312" 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=3Dgb2312"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t= rim:punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi,all<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   I tried to bulid a OVirt_Engine_Development_Environment f= ollowing the <a href=3D"http://wiki.ovirt.org/OVirt_Engine_Development_Environment">http= ://wiki.ovirt.org/OVirt_Engine_Development_Environment</a>.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   When I prepared the source code and environment , I execu= te =A1=B0make install-dev PREFIX=3D"$HOME/ovirt-engine" and an er= ror was prompted as below.<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">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">if [ "1" !=3D 0 ]; th= en \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/shell-check.sh && \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/python-check.sh && \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/dbscripts-duplicate_upgrade_scripts.sh; \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   fi<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">packaging/bin/pki-common.sh: 33= : Syntax error: end of file unexpected (expecting "then")<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">packaging/bin/engine-prolog.sh:= 19: Syntax error: word unexpected (expecting "do")<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make[1]: *** [validations] Erro= r 1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make[1]: Leaving directory `/ho= me/onlyellow/ovirt-engine'<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make: *** [all-dev] Error 2<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">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<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">I check the =A1=B0packaging/bin= /pki-common.sh=A1=B1 and find it seems well (the attendment). Does anybody = have the same problem?<o:p></o:p></span></p> </div> </body> </html> --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_-- --_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: application/octet-stream; name="pki-common.sh" Content-Description: pki-common.sh Content-Disposition: attachment; filename="pki-common.sh"; size=683; creation-date="Sun, 14 Sep 2014 07:32:28 GMT"; modification-date="Sun, 14 Sep 2014 10:39:59 GMT" Content-Transfer-Encoding: base64 DQpQS0lESVI9Ii9ob21lL29ubHllbGxvdy9vdmlydC1lbmdpbmUvZXRjL3BraS9vdmlydC1lbmdp bmUiDQpVU1JESVI9Ii9ob21lL29ubHllbGxvdy9vdmlydC1lbmdpbmUvc2hhcmUvb3ZpcnQtZW5n aW5lIg0KQklORElSPSIke1VTUkRJUn0vYmluIg0KDQpkaWUoKSB7DQoJbG9jYWwgbT0iJDEiDQoJ ZWNobyAiJG0iID4mMg0KCWV4aXQgMQ0KfQ0KDQpjb21tb25fYmFja3VwKCkgew0KCWxvY2FsIHRp bWU9IiQoZGF0ZSArIiVZJW0lZCVIJU0lUyIpIg0KDQoJd2hpbGUgWyAtbiAiJDEiIF07IGRvDQoJ CWxvY2FsIGY9IiQxIg0KCQlzaGlmdA0KCQlpZiBbIC1mICIke2Z9IiBdOyB0aGVuDQoJCQljcCAt YSAiJHtmfSIgIiR7Zn0uJHt0aW1lfSIgfHwgXA0KCQkJCWRpZSAiRmFpbGVkIHRvIGJhY2t1cCAk e2Z9Ig0KCQlmaQ0KCWRvbmUNCn0NCg0KY29tbW9uX3Jlc3RvcmVfcGVybXMoKSB7DQoJbG9jYWwg cGtpZGlyPSIkMSINCg0KCSMgb3BlbnNzbCBhbHdheXMgcmVzZXQgb3duZXJzaGlwDQoJIyBvZiB0 aGVzZSBmaWxlcywgc28gd2UgaGF2ZSB0byByZXNldA0KCSMgb3VyIGRlZmF1bHRzDQoJY2hvd24g LS1yZWZlcmVuY2U9IiR7cGtpZGlyfSIgIiR7cGtpZGlyfSIvc2VyaWFsLnR4dCogIiR7cGtpZGly fSIvZGF0YWJhc2UudHh0KiAiJHtwa2lkaXJ9Ii8ucm5kKiA+IC9kZXYvbnVsbCAyPiYxDQp9DQo= --_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_--

1 1

ovirt 3.5 rc2 and iscsi error with chap enabled during discovery
by Gianluca Cecchi 14 Sep '14

14 Sep '14

Hello, trying to configure iSCSI storage domain. I have configured a CentOS 6.5 server as sw iSCSI target with chap authentication. port 3260 is open for tcp connections. I have an oVirt host that is CentOS 6.5 and when trying to discover targets I get in /var/log/messages Sep 12 23:50:19 ovnode04 vdsm jsonrpc.JsonRpcServer ERROR Internal server error#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest#012 res = method(**params)#012 File "/usr/share/vdsm/rpc/Bridge.py", line 264, in _dynamicMethod#012 raise InvalidCall(fn, methodArgs, e)#012InvalidCall: Attempt to call function: <bound method ISCSIConnection.discoverSendTargets of <API.ISCSIConnection object at 0x7f0a48145150>> with arguments: (u'iscsiuser', u'iscsipwd') error: discoverSendTargets() takes exactly 1 argument (3 given) Sep 12 23:50:22 ovnode04 vdsm jsonrpc.JsonRpcServer ERROR Internal server error#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest#012 res = method(**params)#012 File "/usr/share/vdsm/rpc/Bridge.py", line 264, in _dynamicMethod#012 raise InvalidCall(fn, methodArgs, e)#012InvalidCall: Attempt to call function: <bound method ISCSIConnection.discoverSendTargets of <API.ISCSIConnection object at 0x7f0a480e5ad0>> with arguments: (u'iscsiuser', u'iscsipwd') error: discoverSendTargets() takes exactly 1 argument (3 given) screenshot that returns no new devices found is here: https://drive.google.com/file/d/0BwoPbcrMv8mvbVlycnJCTWJtNXc/edit?usp=shari… BTW: chap user and password input fields could be wider, so that the whole words input can seen on the screen. there is plenty of space... Also password field should not be in clear text as it is now The approach to successfully connect the LUN seems to be: 1) make discovery but with chap unchecked 2) the target then shows up see https://drive.google.com/file/d/0BwoPbcrMv8mvb1pET3VNMWJuRUk/edit?usp=shari… 3) now check the box for chap authentication and select login all you now get the luns https://drive.google.com/file/d/0BwoPbcrMv8mveExRMzN1Z0RtR1k/edit?usp=shari… 4) then select the lun(s) desired and select OK is this correct? In case I think it should be disabled the chap option during discovery phase... otherwise I have not configured correctly my iscsi target perhaps. ovirt host network ip is 10.10.1.61 tgtadm --lld iscsi --mode target --op show Target 1: iqn.2014-07.local.localdomain:store1 System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1994-05.com.redhat:5d9b31319a8e Connection: 0 IP Address: 10.10.1.61 LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: p_iscsi_store1_l SCSI SN: 66666a41 Size: 214738 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/drbd/by-res/iscsiha Backing store flags: Account information: iscsiuser ACL information: 10.10.1.61 10.10.1.62 10.10.1.63 Gianluca

2 1

lost connectivty to the ovirt-engine after adding host
by Ramon Ramirez-Linan 13 Sep '14

13 Sep '14

Hi, I am working on a proof of concept using using oVirt and ManageIQ. I have a CentOS6.5 where I deployed libvirt, I create a VM where I deployed oVirt 3.4. I was trying to add the host where the VM with oVirt resides. After much troubleshooting I was able to add the host but now the oVirt VM is owned by a user vdsm which I dont know the password for, so I can't start the VM with oVirt. This is the result of running virsh list ==================== $virsh list Please enter your authentication name: vdsm@ovirt Please enter your password: error: Failed to reconnect to the hypervisor error: no valid connection error: authentication failed: authentication failed ======================== I added another user with the command ------------ saslpasswd2 -a libvirt [username] ------------ I used that username and password to connect and to do ------------ virsh list -all ------------ That shows the VM but If i try to start it it gives me an error like follows error: Failed to start domain Cent6.5 error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1 qemu-kvm: -drive file=/ovirt/test/virtlive01/miq_demo/cent01.img,if=none,id=drive-virtio-disk0,format=raw,cache=none: could not open disk image /ovirt/test/virtlive01/miq_demo/cent01.img: Permission denied Any ideas how can start that VM? is there a default password for the user vdsm

1 0

[RFI] oVirt 3.6 Planning
by Paul Jansen 13 Sep '14

13 Sep '14

---1212189890-1261065207-1410659964=:78009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My vote is for storage load balancing/scheduler.=0AVmware's Vcenter has the= concept of a 'storage cluster'. It's essentially a logical storage devic= e.=0AWhen you configure hosts/vms to use this device vcenter then works out= which of the actual storage devices underneath this logical device is will= send the storage requests to.=0AThis works out as a basic form of load bal= acing by alternating where the storage for new vms are created.=0AThis isn'= t particularly amazing, but what it does allow - with the highest end vcent= er licensing anyway - is what Vmware calls 'storage distributed resource sc= heduling'.=0AMuch like we already have the ability to have a scheduler that= moves the execution of vms around on hosts based on load, this does the sa= me thing for the storage component of VM.=0AImagine having two configured s= torage locations under a 'storage cluster' and then having the ability to p= ut one of the storage locations into 'maintenance mode'. The storage sched= uler would then 'live storage migrate' all the storage for vms over to the = other storage location. This would then allow the first storage location t= o be taken down for maintenance.=0AThis approach also allows storage to sca= le over time as more is added. The 'storage scheduler' can take inputs suc= h as latency etc into account and manage the load across the 'storage clust= er' to balance things out and make smart decisions so that the avaialble st= orage is utilized as best as it can be (ie: not overloading one storage loc= ation while the other location is mainly idle).=0A=0A=0AI've done a bit a s= earching to see where Ovirt might be up to in this regard and what I've fou= nd seems to indicate that we are not anywhere near this capability just yet= .=0AAn important prerequisite is having the hosts able to actually do a liv= e storage migration. EL7 based hosts under ovirt 3.5 have this, as have Fe= dora 19 and 20 hosts.=0AIf the decision is made to use qemu-kvm-rhev on EL6= hosts - as has been talked about recently - then the host requirement for = supporting live storage migration will be met. This then allows the idea o= f a storage scheduler to be futher considered.=0A=0AI think this is an impo= rtant step in reaching feature parity with Vmware's vcenter product, and re= moves a key reason ovirt/rhev can't be considered in some instances.=0A ---1212189890-1261065207-1410659964=:78009 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= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo= nt-size:12pt"><div>My vote is for storage load balancing/scheduler.</div><d= iv>Vmware's Vcenter has the concept of a 'storage cluster'.   It'= s essentially a logical storage device.</div><div>When you configure hosts/= vms to use this device vcenter then works out which of the actual storage d= evices underneath this logical device is will send the storage requests to.= </div><div>This works out as a basic form of load balacing by alternating w= here the storage for new vms are created.</div><div>This isn't particularly= amazing, but what it does allow - with the highest end vcenter licensing a= nyway - is what Vmware calls 'storage distributed resource scheduling'.</di= v><div>Much like we already have the ability to have a scheduler that moves= the execution of vms around on hosts based on load, this does the same thing for the storage component of VM.</div><div>Imagine having two c= onfigured storage locations under a 'storage cluster' and then having the a= bility to put one of the storage locations into 'maintenance mode'.  T= he storage scheduler would then 'live storage migrate' all the storage for = vms over to the other storage location.  This would then allow the fir= st storage location to be taken down for maintenance.</div><div>This approa= ch also allows storage to scale over time as more is added.  The 'stor= age scheduler' can take inputs such as latency etc into account and manage = the load across the 'storage cluster' to balance things out and make smart = decisions so that the avaialble storage is utilized as best as it can be (i= e: not overloading one storage location while the other location is mainly = idle).<br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-fa= mily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br= ><span></span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-s= erif; background-color: transparent; font-style: normal;"><span>I've done a= bit a searching to see where Ovirt might be up to in this regard and what = I've found seems to indicate that we are not anywhere near this capability = just yet.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; f= ont-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans= -serif; background-color: transparent; font-style: normal;"><span>An import= ant prerequisite is having the hosts able to actually do a live storage mig= ration.  EL7 based hosts under ovirt 3.5 have this, as have Fedora 19 = and 20 hosts.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16p= x; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><sp= an>If the decision is made to use qemu-kvm-rhev on EL6 hosts - as has been = talked about recently - then the host requirement for supporting live stora= ge migration will be met.  This then allows the idea of a storage sche= duler to be futher considered.</span></div><div style=3D"color: rgb(0, 0, 0= ); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Ari= al,Lucida Grande,sans-serif; background-color: transparent; font-style: nor= mal;"><br><span></span></div><div style=3D"color: rgb(0, 0, 0); font-size: = 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gran= de,sans-serif; background-color: transparent; font-style: normal;"><span>I = think this is an important step in reaching feature parity with Vmware's vc= enter product, and removes a key reason ovirt/rhev can't be considered in s= ome instances.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,sans-serif; background-color: transparent; font-style: normal;"><span><= br></span></div></div></body></html> ---1212189890-1261065207-1410659964=:78009--

1 0

: password authentication failed for user "engine"
by Ramon Ramirez-Linan 13 Sep '14

13 Sep '14

Hello, New to the list and relatively new to oVirt I am trying to deploy the "all in one" for ovirt3.4. But the engine-setup script is stuck in the process of creating the db schema reating PostgreSQL 'engine' database [ INFO ] Configuring PostgreSQL [ INFO ] Creating Engine database schema [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/create_schema.sh' failed to execute [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back database schema - OperationalError: FATAL: password authentication failed for user "engine" .FATAL: password authentication failed for user "engine" Any suggestions would be greatly appreciate Thanks Rezuma

2 2

feature review - ReportGuestDisksLogicalDeviceName
by Liron Aravot 13 Sep '14

13 Sep '14

Feel free to review the the following feature. http://www.ovirt.org/Features/ReportGuestDisksLogicalDeviceName

5 7

VDSM and iSCSI issue due to ulimits
by Trey Dockendorf 12 Sep '14

12 Sep '14

Today I got an alert from monitoring systems that my EL7 MariaDB VM was down. I looked in oVirt and it showed the VM as "paused due to storage I/O problem". That VM is the only one currently attached to disks that are on an iSCSI storage domain. That iSCSI storage domain uses iSER (over DDR Infiniband). My instance is made up of two ovirt nodes, both with CentOS 6.5 running oVirt 3.4.3. The host that was running this VM has 16 running VMs total. I looked at the vdsm logs for the hypervisor and found log entries with "No free file handlers in pool". Below are logs. I quick "google" showed old posts about it being a ulimit problem. Right now after resuming the paused VM I see this on the VDSM server # lsof -u vdsm | wc -l 2377 # sudo -H -u vdsm -s ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1032295 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 12288 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited If the issue was due to number of open files, is it the case that if the only VM using the iSCSI storage domain was paused, the file descriptors were flushed? How do I go about finding out the cause of this, so I can prevent future issues? Is the fix to just increase the "nofile" ulimit for vdsm in /etc/security/limits.d/99-vdsm.conf? Thanks, - Trey LOGS: Sep 12 12:10:49 ovirtnode01 vdsm TaskManager.Task ERROR Task=`f467714c-8948-4cc3-94af-efba6b67701c`::Unexpected error#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/task.py", line 873, in _run#012 return fn(*args, **kargs)#012 File "/usr/share/vdsm/logUtils.py", line 45, in wrapper#012 res = f(*args, **kwargs)#012 File "/usr/share/vdsm/storage/hsm.py", line 3055, in getVolumeSize#012 apparentsize = str(dom.getVSize(imgUUID, volUUID))#012 File "/usr/share/vdsm/storage/fileSD.py", line 314, in getVSize#012 return self.oop.os.stat(volPath).st_size#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 312, in callCrabRPCFunction#012 raise Exception("No free file handlers in pool")#012Exception: No free file handlers in pool Sep 12 12:10:49 ovirtnode01 vdsm vm.Vm ERROR vmId=`967dce86-63c2-412a-97c5-d7c6f1af8dfb`::Unable to update the volume 92c6cfd0-c236-44ab-894d-cb80421dd865 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 06060f34-12c5-4396-bfe3-ad0f1d4b03fc) for the drive vda Sep 12 12:10:54 ovirtnode01 sanlock[3379]: 2014-09-12 12:10:54-0500 1773913 [5185]: s1 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.211.245:_tank_ovirt_data/6da59b00-0de7-4219-960b-d581b27052b5/dom_md/ids Sep 12 12:10:54 ovirtnode01 sanlock[3379]: 2014-09-12 12:10:54-0500 1773913 [5185]: s1 renewal error -202 delta_length 10 last_success 1773883 <repeats a few times> Sep 12 12:10:58 ovirtnode01 vdsm vm.Vm ERROR vmId=`151972dc-0025-470e-bdfe-38d3b085a63c`::Unable to update the volume 1b589b1b-aeb8-4a7a-a005-d5042de47f36 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 5d9456a3-12e1-4e50-b899-b12430a4fdb9) for the drive vda Sep 12 12:10:58 ovirtnode01 vdsm vm.Vm ERROR vmId=`b15f90ff-f359-447a-b309-2cf64d01d0ce`::Unable to update the volume 70a0fee4-2dd3-4460-94da-9ddbfb66845b (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 4e133730-f549-4b49-a8e9-baedaca4c1f1) for the drive vda <snip> Then lines like this: Sep 12 12:11:49 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:49-0500 1773968 [5185]: s1 delta_renew read rv -2 offset 0 /rhev/data-center/mnt/192.168.211.245:_tank_ovirt_data/6da59b00-0de7-4219-960b-d581b27052b5/dom_md/ids Sep 12 12:11:49 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:49-0500 1773968 [5185]: s1 renewal error -2 delta_length 10 last_success 1773883 Sep 12 12:11:49 ovirtnode01 vdsm TaskManager.Task ERROR Task=`b39a6636-451e-409c-9a81-7392000206d3`::Unexpected error#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/task.py", line 873, in _run#012 return fn(*args, **kargs)#012 File "/usr/share/vdsm/logUtils.py", line 45, in wrapper#012 res = f(*args, **kwargs)#012 File "/usr/share/vdsm/storage/hsm.py", line 3055, in getVolumeSize#012 apparentsize = str(dom.getVSize(imgUUID, volUUID))#012 File "/usr/share/vdsm/storage/fileSD.py", line 314, in getVSize#012 return self.oop.os.stat(volPath).st_size#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in callCrabRPCFunction#012 *args, **kwargs)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction#012 rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll#012 raise Timeout()#012Timeout Sep 12 12:11:49 ovirtnode01 vdsm vm.Vm ERROR vmId=`ca242da9-b7ad-41e2-a26a-db2fea2e49d7`::Unable to update the volume 03baf076-ef59-41f6-9cab-8cd64cd89307 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: d1960266-0a06-4b2a-a15d-141612aff740) for the drive vda Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 0 0x7f3dfc0008c0 busy Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 1 0x7f3dfc000910 busy Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 2 0x7f3dfc000960 busy

1 0

3.5 rc2 expand and collapse all not working?
by Gianluca Cecchi 12 Sep '14

12 Sep '14

Hello, just a rapid test on freshly installed latest rc2 engine on CentOS 6.5: on engine I get as version: oVirt Engine Version: 3.5.0-0.0.master.20140911085455.gite1c5ffd.el6 In both firefox 31.0 and chrome 37.0.2062.94 neither "expand all" nor "collapse all" work as expected: they do noting. Gianluca

2 3

[ANN] oVirt 3.5.0 Second Release Candidate is now available for testing
by Sandro Bonazzola 12 Sep '14

12 Sep '14

The oVirt team is pleased to announce that the 3.5.0 Second Release Candidate is now available for testing as of Sep 11th 2014. The release candidate is available now for Fedora 19, Fedora 20 and Red Hat Enterprise Linux 6.5 (or similar) and allow you to use Red Hat Enterprise Linux 7 as node and run Hosted Engine. Feel free to join us testing it on Tue 2014-09-16 third test day! This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.5-pre has been updated for delivering this release without the need of enabling any other repository. If you're already using oVirt 3.5 repository, please update ovirt-release35 rpm. Please refer to release notes [1] for Installation / Upgrade instructions. New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available soon as well[2]. Please note that mirrors may need usually one day before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line and removing the comment on baseurl line. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.5_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 2

Fwd: RE: FC QLogic question
by Daniel Helgenberger 12 Sep '14

12 Sep '14

Hi Daniel, I did a lsmod | grep qxl and it returned nothing... did you perhaps mean qla? [root@ovirt141 ~]# lsmod | grep qla qla2xxx 466573 56 I think that is the one lsscsi does list all of the LUNs... so that's working! But nothing in ovirt engine when I try to add a storage domain. Thanks again, I guess I will try and get a bit further with the installs I have... Bill -----Original Message----- From: Daniel Helgenberger [mailto:daniel.helgenberger@m-box.de] Sent: 11 September 2014 11:53 To: Bill Dossett Subject: Re: [ovirt-users] FC QLogic question On 11.09.2014 12:17, Bill Dossett wrote: > Thanks for responding Daniel. Never mind! > I was wondering and thought the message may be irrelevant. But yes, > it doesn't appear to be working. When I try to add a FC storage > domain, no hosts are showing in the drop down box of hosts. I have > loaded the latests ovirtnode (3.4.something...) on two hosts now and > neither are working. Lets first try to isolate your FC issure. So you are using the latest ovirt-node? EL6? Keep in mind, the kernel is standard Linux and therefore should support Qlogic adapters out of the box (IMHO they are the best supported HBAs in Linux). Please try a: # lsmod | grep qxl to see whatever the qxl module is loaded. Keep in mind you can run into problems with other conrollers in your host, though I only had this with LSI SAS / FC controllers so far. Further check on the FC switch if the N port is logged in and the zoning is correct. Finally, check with # lsscsi if you can see the luns. > Also having a lot of issues with configuring the network. I configure > an interface I can ping it, but it shows as unconfigured... on one host > I have added it to the manager and I see the interfaces anyway, but on > the second host I configure the eth0, I can ping it, it added to the > ovirt engine but it shows no NICs. Should I be using an earlier version maybe? > > thanks again and best regards. > > > *Bill Dossett* > *Virtualisation Architect* > *Pitney Bowes - Tech Central*** > 6 Hercules Way, 600 Leavesden Park > Watford, WD25 7GS > Phone(+44) (0)1923 279353 | VOIP: 54739353 > Mobile(+44) (0)7775 908612 > bill.dossett(a)pb.com <mailto:bill.dossett@pb.com> www.pb.com > <http://www.pb.com/> *In Engineering?**Raise a ticket via Remedy > Anywhere [HERE > <http://teamsite.inside.pb.com/sites/TCPPM/GES/Lists/Create%20Incident > /newIncident.aspx>]takes > less than a minute* > > *ManageIQ User Guide available* [*HERE > <https://dl.dropbox.com/u/6219441/ManageIQ%20-%20User%20Manual%20PB%20 > v4.pdf>*] *Check out the ManageIQ Blog for recent enhancements and > information [HERE] > <http://teamsite.inside.pb.com/sites/TCPPM/GES/manageiq/default.aspx>* > > On Sep 11, 2014, at 10:52 AM, Daniel Helgenberger > <daniel.helgenberger(a)m-box.de <mailto:daniel.helgenberger@m-box.de>> wrote: > > > Hello Bill, > > > > what are your problems acually? Is fibre channel not working (as expected)? > > > > The log snippet you provided is completly normal and the messages > > can safely be ignored. This is also unrelated to oVirt but rather > > CentOS (or the distro you are running) I suppose. > > > > Cheers! > > > > On 11.09.2014 10:51, Bill Dossett wrote: > >> Hi, > >> > >> I seem to have run into a problem setting up ovirt with Fibre Channel storage. > >> > >> I have a 2MBs SAN and qlogic cards in the nodes. I used this same > >> setup with RHEV about 6 months ago and it just worked, storage was > >> there no problems. Now booting with ovirtnode distro, I am seeing > >> > >> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-0091:1: > >> Firmware images can be retrieved from: http://ldriver.qlogic.com/firmware/. > >> > >> Sep 9 08:01:27 localhost kernel: scsi1 : qla2xxx > >> > >> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-00fb:1: > >> QLogic QLE2460 > >> - QLogic 4GB FC Single-Port PCI-E HBA for IBM System x. > >> > >> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-00fc:1: > >> ISP2432: PCIe (2.5GT/s x4) @ 0000:0c:00.0 hdma+ host#=1 fw=4.00.26 (2). > >> > >> Sep 9 08:01:27 localhost kernel: ata_piix 0000:00:1f.1: PCI INT A > >> -> GSI 16 (level, low) -> IRQ 16 > >> > >> I have googled the firmware error and it says some cards need a > >> firmware flash and some don't. These are pretty standard HBAs so I > >> would think they would be supported out of the box, but maybe not. > >> Looking at trying to add the firmware looked kind of complex - if I > >> need to do this, does anyone know of a nice and easy howto guide on > >> this. I'm just getting started with ovirt and appreciate any help > >> > >> > >> Thanks > >> > >> *Bill Dossett* > >> > >> *Virtualisation Architect* > >> > >> *Pitney Bowes - Tech Central*** > >> > >> 6 Hercules Way, 600 Leavesden Park > >> > >> Watford, WD25 7GS > >> > >> Phone(+44) (0)1923 279353 | VOIP: 54739353 > >> > >> Mobile(+44) (0)7775 908612 > >> > >> bill.dossett(a)pb.com <mailto:bill.dossett@pb.com> > >> <mailto:bill.dossett@pb.com> > >> > >> www.pb.com <http://www.pb.com> <http://www.pb.com/> > >> > >> *In Engineering?**Raise a ticket via Remedy Anywhere [HERE > >> <http://teamsite.inside.pb.com/sites/TCPPM/GES/Lists/Create%20Incid > >> ent/newIncident.aspx>]takes > >> > >> less than a minute* > >> > >> *ManageIQ User Guide available*[*HERE > >> <https://dl.dropbox.com/u/6219441/ManageIQ%20-%20User%20Manual%20PB > >> %20v4.pdf>*] > >> > >> *Check out the ManageIQ Blog for recent enhancements and > >> information [HERE] > >> <http://teamsite.inside.pb.com/sites/TCPPM/GES/manageiq/default.asp > >> x>* > >> > >> > >> ------------------------------------------------------------------- > >> ------------- > >> > > > > -- > > 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 <http://www.m-box.de> www.monkeymen.tv > > <http://www.monkeymen.tv> > > > > Geschäftsführer: Martin Retschitzegger / Michaela Göllner > > Handeslregister: Amtsgericht Charlottenburg / HRB 112767 > > > > > ---------------------------------------------------------------------- > ---------- > -- 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 ________________________________

7 15

Modify the MacPoolRange : Former MACs?
by Nicolas Ecarnot 12 Sep '14

12 Sep '14

Hi, I plan to extend the MacPoolRange. If I also completely change the pool, in a way that does not implies the previous setting, will the manager ban all the previous MACs, now outside the defined pool? (and stop the VMs?) Regards, -- Nicolas Ecarnot

4 7

Re: [ovirt-users] FC QLogic question
by Bill Dossett 12 Sep '14

12 Sep '14

Sorry for delay in replying on this, I got pulled into some urgent meetings at the end of the day. Regarding the questions below, Yes under the H/W tab my QLogic cards are listed. Looks like I have two different models of cards, which could be, I think I acquired them off ebay and then got another one later for redundancy. WWNN and WWPNs are listed. Miultipath -ll lists all my LUNs, multipathing is set to RR... not sure if that could be problem as the SAN I am using (old EMC/DGC CX200) is active passive and I would assume it would be MRU... Hope this helps, still no LUNs showing up in my Engine. Thanks again for your help. Bill -----Original Message----- From: Daniel Helgenberger [mailto:daniel.helgenberger@m-box.de] Sent: 11 September 2014 13:06 To: Bill Dossett Subject: Re: [ovirt-users] FC QLogic question On 11.09.2014 13:05, Bill Dossett wrote: > Hi Daniel, > > I did a lsmod | grep qxl and it returned nothing... did you perhaps mean qla? > > [root@ovirt141 ~]# lsmod | grep qla > qla2xxx 466573 56 > > I think that is the one Indeed, sorry for that. > > lsscsi does list all of the LUNs... so that's working! Great! > > But nothing in ovirt engine when I try to add a storage domain. Please check back in ovirt engine, with Hosts / Hardware info. You should see the adapter there, along with WWN's ect. I am not quite sure, but AFAIK the node uses dm-multipath by default (for iscsi multipathing). So what does: # multipath -ll list? > > Thanks again, I guess I will try and get a bit further with the installs I have... > > Bill > > > > -----Original Message----- > From: Daniel Helgenberger [mailto:daniel.helgenberger@m-box.de] > Sent: 11 September 2014 11:53 > To: Bill Dossett > Subject: Re: [ovirt-users] FC QLogic question > > On 11.09.2014 12:17, Bill Dossett wrote: >> Thanks for responding Daniel. > Never mind! >> I was wondering and thought the message may be irrelevant. But yes, >> it doesn't appear to be working. When I try to add a FC storage >> domain, no hosts are showing in the drop down box of hosts. I have >> loaded the latests ovirtnode (3.4.something...) on two hosts now and >> neither are working. > Lets first try to isolate your FC issure. So you are using the latest ovirt-node? EL6? Keep in mind, the kernel is standard Linux and therefore should support Qlogic adapters out of the box (IMHO they are the best supported HBAs in Linux). > Please try a: > # lsmod | grep qxl > to see whatever the qxl module is loaded. Keep in mind you can run into problems with other conrollers in your host, though I only had this with LSI SAS / FC controllers so far. > > Further check on the FC switch if the N port is logged in and the zoning is correct. > > Finally, check with > # lsscsi > if you can see the luns. > >> Also having a lot of issues with configuring the network. I >> configure an interface I can ping it, but it shows as unconfigured... >> on one host I have added it to the manager and I see the interfaces >> anyway, but on the second host I configure the eth0, I can ping it, >> it added to the ovirt engine but it shows no NICs. Should I be using an earlier version maybe? >> >> thanks again and best regards. >> >> >> *Bill Dossett* >> *Virtualisation Architect* >> *Pitney Bowes - Tech Central*** >> 6 Hercules Way, 600 Leavesden Park >> Watford, WD25 7GS >> Phone(+44) (0)1923 279353 | VOIP: 54739353 >> Mobile(+44) (0)7775 908612 >> bill.dossett(a)pb.com <mailto:bill.dossett@pb.com> www.pb.com >> <http://www.pb.com/> *In Engineering?**Raise a ticket via Remedy >> Anywhere [HERE >> <http://teamsite.inside.pb.com/sites/TCPPM/GES/Lists/Create%20Inciden >> t >> /newIncident.aspx>]takes >> less than a minute* >> >> *ManageIQ User Guide available* [*HERE >> <https://dl.dropbox.com/u/6219441/ManageIQ%20-%20User%20Manual%20PB%2 >> 0 v4.pdf>*] *Check out the ManageIQ Blog for recent enhancements and >> information [HERE] >> <http://teamsite.inside.pb.com/sites/TCPPM/GES/manageiq/default.aspx> >> * >> >> On Sep 11, 2014, at 10:52 AM, Daniel Helgenberger >> <daniel.helgenberger(a)m-box.de <mailto:daniel.helgenberger@m-box.de>> wrote: >> >>> Hello Bill, >>> >>> what are your problems acually? Is fibre channel not working (as expected)? >>> >>> The log snippet you provided is completly normal and the messages >>> can safely be ignored. This is also unrelated to oVirt but rather >>> CentOS (or the distro you are running) I suppose. >>> >>> Cheers! >>> >>> On 11.09.2014 10:51, Bill Dossett wrote: >>>> Hi, >>>> >>>> I seem to have run into a problem setting up ovirt with Fibre Channel storage. >>>> >>>> I have a 2MBs SAN and qlogic cards in the nodes. I used this same >>>> setup with RHEV about 6 months ago and it just worked, storage was >>>> there no problems. Now booting with ovirtnode distro, I am seeing >>>> >>>> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-0091:1: >>>> Firmware images can be retrieved from: http://ldriver.qlogic.com/firmware/. >>>> >>>> Sep 9 08:01:27 localhost kernel: scsi1 : qla2xxx >>>> >>>> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-00fb:1: >>>> QLogic QLE2460 >>>> - QLogic 4GB FC Single-Port PCI-E HBA for IBM System x. >>>> >>>> Sep 9 08:01:27 localhost kernel: qla2xxx [0000:0c:00.0]-00fc:1: >>>> ISP2432: PCIe (2.5GT/s x4) @ 0000:0c:00.0 hdma+ host#=1 fw=4.00.26 (2). >>>> >>>> Sep 9 08:01:27 localhost kernel: ata_piix 0000:00:1f.1: PCI INT A >>>> -> GSI 16 (level, low) -> IRQ 16 >>>> >>>> I have googled the firmware error and it says some cards need a >>>> firmware flash and some don't. These are pretty standard HBAs so I >>>> would think they would be supported out of the box, but maybe not. >>>> Looking at trying to add the firmware looked kind of complex - if I >>>> need to do this, does anyone know of a nice and easy howto guide on >>>> this. I'm just getting started with ovirt and appreciate any help >>>> >>>> >>>> Thanks >>>> >>>> *Bill Dossett* >>>> >>>> *Virtualisation Architect* >>>> >>>> *Pitney Bowes - Tech Central*** >>>> >>>> 6 Hercules Way, 600 Leavesden Park >>>> >>>> Watford, WD25 7GS >>>> >>>> Phone(+44) (0)1923 279353 | VOIP: 54739353 >>>> >>>> Mobile(+44) (0)7775 908612 >>>> >>>> bill.dossett(a)pb.com <mailto:bill.dossett@pb.com> >>>> <mailto:bill.dossett@pb.com> >>>> >>>> www.pb.com <http://www.pb.com> <http://www.pb.com/> >>>> >>>> *In Engineering?**Raise a ticket via Remedy Anywhere [HERE >>>> <http://teamsite.inside.pb.com/sites/TCPPM/GES/Lists/Create%20Incid >>>> ent/newIncident.aspx>]takes >>>> >>>> less than a minute* >>>> >>>> *ManageIQ User Guide available*[*HERE >>>> <https://dl.dropbox.com/u/6219441/ManageIQ%20-%20User%20Manual%20PB >>>> %20v4.pdf>*] >>>> >>>> *Check out the ManageIQ Blog for recent enhancements and >>>> information [HERE] >>>> <http://teamsite.inside.pb.com/sites/TCPPM/GES/manageiq/default.asp >>>> x>* >>>> >>>> >>>> ------------------------------------------------------------------- >>>> ------------- >>>> >>> -- >>> 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 <http://www.m-box.de> www.monkeymen.tv >>> <http://www.monkeymen.tv> >>> >>> Geschäftsführer: Martin Retschitzegger / Michaela Göllner >>> Handeslregister: Amtsgericht Charlottenburg / HRB 112767 >>> >> >> --------------------------------------------------------------------- >> - >> ---------- >> > -- > 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 > > > ________________________________ > > -- 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