- Users - oVirt List Archives

Re: [ovirt-users] Bulk move vm disks?
by Staniforth, Paul 24 Mar '17

24 Mar '17

--_000_bb226a5b0a6c4de4a9d19f2ae7c8e530emailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hyaXN0aWFuLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgSSBoYXZlIHJlY2Vu dGx5IG1vdmVkIGFyb3VuZCA3MDAgVk0gZGlza3MgYmV0d2VlbiBzdG9yYWdlIGRvbWFpbnMsIHlv dSBjYW4gc2VsZWN0IG11bHRpcGxlIGRpc2tzIGluIHRoZSBHVUkgYW5kIG1vdmUgdGhlbS4gSSBk aWQgdGhpcyBvbiBvVmlydCAzLjYgbW9zdCBvZiB0aGVzZSB3ZXJlIGRlcGVuZGFudCBvbiB0ZW1w bGF0ZSBkaXNrcyBzbyBJIGhhZCB0byBjb3B5IHRoZSB0ZW1wbGF0ZSBkaXNrcyB0byB0aGUgZGVz dGluYXRpb24gZG9tYWluIG9uY2UgYWxsIHRoZSBkZXBlbmRhbnQgVk0gZGlza3Mgd2VyZSBtb3Zl ZCBJIGNvdWxkIHJlbW92ZSB0aGUgdGVtcGxhdGUgZGlzayBmcm9tIHRoZSBzb3VyY2UgZG9tYWlu Lg0KSWYgdGhlIFZNcyBhcmUgdXAgaXQgYXV0b21hdGljYWxseSBjcmVhdGVzIGEgc25hcHNob3Qs IGluIHZlcnNpb24gMy42IHRoZXNlIGFyZW4ndCBhdXRvbWF0aWNhbGx5IHJlbW92ZWQuDQpSZWdh cmRzLA0KICAgICAgICAgICAgICAgICBQYXVsIFMuDQoNCk9uIDI0IE1hciAyMDE3IDEwOjEyLCBn Zmx3cXMgZ2Zsd3FzIDxnZmx3cXNAZ21haWwuY29tPiB3cm90ZToNCkhpIGxpc3QsDQpJIG5lZWQg dG8gbW92ZSA2MDArIHZtczpmcm9tIG9uZSBkYXRhIGRvbWFpbiB0byBhbm90aGVyLCBob3dldmVy IGZyb20gd2hhdCBpIGNhbiBzZWUgaW4gdGhlIEdVSSBpIGNhbiBvbmx5IG1vdmUgb25lIHZtIGRp c2sgYXQgdGhlIHRpbWUgd2hpY2ggd291bGQgYmUgdmVyeSB0aW1lIGNvbnN1bWluZy4NCg0KSSB0 aGVyZSBhbnkgd2F5IGkgY2FuIGJ1bGsgbW92ZSB0aG9zZSB2bSBkaXNrcz8NCkJ5IHRoZSB3YXks IEkgY2FuJ3Qgc3RvcCB0aGUgdm1zIHRoZXkgaGF2ZSB0byBiZSBvbmxpbmUgZHVyaW5nIHRoZSBt aWdyYXRpb24uLg0KDQpSZWdhcmRzDQpDaHJpc3RpYW4NCg0KVG8gdmlldyB0aGUgdGVybXMgdW5k ZXIgd2hpY2ggdGhpcyBlbWFpbCBpcyBkaXN0cmlidXRlZCwgcGxlYXNlIGdvIHRvOi0NCmh0dHA6 Ly9kaXNjbGFpbWVyLmxlZWRzYmVja2V0dC5hYy51ay9kaXNjbGFpbWVyL2Rpc2NsYWltZXIuaHRt bA0K --_000_bb226a5b0a6c4de4a9d19f2ae7c8e530emailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <EF597DA795ACE048AEBAE6225E7E8146(a)leedsbeckett.ac.uk> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9ImF1 dG8iPg0KPGRpdj5IZWxsbyBDaHJpc3RpYW4sPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgaGF2ZSByZWNlbnRseSBtb3ZlZCBh cm91bmQgNzAwIFZNIGRpc2tzIGJldHdlZW4gc3RvcmFnZSBkb21haW5zLCB5b3UgY2FuIHNlbGVj dCBtdWx0aXBsZSBkaXNrcyBpbiB0aGUgR1VJIGFuZCBtb3ZlIHRoZW0uIEkgZGlkIHRoaXMgb24g b1ZpcnQgMy42IG1vc3Qgb2YgdGhlc2Ugd2VyZSBkZXBlbmRhbnQgb24gdGVtcGxhdGUgZGlza3Mg c28gSSBoYWQgdG8gY29weSB0aGUNCiB0ZW1wbGF0ZSBkaXNrcyB0byB0aGUgZGVzdGluYXRpb24g ZG9tYWluIG9uY2UgYWxsIHRoZSBkZXBlbmRhbnQgVk0gZGlza3Mgd2VyZSBtb3ZlZCBJIGNvdWxk IHJlbW92ZSB0aGUgdGVtcGxhdGUgZGlzayBmcm9tIHRoZSBzb3VyY2UgZG9tYWluLjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPklmIHRoZSBWTXMgYXJlIHVwIGl0IGF1dG9tYXRpY2FsbHkgY3JlYXRl cyBhIHNuYXBzaG90LCBpbiB2ZXJzaW9uIDMuNiB0aGVzZSBhcmVuJ3QgYXV0b21hdGljYWxseSBy ZW1vdmVkLjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGRpcj0i YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtQYXVsIFMuPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiIGRpcj0iYXV0 byI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDI0IE1hciAyMDE3IDEwOjEyLCBn Zmx3cXMgZ2Zsd3FzICZsdDtnZmx3cXNAZ21haWwuY29tJmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0 cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+SGkgbGlzdCwNCjxkaXY+SSBuZWVkIHRvIG1vdmUgNjAwJiM0Mzsg dm1zOmZyb20gb25lIGRhdGEgZG9tYWluIHRvIGFub3RoZXIsIGhvd2V2ZXIgZnJvbSB3aGF0IGkg Y2FuIHNlZSBpbiB0aGUgR1VJIGkgY2FuIG9ubHkgbW92ZSBvbmUgdm0gZGlzayBhdCB0aGUgdGlt ZSB3aGljaCB3b3VsZCBiZSB2ZXJ5IHRpbWUgY29uc3VtaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+SSB0aGVyZSBhbnkgd2F5IGkgY2FuIGJ1bGsgbW92ZSB0aG9zZSB2bSBkaXNr cz88L2Rpdj4NCjxkaXY+QnkgdGhlIHdheSwgSSBjYW4ndCBzdG9wIHRoZSB2bXMgdGhleSBoYXZl IHRvIGJlIG9ubGluZSBkdXJpbmcgdGhlIG1pZ3JhdGlvbi4uPC9kaXY+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PkNocmlzdGlhbjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KVG8gdmlldyB0aGUgdGVybXMgdW5kZXIgd2hpY2ggdGhpcyBlbWFpbCBpcyBkaXN0cmlidXRl ZCwgcGxlYXNlIGdvIHRvOi0gPGJyPg0KPGEgaHJlZj0iaHR0cDovL2Rpc2NsYWltZXIubGVlZHNi ZWNrZXR0LmFjLnVrL2Rpc2NsYWltZXIvZGlzY2xhaW1lci5odG1sIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL2Rpc2NsYWltZXIubGVlZHNiZWNrZXR0LmFjLnVrL2Rpc2NsYWltZXIvZGlzY2xhaW1l ci5odG1sPC9hPg0KPHA+PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_bb226a5b0a6c4de4a9d19f2ae7c8e530emailandroidcom_--

