December 2017 - Users - oVirt List Archives

Official Hyperconverged Gluster oVirt upgrade procedure?
by Hanson 23 Jan '18

23 Jan '18

Hi Guys, Just wondering if we have an updated manual or whats the current procedure for upgrading the nodes in a hyperconverged ovirt gluster pool? Ie Nodes run 4.0 oVirt, as well as GlusterFS, and hosted-engine running in a gluster storage domain. Put node in maintenance mode and disable glusterfs from ovirt gui, run yum update? Thanks!

4 4

oVirt Node 4.1.8 -> 4.2 upgrade
by Ed Stout 18 Jan '18

18 Jan '18

Good Morning, Perhaps someone could clarify for me, please - to update oVirt Nodes from 4.1.8 -> 4.2, should I just be able to yum install the 4.2 release file, then yum update? Or, do I have to start with the 4.2 ISO then update from there? When I try the former it fails with dependency issues for the nodes, I did however manage to update a self hosted appliance engine to 4.2. I had a read through the mailing list archive and couldn't find similar issues, so perhaps I'm doing something wrong. --> Processing Dependency: lshw for package: vdsm-4.20.9.3-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: ovirt-hosted-engine-setup-2.2.3-1.el7.centos.noarch (ovirt-4.2) Requires: libvirt-daemon-config-network Error: Package: ovirt-hosted-engine-setup-2.2.3-1.el7.centos.noarch (ovirt-4.2) Requires: virt-install Error: Package: glusterfs-geo-replication-3.12.3-1.el7.x86_64 (ovirt-4.2-centos-gluster312) Requires: python-prettytable Error: Package: vdsm-4.20.9.3-1.el7.centos.x86_64 (ovirt-4.2) Requires: lshw Error: Package: glusterfs-events-3.12.3-1.el7.x86_64 (ovirt-4.2-centos-gluster312) Requires: python-prettytable You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest OS Version: RHEL - 7 - 4.1708.el7.centos OS Description: oVirt Node 4.1.8 Kernel Version: 3.10.0 - 693.11.1.el7.x86_64 KVM Version: 2.9.0 - 16.el7_4.8.1 LIBVIRT Version: libvirt-3.2.0-14.el7_4.5 VDSM Version: vdsm-4.19.43-1.el7.centos SPICE Version: 0.12.8 - 2.el7.1 GlusterFS Version: glusterfs-3.8.15-2.el7 CEPH Version: librbd1-0.94.5-2.el7 Cheers, Ed

5 8

4.2.0 Unable to create VM disk from VM Portal
by Vrgotic, Marko 18 Jan '18

18 Jan '18

