January 2018 - Users - oVirt List Archives

A possible bug on Fedora 27
by Valentin Bajrami 07 Feb '18

07 Feb '18

Hi Community, Recently we discovered that our VM's became unstable after upgrading from Fedora 26 to Fedora 27. The journalctl log shows the following Jan 29 20:03:28 host1.project.local libvirtd[2741]: 2018-01-29 19:03:28.789+0000: 2741: error : qemuMonitorIO:705 : internal error: End of file from qemu monitor Jan 29 20:09:14 host1.project.local libvirtd[2741]: 2018-01-29 19:09:14.111+0000: 2741: error : qemuMonitorIO:705 : internal error: End of file from qemu monitor Jan 29 20:10:29 host1.project.local libvirtd[2741]: 2018-01-29 19:10:29.584+0000: 2741: error : qemuMonitorIO:705 : internal error: End of file from qemu monitor A similar bug report is already present here: https://bugzilla.redhat.com/show_bug.cgi?id=1523314 but doesn't reflect our problem entirely. This bug seems to be triggered only when a VM is shut down gracefully. In our case this is being triggered without attempting to shutdown a VM. Again, this is causing the VM's to be unstable and eventually they'll shut down by themselves. Do you have any clue what could be causing this? -- Met vriendelijke groeten, Valentin Bajrami

1 1

qemu-kvm images corruption
by Nicolas Ecarnot 06 Feb '18

06 Feb '18

TL;DR: How to avoid images corruption? Hello, On two of our old 3.6 DC, a recent series of VM migrations lead to some issues : - I'm putting a host into maintenance mode - most of the VM are migrating nicely - one remaining VM never migrates, and the logs are showing : * engine.log : "...VM has been paused due to I/O error..." * vdsm.log : "...Improbable extension request for volume..." After digging amongst the RH BZ tickets, I saved the day by : - stopping the VM - lvchange -ay the adequate /dev/... - qemu-img check [-r all] /rhev/blahblah - lvchange -an... - boot the VM - enjoy! Yesterday this worked for a VM where only one error occurred on the qemu image, and the repair was easily done by qemu-img. Today, facing the same issue on another VM, it failed because the errors were very numerous, and also because of this message : [...] Rebuilding refcount structure ERROR writing refblock: No space left on device qemu-img: Check failed: No space left on device [...] The PV/VG/LV are far from being full, so I guess I don't where to look at. I tried many ways to solve it but I'm not comfortable at all with qemu images, corruption and solving, so I ended up exporting this VM (to an NFS export domain), importing it into another DC : this had the side effect to use qemu-img convert from qcow2 to qcow2, and (maybe?????) to solve some errors??? I also copied it into another qcow2 file with the same qemu-img convert way, but it is leading to another clean qcow2 image without errors. I saw that on 4.x some bugs are fixed about VM migrations, but this is not the point here. I checked my SANs, my network layers, my blades, the OS (CentOS 7.2) of my hosts, but I see nothing special. The real reason behind my message is not to know how to repair anything, rather than to understand what could have lead to this situation? Where to keep a keen eye? -- Nicolas ECARNOT

2 2

ovirt 3.6, we had the ovirt manager go down in a bad way and all VMs for one node marked Unknown and Not Reponding while up
by Christopher Cox 05 Feb '18

05 Feb '18

Like the subject says.. I tried to clear the status from the vm_dynamic for a VM, but it just goes back to 8. Any hints on how to get things back to a known state? I tried marking the node in maint, but it can't move the "Unknown" VMs, so that doesn't work. I tried rebooting a VM, that doesn't work. The state of the VMs is up.... and I think they are running on the node they say they are running on, we just have the Unknown problem with VMs on that one node. So... can't move them, reboot VMs doens't fix.... Any trick to restoring state so that oVirt is ok??? (what a mess)

3 8

VM paused due unknown storage error
by Misak Khachatryan 05 Feb '18

05 Feb '18

Hi, After upgrade to 4.2 i'm getting "VM paused due unknown storage error". When i was upgrading i had some gluster problem with one of the hosts, which i was fixed readding it to gluster peers. Now i see something weir in bricks configuration, see attachment - one of the bricks uses 0% of space. How I can diagnose this? Nothing wrong in logs as I can see. Best regards, Misak Khachatryan

2 5

[IOPROCESS] New release for Fedora
by Nir Soffer 04 Feb '18

04 Feb '18

Hi all, I released ioprocess 1.0.0 for Fedora 27 and 28. If you are using Fedora, please install the new version from the updates-testing and test it. Please share your feedback here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fbe8141dd2 This version will be available soon from oVirt repositories. Thanks, Nir

1 1

Using upstream QEMU
by Harry Mallon 02 Feb '18

02 Feb '18

Hello all, Has anyone used oVirt with non-oVirt provided QEMU versions? I need a feature provided by upstream QEMU, but it is disabled in the oVirt/CentOS7 QEMU RPM. I have two possible methods to avoid the issue: 1. Fedora has a more recent QEMU which is closer to 'stock'. I see that oVirt 4.2 has no Fedora support, but is it possible to install the host onto a Fedora machine? I am trying to use the master branch rpms as recommended in the "No Fedora Support" note with no luck currently. 2. Is it safe/sensible to use oVirt with a CentOS7 host running an upstream QEMU version? Thanks, Harry Harry Mallon CODEX | Senior Software Engineer 60 Poland Street | London | England | W1F 7NT E harry.mallon(a)codex.online | T +44 203 7000 989

3 4

ovirt 4.2.1 pre hosted engine deploy failure
by Gianluca Cecchi 02 Feb '18

02 Feb '18

Hello, at the end of the command hosted-engine --deploy I get [ INFO ] TASK [Detect ovirt-hosted-engine-ha version] [ INFO ] changed: [localhost] [ INFO ] TASK [Set ha_version] [ INFO ] ok: [localhost] [ INFO ] TASK [Create configuration templates] [ INFO ] TASK [Create configuration archive] [ INFO ] changed: [localhost] [ INFO ] TASK [Create ovirt-hosted-engine-ha run directory] [ INFO ] changed: [localhost] [ INFO ] TASK [Copy configuration files to the right location on host] [ INFO ] TASK [Copy configuration archive to storage] [ ERROR ] [WARNING]: Failure using method (v2_runner_on_failed) in callback plugin [ ERROR ] (<ansible.plugins.callback.1_otopi_json.CallbackModule object at 0x2dd7d90>): [ ERROR ] 'ascii' codec can't encode character u'\u2018' in position 496: ordinal not in [ ERROR ] range(128) [ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook [ INFO ] Stage: Clean up [ INFO ] Cleaning temporary resources [ INFO ] TASK [Gathering Facts] [ INFO ] ok: [localhost] [ INFO ] TASK [Remove local vm dir] [ INFO ] changed: [localhost] [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20180129164431.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Hosted Engine deployment failed: this system is not reliable, please check the issue,fix and redeploy Log file is located at /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20180129160956-a7itm9.log [root@ov42 ~]# Is there any known bug for this? In log file I have: 2018-01-29 16:44:28,159+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:173 [WARNING]: Failure using method (v2_runner_on_failed) in callback plugin 2018-01-29 16:44:28,160+0100 DEBUG otopi.plugins.otopi.dialog.human human.format:69 newline sent to logger 2018-01-29 16:44:28,160+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:173 (<ansible.plugins.callback.1_otopi_json.CallbackModule object at 0x2dd7d90>): 2018-01-29 16:44:28,160+0100 DEBUG otopi.plugins.otopi.dialog.human human.format:69 newline sent to logger 2018-01-29 16:44:28,160+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:173 'ascii' codec can't encode character u'\u2018' in position 496: ordinal not in 2018-01-29 16:44:28,161+0100 DEBUG otopi.plugins.otopi.dialog.human human.format:69 newline sent to logger 2018-01-29 16:44:28,161+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils.run:173 range(128) 2018-01-29 16:44:28,161+0100 DEBUG otopi.plugins.otopi.dialog.human human.format:69 newline sent to logger 2018-01-29 16:44:28,161+0100 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/gr-he-ansiblesetup/core/target_vm.py", line 193, in _closeup r = ah.run() File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/ansible_utils.py", line 175, in run raise RuntimeError(_('Failed executing ansible-playbook')) RuntimeError: Failed executing ansible-playbook 2018-01-29 16:44:28,162+0100 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Closing up': Failed executing ansible-playbook I'm testing deploy of nested self hosted engine with HE on NFS. Thanks, Gianluca

2 4

Node network setup
by spfma.tech＠e.mail.fr 01 Feb '18

01 Feb '18

--=_40d9d471a95f6be5f29c7f93c9060b7c Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I am trying to setup a cluster of two nodes, with self hoste Engine= . Things went fine for the first machine, but it as rather messy about t= he second one. I would like to have load balancing and failover for both= management network and storage (NFS repository). So what should I exa= ctly do to get a working network stack which can be recognized when I tr= y to add this host to the cluster ? Have tried configuring bonds and b= riges using Cockpit, using manual "ifcfg" files, but all the time I see= the bridges and the bonds not linked in the Engine interface, so the ne= w host cannot be enrolled. If I try to link "ovirtmgmt" to the the assoc= iated bond, I have a connectivity loss because it is the management devi= ce, and I have te restart the network services. As management configurat= ion is not OK, I can't setup the storage connection. And if I just try= to activate the host, I will install and configure things and then comp= lain about missing "ovirtmgmt" and "nfs" networks, which both exist and= work and Centos level. The interface, bonds and bridge names are copy= /paste from the first server. # brctl show ovirtmgmt=0Abridge name bri= dge id STP enabled interfaces=0Aovirtmgmt 8000.44a842394200 no bond0 # i= p addr show bond0=0A33: bond0: mtu 1500 qdisc noqueue master ovirtmgmt= state UP qlen 1000=0A link/ether 44:a8:42:39:42:00 brd ff:ff:ff:ff:ff:f= f=0A inet6 fe80::46a8:42ff:fe39:4200/64 scope link =0A valid_lft forever= preferred_lft forever=0A# ip addr show em1=0A2: em1: mtu 1500 qdisc mq= master bond0 state UP qlen 1000=0A link/ether 44:a8:42:39:42:00 brd ff:= ff:ff:ff:ff:ff=0A# ip addr show em3=0A4: em3: mtu 1500 qdisc mq master= bond0 state UP qlen 1000=0A link/ether 44:a8:42:39:42:00 brd ff:ff:ff:f= f:ff:ff By the way, is it mandatory to stop and disable NetworkManager= or not ? Thanks for any kind of help :-) --=_40d9d471a95f6be5f29c7f93c9060b7c Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <div>Hi,</div>=0A<div>=0A<div>I am trying to setup a cluster of two node= s, with self hoste Engine.</div>=0A<div>Things went fine for the first m= achine, but it as rather messy about the second one.</div>=0A<div>I woul= d like to have load balancing and failover for both management network a= nd storage (NFS repository).</div>=0A<div> </div>=0A<div>So what sh= ould I exactly do to get a working network stack which can be recognized= when I try to add this host to the cluster ?</div>=0A<div> </div>= =0A<div>Have tried configuring bonds and briges using Cockpit, using man= ual "ifcfg" files, but all the time I see the bridges and the bonds not= linked in the Engine interface, so the new host cannot be enrolled.</di= v>=0A<div>If I try to link "ovirtmgmt" to the the associated bond, I hav= e a connectivity loss because it is the management device, and I have te= restart the network services. As management configuration is not OK, I= can't setup the storage connection.</div>=0A<div> </div>=0A<div>An= d if I just try to activate the host, I will install and configure thing= s and then complain about missing "ovirtmgmt" and "nfs" networks, which= both exist and work and Centos level.</div>=0A<div> </div>=0A<div>= The interface, bonds and bridge names are copy/paste from the first serv= er.</div>=0A<div> </div>=0A<div># brctl show ovirtmgmt<br />bridge= name    bridge id        S= TP enabled    interfaces<br />ovirtmgmt   &nbsp= ;    8000.44a842394200    no   &= nbsp;    bond0</div>=0A<div># ip addr show bond0<br />33:= bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc no= queue master ovirtmgmt state UP qlen 1000<br />    link/e= ther 44:a8:42:39:42:00 brd ff:ff:ff:ff:ff:ff<br />    ine= t6 fe80::46a8:42ff:fe39:4200/64 scope link <br />   &nbsp= ;   valid_lft forever preferred_lft forever<br /># ip addr sho= w em1<br />2: em1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 150= 0 qdisc mq master bond0 state UP qlen 1000<br />    link/= ether 44:a8:42:39:42:00 brd ff:ff:ff:ff:ff:ff<br /># ip addr show em3<br= />4: em3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc= mq master bond0 state UP qlen 1000<br />    link/ether 4= 4:a8:42:39:42:00 brd ff:ff:ff:ff:ff:ff</div>=0A<div> </div>=0A<div>= By the way, is it mandatory to stop and disable NetworkManager or not ?<= /div>=0A<div> </div>=0A<div>Thanks for any kind of help :-)</div>= =0A</div> --=_40d9d471a95f6be5f29c7f93c9060b7c--