1 0

[Python SDK] Setup Host network with IP address
by TranceWorldLogic . 24 Mar '17

24 Mar '17

Hi, I am trying to setup network via python sdk as shown below: myhost_service.setup_networks( modified_network_attachments = [ types.NetworkAttachment( host = myhost, host_nic = types.HostNic(name="eth0"), network = types.Network(name="Hello"), ip_address_assignments = [ types.IpAddressAssignment( assignment_method = types.BootProtocol.STATIC, ip = types.Ip( address="192.168.300.10", netmask="255.255.255.0", version=types.IpVersion.V4, ), ) ], ), ] ) But I am getting below error: "ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Bad format of IPv4 address]". HTTP response code is 400." Please help me. Ovirt release version = 4.0 Thanks, ~Rohit

1 1

ovirt Node Building
by shubham dubey 24 Mar '17

24 Mar '17

Hello, I have recently build ovirt-engine from source using this link( http://www.ovirt.org/develop/developer-guide/engine/engine-development-envi…) Now I want to build ovirt node using this( http://www.ovirt.org/develop/projects/node/building/) I am confused that can I build that node on the same system as of ovirt-engine or I need to do these steps on any other system. Thanks, Shubham

1 0

strange behavior of ovirt-node ng update
by Sergey Kulikov 23 Mar '17

23 Mar '17

I have one Ovirt Node in my test cluster(others are centos), I'm observing strange behavior of update checker in engine. In options I can see: engine=# select * from vdc_options where option_name='OvirtNodePackageNamesForCheckUpdate'; option_id | option_name | option_value | version -----------+-------------------------------------+----------------------------+--------- 124 | OvirtNodePackageNamesForCheckUpdate | ovirt-node-ng-image-update | general (1 row) so it tries to check for updated version of ovirt-node-ng-image-update, but there is no ovirt-node-ng-image-update package installed inside updated node image, so engine always shows available updates on this node to the same version: > Check for available updates on host XXX was completed successfully with message 'found updates for packages ovirt-node-ng-image-4.1.1-1.el7.centos, ovirt-node-ng-image-update-4.1.1-1.el7.centos'. I saw a bug in bugzilla, that it should be fixed in 4.0 Initially engine was set up as 4.x version, after that updated between releases and finally to 4.1.0, and today to 4.1.1. I saw this behavior on 4.1.0 node and also on 4.1.1, on this page: http://www.ovirt.org/node/4.0/update/ Maybe my OvirtNodePackageNamesForCheckUpdate was changed between releases, but engine-setup left it untouched and i should change it manually? If so, what it should look like? --

1 0

ovirt-shell backup
by Marcin Kruk 23 Mar '17

23 Mar '17

Hello is it possible to execute below actions from the ovirth-shell: 1. Make snapshot ( ovirt-shell -E 'add snapshot --parent-vm-name <vmname> --description <desc> ) 2. Make clone from snaphot above ( ? ) 3. Export clone ( ? )

2 1

VMs changing to unknown state
by Michael Watters 23 Mar '17

23 Mar '17

I have an ovirt host running ovirt 4.0 which keeps putting the VMs running on that host into an unknown state. I checked the vdsm logs and there are several errors similar to below. Mar 20 10:16:11 ovirt-node-production3.example.com vdsm[17123]: vdsm root ERROR Unhandled exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 372, in wrapper return f(*a, **kw) File "/usr/share/vdsm/virt/migration.py", line 624, in run self.monitor_migration() File "/usr/share/vdsm/virt/migration.py", line 657, in monitor_migration job_stats = self._vm._dom.jobStats() File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 69, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 917, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1387, in jobStats if ret is None: raise libvirtError ('virDomainGetJobStats() failed', dom=self) libvirtError: Requested operation is not valid: domain is not running Restarting vdsmd resolves the issue however I would like to resolve the issue permanently. Does anybody know what would cause this?

1 0

Roadmap
by Julián Tete 23 Mar '17

23 Mar '17

Hi Friends of oVirt Is there any roadmap for oVirt for 2017 and 2018? Any roadmap for oVirt by versions? 4.2.X, 4.3.X, 4.4.X Thank you

2 2

NFS ISO domain from hosted-engine VM
by Devin A. Bougie 23 Mar '17

23 Mar '17

Hi, All. Are there any recommendations or best practices WRT whether or not to host an NFS ISO domain from the hosted-engine VM (running the oVirt Engine Appliance)? We have a hosted-engine 4.1.1 cluster up and running, and now just have to decide where to serve the NFS ISO domain from. Many thanks, Devin

2 2

hosted-engine with iscsi storage domain
by Devin A. Bougie 23 Mar '17

23 Mar '17

We have a hosted-engine running on 4.1 with an iSCSI hosted_storage domain, and are able to import the domain. However, we cannot attache the domain to the data center. Just to make sure I'm not missing something basic, does the engine VM need to be able to connect to the iSCSI target itself? In other words, does the iSCSI traffic need to go over the ovirtmgmt bridged network? Currently we have the iSCSI SAN on a separate subnet from ovirtmgmt, so the hosted-engine VM can't directly see the iSCSI storage. Thanks, Devin

2 4

Python-SDK: ovirtsdk4.Connection object autologout?
by nicolas＠devels.es 23 Mar '17

23 Mar '17

Hi, We've recently upgraded from oVirt 4.0.x to 4.1.0 and it seems that the behavior of a script we wrote in Python-SDK has changed slightly. We have a script that needs to be executed forever (daemon mode). This daemon creates an ovirtsdk4.Connection object and uses the same Connection object all the time. conn = sdk.Connection( url=URI, username=USERNAME, password=PASSWORD, ca_file=CAFILE ) Between iterations we have ~5 minutes delays which we accomplish with a time.sleep(...) call. After some of these iterations (5 or 6), when trying to perform an operation on the Connection object (in this case, listing all SDs): try: sys_serv = conn.system_service() sd_serv = sys_serv.storage_domains_service() storages = sd_serv.list(search=sd_search_query) except Error, e: log('ERR: Error getting storage domains: %s' % (e)) We start getting exceptions (i.e., the sd_serv.list() call throwing an Error exception) with this message: ERR: Error getting storage domains: HTTP response code is 401. I believe this has something to do with the Connection object expiring (even if it's not idle more than 5 minutes at any time). Is there a way to "refresh" the Connection object so it doesn't auto-logout (assuming this is the actual problem)? As I said, this started happening as of oVirt 4.1.0. ovirt-engine-sdk-python version is 4.1.1. Any ideas? Thanks.

4 8