- Users - oVirt List Archives

how can i setup hosted engine on the ovirt-node-3.5-201504280933
by Zhong Qiang 06 Jul '15

06 Jul '15

I 'm installing oVirt Node using a CD(ovirt-node-iso-3.5-0.999.201504280933.el6.iso),and Ovirt Node is worked. How can i setup hosted engine by using OVirt Node Console?or where can i get the Engine OVA? I can't find any description about this in the " www.ovirt.org". The Console looks like this: " Hosted Engine Setup Hosted Engine: Not configured Engine VM Name: Engine Status: Hosted engine not configured Engine ISO/OVA URL for download: _____________ PXE Boot Engine VM [ ] " Thanks.

3 17

Host failed to attach one of the Storage Domains attached to it
by Alin Ilie 04 Jul '15

04 Jul '15

This is a multi-part message in MIME format. --------------060503080301050806000704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, We have a small oVirt deplopyment, with 2 INTEL CPUs and 1 AMD, therefor we defined 2 clusters. One of the Intel machines is running the management as well (We called this SOL). This deployment is connected to a NAS through NFS shares. Suddenly (no more than 2 days) SOL is reported as "Non operational" and in the Action Items is saying " Host failed to attach one of the Storage Domains attached to it." All other machines seems to be fine. In the past we encountered similar errors after (accidental) reboot of the hosts, but now it is not the case: [root@sol ~]# uptime 08:10:48 up 9 days, 15:48, 1 user, load average: 0.08, 0.05, 0.12 The "funny" is that the virtual machines already started on SOL are still running without any problems. I am not sure what logs to check. In /var/log/vdsm/vdsm.log we have this error, but I do not think it is relevant: Thread-38964::ERROR::2015-07-05 08:37:24,882::__init__::506::jsonrpc.JsonRpcServer::(_serveRequest) Internal server error Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 501, in _serveRequest res = method(**params) File "/usr/share/vdsm/rpc/Bridge.py", line 271, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 1330, in getStats stats.update(self._cif.mom.getKsmStats()) File "/usr/share/vdsm/momIF.py", line 60, in getKsmStats stats = self._mom.getStatistics()['host'] File "/usr/lib/python2.6/site-packages/mom/MOMFuncs.py", line 75, in getStatistics host_stats = self.threads['host_monitor'].interrogate().statistics[-1] AttributeError: 'NoneType' object has no attribute 'statistics' Thank you ! --------------060503080301050806000704 Content-Type: multipart/related; boundary="------------000103070605000308060409" --------------000103070605000308060409 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello, We have a small oVirt deplopyment, with 2 INTEL CPUs and 1 AMD, therefor we defined 2 clusters. One of the Intel machines is running the management as well (We called this SOL). This deployment is connected to a NAS through NFS shares. Suddenly (no more than 2 days) SOL is reported as "Non operational" and in the Action Items is saying "<img class="gwt-Image" onload='this.__gwtLastUnhandledEvent="load";' src="cid:part1.08080605.07050106@matrixrom.com" style="width: 14px; height: 12px; background: transparent url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAAKklEQVR42mNgwAL+n0n7/3+mMRifSTP+z0AsGNVIC40gxciYgeZgcPoRAJrmd4n8GZZPAAAAAElFTkSuQmCC") no-repeat scroll 0px 0px; display: inline;" border="0"> <div> <div style="display: inline;" class="gwt-Label">Host failed to attach one of the Storage Domains attached to it." All other machines seems to be fine. In the past we encountered similar errors after (accidental) reboot of the hosts, but now it is not the case: [root@sol ~]# uptime 08:10:48 up 9 days, 15:48, 1 user, load average: 0.08, 0.05, 0.12 The "funny" is that the virtual machines already started on SOL are still running without any problems. I am not sure what logs to check. In /var/log/vdsm/vdsm.log we have this error, but I do not think it is relevant: Thread-38964::ERROR::2015-07-05 08:37:24,882::__init__::506::jsonrpc.JsonRpcServer::(_serveRequest) Internal server error Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 501, in _serveRequest res = method(**params) File "/usr/share/vdsm/rpc/Bridge.py", line 271, in _dynamicMethod result = fn(*methodArgs) File "/usr/share/vdsm/API.py", line 1330, in getStats stats.update(self._cif.mom.getKsmStats()) File "/usr/share/vdsm/momIF.py", line 60, in getKsmStats stats = self._mom.getStatistics()['host'] File "/usr/lib/python2.6/site-packages/mom/MOMFuncs.py", line 75, in getStatistics host_stats = self.threads['host_monitor'].interrogate().statistics[-1] AttributeError: 'NoneType' object has no attribute 'statistics' Thank you ! </div> </div> </body> </html> --------------000103070605000308060409-- --------------060503080301050806000704--

1 0

Re: [ovirt-users] VM run once API required
by Chandrahasa S 03 Jul '15

03 Jul '15

