- Users - oVirt List Archives

Fwd: Issues importing VMs in oVirt
by Cam Mac 17 Jun '16

17 Jun '16

Hi Pavel, I can't do a screenshot right now, but the structure in vCenter is: nssesxi-mgmt.ldn.arda.net --> North Sutton Street --> nssesxi --> nssesxi01-mgmt.ldn.arda.net nssesxi02-mgmt.ldn.arda.net nssesxi03-mgmt.ldn.arda.net nssesxi04-mgmt.ldn.arda.net nssesxi05-mgmt.ldn.arda.net I've tried fully qualified names, but the same error occurs. Cheers, Cam On Fri, Jun 17, 2016 at 11:15 AM, Pavel Gashev <Pax(a)acronis.com> wrote: > Cam, > > > > It's another error. Now there is an issue with esxi server name – > 'nssesxi04-mgmt'. It must be the same as appears in vcenter. A screenshot > of vcenter tree would help. > > > > Please note, there is no need to double escape the URL. > > > > On 17/06/16 13:00, "Cam Mac" <iucounu(a)gmail.com> wrote: > > > > Hi Pavel, > > > > I've tried those URLs (and quite a few other permutations) but get the > following errors: > > > > vpx://ARDA%5ccam@nssesxi-mgmt > /Systems/North%20Sutton%20Street/nssesxi/nssesxi04-mgmt?no_verify=1 > > > > Enter ARDA\cam's password for nssesxi-mgmt: > > error: failed to connect to the hypervisor > > error: internal error: Could not find host system specified in '/North > Sutton Street/Systems/nssesxi/nssesxi04-mgmt' > > > > vpx://ARDA%5ccam@nssesxi-mgmt > /North%20Sutton%20Street/Systems/nssesxi/nssesxi04-mgmt?no_verify=1 > > > > Enter ARDA\cam's password for nssesxi-mgmt: > > error: failed to connect to the hypervisor > > error: internal error: Could not find host system specified in '/North > Sutton Street/Systems/nssesxi/nssesxi04-mgmt' > > > > If I double escape the spaces with %2520, it reports it can't find the > datacenter. > > > > Cheers, > > > > Campbell > > > > > > > > On Fri, Jun 17, 2016 at 10:45 AM, Pavel Gashev <Pax(a)acronis.com> wrote: > > Cam, > > > > I believe the URL must be the following: > > vpx://ARDA%5ccam@nssesxi-mgmt > /Systems/North%20Sutton%20Street/nssesxi/nssesxi04-mgmt?no_verify=1 > > or > > vpx://ARDA%5ccam@nssesxi-mgmt > /North%20Sutton%20Street/Systems/nssesxi/nssesxi04-mgmt?no_verify=1 > > > > > > On 09/06/16 20:28, "users-bounces(a)ovirt.org on behalf of Cam Mac" < > users-bounces(a)ovirt.org on behalf of iucounu(a)gmail.com> wrote: > > > > Hi, > > > > I am trying to import and convert some VMWare guests from a VMWare cluster > with vCenter version 6, to a KVM (oVirt) host. The KVM node (RHEL 7.2) has > virt-v2v 1.28.1, though I've also tried using Fedora 23 which has 1.32.4. > > > > The details are: > > > > vCenter server: nssesxi-mgmt > > Datacenter name: North Sutton Street > > esxi server which runs the VM: nssesxi-mgmt04 > > folder name: Systems > > VM name: wvm2 > > cluster name: nssesxi > > > > I tried via the 'Import' option in the oVirt GUI, and put the details > above in, and after thinking about it for a while, it returns a 500 > internal server error. As I'm authing against AD, I put my username as > cam@ARDA. I have attached the log (gzipped). > > > > > > I've also tried via the command line, and the result is much the same. I > did post the below to the libvirt-users mailing list but have not had a > response, so I thought I'd see if anyone here might know what is going on. > > > > Unfortunately, spaces were put in the name of the datacenter, so I escape > them with %20 > > > > So the final URI is constructed as: > > > > vpx://<DOMAIN\user@<vcenter_server>/<folder>/<datacenter_name>/<esxi_server> > <vm_name> > > > > The error I get is: > > > > # virt-v2v -v -x -ic vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 > wvm2 > > virt-v2v: libguestfs 1.28.1 (x86_64) > > [ 0.0] Opening the source -i libvirt -ic vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 > wvm2 > > input_libvirt_vcenter_https: source: scheme vpx server nssesxi-mgmt > > Enter ARDA\cam's password for nssesxi-mgmt: > > libvirt: ESX Driver error : internal error: Could not find compute > resource specified in '/Systems/North Sutton Street/nssesxi04-mgmt' > > virt-v2v: error: internal error: invalid argument: cannot open libvirt > > connection > > 'vpx://ARDA%5ccam@nssesxi-mgmt > /Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' > > > > If reporting bugs, run virt-v2v with debugging enabled and include the > > complete output: > > > > virt-v2v -v -x [...] > > # > > > > > > # virsh -c 'vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' > list --all > > Enter ARDA\cam's password for nssesxi-mgmt: > > error: failed to connect to the hypervisor > > error: internal error: Could not find compute resource specified in > '/Systems/North Sutton Street/nssesxi04-mgmt' > > # > > > > I can access via http a list of VMs at the following URL: > > > > > https://nssesxi-mgmt/folder?dcPath=North%2520Sutton%2520Street&dsName=nsses… > > > > Below is the URI to the vm itself (once shutdown, it gets the name > 'vm2_1'): > > > > > https://nssesxi-mgmt/folder/wvm2_1?dcPath=North%2520Sutton%2520Street&dsNam… > > > > Any ideas? > > > > Cheers, > > > > -Cam > > > >