--_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydCBjb21tdW5pdHksDQoNCkkgaGF2ZSBmb2xsb3dpbmcgc2V0dXA6DQo0IHNlcnZl cnMgYXMgZ2x1c3RlcmZzIHN0b3JhZ2U6IHByb3ZpZGluZyB2b2x1bWUgMSBmb3IgSG9zdGVkRW5n aW5lIGFkIHZvbHVtZSAyIGZvciBWTSBTdG9yYWdlDQo3IEh5cGVydmlzb3JzDQpTZWxmSG9zdGVk IEVuZ2luZSA0LjIuMCBjbGVhbiBpbnN0YWxsIChub3QgYW4gdXBncmFkZSkNCg0KUHJvYmxlbToN Ck1pc3Npbmcgb3B0aW9uIHRvIGFkZC9jcmVhdGUgVk0gZGlzayBmcm9tIFZNIFBvcnRhbCAvIGV2 ZW4gYXMgQWRtaW4gdXNlci4NCkkgaGF2ZSB0cmllZCB3aXRoIEFkbWluIHN1ZXIgYW5kIGNyZWF0 aW5nIHVzZXIg4oCcVGVzdOKAnSB3dGggUG93ZXJVc2VyIHJvbGUuDQpJbiBib3RoIGNhc2VzIHRo ZXJlIGlzIG5vdCBvcHRpb24gdG8gY3JlYXRlIG9yIGF0dGFjaCBkaXNrLg0KDQpJcyB0aGUgYXBw cm9hY2ggY2hhbmdlZCBzaW5jZSA0LjIuMD8gQW0gSSBtaXNzaW5nIGEgc2V0dGluZz8NClBsZWFz ZSBsZXQgbWUga25vdywgSSB3aWxsIHByb3ZpZGUgbW9yZSBkYXRhIGlmIG5lZWRlZC4NCg0KS2lu ZGx5IGF3YWl0aW5nIHlvdXIgcmVwbHkuDQoNCi0tDQpNZXQgdnJpZW5kZWxpamtlIGdyb2V0IC8g QmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENh cmUNCg0K --_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BE36FEDD7A7564FA55EC61B84810D36(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 cnQgY29tbXVuaXR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ SSBoYXZlIGZvbGxvd2luZyBzZXR1cDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+NCBzZXJ2ZXJzIGFzIGds dXN0ZXJmcyBzdG9yYWdlOiBwcm92aWRpbmcgdm9sdW1lIDEgZm9yIEhvc3RlZEVuZ2luZSBhZCB2 b2x1bWUgMiBmb3IgVk0gU3RvcmFnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij43IEh5cGVydmlzb3JzIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5TZWxmSG9zdGVkIEVuZ2luZSA0LjIuMCBjbGVhbiBpbnN0YWxsIChu b3QgYW4gdXBncmFkZSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlByb2JsZW06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1pc3Npbmcgb3B0aW9uIHRvIGFkZC9jcmVhdGUg Vk0gZGlzayBmcm9tIFZNIFBvcnRhbCAvIGV2ZW4gYXMgQWRtaW4gdXNlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+SSBoYXZlIHRyaWVkIHdpdGggQWRtaW4gc3VlciBhbmQgY3JlYXRpbmcgdXNlciDigJxU ZXN04oCdIHd0aCBQb3dlclVzZXIgcm9sZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4gYm90aCBjYXNl cyB0aGVyZSBpcyBub3Qgb3B0aW9uIHRvIGNyZWF0ZSBvciBhdHRhY2ggZGlzay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIHRoZSBhcHByb2FjaCBjaGFuZ2Vk IHNpbmNlIDQuMi4wPyBBbSBJIG1pc3NpbmcgYSBzZXR0aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Q bGVhc2UgbGV0IG1lIGtub3csIEkgd2lsbCBwcm92aWRlIG1vcmUgZGF0YSBpZiBuZWVkZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LaW5kbHkgYXdhaXRpbmcg eW91ciByZXBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B536AA2E93C94EFF948B2FB02AFDD203activevideocom_--

3 5

oVirt NGN image customization troubles
by Giuseppe Ragusa 12 Jan '18

12 Jan '18

Hi all, I'm trying to modify the oVirt NGN image (to add RPMs, since imgbased rpmpersistence currently seems to have a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1528468 ) but I'm unfortunately stuck at the very beginning: it seems that I'm unable to recreate even the standard 4.1 squashfs image. I'm following the instructions at https://gerrit.ovirt.org/gitweb?p=ovirt-node-ng.git;a=blob;f=README I'm working inside a CentOS7 fully-updated vm (hosted inside VMware, with nested virtualization enabled). I'm trying to work on the 4.1 branch, so I issued a: ./autogen.sh --with-ovirt-release-rpm-url=http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm And after that I'm stuck in the "make squashfs" step: it never ends (keeps printing dots forever with no errors/warnings in log messages nor any apparent activity on the virtual disk image). Invoking it in debug mode and connecting to the VNC console shows the detailed Plymouth startup listing stuck (latest messages displayed: "Starting udev Wait for Complete Device Initialization..." and "Starting Device-Mapper Multipath Device Controller...") I wonder if it's actually supposed to be run only from a recent Fedora (the "dnf" reference seems a good indicator): if so, which version? I kindly ask for advice: has anyone succeeded in modifying/reproducing NGN squash images recently? If so, how? :-) Many thanks in advance, Giuseppe

3 2

10Gb Networking with OVN
by Beau Sapach 12 Jan '18

12 Jan '18

Hello everyone, I see here: https://www.ovirt.org/blog/2017/09/introducing-ovirt-4.2.0/ that version 4.2 will have OVN support. Does anyone know if this will allow VMs to take advantage of 10Gb networking without needing SR-IOV? -- Beau Sapach *System Administrator | Information Technology Services | University of Alberta Libraries* *Phone: 780.492.4181 | Email: Beau.Sapach(a)ualberta.ca <Beau.Sapach(a)ualberta.ca>*

4 6

oVirt Node 4.1 question, writing files to /root and RPMs
by Matt Simonsen 11 Jan '18

11 Jan '18

Hello all, I read at https://www.ovirt.org/develop/projects/node/troubleshooting/ that "Changes made from the command line are done at your own risk. Making changes has the potential to leave your system in an unusable state." It seems clear that RPMs should not be installed. Is this accurate for https://www.ovirt.org/node/ ? We have added smartctl and hpacucli in order to do disk and RAID monitoring. So far our node servers have retained changes across reboots, which is the primary reason I'm wondering if perhaps this applies to an older version of oVirt Node. If what we have been doing is not supported, what is the suggested method to do do hardware monitoring (in particular disks)? Thanks Matt

5 5

[vdsm] status update: running containers alongside VMs
by Francesco Romani 05 Jan '18

05 Jan '18

Hi everyone, I'm happy to share some progress about the former "convirt"[1] project, which aims to let Vdsm containers alongside VMs, on bare metal. In the last couple of months I kept updating the patch series, which is approaching the readiness to be merged in Vdsm. Please read through this mail to see what the patchset can do now, how you could try it *now*, even before it is merged. Everyone is invited to share thoughts and ideas about how this effort could evolve. This will be a long mail; I will amend, enhance and polish the content and make a blog post (on https://mojaves.github.io) to make it easier to consume and to have some easy-to-find documentation. Later on the same content will appear also on the oVirt blog. Happy hacking! +++ # How to try how the experimental container support for Vdsm. Vdsm is gaining *experimental* support to run containers alongside VMs. Vdsm had since long time the ability to manage VMs which run containers, and recently gained support for [atomic guests](http://www.projectatomic.io/blog/2015/01/running-ovirt-guest-agent-as-privileged-container/). With the new support we are describing, you will be able to manage containers with the same, proven infrastructure that let you manage VMs. This feature is currently being developed and it is still not merged in the Vdsm codebase, so some extra work is needed if you want to try it out. We aiming to merge it in the oVirt 4.1.z cycle. ## What works, aka what to expect The basic features are expected to work: 1. Run any docker image on the public docker registry 2. Make the container accessible from the outside (aka not just from localhost) 3. Use file-based storage for persistent volumes ## What does not yet work, aka what NOT to expect Few things are planned and currently under active development: 1. Monitoring. Engine will not get any update from the container besides "VM" status (Up, Down...) One important drawback is that you will not be told the IP of the container from Engine, you will need to connect to the Vdsm host to discover it using standard docker tools. 2. Proper network integration. Some steps still need manual intervention 3. Stability and recovery - it's pre-alpha software after all! :) ## 1. Introduction and prerequisites Trying out container support affects only the host and the Vdsm. Besides add few custom properties (totally safe and supported since early 3.z), there are zero changes required to the DB and to Engine. Nevertheless, we recommend to dedicate one oVirt 4.y environment, or at least one 4.y host, to try out the container feature. To get started, first thing you need is to setup a vanilla oVirt 4.y installation. We will need to make changes to the Vdsm and to the Vdsm host, so hosted engine and/or oVirt node may add extra complexity, better to avoid them at the moment. The reminder of this tutorial assumes you are using two hosts, one for Vdsm (will be changed) and one for Engine (will require zero changes); furthermore, we assume the Vdsm host is running on CentOS 7.y. We require: - one test host for Vdsm. This host need to have one NIC dedicated to containers. We will use the [docker macvlan driver](https://raesene.github.io/blog/2016/07/23/Docker-MacVLAN/), so this NIC *must not be* part of one bridge. - docker >= 1.12 - oVirt >= 4.0.5 (Vdsm >= 4.18.15) - CentOS >= 7.2 Docker >= 1.12 is avaialable for download [here](https://docs.docker.com/engine/installation/linux/centos/) Caveats: 1. docker from official rpms conflicts con docker from CentOS, and has a different package name: docker-engine vs docker. Please note that the kubernetes package from CentOS, for example, require 'docker', not 'docker-engine'. 2. you may want to replace the default service file [with this one](https://github.com/mojaves/convirt/blob/master/patches/centos72/system… and to use this [sysconfig file](https://github.com/mojaves/convirt/blob/master/patches/centos72/syste…. Here I'm just adding the storage options docker requires, much like the CentOS docker is configured. Configuring docker like this can save you some troubleshooting, especially if you had docker from CentOS installed on the testing box. ## 2. Patch Vdsm to support containers You need to patch and rebuild Vdsm. Fetch [this patch](https://github.com/mojaves/convirt/blob/master/patches/vdsm/4.18.15.… and apply it against Vdsm 4.18.15.1. Vdsm 4.18.15.{1,2,...} are supported as well. Rebuild Vdsm and reinstall on your box. [centos 7.2 packages are here](https://github.com/mojaves/convirt/tree/master/rpms/centos72) Make sure you install the Vdsm command line client (vdsm-cli) Restart *both* Vdsm and Supervdsm, make sure Engine still works flawlessly with patched Vdsm. This ensure that no regression is introduced, and that your environment can run VMs just as before. Now we can proceed adding the container support. start docker: # systemctl start docker-engine (optional) # systemctl enable docker-engine Restart Vdsm again # systemctl restart vdsm Now we can check if Vdsm detects docker, so you can use it: still on the same Vdsm host, run $ vdsClient -s 0 getVdsCaps | grep containers containers = ['docker', 'fake'] This means this Vdsm can run containers using 'docker' and 'fake' runtimes. Ignore the 'fake' runtime; as the name suggests, is a test driver, kinda like /dev/null. Now we need to make sure the host network configuration is fine. ### 2.1. Configure the docker network for Vdsm PLEASE NOTE that the suggested network configuration assumes that * you have one network, `ovirtmgmt` (the default one) you use for everything * you have one Vdsm host with at least two NICs, one bound to the `ovirtmgmt` network, and one spare _This step is not yet automated by Vdsm_, so manual action is needed; Vdsm will take care of this automatically in the future. You can use [this helper script](https://github.com/mojaves/convirt/blob/master/patches/vdsm/cont-se…, which reuses the Vdsm libraries. Make sure you have patched Vdsm to support container before to use it. Let's review what the script needs: # ./cont-setup-net -h usage: cont-setup-net [-h] [--name [NAME]] [--bridge [BRIDGE]] [--interface [INTERFACE]] [--gateway [GATEWAY]] [--subnet [SUBNET]] [--mask [MASK]] optional arguments: -h, --help show this help message and exit --name [NAME] network name to use --bridge [BRIDGE] bridge to use --interface [INTERFACE] interface to use --gateway [GATEWAY] address of the gateway --subnet [SUBNET] subnet to use --mask [MASK] netmask to use So we need to feed --name, --interface, --gateway, --subnet and optionally --mask (default, /24, is often fine). For my case the default mask was indeed fine, so I used the script like this: # ./cont-setup-net --name ovirtmgmt --interface enp3s0 --gateway 192.168.1.1 --subnet 192.168.1.0 Thhis is the output I got: DEBUG:virt.containers.runtime:configuring runtime 'docker' DEBUG:virt.containers.command:* calling ['/bin/docker', 'network', 'inspect', 'ovirtmgmt'] Error: No such network: ovirtmgmt DEBUG:virt.containers.command:* called ['/bin/docker', 'network', 'inspect', 'ovirtmgmt'] DEBUG:virt.containers.runtime.Docker:config: cannot load 'ovirtmgmt', ignored DEBUG:virt.containers.command:* calling ['/bin/docker', 'network', 'create', '-d', 'macvlan', '--subnet=192.168.1.0/24', '--gateway=192.168.1.1', '--ip-range=192.168.1.0/24', '-o', 'parent=enp3s0', 'ovirtmgmt'] DEBUG:virt.containers.command:* called ['/bin/docker', 'network', 'create', '-d', 'macvlan', '--subnet=192.168.1.0/24', '--gateway=192.168.1.1', '--ip-range=192.168.1.0/24', '-o', 'parent=enp3s0', 'ovirtmgmt'] DEBUG:virt.containers.runtime:configuring runtime 'fake' You can clearly see what the script did, and why it needed the root privileges. Let's deoublecheck using the docker tools: # docker network ls NETWORK ID NAME DRIVER SCOPE 91535f3425a8 bridge bridge local d42f7e5561b5 host host local 621ab6dd49b1 none null local f4b88e4a67eb ovirtmgmt macvlan local # docker network inspect ovirtmgmt [ { "Name": "ovirtmgmt", "Id": "f4b88e4a67ebb7886ec74073333d613b1893272530cae4d407c95ab587c5fea1", "Scope": "local", "Driver": "macvlan", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "192.168.1.0/24", "IPRange": "192.168.1.0/24", "Gateway": "192.168.1.1" } ] }, "Internal": false, "Containers": {}, "Options": { "parent": "enp3s0" }, "Labels": {} } ] Looks good! the host configuration is completed. Let's move to the Engine side. ## 3. Configure Engine As mentioned above, we need now to configure Engine. This boils down to: Add a few custom properties for VMs: In case you were already using custom properties, you need to amend the command line to not overwrite your existing ones. # engine-config -s UserDefinedVMProperties='volumeMap=^[a-zA-Z_-]+:[a-zA-Z_-]+$;containerImage=^[a-zA-Z]+(://|)[a-zA-Z]+$;containerType=^(docker|rkt)$' --cver=4.0 It is worth stressing that while the variables are container-specific, the VM custom properties are totally inuntrusive and old concept in oVirt, so this step is totally safe. Now restart Engine to let it use the new variables: # systemctl restart ovirt-engine The next step is actually configure one "container VM" and run it. ## 4. Create the container "VM" To finally run a container, you start creating a VM much like you always did, with few changes 1. most of the hardware-related configuration isn't relevant for container "VMs", besides cpu share and memory limits; this will be better documented in the future; unneeded configuration will just be ignored 2. You need to set some custom properties for your container "VM". Those are actually needed to enable the container flow, and they are documented in the next section. You *need* to set at least `containerType` and `containerImage`. ### 4.2. Custom variables for container support The container support needs some custom properties to be properly configured: 1. `containerImage` (*needed* to enable the container system). Just select the target image you want to run. You can use the standard syntax of the container runtimes. 2. `containerType` (*needed* to enable the container system). Selects the container runtime you want to use. All the available options are always showed. Please note that unavailable container options are not yet grayed out. If you *do not* have rkt support on your host, you still can select it, but it won't work. 3. `volumeMap` key:value like. You can map one "VM" disk (key) to one container volume (value), to have persistent storage. Only file-based storage is supported. Example configuration: `containerImage = redis` `containerType = docker` `volumeMap = vda:data` (this may not be needed, and the volume label is just for illustrative purposes) ### 4.2. A little bit of extra work: preload the images on the Vdsm host This step is not needed by the flow, and will be handled by oVirt in the future. The issue is how the container image are handled. They are stored by the container management system (rkt, docker) on each host, and they are not pre-downloaded. To shorten the duration of the first boot, you are advised to pre-download the image(s) you want to run. For example ## on the Vdsm host you want to use with containers # docker pull redis ## 5. Run the container "VM" You are now all set to run your "VM" using oVirt Engine, just like any existing VM. Some actions doesn't make sense for a container "VM", like live migration. Engine won't stop you to try to do those actions, but they will fail gracefully using the standard errors. ## 6. Next steps What to expect from this project in the future? For the integration with Vdsm, we want to fix the existing known issues, most notably: * add proper monitoring/reporting of the container health * ensure proper integration of the container image store with oVirt storage management * streamline the network configuration What is explicitely excluded yet is any Engine change. This is a Vdsm-only change at the moment, so fixing the following is currently unplanned: * First and foremost, Engine will not distinguish between real VMs and container VMs. Actions unavailable to container will not be hidden from UI. Same for monitoring and configuration data, which will be ignored. * Engine is NOT aware of the volumes one container can use. You must inspect and do the mapping manually. * Engine is NOT aware of the available container runtimes. You must select it carefully Proper integration with Engine may be added in the future once this feature exits from the experimental/provisional stage. Thanks for reading, make sure to share your thoughts on the oVirt mailing lists! +++ [1] we keep calling it that way _only_ internally, because it's a short name we are used to. After the merge/once we release it, we will use a different name, like "vdsm-containers" or something like it. -- Francesco Romani Red Hat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