This is a multipart message in MIME format. --=_alternative 0026CB3D65257E77_= Content-Type: text/plain; charset="US-ASCII" Any one can help on this ?? Thanks & Regards From: Chandrahasa S/MUM/TCS To: Users(a)ovirt.org Date: 30-06-2015 11:46 Subject: VM run once API required Hi Experts, We are integrating RHEV(M) with our internal cloud portal using RHEV(M) API, we are able to provision Linux VM using API. But IP and Hostname not getting reflected on vm first boot. If we boot VM manually using run once its working fine. We are not able to find any run once API on RHEV end. Requested your help on this. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0026CB3D65257E77_= Content-Type: text/html; charset="US-ASCII" Any one can help on this ?? Thanks & Regards From:        Chandrahasa S/MUM/TCS To:        Users(a)ovirt.org Date:        30-06-2015 11:46 Subject:        VM run once API required <hr noshade> Hi Experts, We are integrating RHEV(M) with our internal cloud portal using RHEV(M) API, we are able to provision Linux VM using API. But IP and Hostname not getting reflected on vm  first boot. If we boot VM manually using run once its working fine. We are not able to find any run once API on RHEV end. Requested your help on this. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 0026CB3D65257E77_=--

3 2

veam backup integration or equivalent.
by Nathanaël Blanchet 03 Jul '15

03 Jul '15