1 0

Issues importing VMs in oVirt
by Cam Mac 17 Jun '16

17 Jun '16

Hi, I am trying to import and convert some VMWare guests from a VMWare cluster with vCenter version 6, to a KVM (oVirt) host. The KVM node (RHEL 7.2) has virt-v2v 1.28.1, though I've also tried using Fedora 23 which has 1.32.4. The details are: vCenter server: nssesxi-mgmt Datacenter name: North Sutton Street esxi server which runs the VM: nssesxi-mgmt04 folder name: Systems VM name: wvm2 cluster name: nssesxi I tried via the 'Import' option in the oVirt GUI, and put the details above in, and after thinking about it for a while, it returns a 500 internal server error. As I'm authing against AD, I put my username as cam@ARDA. I have attached the log (gzipped). I've also tried via the command line, and the result is much the same. I did post the below to the libvirt-users mailing list but have not had a response, so I thought I'd see if anyone here might know what is going on. Unfortunately, spaces were put in the name of the datacenter, so I escape them with %20 So the final URI is constructed as: vpx://<DOMAIN\user@<vcenter_server>/<folder>/<datacenter_name>/<esxi_server> <vm_name> The error I get is: # virt-v2v -v -x -ic vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 wvm2 virt-v2v: libguestfs 1.28.1 (x86_64) [ 0.0] Opening the source -i libvirt -ic vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 wvm2 input_libvirt_vcenter_https: source: scheme vpx server nssesxi-mgmt Enter ARDA\cam's password for nssesxi-mgmt: libvirt: ESX Driver error : internal error: Could not find compute resource specified in '/Systems/North Sutton Street/nssesxi04-mgmt' virt-v2v: error: internal error: invalid argument: cannot open libvirt connection 'vpx://ARDA%5ccam@nssesxi-mgmt /Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] # # virsh -c 'vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' list --all Enter ARDA\cam's password for nssesxi-mgmt: error: failed to connect to the hypervisor error: internal error: Could not find compute resource specified in '/Systems/North Sutton Street/nssesxi04-mgmt' # I can access via http a list of VMs at the following URL: https://nssesxi-mgmt/folder?dcPath=North%2520Sutton%2520Street&dsName=nsses… Below is the URI to the vm itself (once shutdown, it gets the name 'vm2_1'): https://nssesxi-mgmt/folder/wvm2_1?dcPath=North%2520Sutton%2520Street&dsNam… Any ideas? Cheers, -Cam

2 3

host usb
by Fernando Fuentes 16 Jun '16

16 Jun '16

After upgrading my ovirt to 3.6 and configuring my host usb passthrough again. My vm is unable to start with the following error message: VM methub is down with error. Exit message: Node device not found: no node device with matching name 'usb' The host is running Centos 7 x86_64 Any ideas? Regards, -- Fernando Fuentes ffuentes(a)txweather.org http://www.txweather.org