2 1

Upgrade via reinstall?
by Jamie Lawrence 01 Feb '18

01 Feb '18

Hello, I currently have an Ovirt 4.1.8 installation with a hosted engine using Gluster for storage, with the DBs hosted on a dedicated PG cluster. For reasons[1], it seems possibly simpler for me to upgrade our installation by reinstalling rather than upgrading. In this case, I can happily bring down the running VMs/otherwise do things that one normally can't. Is there any technical reason I can't/shouldn't rebuild from bare-metal, including creating a fresh hosted engine, without losing anything? I suppose a different way of asking this is, is there anything on the engine/host filesystems that I should preserve/restore for this to work? Thanks, -j [1] If this isn't an option, I'll go in to them in order to figure out a plan B; just avoiding a lot of backstory that isn't needed for the question.

2 2

engine add hosts
by 李强华 01 Feb '18

01 Feb '18

hello~，I want to add hosts ，but my host offline , can not connect to internal .engine add hosts , the message： installing hosts node failed . My engine was setup successful , i use engine-setup --offline OK，please help~ [cid:4eed0bd5-8485-41c4-b73b-b82855c988e7] [cid:06876a73-d34b-435f-8479-32aec82c5a0b]

2 1

Engine VM cannot be migrated
by spfma.tech＠e.mail.fr 31 Jan '18

31 Jan '18

--=_0478ea78b27bb4a39cbe20ae18efe4cb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, What can prevent the hosted engine VM from being migrated ? I can mi= grate any other VM in the cluster (same servers), and it is supposed to= be configured to be migrated manually or automatically as far as I can= see.=0A Regards --=_0478ea78b27bb4a39cbe20ae18efe4cb Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <div><span style=3D"font-family: arial, helvetica, sans-serif; font-size= : 10pt; color: #000000;">Hi,</span></div>=0A<div><span style=3D"font-fam= ily: arial, helvetica, sans-serif; font-size: 10pt; color: #000000;">Wha= t can prevent the hosted engine VM from being migrated ?</span></div>=0A= <div><span style=3D"font-family: arial, helvetica, sans-serif; font-size= : 10pt; color: #000000;">I can migrate any other VM in the cluster (same= servers), and it is supposed to be configured to be migrated manually o= r automatically as far as I can see.<br /></span></div>=0A<div><span sty= le=3D"font-family: arial, helvetica, sans-serif; font-size: 10pt; color:= #000000;">Regards</span></div>=0A<div> </div> --=_0478ea78b27bb4a39cbe20ae18efe4cb--

1 0

QEMU custom bios and machine setup
by Harry Mallon 31 Jan '18

31 Jan '18

Hello all, I have only been using oVirt for a couple of weeks, but it is working well. I can see in Advanced options that I can pick a custom machine definition. Is there a way to customise the machine as you can with QEMU command line or libvirt XML? I need to access some weirder settings like bios image. Thanks for your help, Harry Harry Mallon CODEX | Senior Software Engineer 60 Poland Street | London | England | W1F 7NT E harry.mallon(a)codex.online | T +44 203 7000 989

2 3

Move Export Domain across web via NFS verses Rsync Image
by Matt Simonsen 31 Jan '18

31 Jan '18

Hello all, We have a several oVirt data centers mostly using oVirt 4.1.9 and NFS backed storage. I'm planning a move for what will eventually be an exported VM, from one physical location to another one. Is there any reason it would be problematic to export the image and then use rsync to migrate the image directory to a different export domain? Thanks, Matt

3 3

cloud-init not setting gateway
by Maton, Brett 31 Jan '18

31 Jan '18

Are there any known issues with cloud-init not setting the network gateway ? I'm trying to create a host with the ansible roles, all is Ok apart from network settings. Ansible code: - block: - name: Authenticate ovirt_auth: password: *** url: "https://***/ovirt-engine/api" username: admin@internal - name: "Create Virtual Machines" ovirt_vms: auth: "{{ ovirt_auth }}" clone: false cloud_init: custom_script: "touch /etc/cloud/cloud-init.disabled" dns_search: *** dns_servers: "*** ***" host_name: *** nic_boot_protocol: static nic_gateway: "***" nic_ip_address: "***" nic_name: eth0 nic_netmask: "***" nic_on_boot: true cluster: Default comment: "Ansible Created" name: "***" state: present stateless: false storage_domain: "***" template: CentOS7_1711_could_init timeout: 600 register: ovirt_vm always: - name: "Sign Out" ovirt_auth: ovirt_auth: "{{ ovirt_auth }}" state: absent I've also tried using the web-ui, again most 'things' get set but not the gateway which is a killer as I can only access the VM with remote console until I set the gateway. Regards, Brett

3 3

[ANN] oVirt 4.1.9 Release is now available
by Lev Veyde 31 Jan '18

31 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.1.9 release, as of January 24th, 2017 This update is the ninth in a series of stabilization updates to the 4.1 series. Please note that no further updates will be issued for the 4.1 series. We encourage users to upgrade to 4.2 series to receive new features and updates. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.1 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Live is already available [2] - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.1.9 release highlights: http://www.ovirt.org/release/4.1.9/ * 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] http://www.ovirt.org/release/4.1.9/ [2] http://resources.ovirt.org/pub/ovirt-4.1/iso/ -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

6 7

ovirt-guest-agent.service has broken in Debian 8 virtual machines after updates hosts to 4.2
by Алексей Максимов 30 Jan '18

30 Jan '18

Hello, oVirt guru's I just successfully updated my oVirt HE to 4.2. But after I upgraded all hosts and virtual machine restart, the ovirt-guest-agent.service has stopped running in virtual machines with Debian Jessie. ---- # lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.10 (jessie) Release: 8.10 Codename: jessie ---- # dpkg -l | grep ovirt ii ovirt-guest-agent 1.0.10.2.dfsg-2+deb8u1 all daemon that resides within guest virtual machines Note: This package installed from Debian Jessie official repo ---- # systemctl status ovirt-guest-agent.service ● ovirt-guest-agent.service - oVirt Guest Agent Loaded: loaded (/lib/systemd/system/ovirt-guest-agent.service; disabled) Active: failed (Result: exit-code) since Tue 2018-01-02 17:36:29 MSK; 23min ago Main PID: 3419 (code=exited, status=1/FAILURE) Jan 02 17:36:29 APP3 systemd[1]: Started oVirt Guest Agent. Jan 02 17:36:29 APP3 systemd[1]: ovirt-guest-agent.service: main process exited, code=exited, status=1/FAILURE Jan 02 17:36:29 APP3 systemd[1]: Unit ovirt-guest-agent.service entered failed state. ---- >From /var/log/ovirt-guest-agent/ovirt-guest-agent.log: MainThread::INFO::2018-01-02 17:36:29,764::ovirt-guest-agent::57::root::Starting oVirt guest agent MainThread::ERROR::2018-01-02 17:36:29,768::ovirt-guest-agent::138::root::Unhandled exception in oVirt guest agent! Traceback (most recent call last): File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 132, in <module> agent.run(daemon, pidfile) File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 63, in run self.agent = LinuxVdsAgent(config) File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 375, in __init__ AgentLogicBase.__init__(self, config) File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 171, in __init__ self.vio = VirtIoChannel(config.get("virtio", "device")) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 150, in __init__ self._stream = VirtIoStream(vport_name) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 131, in __init__ self._vport = os.open(vport_name, os.O_RDWR) OSError: [Errno 2] No such file or directory: '/dev/virtio-ports/com.redhat.rhevm.vdsm' ---- Before updating to version 4.2 (for version 4.1.8) everything worked fine. Please help solve the problem

4 7

[ANN] oVirt 4.2.1 Fourth Release Candidate is now available
by Lev Veyde 30 Jan '18

30 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.2.1 Fourth Release Candidate, as of January 30th, 2017 This update is a release candidate of the first in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.2.1 release highlights: http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.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] http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.1/> [2] http://resources.ovirt.org/pub/ovirt-4. <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>2-pre <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>/iso/ <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/> -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

Nvidia Tesla M60 Direct GPU-Passthrough giving issues + VNC
by Ravyu Sivakumaran 30 Jan '18

30 Jan '18

Hi, I am running an Ovirt host on a SuperMicro SuperServer 2028GR-TRH equipped with 2x2 Tesla M60s (they are dual GPU Cards). I've followed this guide- https://www.ovirt.org/develop/release-management/features/virt/hostdev-pass… and managed to get a Windows 10 Enterprise guest running with one GPU attached to it. The windows guest successfully detects the single M60 GPU and I can install the latest Tesla drivers (390.65) on it with no problem. However, the GPU refuses to do any work whatsoever. The control panel says the GPU is being used for compute and not as a VGA adapter (shows up as inactive on the activity monitor). Nvidia's GPUModeSwitcher tool tells me that the GPU is in Graphics mode, so there is a driver issue here. I have access to the GRID Drivers. However I'm not sure why I'd need them as I'm only doing a direct-passthrough, not GPU Virtualization. Any ideas? Also, after activating Device-Passthrough, I'm unable to access my VM's via the Hosts' VNC anymore. I get an "unable to connect" error. Im currently accessing the Guests with a direct VNC connection. Problem is, I can't clone/create new VMs anymore because of this. I must've done something wrong, not sure what. Thanks in advance! -- Yours Faithfully Ravyu

2 1

SSL Workflow for oVirt
by Gabriel Stein 29 Jan '18

29 Jan '18

Hi all, I think that I found a way to solve the problem from: http://lists.ovirt.org/pipermail/users/2018-January/086441.html and I'm trying to fix it. But my servers are in Production(50%) and I found that are some errors with my SSL Certificates. ## What I need now? Fixes all certificates problems using my Freeipa generated certificates: vdsmclient* on hosts, ovirt-engine communication ssl certificates on hosted-engine. I made with Freeipa(internal) the certificates for ovirt-engine( only apache - self hosted) and Hosts(vsdmclient and vdsmkey....) and replaced using this howto: https://gist.github.com/qrkourier/9c9ac3e8b190dcb91d3767179d5a39ea ## Now ovirt-engine can't contact a Host(Non Responsive) with the errors(Yes, I have a Backup from all old certificates): *VDSM host.domain.tld command GetCapabilitiesVDS failed: General SSLEngine problem* On engine.log: *2018-01-23 13:33:40,160+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-23) [] Command 'GetAllVmStatsVDSCommand(HostName = host.domain.tld, VdsIdVDSCommandParametersBase:{hostId='d6bc650b-7edd-4019-b316-54313217880f'})' execution failed: VDSGenericException: VDSNetworkException: General SSLEngine problem* *2018-01-23 13:33:40,160+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] (EE-ManagedThreadFactory-engineScheduled-Thread-23) [] Failed to fetch vms info for host 'host.domain.tld' - skipping VMs monitoring.* ## I read, that ovirt-engine generates certificates for all hosts and it uses his own CA. Questions: - How can I fix the communication from hosted-engine and vsdm on hosts? Should I copy my Freeipa ca.crt and replace the ca.der file on */etc/pki/ovirt-engine/certs*? - Should I change the engine.cer certificate from */etc/pki/ovirt-engine/certs *with my Certificate made using Freeipa? - How to do that properly? - Where can I find a complete workflow from SSL Certificates from oVirt? What certificates should I change? ## I found some links that to me are confusing(or I'm just dumb), I will take my end solution and do a howto to all: - https://www.ovirt.org/develop/release-management/features/infra/pki/ - how updated is that? I can't overwrite a ca from ovirt-engine? - https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/ *- * *Note:** Using a commercially issued certificate for HTTPS connections does not affect the certificate used for authentication between your Engine and hosts. They will continue to use the self-signed certificate generated by the Engine... * ... Well, why I keep receiving errors with the self-signed CA from ovirt-engine and the disk uploads?(*Unable to upload image to disk a-b-c-d-e due to a network error. Make sure ovirt-imageio-proxy service is installed and configured, and ovirt-engine's certificate is registered as a valid CA in the browser. The certificate can be fetched from https://<engine_url>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA* ) Thanks in Advance! Best Regards, Gabriel PS: I would help with the oVirt Wiki if needed, I would follow the rhce path and do the rhcs certification too, will be nice to study a lot. Gabriel Stein ------------------------------ Gabriel Ferraz Stein Tel.: +49 (0) 170 2881531