3 2

Get UU
by Blaster 03 Jan '18

03 Jan '18

--Apple-Mail=_E9FF7EA0-826C-45A7-AB9C-F7262CD9645B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I need to create an old oVirt Windows VM. The VM has an old licensed = product that we can no longer get a licensed reissued for. It looks = like I need to feed back the original qemu UUID that was used when the = VM was created. I have an engine config backup and a backup of the oVirt storage domain. I viewed the engine backup, but the format as-is doesn't give any = obvious configuration details of the VMs at the time of the backup. Is = the UUID as obvious as the file name of the VM's boot volume UUID name? --Apple-Mail=_E9FF7EA0-826C-45A7-AB9C-F7262CD9645B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""> <meta http-equiv="content-type" content="text/html; charset=utf-8" class=""> <div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I need to create an old oVirt Windows VM.  The VM has an old licensed product that we can no longer get a licensed reissued for.  It looks like I need to feed back the original qemu UUID that was used when the VM was created.</p><p class="">I have an engine config backup and a backup of the oVirt storage domain.</p><p class="">I viewed the engine backup, but the format as-is doesn't give any obvious configuration details of the VMs at the time of the backup.  Is the UUID as obvious as the file name of the VM's boot volume UUID name?</p><p class=""><br class=""> </p> </div> </body></html> --Apple-Mail=_E9FF7EA0-826C-45A7-AB9C-F7262CD9645B--