4 7

VM get stuck randomly
by Christophe TREFOIS 16 Jun '16

16 Jun '16

Dear all, I have a problem since couple of weeks, where randomly 1 VM (not always the same) becomes completely unresponsive. We find this out because our Icinga server complains that host is down. Upon inspection, we find we can’t open a console to the VM, nor can we login. In oVirt engine, the VM looks like “up”. The only weird thing is that RAM usage shows 0% and CPU usage shows 100% or 75% depending on number of cores. The only way to recover is to force shutdown the VM via 2-times shutdown from the engine. Could you please help me to start debugging this? I can provide any logs, but I’m not sure which ones, because I couldn’t see anything with ERROR in the vdsm logs on the host. The host is running OS Version: RHEL - 7 - 1.1503.el7.centos.2.8 Kernel Version: 3.10.0 - 229.14.1.el7.x86_64 KVM Version: 2.1.2 - 23.el7_1.8.1 LIBVIRT Version: libvirt-1.2.8-16.el7_1.4 VDSM Version: vdsm-4.16.26-0.el7.centos SPICE Version: 0.12.4 - 9.el7_1.3 GlusterFS Version: glusterfs-3.7.5-1.el7 We use a locally exported gluster as storage domain (eg, storage is on the same machine exposed via gluster). No replica. We run around 50 VMs on that host. Thank you for your help in this, — Christophe

5 20

Problem with Getty and Serial Consoles
by Christophe TREFOIS 16 Jun '16

16 Jun '16