This is a multi-part message in MIME format. --------------060009030102000405000501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, I need advices about backing up vms. At this point, I can count three possible levels of backup: * lun snapshot on a FC/iSCSI SAN, but we save the whole storage domain * vm snapshot with the qemu capabilities * file system backup with a system like rsnaphot afaik, it will be possible to make LVM snapshot in the upcoming 3.6 To my mind the most convinient backup is the vm snapshot level, but the=20 backup API provided since 3.4 is difficult to use. At the end of=20 december, Lucas Vandroux (ovirt china) announciated the avaibility of=20 vm-backup-scheduler=20 (https://github.com/ovirt-china/vm-backup-scheduler) but I never=20 managed to make it work. A colleague told me about veam backup for backing up at vm level, but it=20 seems to support only hyper-V and vmware. Does it exist some equivalent? Good practices of senior sysadmin are welcome! --=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr --------------060009030102000405000501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf= -8"> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> Hi all, I need advices about backing up vms. At this point, I can count three possible levels of backup: <ul> <li>lun snapshot on a FC/iSCSI SAN, but we save the whole storage domain</li> <li>vm snapshot with the qemu capabilities</li> <li>file system backup with a system like rsnaphot</li> </ul> afaik, it will be possible to make LVM snapshot in the upcoming 3.6 To my mind the most convinient backup is the vm snapshot level, but the backup API provided since 3.4 is difficult to use. At the end of december, Lucas Vandroux (ovirt china) announciated the avaibility of vm-backup-scheduler (https= ://github.com/ovirt-china/vm-backup-scheduler), but I never managed to make it work. A colleague told me about veam backup for backing up at vm level, but it seems to support only hyper-V and vmware. Does it exist some equivalent? Good practices of senior sysadmin are welcome! <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet(a)abes.fr</a> </pre> </body> </html> --------------060009030102000405000501--

1 0

Re: [ovirt-users] Can´t use a VM Network VLAN, because the Virtual Machines inside can't reach the Gateway
by Julián Tete 02 Jul '15

02 Jul '15

I tried a different Aproach: One VLAN for each NIC I tried but not works.... I left the Virtual Machine pinging the Gateway after 10 minutes I left my Worstation alone and I went back to my home. Today i see the ping working (¿?) Maybe I rush too much...or maybe not. I reboot the Virtual Machine, same problem: after 15 minutes the Machine can't reach the Gateway, we need HA and 10+ minutes it's not considerated. After a I mess my oVirt LAB, after trying everything. This my last working setup with sloooooooooow reaching of Gateway: DATA CENTERS Logical Networks: ----------- Name: ovirtmgmt Description: Management Network Network Label: 1 MTU: Default ----------- Name: dmz Description: VLAN 50 Network Label: 50 Enable VLAN tagging: 50 VM network MTU: Default ----------- Name: Hosting Description: VLAN 100 Network Label: 100 Enable VLAN tagging: 100 VM network MTU: Default ------------ CLUSTERS Logical Networks ovirtmgmt Assign Required Display Network Migration Network dmz Assign Hosting Assign Required HOSTS Name: srvovirt02.cnsc.net Hostname/IP: 192.168.0.63 Network Interfaces HOSTS BOND VLAN NETWORK NAME ADDRESS MAC SPEED(Mbps) RX(Mbps) TX(Mbps) eno1 * ovirtmgmt 192.168.0.63 00:17:a4:77:00:18 10000 < 1 < 1 eno2 eno2.50 (50) dmz 192.168.50.8 00:17:a4:77:00:1a 10000 < 1 < 1 ens1f0 ens1f0.100 (100) Hosting 192.168.100.7 00:17:a4:77:00:1c 10000 < 1 < 1 ens1f1 00:17:a4:77:00:1e 0 < 1 < 1 Setup Hosts Networks Network: ovirtmgmt Static IP: 192.168.0.63 Subnet Mask: 255.255.255.0 Gateway: 192.168.0.1 Custom Properties: No available keys Sync network: Yes Network: dmz Static IP: 192.168.50.8 Subnet Mask: 255.255.255.224 Gateway: 192.168.50.1 Custom Properties: Please select a key... Network: Hosting Static IP: 192.168.100.7 Subnet Mask: 255.255.255.240 Gateway: 192.168.100.1 Custom Properties: Please select a key... Virtual Machines Name: PruebaVLAN Host: srvovirt02.cnsc.net Edit Network Interface Name: nic1 Profile: dmz/dmz Type: VirtIO Custom MAC address: 00:00:1a:4a:3e:00 Link State: Up Card Status: Plugged Network Interfaces in the Host srvovirt02.cnsc.net: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovirtmgmt state UP qlen 1000 link/ether 00:17:a4:77:00:18 brd ff:ff:ff:ff:ff:ff inet6 fe80::217:a4ff:fe77:18/64 scope link valid_lft forever preferred_lft forever 3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:17:a4:77:00:1a brd ff:ff:ff:ff:ff:ff inet6 fe80::217:a4ff:fe77:1a/64 scope link valid_lft forever preferred_lft forever 4: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:17:a4:77:00:1c brd ff:ff:ff:ff:ff:ff inet6 fe80::217:a4ff:fe77:1c/64 scope link valid_lft forever preferred_lft forever 5: ens1f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 00:17:a4:77:00:1e brd ff:ff:ff:ff:ff:ff 6: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN link/ether 72:f8:9c:75:e3:86 brd ff:ff:ff:ff:ff:ff 7: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master dmz state UNKNOWN qlen 500 link/ether fe:00:1a:4a:3e:00 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc00:1aff:fe4a:3e00/64 scope link valid_lft forever preferred_lft forever 17: eno2.50@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master dmz state UP link/ether 00:17:a4:77:00:1a brd ff:ff:ff:ff:ff:ff inet6 fe80::217:a4ff:fe77:1a/64 scope link valid_lft forever preferred_lft forever 18: dmz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:17:a4:77:00:1a brd ff:ff:ff:ff:ff:ff inet 192.168.50.8/27 brd 192.168.50.31 scope global dmz valid_lft forever preferred_lft forever inet6 fe80::217:a4ff:fe77:1a/64 scope link valid_lft forever preferred_lft forever 19: ens1f0.100@ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master Hosting state UP link/ether 00:17:a4:77:00:1c brd ff:ff:ff:ff:ff:ff inet6 fe80::217:a4ff:fe77:1c/64 scope link valid_lft forever preferred_lft forever 20: Hosting: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:17:a4:77:00:1c brd ff:ff:ff:ff:ff:ff inet 192.168.100.7/28 brd 192.168.100.15 scope global Hosting valid_lft forever preferred_lft forever inet6 fe80::217:a4ff:fe77:1c/64 scope link valid_lft forever preferred_lft forever 21: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 00:17:a4:77:00:18 brd ff:ff:ff:ff:ff:ff inet 192.168.0.63/24 brd 192.168.0.255 scope global ovirtmgmt valid_lft forever preferred_lft forever inet6 fe80::217:a4ff:fe77:18/64 scope link valid_lft forever preferred_lft forever 2015-06-30 21:34 GMT-05:00 Julián Tete <danteconrad14(a)gmail.com>: > You can count on it :) > > 2015-06-30 21:23 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: > >> Let us know how it works out, I am curious to see if having a untagged >> and tagged interface on the same bridge was an issue. >> On Jun 30, 2015 10:21 PM, "Julián Tete" <danteconrad14(a)gmail.com> wrote: >> >>> Thanks Donny, Tomorrow I'm going to try this. :) >>> >>> 2015-06-30 21:12 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>> >>>> That tells me that there is a tagging issue between the host and the >>>> switch. >>>> Untagged traffic flows without issue via the same interface as tagged >>>> traffic. >>>> As a personal best practice I separate access ports(untagged) and trunk >>>> ports (tagged) traffic on different physical ports. >>>> Can you setup a separate phys interface for the tagged traffic, or must >>>> you be able to pass both on the same interface. >>>> On Jun 30, 2015 10:05 PM, "Julián Tete" <danteconrad14(a)gmail.com> >>>> wrote: >>>> >>>>> My mgmt network works wonderfully, Virtual Machines created on the >>>>> mgmt even can reach Internet. But my company wants the traffic separated. >>>>> >>>>> Thanks Donny, I'm a RHCSA from Colombia, but I'm learning about oVirt. >>>>> (oVirt is a new thing in my country) >>>>> >>>>> P.S : I want to put VMware in the Trash Can too. ^_ ^ >>>>> >>>>> 2015-06-30 20:59 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>>>> >>>>>> There is a special place in my DC for vmware. TrashCan...lol >>>>>> On Jun 30, 2015 9:50 PM, "Julián Tete" <danteconrad14(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> I'm going to check it out... but how the host can reach the Gateway >>>>>>> and the Virtual Machine inside doesn't ? >>>>>>> >>>>>>> Donny you are very kind, this the last step to free my DataCenter >>>>>>> from VMware. >>>>>>> >>>>>>> 2015-06-30 20:46 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>>>>>> >>>>>>>> Does your switch have an IP on that vlan... I would step things out >>>>>>>> VM>host>switch>rtr >>>>>>>> >>>>>>>> You have already confirmed VM to host. >>>>>>>> >>>>>>>> I'm going to look at your screens again to make sure I didn't miss >>>>>>>> anything >>>>>>>> On Jun 30, 2015 9:42 PM, "Julián Tete" <danteconrad14(a)gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks for the explanation :) >>>>>>>>> >>>>>>>>> I set everything of the VLANs at oVirt, After I put a IP on the >>>>>>>>> Virtual Machine. But the Virtual Machine can't reach the gateway, The host >>>>>>>>> can do. The Virtual Machine only can reach the host. All the machines of >>>>>>>>> the range of net can reach the Virtual Machine. >>>>>>>>> >>>>>>>>> 2015-06-30 20:36 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>>>>>>>> >>>>>>>>>> I'm asking if your setting the vlan on the VM or at ovirt. >>>>>>>>>> >>>>>>>>>> More than likely if you are coming from VMware you have the Vlans >>>>>>>>>> set at the hypervisor. This does work in ovirt, I am doing it right now >>>>>>>>>> On Jun 30, 2015 9:31 PM, "Julián Tete" <danteconrad14(a)gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Mmmm I'm new in oVirt :( >>>>>>>>>>> >>>>>>>>>>> VMs Interface is Virtual MachineS Interface or VM Network >>>>>>>>>>> Interface in the host ? >>>>>>>>>>> >>>>>>>>>>> I configured the IP of the VLAN in the host. >>>>>>>>>>> >>>>>>>>>>> I double check: the NIC of the Host has the VLAN assigned. >>>>>>>>>>> >>>>>>>>>>> Can you help me ? >>>>>>>>>>> >>>>>>>>>>> 2015-06-30 20:11 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>>>>>>>>>> >>>>>>>>>>>> Are you configuring the vms interface with the vlan or tagging >>>>>>>>>>>> at the host. >>>>>>>>>>>> On Jun 30, 2015 7:28 PM, "Julián Tete" <danteconrad14(a)gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Donny >>>>>>>>>>>>> >>>>>>>>>>>>> We have HP Switches (HP 5406zl) and they are configurated on >>>>>>>>>>>>> trunk mode. (VMware is configurated to use that). >>>>>>>>>>>>> >>>>>>>>>>>>> Any suggestion ? >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your response. >>>>>>>>>>>>> >>>>>>>>>>>>> :) >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-06-30 17:51 GMT-05:00 Donny Davis <donny(a)cloudspin.me>: >>>>>>>>>>>>> >>>>>>>>>>>>>> Vlans are layer 2, sounds like a tagging problem. Cisco >>>>>>>>>>>>>> switches? The tag sticks to the host bridge, but is being stripped off when >>>>>>>>>>>>>> it leaves the host.... Is your switch in access mode or trunk? >>>>>>>>>>>>>> Hi Friends of oVirt >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm trying to migrate my company from VMware to oVirt. >>>>>>>>>>>>>> In my final tests, I set up 2 more VLANs in oVirt, (VM VLANs) >>>>>>>>>>>>>> The Virtual Machines in these VLANs, can be reached from the >>>>>>>>>>>>>> external IPs from the net range, >>>>>>>>>>>>>> but from the Virtual machines only can ping the Host with the >>>>>>>>>>>>>> Bridge and itself, can't reach the gateway. ¿? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I configured a IP Forwarding in the Host with the virtual >>>>>>>>>>>>>> machine, and nothing changes... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any idea ? This is the last duty before embrace oVirt in the >>>>>>>>>>>>>> company. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Look to the VLAN 100 configuration (My desired VM Network): >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/7hrog0a2n/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/68b40i1vr/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/lu6mlshgp/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/540o1qc0t/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/4kyg787bt/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/v7ralh7zb/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://postimg.org/image/kn903cl03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> For any idea, thanks in advance >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Users mailing list >>>>>>>>>>>>>> Users(a)ovirt.org >>>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >

2 3

Confused / Hosted-Engine won't start
by Christopher Young 02 Jul '15

02 Jul '15

I'm sure I have worked through this before, but I've been banging my head against this one for a while now, and I think I'm too close to the issue. Basically, my hosted-engine won't start anymore. I do recall attempting to migrate it to a new gluster-based NFS share recently, but I could have sworn that was successful and working. I _think_ I have some sort of id issue with storage/volume/whatever id's, but I need some help digging through it if someone would be so kind. I have the following error in /var/log/libvirt/qemu/HostedEngine.log: ---------- 2015-07-02T00:01:13.080952Z qemu-kvm: -drive file=/var/run/vdsm/storage/4e3017eb-d062-4ad1-9df8-7057fcee412c/5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836/eeb2d821-a432-4df6-8856-fdb14df260e3,if=none,id=drive-virtio-disk0,format=raw,serial=5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836,cache=none,werror=stop,rerror=stop,aio=threads: could not open disk image /var/run/vdsm/storage/4e3017eb-d062-4ad1-9df8-7057fcee412c/5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836/eeb2d821-a432-4df6-8856-fdb14df260e3: Could not refresh total sector count: Input/output error ---------- I also am including a few command outputs that I'm sure might help: ---------- [root@orldc-dev-vnode02 4e3017eb-d062-4ad1-9df8-7057fcee412c]# ls -la /var/run/vdsm/storage/4e3017eb-d062-4ad1-9df8-7057fcee412c/ total 8 drwxr-xr-x. 2 vdsm kvm 80 Jul 1 20:04 . drwxr-xr-x. 3 vdsm kvm 60 Jul 1 20:04 .. lrwxrwxrwx. 1 vdsm kvm 128 Jul 1 20:04 1d80a60c-8f26-4448-9460-2c7b00ff75bf -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/1d80a60c-8f26-4448-9460-2c7b00ff75bf lrwxrwxrwx. 1 vdsm kvm 128 Jul 1 20:04 23ac8897-b0c7-41d6-a7de-19f46ed78400 -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/23ac8897-b0c7-41d6-a7de-19f46ed78400 ---------- [root@orldc-dev-vnode02 4e3017eb-d062-4ad1-9df8-7057fcee412c]# cat /etc/ovirt-hosted-engine/vm.conf vmId=6b7329f9-518a-4488-b1c4-2cd809f2f580 memSize=5120 display=vnc devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0, bus:1, type:drive},specParams:{},readonly:true,deviceId:77924fc2-c5c9-408b-97d3-cd0b0d11a62c,path:/home/tmp/CentOS-6.6-x86_64-minimal.iso,device:cdrom,shared:false,type:disk} devices={index:0,iface:virtio,format:raw,poolID:00000000-0000-0000-0000-000000000000,volumeID:eeb2d821-a432-4df6-8856-fdb14df260e3,imageID:5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836,specParams:{},readonly:false,domainID:4e3017eb-d062-4ad1-9df8-7057fcee412c,optional:false,deviceId:5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836,address:{bus:0x00, slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shared:exclusive,propagateErrors:off,type:disk,bootOrder:1} devices={device:scsi,model:virtio-scsi,type:controller} devices={nicModel:pv,macAddr:00:16:3e:0e:d0:68,linkActive:true,network:ovirtmgmt,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:f70ba622-6ac8-4c06-a005-0ebd940a15b2,address:{bus:0x00, slot:0x03, domain:0x0000, type:pci, function:0x0},device:bridge,type:interface} devices={device:console,specParams:{},type:console,deviceId:98386e6c-ae56-4b6d-9bfb-c72bbd299ad1,alias:console0} vmName=HostedEngine spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir smp=2 cpuType=Westmere emulatedMachine=pc ---------- [root@orldc-dev-vnode02 4e3017eb-d062-4ad1-9df8-7057fcee412c]# cat /etc/ovirt-hosted-engine/hosted-engine.conf fqdn=orldc-dev-vengine01.******* vm_disk_id=5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836 vmid=6b7329f9-518a-4488-b1c4-2cd809f2f580 storage=ovirt-gluster-nfs:/engine conf=/etc/ovirt-hosted-engine/vm.conf service_start_time=0 host_id=1 console=vnc domainType=nfs3 spUUID=379cf161-d5b1-4c20-bb71-e3ca5d2ccd6b sdUUID=4e3017eb-d062-4ad1-9df8-7057fcee412c connectionUUID=0d1b50ac-cf3f-4cd7-90df-3c3a6d11a984 ca_cert=/etc/pki/vdsm/libvirt-spice/ca-cert.pem ca_subject="C=EN, L=Test, O=Test, CN=Test" vdsm_use_ssl=true gateway=10.16.3.1 bridge=ovirtmgmt metadata_volume_UUID=dd9f373c-d161-4fa0-aab1-3cb52305dba7 metadata_image_UUID=23ac8897-b0c7-41d6-a7de-19f46ed78400 lockspace_volume_UUID=d9bacbf6-c2f4-4f74-a91f-3a3a52f255bf lockspace_image_UUID=1d80a60c-8f26-4448-9460-2c7b00ff75bf # The following are used only for iSCSI storage iqn= portal= user= password= port= ---------- (mount output for the NFS share this should be running on (gluster-based): ovirt-gluster-nfs:/engine on /rhev/data-center/mnt/ovirt-gluster-nfs:_engine type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,soft,nolock,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=10.16.3.30,mountvers=3,mountport=38465,mountproto=tcp,local_lock=all,addr=10.16.3.30) ---------- [root@orldc-dev-vnode02 4e3017eb-d062-4ad1-9df8-7057fcee412c]# tree /rhev/data-center/mnt/ovirt-gluster-nfs\:_engine/ /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/ ├── 4e3017eb-d062-4ad1-9df8-7057fcee412c │ ├── dom_md │ │ ├── ids │ │ ├── inbox │ │ ├── leases │ │ ├── metadata │ │ └── outbox │ ├── ha_agent │ │ ├── hosted-engine.lockspace -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/1d80a60c-8f26-4448-9460-2c7b00ff75bf/d9bacbf6-c2f4-4f74-a91f-3a3a52f255bf │ │ └── hosted-engine.metadata -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/23ac8897-b0c7-41d6-a7de-19f46ed78400/dd9f373c-d161-4fa0-aab1-3cb52305dba7 │ ├── images │ │ ├── 1d80a60c-8f26-4448-9460-2c7b00ff75bf │ │ │ ├── d9bacbf6-c2f4-4f74-a91f-3a3a52f255bf │ │ │ ├── d9bacbf6-c2f4-4f74-a91f-3a3a52f255bf.lease │ │ │ └── d9bacbf6-c2f4-4f74-a91f-3a3a52f255bf.meta │ │ ├── 23ac8897-b0c7-41d6-a7de-19f46ed78400 │ │ │ ├── dd9f373c-d161-4fa0-aab1-3cb52305dba7 -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/23ac8897-b0c7-41d6-a7de-19f46ed78400 │ │ │ ├── dd9f373c-d161-4fa0-aab1-3cb52305dba7.lease │ │ │ └── dd9f373c-d161-4fa0-aab1-3cb52305dba7.meta │ │ ├── 3278c444-d92a-4cb9-87d6-9669c6e4993e │ │ │ ├── 1a4b6a5d-9c8f-4d54-91a7-3dd87377c362 │ │ │ ├── 1a4b6a5d-9c8f-4d54-91a7-3dd87377c362.lease │ │ │ └── 1a4b6a5d-9c8f-4d54-91a7-3dd87377c362.meta │ │ ├── 5ead7b5d-50e8-4d6c-a0e5-bbe6d93dd836 │ │ │ ├── eeb2d821-a432-4df6-8856-fdb14df260e3.lease │ │ │ └── eeb2d821-a432-4df6-8856-fdb14df260e3.meta │ │ ├── 6064179f-2720-4db9-a7c4-a97e044c2238 │ │ │ ├── 05afaa26-95af-4226-9a00-5383d8937a83 │ │ │ ├── 05afaa26-95af-4226-9a00-5383d8937a83.lease │ │ │ └── 05afaa26-95af-4226-9a00-5383d8937a83.meta │ │ └── bb9d9a37-4f91-4973-ba9e-72ee81aed0b6 │ │ ├── 5acb27b3-62c5-46ac-8978-576a8a4a0399 │ │ ├── 5acb27b3-62c5-46ac-8978-576a8a4a0399.lease │ │ └── 5acb27b3-62c5-46ac-8978-576a8a4a0399.meta │ └── master │ ├── tasks │ │ └── fef13299-0e7f-4c7a-a399-092a1235faab │ │ ├── fef13299-0e7f-4c7a-a399-092a1235faab.job.0 │ │ ├── fef13299-0e7f-4c7a-a399-092a1235faab.recover.0 │ │ ├── fef13299-0e7f-4c7a-a399-092a1235faab.recover.1 │ │ ├── fef13299-0e7f-4c7a-a399-092a1235faab.result │ │ └── fef13299-0e7f-4c7a-a399-092a1235faab.task │ └── vms └── __DIRECT_IO_TEST__ 16 directories, 28 files ---------- [root@orldc-dev-vnode02 4e3017eb-d062-4ad1-9df8-7057fcee412c]# tree /var/run/vdsm/storage/4e3017eb-d062-4ad1-9df8-7057fcee412c /var/run/vdsm/storage/4e3017eb-d062-4ad1-9df8-7057fcee412c ├── 1d80a60c-8f26-4448-9460-2c7b00ff75bf -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/1d80a60c-8f26-4448-9460-2c7b00ff75bf └── 23ac8897-b0c7-41d6-a7de-19f46ed78400 -> /rhev/data-center/mnt/ovirt-gluster-nfs:_engine/4e3017eb-d062-4ad1-9df8-7057fcee412c/images/23ac8897-b0c7-41d6-a7de-19f46ed78400 2 directories, 0 files ---------- Can you anyone point me in the right direction here? Eventually, I'd like to get this hosted-engine running in HA mode (I had started this process with ctdb/gluster/etc. via the well-known guide out there), but I'm thinking that at this point, I should get this up and running again, export everything, and perhaps just build a new hosted-engine and import things into (if that is possible). Right now, though, I just need to get this hosted-engine run. Many many thanks! Chris