2 1

No master storage domain, force select?
by Jure Kranjc 29 Jan '18

29 Jan '18

This is a cryptographically signed message in MIME format. --------------ms000006050602060305000308 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hello, is there a way to force select master storage domain? I have three data=20 domains, we had some storage problems and now none of the domains is=20 master. I cannot activate any because I should first activate the master = one. Any help appreciated. --------------ms000006050602060305000308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC ChcwggUAMIID6KADAgECAhADS+4XH7fhBjcv1HJCQL0qMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMU VEVSRU5BIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG pbsfVYL0pTRyFHJlm1/V6qBo2JuCiU9TYpx7jM4O2tQyDq8bjMum69vg6wM0lMGHflMgqB75 GxeKfQFmEldoXi2cLishqFUvU2cJeM3SaRsLk2BsuCgTzh9NsYgmrUX60KHOq7eYKVZxbPFW JF2nMOBuMXNu2qBXTGSLeLXHnNvG3r7TLzGg1oA5teAxQE6Eo8ySSeIXbP7wZB76urwlh51P IbrJZjkDjdQVELh7OlTP1WO6T/Hf6BsEfeFcpoa1e+MW/lw0VetTPPHQ15HYKYP2WYohHxzD iC+QUwE7UZVBlp9cXIpwHuDzSibc5RG3z0n/j2SQCx0Dk5FMAUErAgMBAAGjggGmMIIBojAS BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcBAQRtMGswJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDov L2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQU8CHpSXdzn4WuGDvoUnAU Bu1C7sowHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQAD ggEBADrCGyv+Y967YbS5R6j8fAWxJiAiUZvIPfn1xVgesF6jspwCQY8xGn/MG04d+Jh97I8I /Xfx29JEEFq2rQmw4PxiO9RiDZ7xoDxNd4rrRDR7jrtOKQP8J+o+ah0vSOP62hnD/zPS7NRM tIyVS2G277KAL5fIR62ngr984fmJghDv0bsjGAmeu3EP0xhUsDJT61IoAGoKBnxBPAeg3WXs dSm4Gn7btyvakeyFtYebr2KmOBSa28PRqGSDur56aZhJoM2eMzc6prmvGwwtAzRsc5t2OsKR uHWV6O3anP2K27jGZR2bi1VX1NQUvIbpVNTuwjm+XcZtsa/AAJF9KGkEseAwggUPMIID96AD AgECAhAIjN7NyFkWCGXu+LbfMlIUMA0GCSqGSIb3DQEBCwUAMGkxCzAJBgNVBAYTAk5MMRYw FAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRF UkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMwHhcNMTcxMTE0MDAwMDAwWhcN MjAxMTE0MTIwMDAwWjBHMQswCQYDVQQGEwJTSTESMBAGA1UEBxMJTGp1YmxqYW5hMQ4wDAYD VQQKEwVBcm5lczEUMBIGA1UEAxMLSnVyZSBLcmFuamMwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCgHE2xBKE9iUzRk9FUDtg8mDmUj0HNXP38LsV/md9bkIGuCqxfig7D1Mq3 5Bf15GuYp5bii2scJqYNkN0haf2y27GO2/VsQLvdonHr7iRpltqoSbg8INXyedjDsnnF970e aiQc260SxV8eWFua4CS92mykJIz1koU1du0u4nqoM0yoh4ovIdKWeSmFN3C1uEukAk8jycAM gup39xXCjB+A+V0RA3f8/re2dsIrNG672QrUIHIyAksH1bZztmlVXZYu+qSKwVuuyTb5wkLW TwSZ01MI9jXE9Qy65FzMWVZELTTUcGDB359EPjy3n04uNsp3oGP9/0mhuI7VmGDEQ4CXAgMB AAGjggHTMIIBzzAfBgNVHSMEGDAWgBTwIelJd3Ofha4YO+hScBQG7ULuyjAdBgNVHQ4EFgQU kK/eYmNE8toxdJaCsjvO0lhb1sUwDAYDVR0TAQH/BAIwADAfBgNVHREEGDAWgRRqdXJlLmty YW5qY0Bhcm5lcy5zaTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczov L3d3dy5kaWdpY2VydC5jb20vQ1BTMHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENBMy5jcmwwNKAyoDCGLmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENBMy5jcmwwcwYIKwYBBQUHAQEEZzBlMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wPQYIKwYBBQUHMAKGMWh0dHA6Ly9j YWNlcnRzLmRpZ2ljZXJ0LmNvbS9URVJFTkFQZXJzb25hbENBMy5jcnQwDQYJKoZIhvcNAQEL BQADggEBAMKWUMYBnUkSdz/tVYzPwEamsxN4QmVVpFzDogZxBspz1p/F9i+dyIPuZHP6/ahm ru3lLvtHT+SH+8YZ1lTeu25Y64gHBsAEGqR2wRt35ZX72+ekU2U8zCA+2QnYD3ejeGSfUuNr Bz9k6JHxg/d2+A4sZI4L2VXrFOnLMTWmxeFN5lS4l2UU72Ckjs6xrb6RUHBqp0XJJs8GGR64 lZjrALDewuZk+Gb6oua1hKNw7obTFLTw+1gKaV+hyOFmcP95iHy/mESGcz+JJz7EjzmbFkQs QS2e/gRmxwZMIs5yWTJXnKjQE9/8GKOwkCqWL0Fd5IlFUEByRo7NdyASSw587rkxggOjMIID nwIBATB9MGkxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFs IENBIDMCEAiM3s3IWRYIZe74tt8yUhQwDQYJYIZIAWUDBAIBBQCgggH3MBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDExODA1MjYwNFowLwYJKoZIhvcN AQkEMSIEILwdN21ICV8CYh//3XjmddP6J/SHbLUwZQqiAdt20otYMGwGCSqGSIb3DQEJDzFf MF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYwGCSsGAQQBgjcQ BDF/MH0waTELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcT CUFtc3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMR0wGwYDVQQDExRURVJFTkEgUGVyc29uYWwg Q0EgMwIQCIzezchZFghl7vi23zJSFDCBjgYLKoZIhvcNAQkQAgsxf6B9MGkxCzAJBgNVBAYT Ak5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNV BAoTBlRFUkVOQTEdMBsGA1UEAxMUVEVSRU5BIFBlcnNvbmFsIENBIDMCEAiM3s3IWRYIZe74 tt8yUhQwDQYJKoZIhvcNAQEBBQAEggEACozEx+i2cc/jB1De3hwoILq4fKLPrZ1isUKE0C7G EuRsT9cPhgAkA7SLZUbaiLqnekwY8q83vTDHlKzcghwgnTb5JGRrIKdgA1gaN3LSqN6Gp6pJ mAcz4/M7uhPr2t1e7DpOVO5tx/TaDhsobeRCcc7YvkxXdCnEJtLIX3TGBAOJba/XHNDhIS21 6jQh3PyY+d96HMiS77QaUXLNtg7V3Yf7sA4ox7xfOOTXXCCRbrDenNYFvehm0513dVjHG3l6 G3F2IWpeEWcfkUsAoAhFgAN/9ipAOrDXy9iMQoFdQ2PcLdYMZdAQKZfi2r7M6T74d6h8m1/L tyGSXZOOeSQwvgAAAAAAAA== --------------ms000006050602060305000308--

2 2

PHX planned maintenance 29.01.2018 @19:00 GMT
by Evgheni Dereveanchin 29 Jan '18

29 Jan '18

Hi everyone, Planned works are going to be performed in the PHX data center today. They are related to core networking hardware upgrades and may cause short connectivity loss to services hosted by the oVirt project, including: * Jenkins CI * Package repositories * project website * mailing lists The maintenance window starts at 19:00 GMT and has a duration of one hour. I will pause CI job execution before the maintenance window so builds will be queued and executed after network upgrades are implemented to decrease the possibility of false positives. I will follow up with any further updates. -- Regards, Evgheni Dereveanchin

1 1

NFS sync vs async
by Jean-Francois Courteau 29 Jan '18

29 Jan '18

Hello there, At first I thought I had a performance problem with virtio-scsi on Windows, but after thorough experimentation, I finally found that my performance problem was related to the way I share my storage using NFS. Using the settings suggested on the oVirt website for the /etc/exports file, I implemented the following line: /storage *(rw,sync,no_subtree_check,all_squash,anonuid=36,anongid=36) The underlying filesystem is ext4. In the end, whatever the VM I am running through this NFS export, I get extremely poor write performance, like sub-100 IOPS (my disks usually can do 800-1k). Under the hood, iotop shows that my host IO is all taken up by jbd2, and if I understand correctly, it is the ext4 logging process. I have read that using the "async" option in my NFS export is unsafe, like if my host crashes during a write operation, it could corrupt my VM Disks. What is the best combination of filesystem / settings if I want to go with NFS sync? Is someone getting good performance with the same options as me? if so, why do I get such abysmal IOPS numbers? Thanks! J-F Courteau

1 0

Q: Core Reservation on Hyperthreaded CPU
by Andrei V 29 Jan '18

29 Jan '18

Hi, I’m currently running node on HP ProLiant with 2 x Xeon with 4 core each. Because of hyperthreading each physical core is being seen as 2. How KVM/oVirt reserves cores if for example I allocate 4 CPU cores for VM ? Does it allocates 4 real CPU cores, or 2 cores with 2 threads each ? Each VM consumes very low CPU resources. What happens if # of used cores consumed by VMs will exceed real count of physical CPU cores ? Thanks. Andrei

2 1

disk copy exception
by Donny Davis 28 Jan '18

28 Jan '18

I am trying to copy a disk that was from a storage domain that was imported from 4.1 to a newer storage domain and this exception is thrown in the UI Uncaught exception occurred. Please try reloading the page. Details: Exception caught: (TypeError) : Cannot read property 'g' of null Please have your administrator check the UI logs

2 3

Basic parts for rebuilding ovirt server
by Alex Bartonek 27 Jan '18

27 Jan '18