--_000_429D7E867135438DBFC2390B5891BEEAunilu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYW0gcnVubmluZyAzLjYuNiBhbmQgYW0gYWJsZSB0byBzZWxlY3QgYSBD b25zb2xlLCBob3dldmVyLCB0aGUgc2NyZWVuIGlzIGJsYWNrLg0KDQpPbiB0aGUgaHlwZXJ2aXNv ciwgSSB0cnkgdG8gc3RhcnQgZ2V0dHkgc2VydmljZSBtYW51YWxseSwgYW5kIGVuZCB1cCB3aXRo IGZvbGxvd2luZyBlcnJvciBpbiBqb3VybmFsDQoNCkp1biAxMyAxNzowMTowMSBlbGVwaGFudC1z ZXJ2ZXIubGNzYi51bmkubHU8aHR0cDovL2VsZXBoYW50LXNlcnZlci5sY3NiLnVuaS5sdT4gc3lz dGVtZFsxXTogU3RvcHBpbmcgdXNlci0wLnNsaWNlLg0KLS0gU3ViamVjdDogVW5pdCB1c2VyLTAu c2xpY2UgaGFzIGJlZ3VuIHNodXR0aW5nIGRvd24NCi0tIERlZmluZWQtQnk6IHN5c3RlbWQNCi0t IFN1cHBvcnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9z eXN0ZW1kLWRldmVsDQotLQ0KLS0gVW5pdCB1c2VyLTAuc2xpY2UgaGFzIGJlZ3VuIHNodXR0aW5n IGRvd24uDQpKdW4gMTMgMTc6MDE6MzcgZWxlcGhhbnQtc2VydmVyLmxjc2IudW5pLmx1PGh0dHA6 Ly9lbGVwaGFudC1zZXJ2ZXIubGNzYi51bmkubHU+IHN5c3RlbWRbMV06IEpvYiBkZXYtaHZjMC5k ZXZpY2Uvc3RhcnQgdGltZWQgb3V0Lg0KSnVuIDEzIDE3OjAxOjM3IGVsZXBoYW50LXNlcnZlci5s Y3NiLnVuaS5sdTxodHRwOi8vZWxlcGhhbnQtc2VydmVyLmxjc2IudW5pLmx1PiBzeXN0ZW1kWzFd OiBUaW1lZCBvdXQgd2FpdGluZyBmb3IgZGV2aWNlIGRldi1odmMwLmRldmljZS4NCi0tIFN1Ympl Y3Q6IFVuaXQgZGV2LWh2YzAuZGV2aWNlIGhhcyBmYWlsZWQNCi0tIERlZmluZWQtQnk6IHN5c3Rl bWQNCi0tIFN1cHBvcnQ6IGh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9zeXN0ZW1kLWRldmVsDQotLQ0KLS0gVW5pdCBkZXYtaHZjMC5kZXZpY2UgaGFzIGZhaWxl ZC4NCi0tDQotLSBUaGUgcmVzdWx0IGlzIHRpbWVvdXQuDQpKdW4gMTMgMTc6MDE6MzcgZWxlcGhh bnQtc2VydmVyLmxjc2IudW5pLmx1PGh0dHA6Ly9lbGVwaGFudC1zZXJ2ZXIubGNzYi51bmkubHU+ IHN5c3RlbWRbMV06IERlcGVuZGVuY3kgZmFpbGVkIGZvciBTZXJpYWwgR2V0dHkgb24gaHZjMC4N Ci0tIFN1YmplY3Q6IFVuaXQgc2VyaWFsLWdldHR5QGh2YzAuc2VydmljZTxtYWlsdG86c2VyaWFs LWdldHR5QGh2YzAuc2VydmljZT4gaGFzIGZhaWxlZA0KLS0gRGVmaW5lZC1CeTogc3lzdGVtZA0K LS0gU3VwcG9ydDogaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3N5c3RlbWQtZGV2ZWwNCi0tDQotLSBVbml0IHNlcmlhbC1nZXR0eUBodmMwLnNlcnZpY2U8bWFp bHRvOnNlcmlhbC1nZXR0eUBodmMwLnNlcnZpY2U+IGhhcyBmYWlsZWQuDQoNCkkgYW0gcnVubmlu ZyBDZW50T1MgNy4yLg0KDQpEb2VzIGFueWJvZHkgaGF2ZSBzb21lIHBvaW50ZXJzIG9uIHdoYXQg Y291bGQgYmUgdGhlIGlzc3VlIGhlcmU/DQoNClRoYW5rIHlvdSwNCg0K4oCUDQpDaHJpc3RvcGhl DQoNCg0KDQoNCg== --_000_429D7E867135438DBFC2390B5891BEEAunilu_ Content-Type: text/html; charset="utf-8" Content-ID: <18D1C523ED256D4194596A35D1804775(a)uni.lux> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KRGVhciBhbGwsDQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHJ1bm5pbmcgMy42 LjYgYW5kIGFtIGFibGUgdG8gc2VsZWN0IGEgQ29uc29sZSwgaG93ZXZlciwgdGhlIHNjcmVlbiBp cyBibGFjay48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPk9uIHRoZSBoeXBlcnZpc29yLCBJIHRyeSB0byBzdGFydCBnZXR0eSBzZXJ2aWNl IG1hbnVhbGx5LCBhbmQgZW5kIHVwIHdpdGggZm9sbG93aW5nIGVycm9yIGluIGpvdXJuYWw8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj5KdW4gMTMgMTc6MDE6MDEgPGEgaHJlZj0iaHR0cDovL2VsZXBoYW50LXNl cnZlci5sY3NiLnVuaS5sdSIgY2xhc3M9IiI+DQplbGVwaGFudC1zZXJ2ZXIubGNzYi51bmkubHU8 L2E+IHN5c3RlbWRbMV06IFN0b3BwaW5nIHVzZXItMC5zbGljZS48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+LS0gU3ViamVjdDogVW5pdCB1c2VyLTAuc2xpY2UgaGFzIGJlZ3VuIHNodXR0aW5nIGRvd248 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS0gRGVmaW5lZC1CeTogc3lzdGVtZDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4tLSBTdXBwb3J0OiA8YSBocmVmPSJodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3Jn L21haWxtYW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbCIgY2xhc3M9IiI+DQpodHRwOi8vbGlzdHMu ZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbDwvYT48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS0gVW5pdCB1c2VyLTAuc2xp Y2UgaGFzIGJlZ3VuIHNodXR0aW5nIGRvd24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkp1biAxMyAx NzowMTozNyA8YSBocmVmPSJodHRwOi8vZWxlcGhhbnQtc2VydmVyLmxjc2IudW5pLmx1IiBjbGFz cz0iIj4NCmVsZXBoYW50LXNlcnZlci5sY3NiLnVuaS5sdTwvYT4gc3lzdGVtZFsxXTogSm9iIGRl di1odmMwLmRldmljZS9zdGFydCB0aW1lZCBvdXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkp1biAx MyAxNzowMTozNyA8YSBocmVmPSJodHRwOi8vZWxlcGhhbnQtc2VydmVyLmxjc2IudW5pLmx1IiBj bGFzcz0iIj4NCmVsZXBoYW50LXNlcnZlci5sY3NiLnVuaS5sdTwvYT4gc3lzdGVtZFsxXTogVGlt ZWQgb3V0IHdhaXRpbmcgZm9yIGRldmljZSBkZXYtaHZjMC5kZXZpY2UuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPi0tIFN1YmplY3Q6IFVuaXQgZGV2LWh2YzAuZGV2aWNlIGhhcyBmYWlsZWQ8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+LS0gRGVmaW5lZC1CeTogc3lzdGVtZDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4tLSBTdXBwb3J0OiA8YSBocmVmPSJodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxt YW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbCIgY2xhc3M9IiI+DQpodHRwOi8vbGlzdHMuZnJlZWRl c2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vc3lzdGVtZC1kZXZlbDwvYT48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS0gVW5pdCBkZXYtaHZjMC5kZXZpY2Ug aGFzIGZhaWxlZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LS0gVGhlIHJlc3VsdCBpcyB0aW1lb3V0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5KdW4gMTMgMTc6 MDE6MzcgPGEgaHJlZj0iaHR0cDovL2VsZXBoYW50LXNlcnZlci5sY3NiLnVuaS5sdSIgY2xhc3M9 IiI+DQplbGVwaGFudC1zZXJ2ZXIubGNzYi51bmkubHU8L2E+IHN5c3RlbWRbMV06IERlcGVuZGVu Y3kgZmFpbGVkIGZvciBTZXJpYWwgR2V0dHkgb24gaHZjMC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ LS0gU3ViamVjdDogVW5pdCA8YSBocmVmPSJtYWlsdG86c2VyaWFsLWdldHR5QGh2YzAuc2Vydmlj ZSIgY2xhc3M9IiI+DQpzZXJpYWwtZ2V0dHlAaHZjMC5zZXJ2aWNlPC9hPiBoYXMgZmFpbGVkPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPi0tIERlZmluZWQtQnk6IHN5c3RlbWQ8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LS0gU3VwcG9ydDogPGEgaHJlZj0iaHR0cDovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3N5c3RlbWQtZGV2ZWwiIGNsYXNzPSIiPg0KaHR0cDovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N5c3RlbWQtZGV2ZWw8L2E+PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi0tPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0tIFVuaXQgPGEgaHJlZj0ibWFp bHRvOnNlcmlhbC1nZXR0eUBodmMwLnNlcnZpY2UiIGNsYXNzPSIiPnNlcmlhbC1nZXR0eUBodmMw LnNlcnZpY2U8L2E+IGhhcyBmYWlsZWQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGFtIHJ1bm5pbmcgQ2VudE9TIDcuMi48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRvZXMg YW55Ym9keSBoYXZlIHNvbWUgcG9pbnRlcnMgb24gd2hhdCBjb3VsZCBiZSB0aGUgaXNzdWUgaGVy ZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoYW5rIHlvdSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPuKAlDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DaHJpc3RvcGhlPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8cCBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwcHQ7IGxpbmUt aGVpZ2h0OiAxNnB4OyBjb2xvcjogcmdiKDMzLCAzMywgMzMpOyIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8L3A+DQombmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_429D7E867135438DBFC2390B5891BEEAunilu_--