3 7

New VDSM and QEmu-KVM versions available for testing
by Sandro Bonazzola 02 Jul '15

02 Jul '15

Hi, the following packages from oVirt 3.5.4 RC1[1] have been pushed to CentOS Virt SIG testing repositories: - qemu-kvm-ev-2.1.2-23.el7_1.4.1 - vdsm-4.16.21-1.el7 You're welcome to test them[2] and provide feedback. [1] http://www.ovirt.org/OVirt_3.5.4_Release_Notes [2] http://wiki.centos.org/HowTos/oVirt Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt 3.5.3 Host Network Interfaces
by Prof. Dr. Michael Schefczyk 01 Jul '15

01 Jul '15

------=_Part_144_347748262.1435789919138 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Language: de-DE Dear All, Having set up a Centos 7 server with Gluster, oVirt 3.5.3 and hosted engine= according to https://community.redhat.com/blog/2014/10/up-and-running-with= -ovirt-3-5/, I was hoping that the NIC management and particularly NIC bond= /bridge capabilities would have improved a bit. My server has four NICs, tw= o connected to the LAN and two to an adjacent server to be used as a Gluste= r network between the two servers. My aim is to use NIC bonding for two NIC= s each. Via the engine, I would like to use Hosts -> Network Interfaces -> Setup Ho= st Networks. As I use hosted engine, I cannot set the only host to maintena= nce mode. At least during normal operations, however, I am neither able to = change the ovirt bridge from DHCP to static IP nor create a bond consisting= of the two LAN facing NICs. In each case I get, "Error while executing act= ion Setup Networks: Network is currently being used". Editing the network s= cripts manually is not an option either, as that does not survive a reboot.= Contrary to this real view, everything should be easily configurable accor= ding to section 6.6 of the oVirt administration guide. One workaround approach could be to temporarily move one NIC connection fro= m the adjacent server to the LAN or even temporarily swap both pairs of NIC= s and edit interfaces while they are not in use. Is this really the way for= ward? Should there not be a more elegant approach not requiring physically = plugging NIC connections just to work around such issue? Regards, Michael ------=_Part_144_347748262.1435789919138 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggZZMIIF QaADAgECAgJS9zANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4X DTE0MDgyOTIxMTg1NVoXDTE2MDgzMDE3MDkzOVowczELMAkGA1UEBhMCREUxEDAOBgNVBAgTB1Nh Y2hzZW4xEDAOBgNVBAcTB0RyZXNkZW4xGjAYBgNVBAMTEU1pY2hhZWwgU2NoZWZjenlrMSQwIgYJ KoZIhvcNAQkBFhVtaWNoYWVsQHNjaGVmY3p5ay5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCt5lyNrHr+nGpNQjbzWFly9TrHozxRULCpKpAsM30y+zC+HVtE0yAh+EE54kxvzeqn hxAiGf/LnYjwiUO+GcaDEElBJzCL+RxLb4/cUfejt1Xvlkq9ksDNS/RDJHEPnDR5zl1jyhahIxU8 cb8mcJ4AI/Jzxn98OlMi8mNCyv+K00hJDb+2L/rv67Sbhmo2P6SjCtfUmOyN9O8o0B2RSQVcceW3 0gzMtGpg5XurhJGpLTEQabxc7N55WaHra6kofeVSIAffH1pGfOj5h+L5MU5yFDk3wVsJOXFe5oW/ vI2ONd6gyVHsO8DGk5/MfFLJkfC5pOVRyRVbEfWwGHfRzD1fAgMBAAGjggLbMIIC1zAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYE FAP+tMlaA2ov17PpSyQxT8o2eu7eMB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MCAG A1UdEQQZMBeBFW1pY2hhZWxAc2NoZWZjenlrLm5ldDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3Mg MiBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1o dHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKG Nmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBAJvF IHWAXqVt6Pfh3Liq9z1GN+yEKlo94psj3IHJ6qTS6iERIwbwQzKSsBWxI20kEWzysLEh1aWTJJnf bfjx4tidj0WhQYoX99FLnMSvuYAvvXSfWt99hfXyRi6zHav7X7gyeFPuRdK+hZcIzEDp9RLmSloo Pcptb3J9YiUZY7tpQ0Z2A+RM1jVne0Y2kMCD8J7FSw7h+GM3RHKMNzEniE4LAQaXoLFdcLIXKHaC Zaw6BVE86Z8DVQTBN8LNrF7j6rNbZdGMxHNBZVzFlSbWXGd8UG9L6LXW5QLseGwYrVBEHWTqZzuf uTccXnOXT1SPiYR2PqZ2c/2EJHLUo9aqIdswggY0MIIEHKADAgECAgEgMA0GCSqGSIb3DQEBBQUA MH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTVaFw0xNzEwMjQyMTAyNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDLKIVFnAEs +xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQA7Xj9AGM6wgP hEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQgKO19b+Rt8sP DAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj113yKMm8vmNpt RPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpUeuXHRs07JqCC vFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1Ud DwEB/wQEAwIBBjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswHwYDVR0jBBgwFoAUTgvv GqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nm c2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5j cmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1 BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMA0GCSqGSIb3DQEBBQUAA4ICAQA6qScNyNO0FpHvaZTQacVMXH33O51KyEKSRw3IvdQxRu31 YR0ZDGdSfgSoOVDVMSBSdmfQfdDInHPzV3LO5DwUXZ+lxjv7z3PO2OkfnFkvTXPfn6dxJ5rJveDs TsCPcJ/Kp6/+qN5g+J6D/SaYcFD018B6L42r0Z4VEBy36P4tjRtF14Ex10tl5tJFVKM16qWKQHbp jIgf73s49UB0CQ5lHT2DHKfq3oPfdNc5Mk93w1v4ryVb+qVrZIej8NsrWU+5r4O2IV91edDb/OtH FddZqHFFXKgS79IHE/hwQ2LW7r3sTX7cDUCg+dfdwO8zeLxuwk2JF8crUoyrl66RGrRIhT8VoG/O J1Y9uUlOav69V4cG8upi4ZG2l7JZFbcBFk91Wp+Payo5SuF61CmGFrZ386umkmpObtFacXda2O/b VoQ9xHQrzoTc/0KZTWvlZCLK3Ke/vGYT9ZdW9lOjGsSFbXrlTA919L84iMK+48WGnvRWY28ZaVHp ql43AtEGhXze6iNCbEDACy+4hkQYOytAqDgcxAnQ937mYpeZFPyz/XK9QSt9VNFMuudWxZwDDDJK oQAoSG59Hou9lZ26UrK60nRdAQBmEPL8h2nuWgoPh++XVQld9yuhbsWa39Pck8/lcfz5HUVGJF5m c/zk38iV7FDlF68puiryNq2KXHEpOTCCB8kwggWxoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwfTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYzNlowfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIC IjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7p d/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkF Uln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8 XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NT FoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxW qq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNdu QuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJ vhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDU i39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOv K8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIwggJOMAwGA1UdEwQFMAMBAf8w CwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD0EGu8jBkBgNVHR8EXTBbMCyg KqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1UdIASCAVQwggFQMIIBTAYLKwYB BAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5 LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2ludGVybWVkaWF0ZS5w ZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0YXJ0Q29tKSBMdGQuMAMC AQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlv bnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxh YmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEGCWCGSAGG+EIBAQQE AwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs2hBOOBxe36YlBUuRMsHoO/E9 3UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmRHVGrgnt+1c5a5OIDV3Bplwj5 XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdEw5Aa3jipPKxDTWRFzt0oqVzy c3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3Tmh2a82VQ9aDQdZ8vr/DqgkOY +GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxyweSxFEyDRSJ80KXZ+FwYnVGnjy lRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98iWX1jkNUDqvdpYA5lGDANMmW cCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIousNE4mIgShhyx1SrflfRPXuAxk wDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkEGkcJ5g8BViT7H78OealYLrnE CQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2IgyudWS2Xq/mzBJJMkoTTrBf+a Iq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeAAAxggK8MIICuAIBATCBkzCBjDELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgJS9zAJBgUrDgMCGgUAoIH+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE1MDcwMTIyMzE1OVowIwYJKoZIhvcNAQkEMRYEFNWh/Okn9h2dulBL shQDtizEBGnuMIGeBgkqhkiG9w0BCQ8xgZAwgY0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA8GCSqGSIb2fQdCCgICAIAw DQYLKoMIjJpLPQEBAQQwDQYLKoMIjJpLPQEBAQMwDQYLKoMIjJpLPQEBAQIwCgYIKoMajJpEAQQw DQYJKoZIhvcNAQEBBQAEggEANfOlGxDMvW7+Nwh/gvYlH7yHjmek6dIMu/0cRiN3Gal9R4u8CwCs HcqLPb6XJfSw99SVjJXR01COrHgjJwYvhd1qSJQQ9iDIeIBhRKlsJl7WbxkFxl7Yb3d2BEEHjAgB hCKZPZCoREk1r8ApO7r0QhnfZHtH/i8yM/ZtIOyLdmwgJm2JMdTFwF6409b8thdrtRzOSJ6nnqN2 QekT+rraZFi8gnoqLC+yE+0Mc8HuWoZpfTeQBlBdr/uNf1tiYdJnnY8pk6PokgyMIIXKSlACPs/1 bJNgK20PRbiKU4dVdeM/rATC5Cl5QWzyc4uw8/7ez3+WSb2yDUO72VnWSa6z1AAAAAAAAA== ------=_Part_144_347748262.1435789919138--