This is a multi-part message in MIME format. --b1_f894a230c95068ff2d09e33adb4dda21 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 S2luZGEgcGxlYXNlZCB3aXRoIHRoZSB3YXkgdGhlIHJlc3RvcmUgd2VudC4gU3Vja3MgdGhhdCBt eSBiYWNrdXBzIHdlcmVuJ3Qgd29ya2luZyBsaWtlIEkgdGhvdWdodC4KCkkgZGlkIGFuIGVuZ2lu ZSBiYWNrdXAsIGNvbXBsZXRlIGFib3V0IGEgZGF5IGJlZm9yZSBJIGxvc3QgZGF0YS4KCkFyZSB0 aGVzZSB0aGUgYmFzaWMgc3RlcHM6CgoxLiBSZWluc3RhbGwgQ2VudE9TICh3aGF0ZXZlciBPUyB5 b3UgdXNlZCkKMi4gVXBkYXRlIGFsbCBwYWNrYWdlcwozLiBJbnN0YWxsIG92aXJ0CjQuIEVuZ2lu ZSByZXN0b3JlCjUuIEVuZ2luZSBzZXR1cAoKVGhhdCBnZXRzIHlvdSBhIGJhc2ljIG92aXJ0IHNl cnZlciB3aXRoIHlvdXIgcHJldmlvdXMgc2V0dGluZ3MuCgpNeSBwcm9ibGVtOgpTdG9yYWdlIGRv bWFpbnMgYXJlIGdvbmUgYWxvbmcgd2l0aCB0aGUgdm1zLiBIb3cgZG8gSSByZW1vdmUgdGhlIFZN J3MgYW5kIHN0b3JhZ2UgZG9tYWlucyB0aGF0IHdheSBJIGNhbiByZWNyZWF0ZSB0aGVtPwoKVGhh bmtzCgpTZW50IGZyb20gUHJvdG9uTWFpbCBtb2JpbGU= --b1_f894a230c95068ff2d09e33adb4dda21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGJyPktpbmRhIHBsZWFzZWQgd2l0aCB0aGUgd2F5IHRoZSByZXN0b3JlIHdlbnQuICBTdWNrcyB0 aGF0IG15IGJhY2t1cHMgd2VyZW4ndCB3b3JraW5nIGxpa2UgSSB0aG91Z2h0Ljxicj48YnI+SSBk aWQgYW4gZW5naW5lIGJhY2t1cCwgY29tcGxldGUgYWJvdXQgYSBkYXkgYmVmb3JlIEkgbG9zdCBk YXRhLjxicj48YnI+QXJlIHRoZXNlIHRoZSBiYXNpYyBzdGVwczo8YnI+PGJyPjEuIFJlaW5zdGFs bCBDZW50T1MgKHdoYXRldmVyIE9TIHlvdSB1c2VkKTxicj4yLiBVcGRhdGUgYWxsIHBhY2thZ2Vz PGJyPjMuIEluc3RhbGwgb3ZpcnQ8YnI+NC4gRW5naW5lIHJlc3RvcmUgPGJyPjUuIEVuZ2luZSBz ZXR1cDxicj48YnI+VGhhdCBnZXRzIHlvdSBhIGJhc2ljIG92aXJ0IHNlcnZlciB3aXRoIHlvdXIg cHJldmlvdXMgc2V0dGluZ3MuPGJyPjxicj5NeSBwcm9ibGVtOjxicj5TdG9yYWdlIGRvbWFpbnMg YXJlIGdvbmUgYWxvbmcgd2l0aCB0aGUgdm1zLiAgSG93IGRvIEkgcmVtb3ZlIHRoZSBWTSdzIGFu ZCBzdG9yYWdlIGRvbWFpbnMgdGhhdCB3YXkgSSBjYW4gcmVjcmVhdGUgdGhlbT88YnI+PGJyPlRo YW5rczxicj48YnI+U2VudCBmcm9tIFByb3Rvbk1haWwgbW9iaWxlPGJyPjxicj48YnI+ --b1_f894a230c95068ff2d09e33adb4dda21--

1 0

Bad hd? or?
by Alex Bartonek 27 Jan '18

27 Jan '18

This is a multi-part message in MIME format. --b1_10225c10029a5ba476cd62c721026aac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSdtIHN0dW1wZWQuCgpJIHBvd2VyY3ljbGVkIG15IHNlcnZlciBvbiBhY2NpZGVudCBhbmQgSSBj YW5ub3QgbW91bnQgbXkgZGF0YSBkcml2ZS4gIEkgd2FzIGdldHRpbmcgYnVmZmVyIGkvbyBlcnJv cnMgYnV0IGZpbmFsbHkgd2FzIGFibGUgdG8gYm9vdCB1cCBieSBkaXNhYmxpbmcgYXV0b21vdW50 IGluIGZzdGFiLgoKSSBjYW5ub3QgbW91bnQgbXkgZXh0NCBkcml2ZS4gICBBbnl0aGluZyBlbHNl IEkgY2FuIGNoZWNrPwoKcm9vdEBibGl0emVuIHRdIyBkbWVzZ3xncmVwIHNkYgpbICAgIDEuNzE0 MTM4XSBzZCAyOjE6MDoxOiBbc2RiXSA1ODU4NzE5NjQgNTEyLWJ5dGUgbG9naWNhbCBibG9ja3M6 ICgyOTkgR0IvMjc5IEdpQikKWyAgICAxLjcxNDI3NV0gc2QgMjoxOjA6MTogW3NkYl0gV3JpdGUg UHJvdGVjdCBpcyBvZmYKWyAgICAxLjcxNDI3OV0gc2QgMjoxOjA6MTogW3NkYl0gTW9kZSBTZW5z ZTogNmIgMDAgMDAgMDgKWyAgICAxLjcxNDYyM10gc2QgMjoxOjA6MTogW3NkYl0gV3JpdGUgY2Fj aGU6IGRpc2FibGVkLCByZWFkIGNhY2hlOiBlbmFibGVkLCBkb2Vzbid0IHN1cHBvcnQgRFBPIG9y IEZVQQpbICAgIDEuNzUwNDAwXSAgc2RiOiBzZGIxClsgICAgMS43NTA5NjldIHNkIDI6MTowOjE6 IFtzZGJdIEF0dGFjaGVkIFNDU0kgZGlzawpbICA0NDMuOTM2Nzk0XSAgc2RiOiBzZGIxClsgIDQ1 Mi41MTk0ODJdICBzZGI6IHNkYjEKCnNkYiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDg6MTYgICAwIDI3OS40RyAgMCBkaXNrCuKUnOKUgHNkYjEgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA4OjE3ICAgMCAyNzkuNEcgIDAgcGFydArilJTilIAzNjAwNTA4 YjEwMDEwMzQzMTMyMjAyMDIwMjAyMDAwMGEgICAgIDI1MzozICAgIDAgMjc5LjRHICAwIG1wYXRo CiAg4pSU4pSAMzYwMDUwOGIxMDAxMDM0MzEzMjIwMjAyMDIwMjAwMDBhMSAgMjUzOjQgICAgMCAy NzkuNEcgIDAgcGFydAoKW3Jvb3RAYmxpdHplbiB0XSMgbW91bnQgL2Rldi9zZGIxIC9tbnQvb3Zp cnRfZGF0YS8KbW91bnQ6IC9kZXYvc2RiMSBpcyBhbHJlYWR5IG1vdW50ZWQgb3IgL21udC9vdmly dF9kYXRhIGJ1c3kKW3Jvb3RAYmxpdHplbiB0XSMgbW91bnR8Z3JlcCBzZGIKW3Jvb3RAYmxpdHpl biB0XSMKClRoYW5rcyBpbiBhZHZhbmNlLg== --b1_10225c10029a5ba476cd62c721026aac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JJ20gc3R1bXBlZC48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHBvd2VyY3lj bGVkIG15IHNlcnZlciBvbiBhY2NpZGVudCBhbmQgSSBjYW5ub3QgbW91bnQgbXkgZGF0YSBkcml2 ZS4mbmJzcDsgSSB3YXMgZ2V0dGluZyBidWZmZXIgaS9vIGVycm9ycyBidXQgZmluYWxseSB3YXMg YWJsZSB0byBib290IHVwIGJ5IGRpc2FibGluZyBhdXRvbW91bnQgaW4gZnN0YWIuPGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBjYW5ub3QgbW91bnQgbXkgZXh0NCBkcml2ZS4mbmJzcDsm bmJzcDsgQW55dGhpbmcgZWxzZSBJIGNhbiBjaGVjaz88YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5yb290QGJsaXR6ZW4gdF0jIGRtZXNnfGdyZXAgc2RiPGJyPjwvZGl2PjxkaXY+WyZuYnNw OyZuYnNwOyZuYnNwOyAxLjcxNDEzOF0gc2QgMjoxOjA6MTogW3NkYl0gNTg1ODcxOTY0IDUxMi1i eXRlIGxvZ2ljYWwgYmxvY2tzOiAoMjk5IEdCLzI3OSBHaUIpPGJyPjwvZGl2PjxkaXY+WyZuYnNw OyZuYnNwOyZuYnNwOyAxLjcxNDI3NV0gc2QgMjoxOjA6MTogW3NkYl0gV3JpdGUgUHJvdGVjdCBp cyBvZmY8YnI+PC9kaXY+PGRpdj5bJm5ic3A7Jm5ic3A7Jm5ic3A7IDEuNzE0Mjc5XSBzZCAyOjE6 MDoxOiBbc2RiXSBNb2RlIFNlbnNlOiA2YiAwMCAwMCAwODxicj48L2Rpdj48ZGl2PlsmbmJzcDsm bmJzcDsmbmJzcDsgMS43MTQ2MjNdIHNkIDI6MTowOjE6IFtzZGJdIFdyaXRlIGNhY2hlOiBkaXNh YmxlZCwgcmVhZCBjYWNoZTogZW5hYmxlZCwgZG9lc24ndCBzdXBwb3J0IERQTyBvciBGVUE8YnI+ PC9kaXY+PGRpdj5bJm5ic3A7Jm5ic3A7Jm5ic3A7IDEuNzUwNDAwXSZuYnNwOyBzZGI6IHNkYjE8 YnI+PC9kaXY+PGRpdj5bJm5ic3A7Jm5ic3A7Jm5ic3A7IDEuNzUwOTY5XSBzZCAyOjE6MDoxOiBb c2RiXSBBdHRhY2hlZCBTQ1NJIGRpc2s8YnI+PC9kaXY+PGRpdj5bJm5ic3A7IDQ0My45MzY3OTRd Jm5ic3A7IHNkYjogc2RiMTxicj48L2Rpdj48ZGl2PlsmbmJzcDsgNDUyLjUxOTQ4Ml0mbmJzcDsg c2RiOiBzZGIxPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+c2RiJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDg6MTYmbmJzcDsmbmJz cDsgMCAyNzkuNEcmbmJzcDsgMCBkaXNrJm5ic3A7PGJyPjwvZGl2PjxkaXY+4pSc4pSAc2RiMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4OjE3Jm5ic3A7Jm5ic3A7IDAg Mjc5LjRHJm5ic3A7IDAgcGFydCZuYnNwOzxicj48L2Rpdj48ZGl2PuKUlOKUgDM2MDA1MDhiMTAw MTAzNDMxMzIyMDIwMjAyMDIwMDAwYSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyNTM6MyZuYnNw OyZuYnNwOyZuYnNwOyAwIDI3OS40RyZuYnNwOyAwIG1wYXRoPGJyPjwvZGl2PjxkaXY+Jm5ic3A7 IOKUlOKUgDM2MDA1MDhiMTAwMTAzNDMxMzIyMDIwMjAyMDIwMDAwYTEmbmJzcDsgMjUzOjQmbmJz cDsmbmJzcDsmbmJzcDsgMCAyNzkuNEcmbmJzcDsgMCBwYXJ0Jm5ic3A7PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+W3Jvb3RAYmxpdHplbiB0XSMgbW91bnQgL2Rldi9zZGIxIC9tbnQvb3Zp cnRfZGF0YS88YnI+PC9kaXY+PGRpdj5tb3VudDogL2Rldi9zZGIxIGlzIGFscmVhZHkgbW91bnRl ZCBvciAvbW50L292aXJ0X2RhdGEgYnVzeTxicj48L2Rpdj48ZGl2Pltyb290QGJsaXR6ZW4gdF0j IG1vdW50fGdyZXAgc2RiPGJyPjwvZGl2PjxkaXY+W3Jvb3RAYmxpdHplbiB0XSM8YnI+PC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+VGhhbmtzIGluIGFkdmFuY2UuPGJyPjxkaXY+ PGJyPjwvZGl2Pg== --b1_10225c10029a5ba476cd62c721026aac--