2 2

Re: [ovirt-users] Issues importing VMs in oVirt
by Richard W.M. Jones 16 Jun '16

16 Jun '16

> ---------- Forwarded message ---------- > From: Cam Mac <iucounu(a)gmail.com> > Date: Thu, Jun 9, 2016 at 8:28 PM > Subject: [ovirt-users] Issues importing VMs in oVirt > To: users <users(a)ovirt.org> > > > So the final URI is constructed as: > > vpx://<DOMAIN\user@<vcenter_server>/<folder>/<datacenter_name>/<esxi_server> > <vm_name> > > The error I get is: > > # virt-v2v -v -x -ic > vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 > wvm2 > virt-v2v: libguestfs 1.28.1 (x86_64) > [ 0.0] Opening the source -i libvirt -ic > vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1 > wvm2 > input_libvirt_vcenter_https: source: scheme vpx server nssesxi-mgmt > Enter ARDA\cam's password for nssesxi-mgmt: > libvirt: ESX Driver error : internal error: Could not find compute resource > specified in '/Systems/North Sutton Street/nssesxi04-mgmt' > virt-v2v: error: internal error: invalid argument: cannot open libvirt > connection > 'vpx://ARDA%5ccam@nssesxi-mgmt > /Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' > > If reporting bugs, run virt-v2v with debugging enabled and include the > complete output: > > virt-v2v -v -x [...] > # > > > # virsh -c 'vpx://ARDA%5ccam@nssesxi-mgmt/Systems/North%20Sutton%20Street/nssesxi04-mgmt?no_verify=1' > list --all > Enter ARDA\cam's password for nssesxi-mgmt: > error: failed to connect to the hypervisor > error: internal error: Could not find compute resource specified in > '/Systems/North Sutton Street/nssesxi04-mgmt' I'm not sure what the problem is, although you are going about diagnosing the problem in the right way. I would try not escaping the spaces, double escaping them (%2520), and also removing elements from the path (especially "/Systems" which does not seem to be necessary) until you can get a URL that works. An alternative approach entirely is to use an OVA export: http://libguestfs.org/virt-v2v.1.html#input-from-vmware-ova Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

