- Users - oVirt List Archives

oVirt repositories 101; or everything you wanted to know about oVirt repositories and didn't ask
by Eyal Edri 09 Apr '17

09 Apr '17

Hi oVirt developers and users, Some of you might be familiar with the oVirt repositories and all their flavors, while some of you are just familiar with the official releases. The fact is, we have plenty of them and each has its own role and a right usage. Moreover, we did a significant overhaul on all the repositories in the past months, So hopefully now it will be easier to explain which repo to use when. I'll start with reviewing each oVirt repository and give a bit of background and the logic behind it, how to consume it and the relevant usage for it. For simplicity, I'll review the repositories on the 4.1 release, but it valid for all other oVirt releases ( except 'master' which doesn't have an official or pre-release repositories ). I will also upload this information to the oVirt.org site, but since this is important, I didn't want to wait with the sending this email. *oVirt repositories* *Official repositories* *Desc:* here you can find the official signed oVirt RPMs, immediately after an official release has been done. *Path:* http://resources.ovirt.org/pub/ovirt-4.1/rpm/$distro *Update frequency:* on every oVirt release, usually happens on a monthly cadence. *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm *Who should use it? * oVirt users, developers or anyone who wants a final and official release *Pre-release repositories* *Desc:* here you can find the pre-release bits of oVirt RC builds, just before they are released. *Path:* http://resources.ovirt.org/pub/ovirt-4.1-pre/rpm/$distro *Update frequency:* usually on a weekly or bi-weekly basis *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt- release41-pre.rpm *Who should use it? * oVirt users, developers or anyone who wants to try out oVirt new version before its out, Keeping in mind this isn't a fully verified release and might still have critical bugs which are not fixed yet. Packages in this repo are verified by automation and checked by humans for basic sanity before publishing. *Nightly snapshot (verified) repositories* *Desc:* here you can find the nightly snapshot of RPMs, which passed basic sanity by our 'oVirt System Tests' framework in the oVirt CI system. *Path:* http://resources.ovirt.org/pub/ovirt-4.1-snapshot/rpm/$distro *Update frequency:* Every night *Release rpm: *http://resources.ovirt.org/pub/yum-repo/ovirt- release41-snapshot.rpm *Who should use it? * oVirt users, developers or anyone who wants to try out oVirt latest bits right of the build oven! We trust our system tests, which already run more than 40 various tests such as 'add host', 'create VM', 'live migration' and more! *** Important note: the snapshot repositories are verified only in master currently, we might do the same for 4.1 soon, as we see no issues with master so far ** * *The above repos should suffice to most usres and developers, but if you feel its not enough and you still need a faster verified repo, look below! * *Advanced oVirt repositories* *Builds artifacts repo* *Desc:* This is a new feature from oVirt 'standard CI' project, where each 'build-artifacts' job is actually a yum repo as well. *Path:* http://jenkins.ovirt.org/job/ovirt-engine_4.1_ build-artifacts-on-demand-el7-x86_64/lastSuccessfulBuild/ artifact/exported-artifacts ( example ) *Update frequency:* after each commit or 'ci please build' comment *Release rpm: *N/A *Who should use it? * oVirt developers who need latest RPMs from another oVirt project and cannot or need not wait for that project`s packages to pass OST". oVirt developers running manual OST job and need to test an open Gerrit patch, using the 'ci please build' command. *Tested repositories* *Desc:* The tested repositories hold all the oVIrt packages which passed CI ( similar to snapshot repos ) and retain also version history for X versions back. *Path:* http://resources.ovirt.org/repos/ovirt/tested/4.1/rpm/$distro *Update frequency:* after each 'build artifacts' job is triggered by any oVirt project and if the packages passed sanity checks *Release rpm: *N/A *Who should use it? * If you want to have latest and greatest oVirt packages and can't wait for the nightly repo. If you are testing upgrades or need more than one version of a pacakge in your repo. *Experimental repositories * *Desc:* Internal CI repos which are a part of the 'experimental' flow which runs OST on each built package. *Path:* http://resources.ovirt.org/repos/ovirt/experimental/ 4.1/latest.tested/rpm/el7/$distro *Update frequency:* after each 'build artifacts' job is triggered by any oVirt project and if the packages passed sanity checks *Release rpm: *N/A *Who should use it? * *No one other than internal CI jobs.* These repos are constantly refreshed and RPMs are being removed from them, so they are very prone to errors, please don't use them. I hope this makes a bit of order in all the repos and how to use them. If you still have questions, please don't hesitate to contact the infra team at infra(a)ovirt.org or just reply to this thread. -- Eyal edri ASSOCIATE MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

moving disk from one storage domain to another
by Bill James 09 Apr '17

09 Apr '17

We are trying to convert our qa environment from local nfs to gluster. When I move a disk with a VM that is running on same server as the storage it fails. When I move a disk with VM running on a different system it works. VM running on same system as disk: 2017-04-06 13:31:00,588 ERROR (jsonrpc/6) [virt.vm] (vmId='e598485a-dc74-43f7-8447-e00ac44dae21') Unable to start replication for vda to {u'domainID': u'6affd8c3-2c51-4cd1-8300-bfbbb14edbe9', 'volumeInfo': {'domainID': u'6affd8c3-2c 51-4cd1-8300-bfbbb14edbe9', 'volType': 'path', 'leaseOffset': 0, 'path': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5', 'volumeID': u'30fd46c9-c738-4b13-aeca-3dc9ffc677f5', 'leasePath': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5.lease', 'imageID': u'7ae9b3f7-3507-4469-a080-d0944d0ab753'}, 'diskType': 'file', 'format': 'cow', 'cache': 'none', u'volumeID': u'30fd46c9-c738-4b13-aeca-3dc9ffc677f5', u'imageID': u'7ae9b3f7-3507-4469-a080-d0944d0ab753', u'poolID': u'8b6303b3-79c6-4633-ae21-71b15ed00675', u'device': 'disk', 'path': u'/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5', 'propagateErrors': u'off', 'volumeChain': [{'domainID': u'6affd8c3-2c51-4cd1-8300-bfbbb14edbe9', 'volType': 'path', 'leaseOffset': 0, 'path': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/6756eb05-6803-42a7-a3a2-10233bf2ca8d', 'volumeID': u'6756eb05-6803-42a7-a3a2-10233bf2ca8d', 'leasePath': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/6756eb05-6803-42a7-a3a2-10233bf2ca8d.lease', 'imageID': u'7ae9b3f7-3507-4469-a080-d0944d0ab753'}, {'domainID': u'6affd8c3-2c51-4cd1-8300-bfbbb14edbe9', 'volType': 'path', 'leaseOffset': 0, 'path': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5', 'volumeID': u'30fd46c9-c738-4b13-aeca-3dc9ffc677f5', 'leasePath': u'/rhev/data-center/mnt/glusterSD/ovirt1-ks.test.j2noc.com:_gv2/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5.lease', 'imageID': u'7ae9b3f7-3507-4469-a080-d0944d0ab753'}]} (vm:3594) Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py", line 3588, in diskReplicateStart self._startDriveReplication(drive) File "/usr/share/vdsm/virt/vm.py", line 3713, in _startDriveReplication self._dom.blockCopy(drive.name, destxml, flags=flags) File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 69, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 941, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 684, in blockCopy if ret == -1: raise libvirtError ('virDomainBlockCopy() failed', dom=self) libvirtError: internal error: unable to execute QEMU command 'drive-mirror': Could not open '/rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5': Permission denied [root@ovirt1 test vdsm]# ls -l /rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5 -rw-rw---- 2 vdsm kvm 197120 Apr 6 13:29 /rhev/data-center/8b6303b3-79c6-4633-ae21-71b15ed00675/6affd8c3-2c51-4cd1-8300-bfbbb14edbe9/images/7ae9b3f7-3507-4469-a080-d0944d0ab753/30fd46c9-c738-4b13-aeca-3dc9ffc677f5 Then if I try and rerun it it says, even though move failed: 2017-04-06 13:49:27,197 INFO (jsonrpc/1) [dispatcher] Run and protect: getAllTasksStatuses, Return response: {'allT asksStatus': {'078d962c-e682-40f9-a177-2a8b479a7d8b': {'code': 212, 'message': 'Volume already exists', 'taskState': 'finished', 'taskResult': 'cleanSuccess', 'taskID': '078d962c-e682-40f9-a177-2a8b479a7d8b'}}} (logUtils:52) So now I have to clean up the disks that it failed to move so I can migrate the VM and then move the disk again. Or so it seems. Failed move disks do exist in new location, even though it "failed". vdsm.log attached. ovirt-engine-tools-4.1.0.4-1.el7.centos.noarch vdsm-4.19.4-1.el7.centos.x86_64

4 4

Re: [ovirt-users] Hosts Network Management
by Charles Tassell 09 Apr '17

09 Apr '17

Hey Kai, Go into the Hosts tab, click on the host you want to add the bonded interface to then on the Network Interfaces tab in the bottom pane. Click on Setup Host Networks and drag an unused network adaptor over the one that you want to bond it with. A box will come up and let you configure bonding parameters like which mode to use. On 2017-04-09 04:17 AM, users-request(a)ovirt.org wrote: > Date: Sat, 8 Apr 2017 23:46:27 +0200 > From: Kai Wagner <kwagner(a)suse.com> > To: Ondrej Svoboda <osvoboda(a)redhat.com>, users(a)ovirt.org > Subject: Re: [ovirt-users] Hosts Network Management > Message-ID: <b38cc8d1-d7f3-0172-fc97-6cbf31e6a8f3(a)suse.com> > Content-Type: text/plain; charset="utf-8" > > I need to create a bonded device with lacp. How can I do this through > the UI? > > Sorry, maybe it's quite easy, but I don't know how to configure it. > > > On 04/07/2017 07:10 PM, Ondrej Svoboda wrote: >> Hello Kai, >> >> I'd like to know ? what is your initial problem that you cannot solve >> through the GUI? >> >> VDSM does use a custom comment in ifcfg files, but only to recognize >> them ? if they are unknown, it acquires the relevant network devices >> from NetworkManager. But VDSM is in charge of networking >> configuration, exclusively. >> >> If you need to add extra configuration parameters in ifcfg files, or >> modify them, you could write or use a VDSM hook to alter the ifcfg >> files as they are written. >> >> But perhaps it is better for us to know what problems you are having >> and whether they can be solved by available methods. >> >> Thank you, >> Ondra >> >> On Thu, Apr 6, 2017 at 12:14 PM, Kai Wagner <kwagner(a)suse.com >> <mailto:kwagner@suse.com>> wrote: >> >> Hi all, >> >> is it possible to set a comment at the beginning of a file for network >> files -> something like don't touch this anymore please? >> >> I want to configure my network stuff on the cli and not via the UI >> because I failed now a few times. >> >> Thx >> >> Kai >> >> >> -- >> SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham >> Norton, HRB 21284 (AG N?rnberg) >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >>

1 0

Hosts Network Management
by Kai Wagner 08 Apr '17

08 Apr '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WIvTsgqFc0Vw6IGKvn67rP3OvSNrUQp2q Content-Type: multipart/mixed; boundary="crsmAHLwUdrTsU3RpOWU8fVd1rFuR7MjK"; protected-headers="v1" From: Kai Wagner <kwagner(a)suse.com> To: users(a)ovirt.org Message-ID: <e30a5560-e5e2-bb38-89d7-a55bc5630d0b(a)suse.com> Subject: Hosts Network Management --crsmAHLwUdrTsU3RpOWU8fVd1rFuR7MjK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, is it possible to set a comment at the beginning of a file for network files -> something like don't touch this anymore please? I want to configure my network stuff on the cli and not via the UI because I failed now a few times. Thx Kai --=20 SUSE Linux GmbH, GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton= , HRB 21284 (AG N=C3=BCrnberg) --crsmAHLwUdrTsU3RpOWU8fVd1rFuR7MjK-- --WIvTsgqFc0Vw6IGKvn67rP3OvSNrUQp2q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJY5hULAAoJEB6MkVYW48RuVrMH/3oAENmN3vKuQRdOHH/6wHKp RWUFeN4hlIdm15iO5PXaLyCHlc7EjnvA2j7z31Pt6jVsMCaZm9TRffMXSxKQ1kfF 4nUaFNJ09p2h4m2L4s8EgRoTd3jziKVGrljEicw9tKD2HJSgfI99+6IzBNLR/jmB GbKQbwmR9oXW3kT1vAQ6eJ34XsmYO4MDWSTb6vsyRCJs9T/MIwEXP/ShioRwQaNR aoCKZm9jrUuUIAvdteJ7nOKhDr1udQzjRzKudMaaP5pRRLtPvw3rMTLs2qWHwNnP lAKWDiZrq2qn9K26OwAr83lLj+Pc4bOZVImYbC9HU0OY20Y6xs2ZH+WShxT3z6s= =atZW -----END PGP SIGNATURE----- --WIvTsgqFc0Vw6IGKvn67rP3OvSNrUQp2q--

2 2

JavaAPI exporting VM
by David David 07 Apr '17

07 Apr '17

Hello. Can't reexport a VM if this VM is already present in the export domain With Java api: *VM vm = api.getVMs().get("vm01");StorageDomain exportDomain = api.getStorageDomains().get("export"); * *Action act = vm.exportVm(new Action() { { setExclusive(True); setDiscardSnapshots(True); setStorageDomain(exportDomain); }});* And following error is returned: Exception in thread "main" code : 409 reason: Conflict detail: Cannot export VM. VM with the same identifier already exists. at org.ovirt.engine.sdk.web.HttpProxy.execute(HttpProxy.java:120) at org.ovirt.engine.sdk.web.HttpProxyBroker.add(HttpProxyBroker.java:209) at org.ovirt.engine.sdk.web.HttpProxyBroker.action(HttpProxyBroker.java:153) at org.ovirt.engine.sdk.decorators.VM.exportVm(VM.java:784)

2 1

for some reason ovirtnode creates unecessary vg and lvs
by martin chamambo 07 Apr '17

07 Apr '17

I managed to configure the mail iscsi domain for my ovirt 4.1 engine and node , it connects to the storage initially and initialises the data center ,but after rebooting the node and engine , it creates unecessary vg and lvs like below 280246d3-ac7b-44ff-8c03-dc2bcb9edb70 d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 128.00m 2d57ab88-16e4-4007-9047-55fc4a35b534 d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 128.00m ids d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 128.00m inbox d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 128.00m leases d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 2.00g master d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 1.00g metadata d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 512.00m outbox d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 128.00m xleases d5104206-5863-4f9d-9ea7-2b140c97d65f -wi-a----- 1.00g whats the cause of this NB:mY ISCSI storage is on a centos 7 box

4 7

Host in connecting state and all data domains are red in ovirt 4.1
by gflwqs gflwqs 07 Apr '17

07 Apr '17

Hi list this morning i saw one of my 2 hosts were in connecting state. When i checked the /var/log/messages on the host i saw this happened: Apr 7 06:05:38 ovirt12 journal: ovirt-ha-broker ovirt_hosted_engine_ha.broker.submonitor_base.SubmonitorBase ERROR Error executing submonitor mgmt-bridge, args {'use_ssl': 'true', 'bridge_name': 'ovirtmgmt', 'address': '0'}#012Traceback (most recent call last):#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/submonitor_base.py", line 115, in _worker#012 self.action(self._options)#012 File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/submonitors/mgmt_bridge.py", line 44, in action#012 caps = cli.getVdsCapabilities()#012 File "/usr/lib/python2.7/site-packages/vdsm/jsonrpcvdscli.py", line 167, in _callMethod#012 raise JsonRpcNoResponseError(method)#012JsonRpcNoResponseError: [-32605] No response for JSON-RPC Host.getCapabilities request. Apr 7 06:05:40 ovirt12 journal: vdsm vds.dispatcher ERROR SSL error receiving from <yajsonrpc.betterAsyncore.Dispatcher connected ('::1', 53454, 0, 0) at 0x7fcc685ce560>: unexpected eof Is this the cause of the problem? What has happened? How do i get out of this problem? Regards Christian

1 0

Upgrading libguestfs to import debian VM
by Simon Vincent 06 Apr '17

06 Apr '17

I find that running oVirt 4.1.1 I can not import any debian based VMs as virt-v2v/libguestfs is too old. This bug report https://bugzilla.redhat.com/show_bug.cgi?id=1362497 indicates that newer versions of libguestfs support importing debian and Ubuntu VMs. Are there any plans to include a newer version of libguestfs in oVirt soon? If I built a newer version of libguestfs on my ovirt-node would it break everything? Regards Simon

2 1

mount glusterfs from 127.0.0.1
by /dev/null 06 Apr '17

06 Apr '17

Hello all together, having a three node oVirt cluster for virtualization and gluster, each node providing bricks for a replica 3 volume, I would like to mount the volume from 127.0.0.1 to distribute i/o and to have a better failover situation. This leads to a volume having the same address in oVirt althoght it is addressed on different hosts. Is this common, supported, relyable and recommended? Thanks in advance! /dev/null -- Diese Nachricht wurde auf Viren und andere gefährliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. For all your IT requirements visit: http://www.transtec.co.uk

2 3

New SAN Storage Domain: Cannot deactivate Logical Volume
by Николаев Алексей 06 Apr '17

06 Apr '17

3 8

After 3.5->3.6 upgrade, OVF update error every hour
by Chris Adams 06 Apr '17

06 Apr '17

After upgrading an oVirt cluster from 3.5 to 3.6, I am getting the following error every hour: Failed to update OVF disks ce8647c6-f936-4633-8a7b-e7dcb45d8ebb, OVF data isn't updated on those OVF stores (Data Center Middle-Earth, Storage Domain equallogic). Looking in the vdsm log on the SPM node, it looks like the problem is that an attempt was made to lvextend an LV to 2m, but the LV is already 128m, so the extend failed (not needed). I've attached the log entries for that task. Any suggestions, ideas how to fix, etc.? -- Chris Adams <cma(a)cmadams.net>

2 3

oVirt Roadmap
by John Rushe 06 Apr '17

06 Apr '17

Hi, Does anyone know if there is a roadmap for oVirt 4.x published online any where? I can't seem to be able to find one for 4.x only for the 3.x releases. Regards John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Problem Ovirt 4.1
by eric stam 06 Apr '17

06 Apr '17

On my Ovirt 4.1 environment, is is not possible anymore to import images from "external providers". In previous versions, it was possible. Is this a bug, or is there something I have to do to get this working again. I starten with a previous version of Overt 4 and in that version it was working fine. Regards, Eric

2 1

mapping shell fencing opions with gui ones for ipmilan agent
by Gianluca Cecchi 06 Apr '17

06 Apr '17

Hello, executing from host itself the following command it works [root@ov300 ~]# fence_ipmilan -P -a 10.10.193.103 -l fenceuser -A password -L operator -S /usr/local/bin/pwd_ov300.sh -o status Status: ON [root@ov300 ~]# But I'm unable to obtain successful test result in web admin fencing agent config window I set ip, user, password and ipmilan as agent, and then tried in options auth=password,privlvl=operator,lanplus=1 and also auth=password,privlvl=operator,lanplus=on this the only host in cluster so it is the one used for testing by oVirt. Tipically on these same server in RHEL 6.x ClusterSuite I use this in cluster.conf and it works too: <fencedevices> <fencedevice agent="fence_ipmilan" auth="password" delay="20" ipaddr="10.10.193.107" lanplus="1" login="fenceuser" name="dracnode01" passwd_script="/usr/local/bin/pwd_dracnode01.sh" privlvl="operator"/> Any hint on correct mapping of parameters for oVirt? Thanks, Gianluca

1 1

Separating NFS network flow
by Alexis HAUSER 06 Apr '17

06 Apr '17

------=_Part_4864013_71059764.1491480942414 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, Is there a way to separate the network flow from NFS ? I know it is possible to do it with VM, display, ovirtmgmt, iSCSI, but what about NFS ? Does it use ovirtmgmt ? Thanks in advance ------=_Part_4864013_71059764.1491480942414 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Hi,<br data-mce-bogus="1"></div><div><br></div><div>Is there a way to separate the network flow from NFS ? I know it is possible to do it with VM, display, ovirtmgmt, iSCSI, but what about NFS ? Does it use ovirtmgmt ?<br></div><div><br></div><div>Thanks in advance<br></div></div></body></html> ------=_Part_4864013_71059764.1491480942414--

1 0

MAC Address is already in use; several of times before Nic/MAC is acceppetd
by Matt . 06 Apr '17

06 Apr '17

Hi Guys, Since the upgrade to 4.1 I have the issue that every nic I add I get a several of times: MAC Address xx:xx:xx:xx:xx is already in use. I have added an extra pool and this issue still exists. Anyone a clue why this happens ? Thanks, Matt

3 2

[ANN] oVirt 4.1.1 Async release
by Sandro Bonazzola 06 Apr '17

06 Apr '17

The oVirt Project is pleased to announce the availability of the oVirt 4.1.1 Async Release, as of April 6th, 2017 Following oVirt 4.1.1 GA the oVirt team identified some bugs worth to be addressed out of the usual release cycle. For this reason an async release including these fixes has been prepared and is now available for: * Fedora 24 (tech preview) * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later * Fedora 24 (tech preview) See the new section "What's New in 4.1.1 Async release" within oVirt 4.1.1 release notes [3] for a list of new features and bugs fixed. Notes: - oVirt Engine Appliance, oVirt node and oVirt Live will be available soon [4] Additional Resources: * Read more about the oVirt 4.1.1 release highlights: http://www.ovirt.org/release/4.1.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.1.1/ [4] http://resources.ovirt.org/pub/ovirt-4.1/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

VM in oVirt 4 sometimes does not have proper CPU guest count
by Christophe TREFOIS 06 Apr '17

06 Apr '17

--_000_8C4DA8EBA840444999AC78F54E14506Cunilu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIHVwZ3JhZGVkIHRvZGF5IGVuZ2luZSB0byA0LjAuNiBhbmQgYSBob3N0 IHRvIENlbnRPUyA3LjMgYW5kIGFsbCBwYWNrYWdlcyB1cGRhdGVkLg0KDQpNb3N0IFZNcyBzdGFy dCB1cCB3aXRoIGNvcnJlY3QgbnVtYmVyIG9mIGd1ZXN0IENQVXMgZXhjZXB0IDIgb3IgMyB0aGF0 IG9ubHkgc3Bhd24gd2l0aCAxIGd1ZXN0IENQVSBjb3VudC4NCldlIHNldCBmb3IgaW5zdGFuY2Ug YSBDUFUgcHJvZmlsZSBvZiAxOjQ6MSBidXQgb25seSAxIHZDUFUgaXMgYXZhaWxhYmxlIHRvIFZN Lg0KDQpUaGUgVk0gaXRzZWxmIGlzIHJ1bm5pbmcgVHJ1c3R5LCBidXQgb3RoZXIgVHJ1c3R5IFZN IHNlZW0gZmluZS4NCg0KRG8geW91IGhhdmUgYW55IGlkZWEgd2hhdCBjb3VsZCBiZSB0aGUgaXNz dWUgYW5kIGhvdyB0byBwZXJoYXBzIGZpeCB0aGlzPw0KDQpLaW5kIHJlZ2FyZHMsDQpDaHJpc3Rv cGhlDQoNCi0tDQoNCkRyIENocmlzdG9waGUgVHJlZm9pcywgRGlwbC4tSW5nLg0KVGVjaG5pY2Fs IFNwZWNpYWxpc3QgLyBQb3N0LURvYw0KDQpVTklWRVJTSVTDiSBEVSBMVVhFTUJPVVJHDQoNCkxV WEVNQk9VUkcgQ0VOVFJFIEZPUiBTWVNURU1TIEJJT01FRElDSU5FDQpDYW1wdXMgQmVsdmFsIHwg SG91c2Ugb2YgQmlvbWVkaWNpbmUNCjYsIGF2ZW51ZSBkdSBTd2luZw0KTC00MzY3IEJlbHZhdXgN ClQ6ICszNTIgNDYgNjYgNDQgNjEyNA0KRjogKzM1MiA0NiA2NiA0NCA2OTQ5DQpodHRwOi8vd3d3 LnVuaS5sdS9sY3NiDQoNCltGYWNlYm9va108aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL3RyZWZl eD4gIFtUd2l0dGVyXSA8aHR0cHM6Ly90d2l0dGVyLmNvbS9UcmVmZXg+ICAgW0dvb2dsZSBQbHVz XSA8aHR0cHM6Ly9wbHVzLmdvb2dsZS5jb20vK0NocmlzdG9waGVUcmVmb2lzLz4gICBbTGlua2Vk aW5dIDxodHRwczovL3d3dy5saW5rZWRpbi5jb20vaW4vdHJlZm9pc2NocmlzdG9waGU+ICAgW3Nr eXBlXSA8aHR0cDovL3NreXBlOlRyZWZleD9jYWxsPg0KDQotLS0tDQpUaGlzIG1lc3NhZ2UgaXMg Y29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uLg0KSXQg aXMgaW50ZW5kZWQgZm9yIHRoZSBuYW1lZCByZWNpcGllbnQgb25seS4NCklmIHlvdSByZWNlaXZl IGl0IGluIGVycm9yIHBsZWFzZSBub3RpZnkgbWUgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUg b3JpZ2luYWwgbWVzc2FnZSBhbmQgYW55IGNvcGllcy4NCi0tLS0NCg0KDQoNCg== --_000_8C4DA8EBA840444999AC78F54E14506Cunilu_ Content-Type: text/html; charset="utf-8" Content-ID: <12A4DD0F8469944C8B7B680FAEB41A7C(a)uni.lux> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBhbGwsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSB1cGdyYWRlZCB0b2Rh eSBlbmdpbmUgdG8gNC4wLjYgYW5kIGEgaG9zdCB0byBDZW50T1MgNy4zIGFuZCBhbGwgcGFja2Fn ZXMgdXBkYXRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPk1vc3QgVk1zIHN0YXJ0IHVwIHdpdGggY29ycmVjdCBudW1iZXIgb2YgZ3Vl c3QgQ1BVcyBleGNlcHQgMiBvciAzIHRoYXQgb25seSBzcGF3biB3aXRoIDEgZ3Vlc3QgQ1BVIGNv dW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBzZXQgZm9yIGluc3RhbmNlIGEgQ1BVIHByb2Zp bGUgb2YgMTo0OjEgYnV0IG9ubHkgMSB2Q1BVIGlzIGF2YWlsYWJsZSB0byBWTS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBWTSBp dHNlbGYgaXMgcnVubmluZyBUcnVzdHksIGJ1dCBvdGhlciBUcnVzdHkgVk0gc2VlbSBmaW5lLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ RG8geW91IGhhdmUgYW55IGlkZWEgd2hhdCBjb3VsZCBiZSB0aGUgaXNzdWUgYW5kIGhvdyB0byBw ZXJoYXBzIGZpeCB0aGlzPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+S2luZCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaHJp c3RvcGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTBwdDsgbGluZS1oZWlnaHQ6IDE2cHg7IGNvbG9yOiBy Z2IoMzMsIDMzLCAzMyk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDYxLCA1 OSwgNTkpOyBkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj4tLSZuYnNwOzwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQ7 IGxpbmUtaGVpZ2h0OiAxNnB4OyBjb2xvcjogcmdiKDMzLCAzMywgMzMpOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRp c3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPkRyIENocmlzdG9waGUgVHJlZm9pcywgRGlwbC4tSW5n Ljwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGluZTsgZm9udC1z aXplOiA3LjVwdDsiIGNsYXNzPSIiPlRlY2huaWNhbCBTcGVjaWFsaXN0IC8gUG9zdC1Eb2M8L3Nw YW4+PC9wPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiA3LjVwdDsgbGluZS1oZWlnaHQ6IDE2cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDogYm9sZDsgY29sb3I6IHJnYig2MSwgNTksIDU5KTsgZGlzcGxheTogaW5saW5l OyIgY2xhc3M9IiI+VU5JVkVSU0lUw4kgRFUgTFVYRU1CT1VSRzwvc3Bhbj48YnIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9sZDsgY29sb3I6IHJnYig2MSwgNTks IDU5KTsgZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+TFVYRU1CT1VSRyBDRU5UUkUgRk9SIFNZ U1RFTVMgQklPTUVESUNJTkU8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPkNhbXB1cyBCZWx2 YWwgfCBIb3VzZSBvZiBCaW9tZWRpY2luZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+NiwgYXZlbnVlIGR1IFN3aW5nJm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCkwtNDM2NyBC ZWx2YXV4PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJy IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6 IGlubGluZTsiIGNsYXNzPSIiPlQ6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2MSwgNTksIDU5KTsg ZGlzcGxheTogaW5saW5lOyIgY2xhc3M9IiI+JiM0MzszNTIgNDYgNjYgNDQgNjEyNDwvc3Bhbj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNjEsIDU5LCA1OSk7IGRpc3BsYXk6IGlubGlu ZTsiIGNsYXNzPSIiPkY6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig2MSwgNTksIDU5KTsgZGlzcGxh eTogaW5saW5lOyIgY2xhc3M9IiI+JiM0MzszNTIgNDYgNjYgNDQgNjk0OTwvc3Bhbj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJkaXNwbGF5OiBp bmxpbmU7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3 dy51bmkubHUvbGNzYiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMTA5LCAxODkpOyBkaXNwbGF5OiBp bmxpbmU7IiBjbGFzcz0iIj5odHRwOi8vd3d3LnVuaS5sdS9sY3NiPC9hPjwvcD4NCjxwIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDE2cHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmZhY2Vib29rLmNv bS90cmVmZXgiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0iIj48aW1nIHdpZHRoPSIy NCIgaGVpZ2h0PSIyNCIgZGF0YS1maWxlbmFtZT0iZmFjZWJvb2sucG5nIiBzcmM9Imh0dHBzOi8v czMuYW1hem9uYXdzLmNvbS9odG1sc2lnLWFzc2V0cy9yb3VuZGVkL2ZhY2Vib29rLnBuZyIgYWx0 PSJGYWNlYm9vayIgY2xhc3M9IiI+PC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9UcmVmZXgiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7IiBjbGFzcz0iIj48aW1nIHdpZHRoPSIyNCIgaGVpZ2h0PSIyNCIgZGF0YS1m aWxlbmFtZT0idHdpdHRlci5wbmciIHNyYz0iaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL2h0bWxz aWctYXNzZXRzL3JvdW5kZWQvdHdpdHRlci5wbmciIGFsdD0iVHdpdHRlciIgY2xhc3M9IiI+PC9h PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6 Ly9wbHVzLmdvb2dsZS5jb20vJiM0MztDaHJpc3RvcGhlVHJlZm9pcy8iIHN0eWxlPSJkaXNwbGF5 OiBpbmxpbmU7IiBjbGFzcz0iIj48aW1nIHdpZHRoPSIyNCIgaGVpZ2h0PSIyNCIgZGF0YS1maWxl bmFtZT0iZ29vZ2xlcGx1cy5wbmciIHNyYz0iaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL2h0bWxz aWctYXNzZXRzL3JvdW5kZWQvZ29vZ2xlcGx1cy5wbmciIGFsdD0iR29vZ2xlIFBsdXMiIGNsYXNz PSIiPjwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi90cmVmb2lzY2hyaXN0b3BoZSIgc3R5bGU9ImRp c3BsYXk6IGlubGluZTsiIGNsYXNzPSIiPjxpbWcgd2lkdGg9IjI0IiBoZWlnaHQ9IjI0IiBkYXRh LWZpbGVuYW1lPSJsaW5rZWRpbi5wbmciIHNyYz0iaHR0cHM6Ly9zMy5hbWF6b25hd3MuY29tL2h0 bWxzaWctYXNzZXRzL3JvdW5kZWQvbGlua2VkaW4ucG5nIiBhbHQ9IkxpbmtlZGluIiBjbGFzcz0i Ij48L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwOi8vc2t5cGU6VHJlZmV4P2NhbGwiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7IiBjbGFzcz0i Ij48aW1nIHdpZHRoPSIyNCIgaGVpZ2h0PSIyNCIgZGF0YS1maWxlbmFtZT0ic2t5cGUucG5nIiBz cmM9Imh0dHBzOi8vczMuYW1hem9uYXdzLmNvbS9odG1sc2lnLWFzc2V0cy9yb3VuZGVkL3NreXBl LnBuZyIgYWx0PSJza3lwZSIgY2xhc3M9IiI+PC9hPjwvcD4NCjxwIGNsYXNzPSJiYW5uZXItY29u dGFpbmVyIiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7IGxpbmUtaGVpZ2h0OiAxNnB4OyI+DQo8L3A+DQo8cCBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDYxLCA1OSwgNTkpOyBmb250LXNpemU6IDlw eDsgbGluZS1oZWlnaHQ6IDE2cHg7IiBjbGFzcz0iIj4NCi0tLS08YnIgY2xhc3M9IiI+DQpUaGlz IG1lc3NhZ2UgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9y bWF0aW9uLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnIgY2xhc3M9IiI+DQpJdCBpcyBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lwaWVudCBvbmx5 LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xh c3M9IiI+DQpJZiB5b3UgcmVjZWl2ZSBpdCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IG1lIGFuZCBw ZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgYW5kIGFueSBjb3BpZXMuPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0i Ij4NCi0tLS08YnIgY2xhc3M9IiI+DQo8L3A+DQombmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8C4DA8EBA840444999AC78F54E14506Cunilu_--

1 1

NFS storage domain path is illegal
by Bill James 05 Apr '17

05 Apr '17

ovirt-engine-tools-4.1.0.4-1.el7.centos.noarch vdsm-4.19.4-1.el7.centos.x86_64 I'm trying to add a NFS storage domain but the gui keeps telling me the export path is illegal. Even though I can mount the volume fine at the command line. I have not found any log that contains the error so I can't attach log entry. It says "Use IP:/path or FQDN:/path" but only IP works, no name I've tried is allowed. Also, how do I remove a storage domain? I could put it into maintenance and then detach it, but I have not found any way to remove/destroy/delete it. What I'm trying for Export Path: qagenfil1_nfs1:/ovirt_inside/images Thanks.

3 4

Customized Network Setup?
by Charles Tassell 05 Apr '17

05 Apr '17

Hi Guys, I'm wondering, is it possible to override VDSM and setup my network interfaces manually? I've got two Dell servers with dual-10G networking that I want to use bonded (LACP) for ovirtmgmt and then some 1G interfaces that I want to use for the VM network/Internet connection. I've got it working on the box I installed the hosted engine on, but it won't properly setup the networking on additional hosts. I've tried setting up bonding before doing the install (worked fine, ran the New host setup through the admin GUI, network died); doing the install with bonding turned off and then adding it in later (didn't create the ovirtmgmt bridge and the policy routing rules that it uses (I'd REALLY like to be able to turn that garbage off) didn't get added to bond0...) In all situations it removes the default route from my standard routing table so I can't access the machines from outside the subnet... I can setup the bonding and bridges manually fairly in 10 minutes, but I'm worried that VDSM is going to come in and overwrite my config with the broken stuff if I do that.

2 2

Live storage migration?
by gflwqs gflwqs 05 Apr '17

05 Apr '17

Hi list! I need to move my vm:s from one datacenter to another. The problem is that i don't have shared storage between those datacenters. How can i move my vm:s without stopping them? I know in vmware that is possible thru vmotion /C

1 0

[ANN] oVirt 4.1.1 Async release candidate
by Sandro Bonazzola 05 Apr '17

05 Apr '17

Hi, following oVirt 4.1.1 GA the oVirt team identified some bugs worth to be addressed out of the usual release cycle. For this reason an async release including these fixes is under preparation. An update to the following packages have been pushed to the pre-release repository for testing. - cockpit-ovirt-0.10.7-0.0.16 - imgbased-0.9.20 - ovirt-engine-4.1.1.8 - ovirt-engine-metrics-1.0.2 - ovirt-release41-4.1.1.1 - ovirt-web-ui-0.1.2-4 - vdsm-jsonrpc-java-1.3.10 - vdsm v4.19.10.1 In order to test it, you'll need pre-release repository enabled: yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41-pre.rpm An update to release notes including bugs related to above packages and updates applied in bugzilla documentation texts has been pushed tohttps://github.com/oVirt/ovirt-site/pull/888 for review. On behalf of the oVirt team, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

rename storage domain
by Gianluca Cecchi 05 Apr '17

05 Apr '17

Hello, I'm in 4.1.1 and imported a storage domain. In import window there is option to put name, but actually afterwards the name is the same as the source one... Is this expected? Is there any way to change name of storage domain? thanks, Gianluca

2 3

Moving from fc based to iSCSI based
by Gianluca Cecchi 05 Apr '17

05 Apr '17

Hello, I have to move some VMs from FCP based storage domain to iSCSI based storage domain. Can I do it offline or online keeping in mind that: Host1, Host2 have access only to the FCP SD Host3, Host4 have access only to the iSCSI SD They are all managed by the same engine in the same DC but in different cluster I suppose it happens through network, correct? Thanks in advance, Gianluca

2 8

Question about firewall on hypervisor
by Gianluca Cecchi 05 Apr '17

05 Apr '17

Suppose I want to disable firewall at already installed hypervisor side (eg because I want to setup OVN and currently if I remember correctly it needs to be disabled for that), can I simply disable the related services through systemctl stop iptables systemctl disable iptables systemctl stop firewalld systemctl disable firewalld Or is anything else to do at hypervisor and/or engine side? I don't see anything in web admin gui editing the host, while when I add the host there is the checkbox "Automatically configure host firewall".... Thanks, Gianluca

2 1