2 2

Has meltdown impacted glusterFS performance?
by Jayme 27 Jan '18

27 Jan '18

I've been considering hyperconverged oVirt setup VS san/nas but I wonder how the meltdown patches have affected glusterFS performance since it is CPU intensive. Has anyone who has applied recent kernel updates noticed a performance drop with glusterFS?

4 3

oVirt 4.1.9 and Spectre-Meltdown checks
by Gianluca Cecchi 27 Jan '18

27 Jan '18

Hello, nice to see integration of Spectre-Meltdown info in 4.1.9, both for guests and hosts, as detailed in release notes: I have upgraded my CentOS 7.4 engine VM (outside of oVirt cluster) and one oVirt host to 4.1.9. Now in General -> Software subtab of the host I see: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 3.10.0 - 693.17.1.el7.x86_64 Kernel Features: IBRS: 0, PTI: 1, IBPB: 0 Am I supposed to manually set any particular value? If I run version 0.32 (updated yesterday) of spectre-meltdown-checker.sh I got this on my Dell M610 blade with Version: 6.4.0 Release Date: 07/18/2013 [root@ov200 ~]# /home/g.cecchi/spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 CPU is Intel(R) Xeon(R) CPU X5690 @ 3.47GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (107 opcodes found, which is >= 70, heuristic to be improved when official patches become available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO (echo 1 > /sys/kernel/debug/x86/ibrs_enabled) * IBRS enabled for User space: NO (echo 2 > /sys/kernel/debug/x86/ibrs_enabled) * IBPB enabled: NO (echo 1 > /sys/kernel/debug/x86/ibpb_enabled) * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO * Retpoline enabled: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer [root@ov200 ~]# So it seems I'm still vulnerable only to Variant 2, but kernel seems ok: * Kernel is compiled with IBRS/IBPB support: YES while bios not, correct? Is RH EL / CentOS expected to follow the retpoline option too, to mitigate Variant 2, as done by Fedora for example? Eg on my just updated Fedora 27 laptop I get now: [g.cecchi@ope46 spectre_meltdown]$ sudo ./spectre-meltdown-checker.sh [sudo] password for g.cecchi: Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Retpoline enabled: YES > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer [g.cecchi@ope46 spectre_meltdown]$ BTW: I updated some days ago this laptop from F26 to F27 and I remember Variant 1 was fixed in F26, while now I see it as vulnerable..... I'm going to check with Fedora mailing list about this... Another question: what should I see for a VM instead related to meltdown/spectre? Currently in "Guest CPU Type" in General subtab of the VM I only see "Westmere".. Should I also see anythin aout IBRS, etc...? Thanks, Gianluca

3 3

Ovirt 4.2 - Help adding VM to numa node via python SDK
by Don Dupuis 27 Jan '18

27 Jan '18

I am able to create a vm using the sdk with nic and disks using the python sdk, but having trouble understanding how to assign it to virtual numanode onto the physical numanode via python sdk. Any help in this area would be greatly appreciated Thanks Don

2 2

Windows 2012R2 virtio-scsi abysmal disk write performance
by Jean-Francois Courteau 26 Jan '18

26 Jan '18

Hello there, I just installed oVirt on brend new machines. The engine on a Virtualbox VM in my current infrastructure, and a single dedicated CentOS host attached to the engine. Here are my host specs (srvhc02): CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz (4C 8T) Mem: 32GB DDR3 Disks: - 2 x WD Black 2TB (RAID1) where the CentOS is installed - 4 x WD Gold 4TB (RAID10) dedicated for a storage domain (/dev/md0, ext4, mounted in /storage and exported with NFS with default settings) NIC: Intel 4 ports Gigabit. One port for VMs, one port for everything else. 2 unused ports. OS: Freshly installed CentOS 7 minimal latest (yum updated) oVirt deployed from the Engine using root account with a password Here are my Engine specs (srvvmmgmt): Virtualbox guest VM in another physical computer just for test purposes. CPU: 2vCPU Mem: 8GB Disk: 50GB VDI on a RAID10 array NIC: Virtual Intel Pro 1000 (Bridged over a physical Intel 4 ports Gigabit) OS: Freshly installed CentOS 7 minimal latest (yum updated) oVirt Engine 4.2 deployed from the repo, yum updated yesterday Storage domain: NFS - srvhc02:/storage ISO domain: NFS - srvhc02:/iso Physical network is Gigabit on Cisco switches, no VLAN tagging. My (barely usable) Windows 2012R2 guest (srvweb03) CPU: 2vCPU Mem: 8GB Disk1: 100GB on the storage domain Disk 2: 200GB on the storage domain (this is the one I was changing the controller for testing purposes) NIC: virtio bridged over the VM port I have tried every possible combination of drive controller (virtio-scsi, virtio, IDE), virtio drivers (stable and latest from the Fedora website, others found in sometimes obsucre places), and the disk write performances are simply unacceptable. Of course I had a reboot between each NIC driver update and driver change. I have compared with a Virtualbox installed on the same host after I cleaned up oVirt, and the host is absolutely not problematic. Here is the compare: oVirt Virtualbox ----------------------------------------------- SEQUENTIAL READ 3000MB/s 406MB/s (this is ridiculously high, oVirt probably reading from RAM) SEQUENTIAL WRITE 31MB/s 164MB/s 4k RANDOM READ 400MB/s 7.18MB/s (this is ridiculously high, oVirt probably reading from RAM) 4k RANDOM WRITE 0.3MB/s(80IOPS) 3MB/s (747IOPS) These performances are using the virtio-scsi in oVirt (any version, none gave me better performance), and the SATA driver in Virtualbox. Needless to say that this is frustrating. I have tried with oVirt virtio-blk (virtio in the interface) driver, it gave me a 10-15% improvement, but never up to the level I could expect from an enterprise grade solution. I also tried IDE. I could not even write at 10kbps on it. I had approx 10IOPM (yes, IO per minute!) with it. Is there something I am missing? -- https://nexcess.ca JEAN-FRANÇOIS COURTEAU _Président, Directeur Général_ C: jean-francois.courteau(a)nexcess.ca T: +1 (418) 558-5169 -------------------------

1 1

Storage Hardware for Hyperconverged oVirt: Gluster best practice
by ovirt＠fateknollogee.com 26 Jan '18

26 Jan '18

oVirt + Gluster (hyperconverged) RAID question: I have 3 nodes of SuperMicro hardware, each node has 1x SATADOM (boot drive for o/s install) and 6x 1TB SSD (to be used for Gluster). For the SSDs, is hardware or software RAID preferred or do I use an HBA? The RedHat docs seem to suggest hardware RAID, others on the forum say HBA or software RAID. What are other folks using?

4 6

live migrating vm from 4.1.7 to 4.1.9 failed because of vmx flag
by Gianluca Cecchi 26 Jan '18

26 Jan '18

Hello, I'm trying to update an environment from 4.1.7 to 4.1.9. Already migrated the engine (separate) and one host. This host is now running a pair of VMs, that was powered off and then powered on it via "run once" feature. Now I'm trying to evacuate VMs from other hosts and get all to 4.1.9. But I have tried with couple of VMs and I'm always getting error events of type: Jan 26, 2018 12:40:00 PM Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). In engine.log 2018-01-26 12:39:48,267+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (default task-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Lock Acquired to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:39:48,350+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] Running command: MigrateVmToServerCommand internal: false. Entities affected : ID: 4f6ecae2-7d71-47c9-af23-2b3e49bc08fc Type: VMAction group MIGRATE_VM with role type USER 2018-01-26 12:39:48,424+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateVDSCommand( MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 7013a234 2018-01-26 12:39:48,425+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] START, MigrateBrokerVDSCommand(HostName = ov301, MigrateVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', srcHost='ov301.mydomain', dstVdsId='d16e723c-b44c-4c1c-be76-c67911e47ccd', dstHost='ov200.mydomain:54321', migrationMethod='ONLINE', tunnelMigration='false', migrationDowntime='0', autoConverge='true', migrateCompressed='false', consoleAddress='null', maxBandwidth='500', enableGuestEvents='true', maxIncomingMigrations='2', maxOutgoingMigrations='2', convergenceSchedule='[init=[{name=setDowntime, params=[100]}], stalling=[{limit=1, action={name=setDowntime, params=[150]}}, {limit=2, action={name=setDowntime, params=[200]}}, {limit=3, action={name=setDowntime, params=[300]}}, {limit=4, action={name=setDowntime, params=[400]}}, {limit=6, action={name=setDowntime, params=[500]}}, {limit=-1, action={name=abort, params=[]}}]]'}), log id: 25d9c017 2018-01-26 12:39:49,620+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateBrokerVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateBrokerVDSCommand, log id: 25d9c017 2018-01-26 12:39:49,622+01 INFO [org.ovirt.engine.core.vdsbroker.MigrateVDSCommand] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] FINISH, MigrateVDSCommand, return: MigratingFrom, log id: 7013a234 2018-01-26 12:39:49,627+01 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-8) [72ccfbb1-735a-4411-a990-cdb2c081e391] EVENT_ID: VM_MIGRATION_START(62), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration started (VM: dbatest3, Source: ov301, Destination: ov200, User: admin@internal-authz). 2018-01-26 12:39:50,782+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [f2fc61e] Fetched 3 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' 2018-01-26 12:39:50,783+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'MigratingTo' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:39:50,784+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler1) [f2fc61e] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' is migrating to VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) ignoring it in the refresh until migration is done 2018-01-26 12:39:51,968+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' was reported as Down on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) 2018-01-26 12:39:51,969+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] START, DestroyVDSCommand(HostName = ov200, DestroyVmVDSCommandParameters:{runAsync='true', hostId='d16e723c-b44c-4c1c-be76-c67911e47ccd', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc', force='false', secondsToWait='0', gracefully='false', reason='', ignoreNoVm='true'}), log id: 3b49afe3 2018-01-26 12:39:52,236+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] Failed to destroy VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc' because VM does not exist, ignoring 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (ForkJoinPool-1-worker-15) [] FINISH, DestroyVDSCommand, log id: 3b49afe3 2018-01-26 12:39:52,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-15) [] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) was unexpectedly detected as 'Down' on VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd'(ov200) (expected on '8ef1ce6f-4e38-486c-b3a4-58235f1f1d06') 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) moved from 'MigratingFrom' --> 'Up' 2018-01-26 12:40:00,237+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (DefaultQuartzScheduler3) [5c4b079b] Adding VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'(dbatest3) to re-run list 2018-01-26 12:40:00,245+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmsMonitoring] (DefaultQuartzScheduler3) [5c4b079b] Rerun VM '4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'. Called from VDS 'ov301' 2018-01-26 12:40:00,287+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] START, MigrateStatusVDSCommand(HostName = ov301, MigrateStatusVDSCommandParameters:{runAsync='true', hostId='8ef1ce6f-4e38-486c-b3a4-58235f1f1d06', vmId='4f6ecae2-7d71-47c9-af23-2b3e49bc08fc'}), log id: 65677081 2018-01-26 12:40:00,818+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.MigrateStatusVDSCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] FINISH, MigrateStatusVDSCommand, log id: 65677081 2018-01-26 12:40:00,823+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] EVENT_ID: VM_MIGRATION_TO_SERVER_FAILED(120), Correlation ID: 72ccfbb1-735a-4411-a990-cdb2c081e391, Job ID: b2f39d2c-87f1-480c-b4c7-b8ab09d09318, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: Migration failed (VM: dbatest3, Source: ov301, Destination: ov200). 2018-01-26 12:40:00,825+01 INFO [org.ovirt.engine.core.bll.MigrateVmToServerCommand] (org.ovirt.thread.pool-6-thread-15) [5c4b079b] Lock freed to object 'EngineLock:{exclusiveLocks='[4f6ecae2-7d71-47c9-af23-2b3e49bc08fc=VM]', sharedLocks=''}' 2018-01-26 12:40:05,796+01 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmsStatisticsFetcher] (DefaultQuartzScheduler1) [27a52eca] Fetched 2 VMs from VDS 'd16e723c-b44c-4c1c-be76-c67911e47ccd' I don't see errors in vdsm logs of target host, but I do see this in /var/log/messages of target host Jan 26 12:39:51 ov200 libvirtd: 2018-01-26 11:39:51.179+0000: 2588: error : virCPUx86UpdateLive:2726 : operation failed: guest CPU doesn't match specification: missing features: vmx Indeed dbatest3 VM has this "vmx=on" flag in qemu-kvm command line on source host, even if I never configured it explicitly...: [root@ov301 ~]# ps -ef|grep dbatest3 qemu 1455 1 1 2017 ? 08:41:29 /usr/libexec/qemu-kvm -name guest=dbatest3,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-27-dbatest3/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere,vmx=on -m 32768 ... A quite similar VM named dbatest4 running on the already upgraded host doesn't have indeed the flag: [root@ov200 vdsm]# ps -ef|grep dbatest4 qemu 15827 1 3 10:47 ? 00:04:37 /usr/libexec/qemu-kvm -name guest=dbatest4,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-1-dbatest4/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off,dump-guest-core=off -cpu Westmere -m 32768 The 2 VMs has been created from the same template and with the same options if I remember correctly and across the previous versions I could live migrate without problems.... What can have changed? This would be a possible great show stopper, because one has to power off all the VMs if he/she wants to upgrade..... Thanks in advance for any help, Gianluca