4 3

Q: 2-Node Failover Setup - NFS or GlusterFS ?
by Andrei V 01 Jan '18

01 Jan '18

Hi ! I'm installing 2-node failover cluster (2 x Xeon servers with local RAID 5 / ext4 for oVirt storage domains). Now I have a dilemma - use either GlusterFS replica 2 or stick with NFS? 4.2 Engine is running on separate hardware. Each node have its own storage domain (on internal RAID). All VMs must be highly available. One of the VMs is an accounting/stock control system with FireBird SQL server on CentOS is speed-critical. No load balancing between nodes necessary. 2nd is just for backup if 1st for whatever reason goes up in smoke. All VM disks must be replicated to backup node in near real-time or in worst case each 1 - 2 hour. GlusterFS solves this issue yet at high performance penalty. >From what I read here http://lists.ovirt.org/pipermail/users/2017-July/083144.html GlusterFS performance with oVirt is not very good right now because QEMU uses FUSE instead of libgfapi. What is optimal way to go on ? Thanks in advance. Andrei

2 3

Error importing Windows Server 2016 VMs from vCenter 6.5
by Matthew Hoberg 01 Jan '18

01 Jan '18

--_000_5379D7896A6C44E8B56660940C3DB028squeakznet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB0cnlpbmcgdG8gaW1wb3J0IFZNcyBmcm9tIFZNd2FyZSA2LjUgaW50byBvVmlydCA0LjIg YW5kIGl0IGlzIGZhaWxpbmcuIFRoZSBvbmx5IG1lc3NhZ2UgSSBnZXQgaW4gdGhlIEVuZ2luZSBp bnRlcmZhY2UgaXMgdGhhdCBpdCBmYWlsZWQgdG8gY29udmVydC4gQWxsIG15IDIwMTYgVk1zIGFy ZSBydW5uaW5nIGluIEVGSSBtb2RlLiBJIGJ1aWx0IGEgZnJlc2ggMjAxNiBWTSBpbiBNQlIgbW9k ZSBhbmQgdGhhdCBpbXBvcnRlZCBmaW5lLiBWTXdhcmUgaXMgYSAyIGhvc3QgY2x1c3RlciBydW5u aW5nIHZDZW50ZXIuIG9WaXJ0IDQuMiBpcyBhIDIgaG9zdCBjbHVzdGVyIHJ1bm5pbmcgYSBob3N0 ZWQgZW5naW5lLiBCb3RoIGNsdXN0ZXJzIGNvbm5lY3QgdG8gaVNDU0kgZGF0YXN0b3Jlcy4gSXMg dGhlcmUgYW55dGhpbmcgZWxzZSBJIGhhdmUgdG8gZG8gdG8gYmUgYWJsZSB0byBpbXBvcnQgYW4g RUZJIGJhc2VkIFZNPw0KDQp+TWF0dA0K --_000_5379D7896A6C44E8B56660940C3DB028squeakznet_ Content-Type: text/html; charset="utf-8" Content-ID: <53008B8C50740B49B9898E2AC9A3F1CF(a)namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGFtIHRyeWluZyB0byBpbXBvcnQgVk1z IGZyb20gVk13YXJlIDYuNSBpbnRvIG9WaXJ0IDQuMiBhbmQgaXQgaXMgZmFpbGluZy4gVGhlIG9u bHkgbWVzc2FnZSBJIGdldCBpbiB0aGUgRW5naW5lIGludGVyZmFjZSBpcyB0aGF0IGl0IGZhaWxl ZCB0byBjb252ZXJ0LiBBbGwgbXkgMjAxNiBWTXMgYXJlIHJ1bm5pbmcgaW4gRUZJIG1vZGUuIEkg YnVpbHQgYSBmcmVzaA0KIDIwMTYgVk0gaW4gTUJSIG1vZGUgYW5kIHRoYXQgaW1wb3J0ZWQgZmlu ZS4gVk13YXJlIGlzIGEgMiBob3N0IGNsdXN0ZXIgcnVubmluZyB2Q2VudGVyLiBvVmlydCA0LjIg aXMgYSAyIGhvc3QgY2x1c3RlciBydW5uaW5nIGEgaG9zdGVkIGVuZ2luZS4gQm90aCBjbHVzdGVy cyBjb25uZWN0IHRvIGlTQ1NJIGRhdGFzdG9yZXMuIElzIHRoZXJlIGFueXRoaW5nIGVsc2UgSSBo YXZlIHRvIGRvIHRvIGJlIGFibGUgdG8gaW1wb3J0IGFuIEVGSSBiYXNlZA0KIFZNPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+fk1hdHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5379D7896A6C44E8B56660940C3DB028squeakznet_--

3 2