1 0

[ANN] oVirt 3.5.4 First Release Candidate is now available for testing
by Sandro Bonazzola 01 Jul '15

01 Jul '15

The oVirt team is pleased to announce that the 3.5.4 First Release Candidate is now available for testing as of July 1st 2015. The release candidate is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS Linux 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO will be 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.4_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

1 0

Shared gluster storage domain for templates
by Christopher Pereira 01 Jul '15

01 Jul '15

Hi, I'm trying to setup a gluster data storage domain exclusively for templates (read only) and share it among different geo distributed ovirt data centers. I believe this is a common requirement. Do you know if there is a clean/efficient way to do this? My experiment: I geo-replicated the templates storage domain in order to keep a local copy on each data center for faster new VM instantiation or thin template provisioning. The problem I faced is it's not possible to import a replicated storage domain when the original Storage Domain UUID is already registered in the same Engine installation. A workarround was to detach the original SD (from Data Center 1) and attach the replicated SD (on Data Center 2)...or use another Engine installation. This works, but still requires to detach and reattach the storage domain. Is there anyway to copy a storage domain or change its UUID? I guess I can change the Storage Domain UUID (dirname and dom_md/metadata), but I'm afraid of the multiple references inside the binary file 'dom_md/ids'. BTW, using a gluster replica-n volume seems to be the cleanest solution because this way Engine would only be showing one single templates storage domain (ideal). The only reason I didn't go this way is because it is not designed between geo distributed data networks.

1 0