1 2

bonding mode-alb
by Demeter Tibor 26 Jan '18

26 Jan '18

--=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear members, I would like to use two switches for make high-availability network connection for my nfs storge. Unfortunately, these switches does not support 802.3.ad lacp, (really I can't stack them) but I've read about mode-alb and mode-tlb bonding modes. I know,these modes are available in ovirt, but how is work that? Also how is safe? Are there for HA or for load balance? I've read some forums, where does not recommended these modes to use in ovirt. What is the truths? I would like to use only for storage-traffic, it will be separated from other network traffic. I have two 10Gbe switches and two 10Gbe ports in my nodes. Thanks in advance, R Tibor --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Dear members,</div><div><br data-mce-bogus= =3D"1"></div><div>I would like to use two switches for make high-availabili= ty network connection for my nfs storge.</div><div>Unfortunately, these swi= tches does not support 802.3.ad lacp, (really I can't stack them)  but= I've read about mode-alb and mode-tlb bonding modes.  <br>I know= ,these modes are available in ovirt, but how is work that? Also how is safe= ? Are there for HA or for load balance? </div><div><br data-mce-bogus= =3D"1"></div><div>I've read some forums, where does not recommended these m= odes to use in ovirt. What is the truths? </div><div>I would like to u= se only for storage-traffic, it will be separated from other network traffi= c. I have two 10Gbe switches and two 10Gbe ports in my nodes. </div><d= iv><br data-mce-bogus=3D"1"></div><div>Thanks in advance, </div><div><= br data-mce-bogus=3D"1"></div><div>R</div><div><br data-mce-bogus=3D"1"></d= iv><div>Tibor</div><div> </div><div><br></div><div data-marker=3D"__SI= G_PRE__"><p style=3D"font-family: 'Times New Roman'; font-size: medium; mar= gin: 0px;"><strong><span style=3D"font-size: medium;"><span style=3D"color:= rgb(45, 103, 176);"></span></span></strong></p><p></p></div></div></body><= /html> --=_a87e03e3-4ae4-4dcb-8739-e4423d90cef2--

5 9

Re: [ovirt-users] oVirt 4.1.9 and Spectre-Meltdown checks
by Arman Khalatyan 26 Jan '18

26 Jan '18

you should download microcode from the intel web page and overwrite the /lib/firmware/intel-ucode or so...please check the readme. Am 26.01.2018 10:50 vorm. schrieb "Gianluca Cecchi" < gianluca.cecchi(a)gmail.com>: Hello, nice to see integration of Spectre-Meltdown info in 4.1.9, both for guests and hosts, as detailed in release notes: I have upgraded my CentOS 7.4 engine VM (outside of oVirt cluster) and one oVirt host to 4.1.9. Now in General -> Software subtab of the host I see: OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: CentOS Linux 7 (Core) Kernel Version: 3.10.0 - 693.17.1.el7.x86_64 Kernel Features: IBRS: 0, PTI: 1, IBPB: 0 Am I supposed to manually set any particular value? If I run version 0.32 (updated yesterday) of spectre-meltdown-checker.sh I got this on my Dell M610 blade with Version: 6.4.0 Release Date: 07/18/2013 [root@ov200 ~]# /home/g.cecchi/spectre-meltdown-checker.sh Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 CPU is Intel(R) Xeon(R) CPU X5690 @ 3.47GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Checking count of LFENCE opcodes in kernel: YES > STATUS: NOT VULNERABLE (107 opcodes found, which is >= 70, heuristic to be improved when official patches become available) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: YES * Currently enabled features * IBRS enabled for Kernel space: NO (echo 1 > /sys/kernel/debug/x86/ibrs_enabled) * IBRS enabled for User space: NO (echo 2 > /sys/kernel/debug/x86/ibrs_enabled) * IBPB enabled: NO (echo 1 > /sys/kernel/debug/x86/ibpb_enabled) * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO * Retpoline enabled: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (PTI mitigates the vulnerability) A false sense of security is worse than no security at all, see --disclaimer [root@ov200 ~]# So it seems I'm still vulnerable only to Variant 2, but kernel seems ok: * Kernel is compiled with IBRS/IBPB support: YES while bios not, correct? Is RH EL / CentOS expected to follow the retpoline option too, to mitigate Variant 2, as done by Fedora for example? Eg on my just updated Fedora 27 laptop I get now: [g.cecchi@ope46 spectre_meltdown]$ sudo ./spectre-meltdown-checker.sh [sudo] password for g.cecchi: Spectre and Meltdown mitigation detection tool v0.32 Checking for vulnerabilities on current system Kernel is Linux 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 x86_64 CPU is Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: NO * CPU indicates IBRS capability: NO * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: NO * CPU indicates IBPB capability: NO * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: NO * CPU indicates STIBP capability: NO * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO * CPU vulnerability to the three speculative execution attacks variants * Vulnerable to Variant 1: YES * Vulnerable to Variant 2: YES * Vulnerable to Variant 3: YES CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Mitigated according to the /sys interface: NO (kernel confirms your system is vulnerable) > STATUS: VULNERABLE (Vulnerable) CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Mitigation 1 * Kernel is compiled with IBRS/IBPB support: NO * Currently enabled features * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * IBPB enabled: NO * Mitigation 2 * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Retpoline enabled: YES > STATUS: NOT VULNERABLE (Mitigation: Full generic retpoline) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Mitigated according to the /sys interface: YES (kernel confirms that the mitigation is active) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: YES * Running as a Xen PV DomU: NO > STATUS: NOT VULNERABLE (Mitigation: PTI) A false sense of security is worse than no security at all, see --disclaimer [g.cecchi@ope46 spectre_meltdown]$ BTW: I updated some days ago this laptop from F26 to F27 and I remember Variant 1 was fixed in F26, while now I see it as vulnerable..... I'm going to check with Fedora mailing list about this... Another question: what should I see for a VM instead related to meltdown/spectre? Currently in "Guest CPU Type" in General subtab of the VM I only see "Westmere".. Should I also see anythin aout IBRS, etc...? Thanks, Gianluca _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Ovirt 4.2, failing to connect to VDSM.
by CRiMSON 25 Jan '18

25 Jan '18

I did a quick upgrade this afternoon on a dev machine. Jan 25 11:57:07 Updated: glusterfs-libs-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-client-xlators-3.12.5-2.el7.x86_64 Jan 25 11:57:08 Updated: glusterfs-3.12.5-2.el7.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-libs-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:09 Updated: kernel-ml-tools-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:10 Updated: glusterfs-api-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-fuse-3.12.5-2.el7.x86_64 Jan 25 11:57:10 Updated: glusterfs-cli-3.12.5-2.el7.x86_64 Jan 25 11:57:11 Updated: python-perf-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:37 Installed: kernel-ml-devel-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:39 Updated: kernel-ml-headers-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Installed: kernel-ml-4.14.15-1.el7.elrepo.x86_64 Jan 25 11:57:52 Updated: rubygem-fluent-plugin-viaq_data_model-0.0.13-1.el7.noarch This is all that was upgraded. But now my storage domains are failing to come up and the host keeps saying it's getting a connection refused. It's all on 1 host. In mom.log I see. 2018-01-25 17:10:49,929 - mom - INFO - MOM starting 2018-01-25 17:10:49,955 - mom.HostMonitor - INFO - Host Monitor starting 2018-01-25 17:10:49,955 - mom - INFO - hypervisor interface vdsmjsonrpcbulk 2018-01-25 17:10:50,013 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 111] Connection refused 2018-01-25 17:10:50,013 - mom - ERROR - Failed to initialize MOM threads Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 29, in run hypervisor_iface = self.get_hypervisor_interface() File "/usr/lib/python2.7/site-packages/mom/__init__.py", line 217, in get_hypervisor_interface return module.instance(self.config) File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 47, in instance return JsonRpcVdsmBulkInterface() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcbulkInterface.py", line 29, in __init__ super(JsonRpcVdsmBulkInterface, self).__init__() File "/usr/lib/python2.7/site-packages/mom/HypervisorInterfaces/vdsmjsonrpcInterface.py", line 43, in __init__ .orRaise(RuntimeError, 'No connection to VDSM.') File "/usr/lib/python2.7/site-packages/mom/optional.py", line 28, in orRaise raise exception(*args, **kwargs) RuntimeError: No connection to VDSM. [root@lv426 vdsm]# My vdsm.log is 0 byes (nothing being logged?) In my engine.log I'm seeing: 2018-01-25 17:12:11,027-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Command 'GetCapabilitiesVDSCommand(HostName = lv426, VdsIdAndVdsVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd', vds='Host[lv426,a645af84-3da1-45ed-bab5-2af66b5924dd]'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:11,028-05 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-99) [] Failure to refresh host 'lv426' runtime info: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,517-05 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to lv426.dasgeekhaus.org/127.0.0.1 2018-01-25 17:12:13,517-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetAllVmStatsVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Command 'GetAllVmStatsVDSCommand(HostName = lv426, VdsIdVDSCommandParametersBase:{hostId='a645af84-3da1-45ed-bab5-2af66b5924dd'})' execution failed: java.net.ConnectException: Connection refused 2018-01-25 17:12:13,518-05 INFO [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] (EE-ManagedThreadFactory-engineScheduled-Thread-25) [] Failed to fetch vms info for host 'lv426' - skipping VMs monitoring. All of my network interfaces do come up ok, iptables is turned off so it's not getting in the way. I'm at a complete loss right now as to what to look at.

1 1

Imageio-Proxy: Failed to verify proxy ticket: Ticket life time expired
by Gabriel Stein 25 Jan '18

25 Jan '18

Hi, oVirt Version: 4.2 Imageio-Proxy: ovirt-imageio-proxy-1.0.0-0 vdsm: vdsm-4.20.9.3-1 I can't upload disks with more than 200GB to oVirt(using UI). Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1538814 I would appreciate any help. Thank you Best Regards Gabriel

1 0

Ovirt 4.2 - Help adding VM to numa node via python SDK
by Don Dupuis 25 Jan '18

25 Jan '18

I am able to create a vm using the sdk with nic and disks using the python sdk, but having trouble understanding how to assign it to virtual numanode onto the physical numanode via python sdk. Any help in this area would be greatly appreciated Thanks Don

2 2

[ANN] oVirt 4.2.1 Third Release Candidate is now available
by Lev Veyde 25 Jan '18

25 Jan '18