2 1

Two ovirt-engine manage one hypervisor
by Sandvik Agustin 16 Jun '16

16 Jun '16

Hi users, Good day, is it possible to configure two ovirt-engine to manage one hypervisor? My purpose for this is what if the first ovirt-engine fails, I still have the 2nd ovirt-engine to manage hypervisor. is this possible? or any suggestion similar to my purpose? TIA Sandvik

5 10

Problems exporting VM's
by Luciano Natale 15 Jun '16

15 Jun '16

Hi everyone. I've been having trouble when exporting VM's. I get error when moving image. I've created a whole new storage domain exclusive for this issue, and same thing happens. It's not always the same VM that fails, but once it fails on a certain storage domain, I cannot export it anymore. Please tell me which logs are relevant so i can post them and any other relevant iformation I can provide, and maybe someone can help me get through this problem. Ovirt version is 3.5.4.2-1.el6. Hosted engines is CentOS 6. Hosts are CentOS 7. VM's are all CentOS 7, except for two that are CentOS 6 and Windows 7. Please excuse my bad english! Thanks in advance! -- Luciano Natale

3 4

Hosted Engine Woes
by Nic Seltzer 15 Jun '16

15 Jun '16

Hello! I'm looking for someone who can help me out with a hosted-engine setup that I have. I experienced a power event a couple of weeks ago. Initially, things seemed to have come back fine, but the other day, I noticed that one of the nodes for the cluster was down. I tried to drop it into maintenance mode (which never completed) and reboot it then "Confirm the Host has been rebooted". Neither of these steps allowed the host to re-enter the cluster. Has anyone encountered this? At this point, I'd like to reboot the hosted-engine, but I can't find documentation instructing me on "how". I'm also open to other suggestions or references to documentation that will help triage my issue. Thanks! nic

3 4

WARNING: lvmetad is running but disabled. Restart lvmetad before enabling it!
by Claude Durocher 15 Jun '16

15 Jun '16

------=_=-_OpenGroupware_org_NGMime-1065-1466026308.760533-2------ content-type: text/plain; charset=utf-8 content-length: 330 content-transfer-encoding: quoted-printable I get this warning in vdsm logs with ovirt 3.6 installed on CentOS 7.2 = : WARNING: lvmetad is running but disabled. Restart lvmetad before enabli= ng it! The service is effectively running but disabled in systemd. In /etc/lvm= /lvm.conf I have : use=5Flvmetad =3D 1 Can someone please advise on how to solve this? =C2=A0 ------=_=-_OpenGroupware_org_NGMime-1065-1466026308.760533-2------ content-type: text/html; charset=utf-8 content-length: 398 content-transfer-encoding: quoted-printable <html>I get this warning in vdsm logs with ovirt 3.6 installed on CentO= S 7.2 : WARNING: lvmetad is running but disabled. Restart lv= metad before enabling it! The service is effectively running= but disabled in systemd. In /etc/lvm/lvm.conf I have : use=5F= lvmetad =3D 1 Can someone please advise on how to solve this= ?  </html> ------=_=-_OpenGroupware_org_NGMime-1065-1466026308.760533-2--------

2 1