The oVirt Project is pleased to announce the availability of the oVirt 4.2.1 Third Release Candidate, as of January 25th, 2017 This update is a release candidate of the first in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. This release is available now for: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.4 or later * CentOS Linux (or similar) 7.4 or later * oVirt Node 4.2 See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Node will be available soon [2] Additional Resources: * Read more about the oVirt 4.2.1 release highlights: http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.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] http://www.ovirt.org/release/4. <http://www.ovirt.org/release/4.2.1/>2 <http://www.ovirt.org/release/4.2.1/>. <http://www.ovirt.org/release/4.2.1/> 1 <http://www.ovirt.org/release/4.2.1/>/ <http://www.ovirt.org/release/4.2.1/> [2] http://resources.ovirt.org/pub/ovirt-4. <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>2-pre <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/>/iso/ <http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/> -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

4.2 Cloud-init & VM Portal question
by Vrgotic, Marko 25 Jan '18

25 Jan '18

--_000_17440597BD9049178A1771E526A26F32activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCwNCg0KSSBoYXZlIGNyZWF0ZWQgYSB0ZW1wbGF0ZSB3aGljaCBpbmNsdWRlcyAg Y2xvdWQtaW5pdCB3aXRoIHVzZXIgLyB0aW1lem9uZSAvIHNzaCBrZXkgLyBuZXR3b3JrIGRlZmlu ZWQuIEludGVudGlvbiBpcyB0byBhbGxvdyByZWd1bGFyIHVzZXJzICYgVk0gUG9ydGFsIHRvIGNy ZWF0ZSBWTXMgdXNpbmcgdGhpcyB0ZW1wbGF0ZS4NCg0KUXVlc3Rpb24gdGhhdCBJIGhhdmUgaXM7 IGlmIHBvc3NpYmxlLCBob3cgY2FuIEkgYXJyYW5nZSB0aGF0IHZtIG5hbWUgSSBmaWxsIGluLCBp cyBwYXNzZWQgdG8gY2xvdWQtaW5pdCBhcyB2bSBob3N0bmFtZSAoYXMgaXQgaXMgZGVmYXVsdCB3 aGVuIGNyZWF0aW5nIFZNIGZyb20gQWRtaW4gUG9ydGFsKT8gSXMgaXQgZXZlbiBwb3NzaWJsZSBh bmQgcGxlYXNlIGlmIHNvLCBwcm92aWRlIHNvbWUgZ3VpZGFuY2UuDQoNCi0tDQpNZXQgdnJpZW5k ZWxpamtlIGdyb2V0IC8gQmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2lu ZWVyL0N1c3RvbWVyIENhcmUNCkFjdGl2ZVZpZGVvDQoNCg== --_000_17440597BD9049178A1771E526A26F32activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2B53B85BE18C0E4DB54AB4EAF1D1E03D(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgb1Zp cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhhdmUgY3Jl YXRlZCBhIHRlbXBsYXRlIHdoaWNoIGluY2x1ZGVzICZuYnNwO2Nsb3VkLWluaXQgd2l0aCB1c2Vy IC8gdGltZXpvbmUgLyBzc2gga2V5IC8gbmV0d29yayBkZWZpbmVkLiBJbnRlbnRpb24gaXMgdG8g YWxsb3cgcmVndWxhciB1c2VycyAmYW1wOyBWTSBQb3J0YWwgdG8gY3JlYXRlIFZNcyB1c2luZyB0 aGlzIHRlbXBsYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ UXVlc3Rpb24gdGhhdCBJIGhhdmUgaXM7IGlmIHBvc3NpYmxlLCBob3cgY2FuIEkgYXJyYW5nZSB0 aGF0IHZtIG5hbWUgSSBmaWxsIGluLCBpcyBwYXNzZWQgdG8gY2xvdWQtaW5pdCBhcyB2bSBob3N0 bmFtZSAoYXMgaXQgaXMgZGVmYXVsdCB3aGVuIGNyZWF0aW5nIFZNIGZyb20gQWRtaW4gUG9ydGFs KT8gSXMgaXQgZXZlbiBwb3NzaWJsZSBhbmQgcGxlYXNlDQogaWYgc28sIHByb3ZpZGUgc29tZSBn dWlkYW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0IiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0Ii Pk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+QWN0aXZlVmlkZW88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_17440597BD9049178A1771E526A26F32activevideocom_--

3 3

what does the metadata param "LEGALITY", "VOLTYPE" and "GEN" means?
by pengyixiang 24 Jan '18

24 Jan '18

------=_Part_119963_1780357530.1516780114893 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 aGVsbG8sIGV2ZXJ5b25lIQogICAgVGhlcmUncyBhIGxpc3Qgc3RvcmFnZSBtZXRhZGF0YSBmb3Jt YXQgaW4gWzFdLCAgd2hhdCBkb2VzIHRoZSAiRkFLRSIgLCAiSU5URVJOQUx8U0hBUkVEfExFQUYi LCAiR0VOIiBtZWFucyBpbiBvdmlydD8gSG93IGRpZCB0aGVzZSB1c2VkPwoKCgoKCgpbMV0KIyBI ZXJlIGlzIHRoZSB3b3JzdCBjYXNlIG1ldGFkYXRhIGZvcm1hdDoKIwojIENUSU1FPTE0NDA5MzUw MzggICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBpbnQodGltZS50aW1lKCkpCiMgREVTQ1JJ UFRJT049ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHRleHR8SlNPTgojIERJU0tU WVBFPTIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBlbnVtCiMgRE9NQUlOPTc1 ZjhhMWJiLTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAjIHV1aWQKIyBGT1JNQVQ9Q09XICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgUkFXfENPVwojIElNQUdFPTc1ZjhhMWJi LTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAgIyB1dWlkCiMgTEVHQUxJVFk9SUxMRUdBTCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAjIElMTEVHQUx8TEVHQUx8RkFLRQojIE1USU1FPTAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBhbHdheXMgMAojIFBPT0xfVVVJ RD0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBhbHdheXMgZW1wdHkKIyBQVVVJ RD03NWY4YTFiYi00NTA0LTQzMTQtOTFjYS1kOTM2NWEzMDY5MmIgICMgdXVpZAojIFNJWkU9MjE0 NzQ4MzY0OCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBzaXplIGluIGJsb2NrcwojIFRZ UEU9UFJFQUxMT0NBVEVEICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBQUkVBTExPQ0FURUR8 VU5LTk9XTnxTUEFSU0UKIyBWT0xUWVBFPUlOVEVSTkFMICAgICAgICAgICAgICAgICAgICAgICAg ICAgICMgSU5URVJOQUx8U0hBUkVEfExFQUYKIyBHRU49OTk5ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICMgaW50CiMgRU9G ------=_Part_119963_1780357530.1516780114893 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+aGVsbG8sIGV2ZXJ5b25lITwvZGl2PjxkaXY+Jm5ic3A7 ICZuYnNwOyBUaGVyZSdzIGEgbGlzdCBzdG9yYWdlIG1ldGFkYXRhIGZvcm1hdCBpbiBbMV0sJm5i c3A7IHdoYXQgZG9lcyB0aGUgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgp OyBmb250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25v JnF1b3Q7OyBmb250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+RkFLRTwv c3Bhbj4iICwgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyBmb250LXN0 eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25vJnF1b3Q7OyBm b250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+SU5URVJOQUx8U0hBUkVE fExFQUY8L3NwYW4+IiwgIjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyOCwgMTI4LCAxMjgpOyBm b250LXN0eWxlOiBpdGFsaWM7IGZvbnQtZmFtaWx5OiAmcXVvdDtEZWphVnUgU2FucyBNb25vJnF1 b3Q7OyBmb250LXNpemU6IDExLjNwdDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+R0VOPC9zcGFu PiIgbWVhbnMgaW4gb3ZpcnQ/IEhvdyBkaWQgdGhlc2UgdXNlZD88L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlsxXTwvZGl2PjxkaXY+PHByZSBz dHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0RlamFWdSBTYW5zIE1vbm8mcXVvdDs7IGZvbnQtc2l6 ZTogMTEuM3B0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7 Ij4jIEhlcmUgaXMgdGhlIHdvcnN0IGNhc2UgbWV0YWRhdGEgZm9ybWF0Ojxicj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jPGJyPjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgQ1RJTUU9MTQ0 MDkzNTAzOCAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGludCh0aW1lLnRpbWUoKSk8YnI+ PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBE RVNDUklQVElPTj0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgdGV4dHxKU09OPGJy Pjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMg RElTS1RZUEU9MiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGVudW08YnI+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBET01B SU49NzVmOGExYmItNDUwNC00MzE0LTkxY2EtZDkzNjVhMzA2OTJiICMgdXVpZDxicj48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jIEZPUk1BVD1D T1cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBSQVd8Q09XPGJyPjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgSU1BR0U9NzVm OGExYmItNDUwNC00MzE0LTkxY2EtZDkzNjVhMzA2OTJiICAjIHV1aWQ8YnI+PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBMRUdBTElUWT1JTExF R0FMICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgSUxMRUdBTHxMRUdBTHxGQUtFPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgTVRJ TUU9MCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGFsd2F5cyAwPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgUE9P TF9VVUlEPSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIGFsd2F5cyBlbXB0eTxi cj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4j IFBVVUlEPTc1ZjhhMWJiLTQ1MDQtNDMxNC05MWNhLWQ5MzY1YTMwNjkyYiAgIyB1dWlkPGJyPjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsiPiMgU0la RT0yMTQ3NDgzNjQ4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAjIHNpemUgaW4gYmxvY2tz PGJyPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzgwODA4MDtmb250LXN0eWxlOml0YWxpYzsi PiMgVFlQRT1QUkVBTExPQ0FURUQgICAgICAgICAgICAgICAgICAgICAgICAgICAjIFBSRUFMTE9D QVRFRHxVTktOT1dOfFNQQVJTRTxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4MDgwODA7 Zm9udC1zdHlsZTppdGFsaWM7Ij4jIFZPTFRZUEU9SU5URVJOQUwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIyBJTlRFUk5BTHxTSEFSRUR8TEVBRjxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM4MDgwODA7Zm9udC1zdHlsZTppdGFsaWM7Ij4jIEdFTj05OTkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIyBpbnQ8YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODA4MDgwO2ZvbnQtc3R5bGU6aXRhbGljOyI+IyBFT0Y8L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+ PGJyPjxicj48c3BhbiB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_119963_1780357530.1516780114893--

1 0

4.2 VM Portal -Create- VM section issue
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_97322B671B9447BB876A2645B13AE31Eactivevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCwNCg0KQWZ0ZXIgc2V0dGluZyBhbGwgcGFyYW1ldGVycyBmb3IgbmV3IFZNIGFu ZCBjbGlja2luZyBvbiDigJxDcmVhdGXigJ0gYnV0dG9uLCBubyBwcm9ncmVzcyBzdGF0dXMgb3Ig dGhhdCBhY3Rpb24gaXMgYWNjZXB0ZWQgaXMgc2VlbiBmcm9tIHdlYnVpLg0KSW4gYWRkaXRpb24s IHdoZW4gY2xvc2luZyB0aGUgYWRkIFZNIHNlY3Rpb24sIEkgYW0gYXNrZWQgaWYgSSBhbSBzdXJl LCBkdWUgdG8gY2hhbmdlcyBtYWRlLg0KDQpJcyB0aGlzIGV4cGVjdGVkIGJlaGF2aW91cj8gQ2Fu IHNvbWV0aGluZyBiZSBkb25lIGFib3V0Pw0KDQpLaW5kbHkgYXdhaXRpbmcgeW91ciByZXBseS4N Cg0KLS0NCk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsDQpNYXJrbyBWcmdv dGljDQpTeXN0ZW0gRW5naW5lZXIvQ3VzdG9tZXIgQ2FyZQ0KQWN0aXZlVmlkZW8NCg0K --_000_97322B671B9447BB876A2645B13AE31Eactivevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6F9AFF1E18424844A8C9C9F7EA036C56(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIG9WaXJ0LDwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIHNldHRpbmcg YWxsIHBhcmFtZXRlcnMgZm9yIG5ldyBWTSBhbmQgY2xpY2tpbmcgb24g4oCcQ3JlYXRl4oCdIGJ1 dHRvbiwgbm8gcHJvZ3Jlc3Mgc3RhdHVzIG9yIHRoYXQgYWN0aW9uIGlzIGFjY2VwdGVkIGlzIHNl ZW4gZnJvbSB3ZWJ1aS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiwgd2hl biBjbG9zaW5nIHRoZSBhZGQgVk0gc2VjdGlvbiwgSSBhbSBhc2tlZCBpZiBJIGFtIHN1cmUsIGR1 ZSB0byBjaGFuZ2VzIG1hZGUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyBleHBlY3RlZCBiZWhhdmlvdXI/IENhbiBzb21l dGhpbmcgYmUgZG9uZSBhYm91dD88L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kbHkgYXdhaXRpbmcgeW91ciByZXBseS48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJl Z2FyZHMsPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1hcmtv IFZyZ290aWM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlN5c3RlbSBFbmdpbmVlci9DdXN0b21lciBDYXJlPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BY3RpdmVWaWRlbzwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_97322B671B9447BB876A2645B13AE31Eactivevideocom_--

1 0

4.2 Cloud-init & VM Portal question
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_A6FDF329CA4E4BD18E0BD2486DACBF13activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCwNCg0KSSBoYXZlIGNyZWF0ZWQgYSB0ZW1wbGF0ZSB3aGljaCBpbmNsdWRlcyBj bG91ZC1pbml0IHdpdGggdXNlciAvIHRpbWV6b25lIC8gc3NoX2tleSAvIG5ldHdvcmsgZGVmaW5l ZC4gSW50ZW50aW9uIGlzIHRvIGFsbG93IHJlZ3VsYXIgdXNlcnMgJiBWTSBQb3J0YWwgdG8gY3Jl YXRlIFZNcyB1c2luZyB0aGlzIHRlbXBsYXRlLg0KDQpRdWVzdGlvbiB0aGF0IEkgaGF2ZSBpczsg aWYgcG9zc2libGUsIGhvdyBjYW4gSSBhcnJhbmdlIHRoYXQgdm0gbmFtZSBJIGZpbGwgaW4sIGlz IHBhc3NlZCB0byBjbG91ZC1pbml0IGFzIHZtIGhvc3RuYW1lIChhcyBpdCBpcyBkZWZhdWx0IHdo ZW4gY3JlYXRpbmcgVk0gZnJvbSBBZG1pbiBQb3J0YWwpPyBJcyBpdCBldmVuIHBvc3NpYmxlIGFu ZCBwbGVhc2UgaWYgc28sIHByb3ZpZGUgc29tZSBndWlkYW5jZT8NCg0KLS0NCk1ldCB2cmllbmRl bGlqa2UgZ3JvZXQvIEJlc3QgcmVnYXJkcywNCk1hcmtvIFZyZ290aWMNClN5c3RlbSBFbmdpbmVl ci9DdXN0b21lciBDYXJlDQpBY3RpdmVWaWRlbw0KDQo= --_000_A6FDF329CA4E4BD18E0BD2486DACBF13activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <DAE216C23161344293837618AF762273(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglt c28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRl YWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIG9WaXJ0LDwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBjcmVhdGVk IGEgdGVtcGxhdGUgd2hpY2ggaW5jbHVkZXMgY2xvdWQtaW5pdCB3aXRoIHVzZXIgLyB0aW1lem9u ZSAvIHNzaF9rZXkgLyBuZXR3b3JrIGRlZmluZWQuIEludGVudGlvbiBpcyB0byBhbGxvdyByZWd1 bGFyIHVzZXJzICZhbXA7IFZNIFBvcnRhbCB0byBjcmVhdGUgVk1zIHVzaW5nIHRoaXMgdGVtcGxh dGUuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UXVlc3Rpb24gdGhhdCBJIGhhdmUgaXM7IGlmIHBvc3NpYmxlLCBob3cgY2FuIEkgYXJy YW5nZSB0aGF0IHZtIG5hbWUgSSBmaWxsIGluLCBpcyBwYXNzZWQgdG8gY2xvdWQtaW5pdCBhcyB2 bSBob3N0bmFtZSAoYXMgaXQgaXMgZGVmYXVsdCB3aGVuIGNyZWF0aW5nIFZNIGZyb20gQWRtaW4g UG9ydGFsKT8gSXMgaXQgZXZlbiBwb3NzaWJsZSBhbmQgcGxlYXNlIGlmIHNvLCBwcm92aWRlIHNv bWUgZ3VpZGFuY2U/PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiPk1ldCB2cmllbmRlbGlqa2UgZ3Jv ZXQvIEJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFya28gVnJnb3RpYzwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVy IENhcmU8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkFjdGl2ZVZpZGVvPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A6FDF329CA4E4BD18E0BD2486DACBF13activevideocom_--

1 0

Re: [ovirt-users] 4.2 can not set noVnc as default console
by Karli Sjöberg 24 Jan '18

24 Jan '18

2 1

Fail to add a second network
by carl langlois 24 Jan '18

24 Jan '18

HI all, I am trying to add second network for back-end traffic. My setup is a 3 hosts running with gluster storage in 3+1 replicat. Now i am trying to add a second network with the UI and when i try to had a the host interface to the new network it is always failing and i lost communication with this host. I am not sure what are the step to add a second network with already 3 Host in the cluster. My setup us 4.2. Any inputs would be appreciated. Thanks

3 8

4.2 can not set noVnc as default console
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydC4NCg0KRXhlY3V0aW5nIGVuZ2luZS1jb25maWcg4oCTcyBDbGllbnRNb2RlVm5j RGVmYXVsdD1Ob1ZuYyBkb2VzIG5vdCByZXN1bHQgYXMgZXhwZWN0ZWQuDQoNCkV2ZW4gdGhvdWdo IGNvbW1hbmQgaXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZpbmQgdGhlIFZNIGNvbnNvbGUgc2V0dXAg KGR1cmluZyBjcmVhdGlvbikgd2hpY2ggc2V0cyBub1ZuYyBhcyBkZWZhdWx0LCBpdOKAmXMgYWx3 YXlzIE5hdGl2ZSBWTkMuDQoNCkFueSBhZHZpY2U/DQoNCi0tDQpNZXQgdnJpZW5kZWxpamtlIGdy b2V0IC8gQmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2luZWVyL0N1c3Rv bWVyIENhcmUNCkFjdGl2ZVZpZGVvDQo= --_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0019EDD6BEA6C641996798343AAB8FE0(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5EZWFyIG9WaXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+RXhlY3V0aW5nJm5ic3A7PGk+ZW5naW5lLWNvbmZpZyDigJNzIENsaWVudE1vZGVWbmNE ZWZhdWx0PU5vVm5jJm5ic3A7PC9pPmRvZXMgbm90IHJlc3VsdCBhcyBleHBlY3RlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkV2ZW4gdGhvdWdoIGNvbW1hbmQg aXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZpbmQgdGhlIFZNIGNvbnNvbGUgc2V0dXAgKGR1cmluZyBj cmVhdGlvbikgd2hpY2ggc2V0cyBub1ZuYyBhcyBkZWZhdWx0LCBpdOKAmXMgYWx3YXlzIE5hdGl2 ZSBWTkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9Ik5MIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+QW55IGFkdmljZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9Ik5MIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1ldCB2 cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NYXJrbyBWcmdvdGljPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN5c3RlbSBFbmdpbmVlci9DdXN0b21l ciBDYXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkFjdGl2ZVZpZGVvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_--

1 0

4.2 Can not set noVnc as default client console
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydC4NCg0KRXhlY3V0aW5nIGVuZ2luZS1jb25maWcg4oCTcyBDbGllbnRNb2RlVm5j RGVmYXVsdD1Ob1ZuYyBkb2VzIG5vdCByZXN1bHQgYXMgZXhwZWN0ZWQuDQoNCkV2ZW4gdGhvdWdo IGNvbW1hbmQgaXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZuZCB0aGUgVk0gY29uc29sZSBzZXR1cCAo ZHVyaW5nIGNyZWF0aW9uKSB3aGljaCBhY3R1YWxseSBzZXRzIG5vVm5jIGFzIGRlZmF1bHQsIGl0 cyBhbHdheXMgTmF0aXZlIFZOQy4NCg0KUGxlYXNlIGFzc2lzdC4NCg0KLS0NCk1ldCB2cmllbmRl bGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsDQpNYXJrbyBWcmdvdGljDQpTeXN0ZW0gRW5naW5l ZXIvQ3VzdG9tZXIgQ2FyZQ0KQWN0aXZlVmlkZW8NCg0K --_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6FE443A96B431C4FBDF4AFDCC59C69D9(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgb1Zp cnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5FeGVjdXRpbmcg PGk+ZW5naW5lLWNvbmZpZyDigJNzIENsaWVudE1vZGVWbmNEZWZhdWx0PU5vVm5jDQo8L2k+ZG9l cyBub3QgcmVzdWx0IGFzIGV4cGVjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+RXZlbiB0aG91Z2ggY29tbWFuZCBpcyBleGVjdXRlZCwgSSBjYW5ub3QgZm5k IHRoZSBWTSBjb25zb2xlIHNldHVwIChkdXJpbmcgY3JlYXRpb24pIHdoaWNoIGFjdHVhbGx5IHNl dHMgbm9WbmMgYXMgZGVmYXVsdCwgaXRzIGFsd2F5cyBOYXRpdmUgVk5DLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIGFzc2lzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJr aXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPi0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1ldCB2cmllbmRlbGlqa2UgZ3Jv ZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+QWN0aXZlVmlkZW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_--

1 0

Multi OVF_STORE entries
by Stefano Danzi 24 Jan '18

24 Jan '18

Hello, I'm checking Storage -> Disks in my oVirt test site. I can find: - 4 disks for my 4 VM - 1 disk for HostedEngine - 4 OVF_STORE entries, sharables and without size. I can't manage, move or remove OVF_STORE entries. I think that they are somethig ported during some upgrade... Does anyone have any ideas?

2 1

host-passthrough or pcid enable for Westmere and SandyBridge
by Eduardo Mayoral 24 Jan '18

24 Jan '18

Hi, With the meltdown patches, now it is specially beneficial to have the pcid feature in the virtual CPUs. See: https://groups.google.com/forum/#!topic/mechanical-sympathy/L9mHTbeQLNU The PCID feature is available in physical "Westmere" (Release date circa 2010) or newer CPUs. However, in libvirt the pcid feature is only avalilable for virtual CPUs Haswell (Release date circa 2013) or newer. The recomendation is using Haswell, Broadwell or Skylake based model or host passthrough. Now, I think "host passthrough" is not an option for oVirt for good reason so this leaves Haswell, Broadwell or Skylake as options. Is it possible to edit /usr/share/libvirt/cpu_map.xml on the compute nodes to add the pcid feature to the virtual CPU models between Westmere and Haswell (that would be Westmere and SandyBridge)? Is anyone aware if something like this is being considered by the libvirt developers? Actually understanding the implications or doing so is way beyond my skill level. By now you may have guessed that my oVirt clusters use physical Westmere and SandyBridge CPUs :-/ Thanks in advance for your help! -- Eduardo Mayoral Jimeno (emayoral(a)arsys.es) Administrador de sistemas. Departamento de Plataformas. Arsys internet. +34 941 620 145 ext. 5153

2 1

Re: [ovirt-users] New post on oVirt blog: Build oVirt Reports Using Grafana
by Mikhail Krasnobaev 24 Jan '18

24 Jan '18

5 5

Apache Directory Server
by C Williams 24 Jan '18

24 Jan '18

Hello, Has anyone successfully connected the ovirt-engine to Apache Directory Server 2.0 ? I have tried the pre-set connections offered by oVirt and have been able to connect to the server on port 10389 after adding the port to a serverset.port. I can query the directory and see users but I cannot log onto the console as a user in the directory. If any one has any experience/guidance on this, please let me know. Thank You Charles Williams

2 1