[ovirt-users] Bug in the engine-backup script when no attached TTY -- Easy fix

[eshwayri]

The output() function.  This line:

printf "%s\n" "${m}"

It will fail if there is no attached TTY, which will set the exit code to 1, 
which in turn will trigger the cleanup() function notifying the engine that the 
backup failed.  This ironically happens when it should be writing "Done." and 
exiting after a successful backup.  Fix I used was to change it to:

printf "%s\n" "${m}" >> "${LOG}"

You can't assume attached TTY since a lot of people like me want to run this as 
part of a pre/post script to an automated backup program.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RKWW2O3XFCG6F3BZUOO264QXDFY4J4YJ/

[ovirt-users] BUG: after upgrading 4.4.2 to 4.4.3 ISO Domain show empty list

[Tarun Kushwaha]

I have upgraded 4.4.2 to 4.4.3 afterthat ISO Domain is not showing any ISO 
files .its show empty list i think this is bug in 4.4.3
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NIDCLKBZXJTXOENFIJZFC6HFXURGP6OI/

[ovirt-users] Bug with ovirt-hosted-engine-setup

[dan . creed]

This is 100% repeatable for me.  Brand new environment, all using the ovirt 
node ISO.  4.3.9 downloaded a couple of days ago. 


[ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 5, "changed": true, 
"cmd": ["hosted-engine", "--reinitialize-lockspace", "--force"], "delta": 
"0:00:00.412864", "end": "2020-05-19 09:23:03.856435", "msg": "non-zero return 
code", "rc": 1, "start": "2020-05-19 09:23:03.443571", "stderr": "Traceback 
(most recent call last):\n  File \"/usr/lib64/python2.7/runpy.py\", line 162, 
in _run_module_as_main\n\"__main__\", fname, loader, pkg_name)\n  File 
\"/usr/lib64/python2.7/runpy.py\", line 72, in _run_code\nexec code in 
run_globals\n  File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/reinitialize_lockspace.py\",
 line 30, in \nha_cli.reset_lockspace(force)\n  File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py\", 
line 286, in reset_lockspace\nstats = broker.get_stats_from_storage()\n  
File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py\", 
line 146, in get_stats_from_storage\nresult = self
 ._proxy.get_stats()\n  File \"/usr/lib64/python2.7/xmlrpclib.py\", line 1233, 
in __call__\nreturn self.__send(self.__name, args)\n  File 
\"/usr/lib64/python2.7/xmlrpclib.py\", line 1591, in __request\n
verbose=self.__verbose\n  File \"/usr/lib64/python2.7/xmlrpclib.py\", line 
1273, in request\nreturn self.single_request(host, handler, request_body, 
verbose)\n  File \"/usr/lib64/python2.7/xmlrpclib.py\", line 1301, in 
single_request\nself.send_content(h, request_body)\n  File 
\"/usr/lib64/python2.7/xmlrpclib.py\", line 1448, in send_content\n
connection.endheaders(request_body)\n  File 
\"/usr/lib64/python2.7/httplib.py\", line 1052, in endheaders\n
self._send_output(message_body)\n  File \"/usr/lib64/python2.7/httplib.py\", 
line 890, in _send_output\nself.send(msg)\n  File 
\"/usr/lib64/python2.7/httplib.py\", line 852, in send\nself.connect()\n  
File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/unixrpc.py\", 
line 60, in connect\nself.
 sock.connect(base64.b16decode(self.host))\n  File 
\"/usr/lib64/python2.7/socket.py\", line 224, in meth\nreturn 
getattr(self._sock,name)(*args)\nsocket.error: [Errno 2] No such file or 
directory", "stderr_lines": ["Traceback (most recent call last):", "  File 
\"/usr/lib64/python2.7/runpy.py\", line 162, in _run_module_as_main", "
\"__main__\", fname, loader, pkg_name)", "  File 
\"/usr/lib64/python2.7/runpy.py\", line 72, in _run_code", "exec code in 
run_globals", "  File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/reinitialize_lockspace.py\",
 line 30, in ", "ha_cli.reset_lockspace(force)", "  File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py\", 
line 286, in reset_lockspace", "stats = broker.get_stats_from_storage()", " 
 File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py\", 
line 146, in get_stats_from_storage", "result = self._proxy.get_stats()", " 
 File \"/usr/lib64/python2.7/
 xmlrpclib.py\", line 1233, in __call__", "return self.__send(self.__name, 
args)", "  File \"/usr/lib64/python2.7/xmlrpclib.py\", line 1591, in 
__request", "verbose=self.__verbose", "  File 
\"/usr/lib64/python2.7/xmlrpclib.py\", line 1273, in request", "return 
self.single_request(host, handler, request_body, verbose)", "  File 
\"/usr/lib64/python2.7/xmlrpclib.py\", line 1301, in single_request", "
self.send_content(h, request_body)", "  File 
\"/usr/lib64/python2.7/xmlrpclib.py\", line 1448, in send_content", "
connection.endheaders(request_body)", "  File 
\"/usr/lib64/python2.7/httplib.py\", line 1052, in endheaders", "
self._send_output(message_body)", "  File \"/usr/lib64/python2.7/httplib.py\", 
line 890, in _send_output", "self.send(msg)", "  File 
\"/usr/lib64/python2.7/httplib.py\", line 852, in send", "self.connect()", 
"  File 
\"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/unixrpc.py\", 
line 60, in connect", "self.sock.connect(base
 64.b16decode(self.host))", "  File \"/usr/lib64/python2.7/socket.py\", line 
224, in meth", "return getattr(self._sock,name)(*args)", "socket.error: 
[Errno 2] No such file or directory"], "stdout": "", "stdout_lines": []}
[ ERROR ] Failed to execute stage 'Closing up': Failed executing 
ansible-playbook
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/RQGXUAOB2O343MC3VSKZCOB3F4F52MTZ/

[ovirt-users] Bug 1666795 - Related? - VM's don't start after shutdown on FCP

[nardusg]

Hi There

Wonder if this issue is related to our problem and if there is a way around it. 
We upgraded from 4.2.8. to 4.3.2. Now when we start some of the VM's fail to 
start. You need to deattach the disks, create new VM, reattach the disks to the 
new VM and then the new VM starts. 

Thanks

Nar
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DYPBUQYBGMGOCOLVP6RYO2VXSNNHYXTW/

[ovirt-users] Bug or feature? Thin provision RAW disk images take all space in advance

[andre...@starlett.lv]

Hi,

Run into strange problem with newly installed latest 4.1.
Defined local storage domain.
Create virtual disk - thin provisioning (in web interface) makes RAW
images, and PREALLOCATES to full size instead of min size 1GB.
Preallocation occurs even before formatting to ext4.
Tried several times, same result.

How to fix this behavior?
Thanks in advance.
Andrei
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] bug disk upload

[Nikolai Kuzmich]

Description of problem:
Try to upload an image using the GUI, disk upload succefully, but it's empty

ovirt-engine.noarch   4.1.2.2-1.el7.centos
ovirt-imageio-common.noarch  1.0.0-1.el7
ovirt-imageio-proxy.noarch   1.0.0-0.201701151456.git89ae3b4.el7.centos
vdsm.x86_644.19.15-1.el7.centos

before upload
md5sum manageiq-ovirt-fine-2.ova
e0585fb92301dd676cb22ba1df9e5477  manageiq-ovirt-fine-2.ova
qemu-img info manageiq-ovirt-fine-2.ova
image: manageiq-ovirt-fine-2.ova
file format: raw
virtual size: 1.3G (1359610880 bytes)
disk size: 1.3G


Steps to Reproduce:

1.   Upload disk manageiq with the above parameters

2.   After upload

qemu-img info c31bac64-09d5-43a6-bf4c-c502b55cf997

image: c31bac64-09d5-43a6-bf4c-c502b55cf997

file format: raw

virtual size: 2.0G (2147483648 bytes)

disk size: 1.3G

3.   Create VM and running

4.   Disk not bootable and empty

If  tar -xvf manageiq-ovirt-fine-2.ova
Before upload:
qemu-img info f6054145-e0d3-4e43-a034-92b00b1e31f8
image: f6054145-e0d3-4e43-a034-92b00b1e31f8
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 4.0G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
after upload:
qemu-img info 4a7f6769-5ce7-4428-8f51-604042c0d424
image: 4a7f6769-5ce7-4428-8f51-604042c0d424
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 4.1G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
Upload successfully, disk bootable, vm starts

Kind regards,
Nikolai Kuzmich
ARTEZIO
System Administrator

e-mail: nikolai.kuzm...@artezio.com
skype: artezio_nkuzmich_1
address: Dzyarzhynskaga str, 8.
Minsk, 220036, Belarus

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] bug with ConsoleWriter ?

[Fabrice Bacchella]

> Le 22 avr. 2017 à 10:39, Juan Hernández  a écrit :
> 
> 

> I also wonder why do you need to convert objects to XML explicitly. Can
> you elaborate on what is your need?
> 

I want to have a generic export for many types, as I migrating my ovirtcmd tool 
(https://github.com/fbacchella/ovirtcmd) to sdk4.

It's used by the export verb: https://github.com/fbacchella/ovirtcmd#exporting


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] bug with ConsoleWriter ?

[Juan Hernández]

On 04/21/2017 05:26 PM, Fabrice Bacchella wrote:
> I'm trying to dump informations about console with the following code:
> 
> vm = vms_service.list(search='name=fa41')[0]
> 
> # Find the service that manages the graphics consoles of the virtual machine:
> vm_service = vms_service.vm_service(vm.id)
> consoles_service = vm_service.graphics_consoles_service()
> console_type = consoles_service.list()[0]
> 
> console_type = connection.follow_link(console_type)
> buf = None
> writer = None
> buf = io.BytesIO()
> writer = xml.XmlWriter(buf, indent=True)
> ConsoleWriter.write_one(console_type, writer)
> writer.flush()
> print buf.getvalue()
> But i got the following result :
> 
> Traceback (most recent call last):
>   File "./export_console.py", line 69, in 
> ConsoleWriter.write_one(console_type, writer)
>   File ".../venv/lib/python2.7/site-packages/ovirtsdk4/writers.py", line 
> 1262, in write_one
> if obj.enabled is not None:
> 
> If I add print console_type.__dict__, it contains:
> 
> {'_address': None, '_instance_type': None, '_href': 
> '/ovirt-engine/api/vms/61a6de0a-2a21-4e90-bc20-29e3f0cd0ad8/graphicsconsoles/7370696365',
>  '_description': None, '_tls_port': None, '_comment': None, '_port': None, 
> '_name': None, '_vm': , 
> '_protocol': , '_template': None, '_id': 
> '7370696365'}
> 
> 
> Did I miss something, or is that a but with the console writer ? 

The problem is that you are trying to use the ConsoleWriter class to
write something that isn't a Console. The GraphicsConsoleService.list
method returns a list of objects of type GraphicsConsole, not Console.
So you need to use GraphicsConsoleWriter.

Note that once you have the virtual machine you can obtain the graphics
consoles directly using the 'follow_link' method, no need to use the
intermediate services. For example:

  vm = ...
  console = connection.follow_link(vm.graphics_consoles)[0]

Remember that the WhateverWriter classes are an implementation detail,
and that they may change or disappear without notice. If you need to
convert objects to XML use the generic Writer.write method that will be
introduced by this patch:

  Add generic writer
  https://gerrit.ovirt.org/75699

Ondra, in what version of the SDK do we plan to include that enhancement?

I also wonder why do you need to convert objects to XML explicitly. Can
you elaborate on what is your need?

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] bug with ConsoleWriter ?

[Fabrice Bacchella]

I'm trying to dump informations about console with the following code:

vm = vms_service.list(search='name=fa41')[0]

# Find the service that manages the graphics consoles of the virtual machine:
vm_service = vms_service.vm_service(vm.id)
consoles_service = vm_service.graphics_consoles_service()
console_type = consoles_service.list()[0]

console_type = connection.follow_link(console_type)
buf = None
writer = None
buf = io.BytesIO()
writer = xml.XmlWriter(buf, indent=True)
ConsoleWriter.write_one(console_type, writer)
writer.flush()
print buf.getvalue()
But i got the following result :

Traceback (most recent call last):
  File "./export_console.py", line 69, in 
ConsoleWriter.write_one(console_type, writer)
  File ".../venv/lib/python2.7/site-packages/ovirtsdk4/writers.py", line 1262, 
in write_one
if obj.enabled is not None:

If I add print console_type.__dict__, it contains:

{'_address': None, '_instance_type': None, '_href': 
'/ovirt-engine/api/vms/61a6de0a-2a21-4e90-bc20-29e3f0cd0ad8/graphicsconsoles/7370696365',
 '_description': None, '_tls_port': None, '_comment': None, '_port': None, 
'_name': None, '_vm': , '_protocol': 
, '_template': None, '_id': '7370696365'}


Did I miss something, or is that a but with the console writer ? 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] BUG: "interface" field empty in "attach disk" windows Ovirt 4.0.5

[Andrea Ghelardi]

Done as requested; filed https://bugzilla.redhat.com/show_bug.cgi?id=1408134

Thank you for your help!
Andrea


From: Fred Rolland [mailto:froll...@redhat.com]
Sent: Thursday, December 22, 2016 8:01 AM
To: Andrea Ghelardi 
Cc: users 
Subject: Re: [ovirt-users] BUG: "interface" field empty in "attach disk" 
windows Ovirt 4.0.5

Thanks for reporting.
Can you open a bug ?

https://www.ovirt.org/community/get-involved/report-a-bug/

On Wed, Dec 21, 2016 at 7:06 PM, Andrea Ghelardi 
mailto:a.ghela...@iontrading.com>> wrote:
Hello team,
FYI there is a minor, cosmetic bug in 4.0.5 GUI


1)  Select VM -> tab DISKS

2)  Click Attach -> “Attach” window pop-ups with list of available disks  
(attach PNG01)

3)  You can click and select interface type (attach PNG02)

4)  If you select disk to attach, Interface becomes blank (PNG03 and PNG04)

5)  If you move mouse up and down, correct entry is shown  (and just that 
one) PNG05 and PNG06

6)  Once selected, filed is still blank (in this case, Virtio-scsi) PNG07

7)  Disk is attached correctly, according to option “blindly” selected PNG08

Cheers
AG


Andrea Ghelardi

+39 050 2203 71 | www.iongroup.com<http://www.iongroup.com/> | 
a.ghela...@iontrading.com<mailto:a.ghela...@iontrading.com>
Via San Martino, 52 – 56125 Pisa - ITALY

This email and any attachments may contain information which is confidential 
and/or privileged. The information is intended exclusively for the addressee 
and the views expressed may not be official policy, but the personal views of 
the originator. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of the contents is prohibited. If you 
have received this email and any file transmitted with it in error, please 
notify the sender by telephone or return email immediately and delete the 
material from your computer. Internet communications are not secure and ION 
Trading is not responsible for their abuse by third parties, nor for any 
alteration or corruption in transmission, nor for any damage or loss caused by 
any virus or other defect. ION Trading accepts no liability or responsibility 
arising out of or in any way connected to this email.

[iON_HBlu_small]
Automation through innovation


___
Users mailing list
Users@ovirt.org<mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] BUG: "interface" field empty in "attach disk" windows Ovirt 4.0.5

[Fred Rolland]

Thanks for reporting.

Can you open a bug ?

https://www.ovirt.org/community/get-involved/report-a-bug/

On Wed, Dec 21, 2016 at 7:06 PM, Andrea Ghelardi 
wrote:

> Hello team,
>
> FYI there is a minor, cosmetic bug in 4.0.5 GUI
>
>
>
> 1)  Select VM -> tab DISKS
>
> 2)  Click Attach -> “Attach” window pop-ups with list of available
> disks  (attach PNG01)
>
> 3)  You can click and select interface type (attach PNG02)
>
> 4)  If you select disk to attach, Interface becomes blank (PNG03 and
> PNG04)
>
> 5)  If you move mouse up and down, correct entry is shown  (and just
> that one) PNG05 and PNG06
>
> 6)  Once selected, filed is still blank (in this case, Virtio-scsi)
> PNG07
>
> 7)  Disk is attached correctly, according to option “blindly”
> selected PNG08
>
>
>
> Cheers
>
> AG
>
>
>
>
>
> *Andrea Ghelardi*
>
>
>
> +39 050 2203 71 *| *www.iongroup.com *| **a.ghela...@iontrading.com
> *
>
> Via San Martino, 52 – 56125 Pisa - ITALY
>
>
>
> *This email and any attachments may contain information which is
> confidential and/or privileged. The information is intended exclusively for
> the addressee and the views expressed may not be official policy, but the
> personal views of the originator. If you are not the intended recipient, be
> aware that any disclosure, copying, distribution or use of the contents is
> prohibited. If you have received this email and any file transmitted with
> it in error, please notify the sender by telephone or return email
> immediately and delete the material from your computer. Internet
> communications are not secure and ION Trading is not responsible for their
> abuse by third parties, nor for any alteration or corruption in
> transmission, nor for any damage or loss caused by any virus or other
> defect. ION Trading accepts no liability or responsibility arising out of
> or in any way connected to this email.*
>
>
>
> [image: iON_HBlu_small]
>
> Automation through innovation
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] bug in disks QOS

[Fabrice Bacchella]

Another strange thing with disk profile

When I create a disk in the tree System/Data Centers//Storage/, tab Disks, the disk profile is requested.

But once created, I can't change it any more.There is no "edit" or any other 
option on that screen.

I need to attach a disk to a VM, go to the Disks tab for this VM to this time 
get a edit option where I can see a screen that present this option, but ignore 
it any way.



> Le 27 mars 2016 à 16:03, Roy Golan  a écrit :
> 
> 
> 
> On Fri, Mar 25, 2016 at 12:22 PM, Fabrice Bacchella 
> mailto:fabrice.bacche...@orange.fr>> wrote:
> I attached a image disk to a VM , but set it using the wrong disk profile, I 
> powered off the VM, and then tried to change it on the GUI.
> 
> The operation in the GUI is ok.
> 
> Need more of the log if you don't see the profiles changing. Please share a 
> bigger w or the whole log. 
>  
> 
> 
> But nothing is done.
> 
> And in the log I get:
> 2016-03-25 10:12:10,467 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Lock Acquired to object 
> 'EngineLock:{exclusiveLocks='null', 
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,608 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Running command: UpdateVmDiskCommand internal: 
> false. Entities affected :  ID: 55d2be6b-7a78-4712-82be-b725b7812db8 Type: 
> DiskAction group EDIT_DISK_PROPERTIES with role type USER
> 2016-03-25 10:12:10,794 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Lock freed to object 
> 'EngineLock:{exclusiveLocks='null', 
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,808 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (default task-26) [2f3b7d9] Correlation ID: 2f3b7d9, Call Stack: null, Custom 
> Event ID: -1, Message: VM test test_Disk3 disk was updated by FA4@apachesso.
> 
> 
> It says "with role type USER" but I'm logged as a super admin
> 
> 
> I know its confusing a bit.  
> 
> The RoleType is an indirect property of an action, in that case UpdateVmDisk. 
> Every action has an ActionGroup, and each Action has a RoleType, and this is 
> used to allow/prevent or display behaviour. 
> 
> So looking at VdcActionType.java and ActionGroup.java, you can see the 
> declaration.
> 
> VdcActionType.java
> UpdateVmDisk(34, ActionGroup.CONFIGURE_VM_STORAGE, false, 
> QuotaDependency.STORAGE),
> ActionGroup.java
> CONFIGURE_VM_STORAGE(10, RoleType.USER, true, ApplicationMode.VirtOnly),
> 
> 
> 
> The set up is totally new, on dedicated centos 7.2, running 
> 3.6.3.4-1.el7.centos.
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org 
> http://lists.ovirt.org/mailman/listinfo/users 
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] bug in disks QOS

[Fabrice Bacchella]

I retried that on a totally reinstalled ovirt stack, using 
3.6.5.1-1.el7.centos. The cluster and pg database is new too.

I'm checking log with tail -f /var/log/ovirt-engine/*. Nothing else is logged. 
Where can I found more informations ?

But isn'it saying that ACTION_TYPE_FAILED_VM_IS_LOCKED ?

> Le 27 mars 2016 à 16:03, Roy Golan  a écrit :
> 
> 
> 
> On Fri, Mar 25, 2016 at 12:22 PM, Fabrice Bacchella 
>  wrote:
> I attached a image disk to a VM , but set it using the wrong disk profile, I 
> powered off the VM, and then tried to change it on the GUI.
> 
> The operation in the GUI is ok.
> 
> Need more of the log if you don't see the profiles changing. Please share a 
> bigger w or the whole log. 
>  
> 
> 
> But nothing is done.
> 
> And in the log I get:
> 2016-03-25 10:12:10,467 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Lock Acquired to object 
> 'EngineLock:{exclusiveLocks='null', 
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,608 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Running command: UpdateVmDiskCommand internal: 
> false. Entities affected :  ID: 55d2be6b-7a78-4712-82be-b725b7812db8 Type: 
> DiskAction group EDIT_DISK_PROPERTIES with role type USER
> 2016-03-25 10:12:10,794 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
> (default task-26) [2f3b7d9] Lock freed to object 
> 'EngineLock:{exclusiveLocks='null', 
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,808 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (default task-26) [2f3b7d9] Correlation ID: 2f3b7d9, Call Stack: null, Custom 
> Event ID: -1, Message: VM test test_Disk3 disk was updated by FA4@apachesso.
> 
> 
> It says "with role type USER" but I'm logged as a super admin
> 
> 
> I know its confusing a bit.  
> 
> The RoleType is an indirect property of an action, in that case UpdateVmDisk. 
> Every action has an ActionGroup, and each Action has a RoleType, and this is 
> used to allow/prevent or display behaviour. 
> 
> So looking at VdcActionType.java and ActionGroup.java, you can see the 
> declaration.
> 
> VdcActionType.java
> UpdateVmDisk(34, ActionGroup.CONFIGURE_VM_STORAGE, false, 
> QuotaDependency.STORAGE),
> ActionGroup.java
> CONFIGURE_VM_STORAGE(10, RoleType.USER, true, ApplicationMode.VirtOnly),
> 
> 
> 
> The set up is totally new, on dedicated centos 7.2, running 
> 3.6.3.4-1.el7.centos.
> 
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [Bug 1319323] New: VLAN ID check for duplicates

[Bill James]

Any one have an idea on how to "hack" or "patch" ovirt so that instead 
of rejecting a new network with duplicate vlan id it would just warn, or 
even just ignore?



On 03/18/2016 01:54 PM, bugzi...@redhat.com wrote:

https://bugzilla.redhat.com/show_bug.cgi?id=1319323

 Bug ID: 1319323
Summary: VLAN ID check for duplicates
Product: ovirt-engine
Version: 3.3
  Component: RFEs
   Severity: medium
   Assignee: sher...@redhat.com
   Reporter: bill.ja...@j2.com
 QA Contact: gkl...@redhat.com
 CC: b...@ovirt.org
 oVirt Team: Network
  Flags: testing_ack?
  Flags: planning_ack?



Description of problem:
Adding new network with vlan tag, ovirt doesn't allow duplicate VLAN IDs.
But it should be allowed, because if you are using multiple interfaces you can
have the same vlan ID as long as they aren't assigned to the same interface on
the hardware node.


Version-Release number of selected component (if applicable):
ovirt-engine-3.6.3.4-1.el7.centos.noarch


How reproducible:
100%

Steps to Reproduce:
1. Just add network with same vlan id as an already added interface.

2.
3.

Actual results:
See email thread labeled "Re: [ovirt-users] multiple NICs VLAN ID conflict".
GUI says vlan already used.

Expected results:
Duplicate VLAN ID should be checked when you are assign network to the hardware
node, not when creating the interface.


Additional info:
Trying to work around this with vdsm hooks in before_network_setup,
after_get_caps and after_get_stats is very difficult to get it to work right.
(see email thread)


Yaniv Kaul  2016-03-20 03:12:24 EDT

Perhaps only WARN.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] bug in disks QOS

[Roy Golan]

On Fri, Mar 25, 2016 at 12:22 PM, Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

> I attached a image disk to a VM , but set it using the wrong disk profile,
> I powered off the VM, and then tried to change it on the GUI.
>
> The operation in the GUI is ok.
>
> Need more of the log if you don't see the profiles changing. Please share
a bigger w or the whole log.



But nothing is done.
>
> And in the log I get:
> 2016-03-25 10:12:10,467 INFO
> [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (default task-26) [2f3b7d9]
> Lock Acquired to object 'EngineLock:{exclusiveLocks='null',
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,608 INFO
> [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (default task-26) [2f3b7d9]
> Running command: UpdateVmDiskCommand internal: false. Entities affected :
> ID: 55d2be6b-7a78-4712-82be-b725b7812db8 Type: DiskAction group
> EDIT_DISK_PROPERTIES with role type USER
> 2016-03-25 10:12:10,794 INFO
> [org.ovirt.engine.core.bll.UpdateVmDiskCommand] (default task-26) [2f3b7d9]
> Lock freed to object 'EngineLock:{exclusiveLocks='null',
> sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c= ACTION_TYPE_FAILED_VM_IS_LOCKED>]'}'
> 2016-03-25 10:12:10,808 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-26) [2f3b7d9] Correlation ID: 2f3b7d9, Call Stack: null,
> Custom Event ID: -1, Message: VM test test_Disk3 disk was updated by
> FA4@apachesso.
>
>
> It says "with role type USER" but I'm logged as a super admin
>
>
I know its confusing a bit.

The RoleType is an indirect property of an action, in that case
UpdateVmDisk. Every action has an ActionGroup, and each Action has a
RoleType, and this is used to allow/prevent or display behaviour.

So looking at VdcActionType.java and ActionGroup.java, you can see the
declaration.

VdcActionType.java

UpdateVmDisk(34, ActionGroup.CONFIGURE_VM_STORAGE, false,
QuotaDependency.STORAGE),

ActionGroup.java

CONFIGURE_VM_STORAGE(10, RoleType.USER, true, ApplicationMode.VirtOnly),




The set up is totally new, on dedicated centos 7.2, running
> 3.6.3.4-1.el7.centos.
>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] bug in disks QOS

[Fabrice Bacchella]

I attached a image disk to a VM , but set it using the wrong disk profile, I 
powered off the VM, and then tried to change it on the GUI.

The operation in the GUI is ok.

But nothing is done.

And in the log I get:
2016-03-25 10:12:10,467 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
(default task-26) [2f3b7d9] Lock Acquired to object 
'EngineLock:{exclusiveLocks='null', 
sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c=]'}'
2016-03-25 10:12:10,608 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
(default task-26) [2f3b7d9] Running command: UpdateVmDiskCommand internal: 
false. Entities affected :  ID: 55d2be6b-7a78-4712-82be-b725b7812db8 Type: 
DiskAction group EDIT_DISK_PROPERTIES with role type USER
2016-03-25 10:12:10,794 INFO  [org.ovirt.engine.core.bll.UpdateVmDiskCommand] 
(default task-26) [2f3b7d9] Lock freed to object 
'EngineLock:{exclusiveLocks='null', 
sharedLocks='[a32e1043-a5a5-4e4c-8436-f7b7a4ff644c=]'}'
2016-03-25 10:12:10,808 INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-26) [2f3b7d9] Correlation ID: 2f3b7d9, Call Stack: null, Custom Event ID: 
-1, Message: VM test test_Disk3 disk was updated by FA4@apachesso.


It says "with role type USER" but I'm logged as a super admin

The set up is totally new, on dedicated centos 7.2, running 
3.6.3.4-1.el7.centos.



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [BUG] Cannot remove quota

[zhangjian2011]

Hi, Ondra

It works, thanks.

Jian

On 01/18/2016 07:44 PM, Ondra Machacek wrote:

Hi Jian,

if you select your DataCenter in tree pane on the left,
then you will see 'Quota' tab between main tabs.

Ondra

On 01/18/2016 02:23 AM, zhangjian2011 wrote:

Hi, Ondra

  If I set DataCenter 's  Quota Mode to Disabled, then the quota
  tab will be hidden as below.

(the quota tab disappeared) So I can't remove quota. Is there any other
way to delete it??






Regards,
Jian


On 01/15/2016 11:29 PM, Ondra Machacek wrote:

One possible way is to change DataCenter quota mode to Disabled.
Then you can remove quota which is assigned to vm.

On 01/15/2016 10:41 AM, zhangjian2011 wrote:


HI, all:

  I found that if the quota is applied to a VM,

then the quota can’t be remove. (Even if I change DataCenter to Audit
Mode)

  the screenshot as below:

  NOW I found the workaround is delete vm.

  How can I remove the quota  without delete the VM



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users















___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [BUG] Cannot remove quota

[Ondra Machacek]

Hi Jian,

if you select your DataCenter in tree pane on the left,
then you will see 'Quota' tab between main tabs.

Ondra

On 01/18/2016 02:23 AM, zhangjian2011 wrote:

Hi, Ondra

  If I set DataCenter 's  Quota Mode to Disabled, then the quota
  tab will be hidden as below.

(the quota tab disappeared) So I can't remove quota. Is there any other
way to delete it??






Regards,
Jian


On 01/15/2016 11:29 PM, Ondra Machacek wrote:

One possible way is to change DataCenter quota mode to Disabled.
Then you can remove quota which is assigned to vm.

On 01/15/2016 10:41 AM, zhangjian2011 wrote:


HI, all:

  I found that if the quota is applied to a VM,

then the quota can’t be remove. (Even if I change DataCenter to Audit
Mode)

  the screenshot as below:

  NOW I found the workaround is delete vm.

  How can I remove the quota  without delete the VM



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users








___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [BUG] Cannot remove quota

[zhangjian2011]

Hi, Ondra

 If I set DataCenter 's  Quota Mode to Disabled, then the quota 
 tab will be hidden as below.


(the quota tab disappeared) So I can't remove quota. Is there any other 
way to delete it??







Regards,
Jian


On 01/15/2016 11:29 PM, Ondra Machacek wrote:

One possible way is to change DataCenter quota mode to Disabled.
Then you can remove quota which is assigned to vm.

On 01/15/2016 10:41 AM, zhangjian2011 wrote:


HI, all:

  I found that if the quota is applied to a VM,

then the quota can’t be remove. (Even if I change DataCenter to Audit 
Mode)


  the screenshot as below:

  NOW I found the workaround is delete vm.

  How can I remove the quota  without delete the VM



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users









___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [BUG] Cannot remove quota

[Ondra Machacek]

One possible way is to change DataCenter quota mode to Disabled.
Then you can remove quota which is assigned to vm.

On 01/15/2016 10:41 AM, zhangjian2011 wrote:


HI, all:

  I found that if the quota is applied to a VM,

then the quota can’t be remove. (Even if I change DataCenter to Audit Mode)

  the screenshot as below:

  NOW I found the workaround is delete vm.

  How can I remove the quota  without delete the VM



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [BUG] Cannot remove quota

[zhangjian2011]

HI, all:

 I found that if the quota is applied to a VM,

then the quota can’t be remove. (Even if I change DataCenter to Audit Mode)

 the screenshot as below:

 NOW I found the workaround is delete vm.

 How can I remove the quota  without delete the VM



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug?

[Ondra Machacek]

Hi,

this error usually mean, that your user can't be translated to 
userprincipalname.

The strange thing is that it worked, but stopped.
Can you please assure, that your user has userprincipalname atttribute?

$ ldapsearch -H ldap://ldapserver:3268/ -x -D 'searchu...@company.be' -w 
password -b '' '(cn=users)' userPrincipalName


If your user has some special upn suffix, then please use whole 
userprincipalname in user_name field.


Ondra

On 11/27/2015 07:07 AM, Koen Vanoppen wrote:

Hi All,

One of our users on ovirt who always was able to login with the AD 
account, now all of a sudden can't login anymore... I already tried 
kicking him out and putting him back in again, but no change... 
Following error is appearing in the log file when he logs in:


2015-11-27 07:01:00,418 ERROR 
[org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] 
(ajp--127.0.0.1-8702-1) Error during CanDoActionFailure.: Class: class 
org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException

Input:
{Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class 
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0, 
Extkey[name=EXTENSION_LICENSE;type=class 
java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL 
2.0, Extkey[name=EXTENSION_NOTES;type=class 
java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display 
name: ovirt-engine-extension-aaa-ldap-1.0.2-1.el6, 
Extkey[name=EXTENSION_HOME_URL;type=class 
java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-f969-42d4-b399-72d192e18304];]=http://www.ovirt.org, 
Extkey[name=EXTENSION_LOCALE;type=class 
java.lang.String;uuid=EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US, 
Extkey[name=EXTENSION_NAME;type=class 
java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authz, 
Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class 
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0, 
Extkey[name=EXTENSION_CONFIGURATION;type=class 
java.util.Properties;uuid=EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***, 
Extkey[name=EXTENSION_AUTHOR;type=class 
java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The 
oVirt Project, Extkey[name=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE;type=class 
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE[2eb1f541-0f65-44a1-a6e3-014e247595f5];]=50, 
Extkey[name=EXTENSION_INSTANCE_NAME;type=class 
java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=BRU_AIR-authz, 
Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class 
java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0, 
Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface 
java.util.Collection;uuid=EXTENSION_CONFIGURATION_SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[], 
Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*, 
Extkey[name=EXTENSION_VERSION;type=class 
java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-8239-4bdb-ab1a-af9f779ce68c];]=1.0.2, 
Extkey[name=AAA_AUTHZ_AVAILABLE_NAMESPACES;type=interface 
java.util.Collection;uuid=AAA_AUTHZ_AVAILABLE_NAMESPACES[6dffa34c-955f-486a-bd35-0a272b45a711];]=[DC=brussels,DC=airport, 
DC=airport], Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface 
org.slf4j.Logger;uuid=EXTENSION_MANAGER_TRACE_LOG[863db666-3ea7-4751-9695-918a3197ad83];]=org.slf4j.impl.Slf4jLogger(org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace.ovirt-engine-extension-aaa-ldap.authz.BRU_AIR-authz), 
Extkey[name=EXTENSION_PROVIDES;type=interface 
java.util.Collection;uuid=EXTENSION_PROVIDES[8cf373a6-65b5-4594-b828-0e275087de91];]=[org.ovirt.engine.api.extensions.aaa.Authz], 
Extkey[name=EXTENSION_CONFIGURATION_FILE;type=class 
java.lang.String;uuid=EXTENSION_CONFIGURATION_FILE[4fb0ffd3-983c-4f3f-98ff-9660bd67af6a];]=/etc/ovirt-engine/extensions.d/BRU_AIR-authz.properties}, 
Extkey[name=AAA_AUTHZ_QUERY_FLAGS;type=class 
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_FLAGS[97d226e9-8d87-49a0-9a7f-af689320907b];]=3, 
Extkey[name=EXTENSION_INVOKE_COMMAND;type=class 
org.ovirt.engine.api.extensions.ExtUUID;uuid=EXTENSION_INVOKE_COMMAND[485778ab-bede-4f1a-b823-77b262a2f28d];]=AAA_AUTHZ_FETCH_PRINCIPAL_RECORD[5a5bf9bb-9336-4376-a823-26efe1ba26df], 
Extkey[name=AAA_AUTHN_AUTH_RECORD;type=class 
org.ovirt.engine.api.extensions.ExtMap;uuid=AAA_AUTHN_AUTH_RECORD[e9462168-b53b-44ac-9af5-f25e1697173e];]={Extkey[name=AAA_AUTHN_AUTH_RECORD_PRINCIPAL;type=class 
java.lang.String;uuid=AAA_AUTHN_AUTH_RECORD_PRINCIPAL[c3498f07-11fe-464c-958c-8bd7490b119a];]=us...@company.be 

[ovirt-users] Bug?

[Koen Vanoppen]

Hi All,

One of our users on ovirt who always was able to login with the AD account,
now all of a sudden can't login anymore... I already tried kicking him out
and putting him back in again, but no change... Following error is
appearing in the log file when he logs in:

2015-11-27 07:01:00,418 ERROR
[org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
(ajp--127.0.0.1-8702-1) Error during CanDoActionFailure.: Class: class
org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException
Input:
{Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
Extkey[name=EXTENSION_LICENSE;type=class
java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL
2.0, Extkey[name=EXTENSION_NOTES;type=class
java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display
name: ovirt-engine-extension-aaa-ldap-1.0.2-1.el6,
Extkey[name=EXTENSION_HOME_URL;type=class
java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-f969-42d4-b399-72d192e18304];]=
http://www.ovirt.org, Extkey[name=EXTENSION_LOCALE;type=class
java.lang.String;uuid=EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US,
Extkey[name=EXTENSION_NAME;type=class
java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authz,
Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
Extkey[name=EXTENSION_CONFIGURATION;type=class
java.util.Properties;uuid=EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
Extkey[name=EXTENSION_AUTHOR;type=class
java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The
oVirt Project, Extkey[name=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE;type=class
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_MAX_FILTER_SIZE[2eb1f541-0f65-44a1-a6e3-014e247595f5];]=50,
Extkey[name=EXTENSION_INSTANCE_NAME;type=class
java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=BRU_AIR-authz,
Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class
java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0,
Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface
java.util.Collection;uuid=EXTENSION_CONFIGURATION_SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[],
Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class
org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*,
Extkey[name=EXTENSION_VERSION;type=class
java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-8239-4bdb-ab1a-af9f779ce68c];]=1.0.2,
Extkey[name=AAA_AUTHZ_AVAILABLE_NAMESPACES;type=interface
java.util.Collection;uuid=AAA_AUTHZ_AVAILABLE_NAMESPACES[6dffa34c-955f-486a-bd35-0a272b45a711];]=[DC=brussels,DC=airport,
DC=airport], Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface
org.slf4j.Logger;uuid=EXTENSION_MANAGER_TRACE_LOG[863db666-3ea7-4751-9695-918a3197ad83];]=org.slf4j.impl.Slf4jLogger(org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace.ovirt-engine-extension-aaa-ldap.authz.BRU_AIR-authz),
Extkey[name=EXTENSION_PROVIDES;type=interface
java.util.Collection;uuid=EXTENSION_PROVIDES[8cf373a6-65b5-4594-b828-0e275087de91];]=[org.ovirt.engine.api.extensions.aaa.Authz],
Extkey[name=EXTENSION_CONFIGURATION_FILE;type=class
java.lang.String;uuid=EXTENSION_CONFIGURATION_FILE[4fb0ffd3-983c-4f3f-98ff-9660bd67af6a];]=/etc/ovirt-engine/extensions.d/BRU_AIR-authz.properties},
Extkey[name=AAA_AUTHZ_QUERY_FLAGS;type=class
java.lang.Integer;uuid=AAA_AUTHZ_QUERY_FLAGS[97d226e9-8d87-49a0-9a7f-af689320907b];]=3,
Extkey[name=EXTENSION_INVOKE_COMMAND;type=class
org.ovirt.engine.api.extensions.ExtUUID;uuid=EXTENSION_INVOKE_COMMAND[485778ab-bede-4f1a-b823-77b262a2f28d];]=AAA_AUTHZ_FETCH_PRINCIPAL_RECORD[5a5bf9bb-9336-4376-a823-26efe1ba26df],
Extkey[name=AAA_AUTHN_AUTH_RECORD;type=class
org.ovirt.engine.api.extensions.ExtMap;uuid=AAA_AUTHN_AUTH_RECORD[e9462168-b53b-44ac-9af5-f25e1697173e];]={Extkey[name=AAA_AUTHN_AUTH_RECORD_PRINCIPAL;type=class
java.lang.String;uuid=AAA_AUTHN_AUTH_RECORD_PRINCIPAL[c3498f07-11fe-464c-958c-8bd7490b119a];]=
us...@company.be}}
Output:
{Extkey[name=EXTENSION_INVOKE_RESULT;type=class
java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2,
Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class
java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7-9d26-b8bdb72f5893];]=No
search for principal 'us...@company.be'}

at
org.ovirt.engine.core.extensions.mgr.ExtensionProxy.invoke(ExtensionProxy.java:91)
[extensions-manager.jar:]
at
org.ovirt.engine.core.extensions.mgr.ExtensionProxy.invoke(ExtensionProxy.java:109)
[extensions-manager.j

Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[Daniel Helgenberger]

On 17.06.2015 13:28, Alon Bar-Lev wrote:
>
>
> - Original Message -
>> From: "Daniel Helgenberger" 
>> To: "Alon Bar-Lev" 
>> Cc: Users@ovirt.org
>> Sent: Wednesday, June 17, 2015 2:26:18 PM
>> Subject: Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot 
>> find a valid baseurl for repo:
>> base/7/x86_64
>>
>> Hello Alon,
>>
>> On 17.06.2015 13:22, Alon Bar-Lev wrote:
>>> Please do not use multiple channels to discuss the same issue.
>>
>> I just make a habit of posting bug links on the ML as well. I see this
>> as an 'FYI', since I often miss BZ if not posted on the list Of course,
>> further discussion sould continue in BZ.
>
> Please do not do that. Discuss in list first, then if a bug should be opened 
> you will instructed to do so.
> If you open a bug, avoid discussion in other mediums.

Ok; next time I'll will discuss it here first, like always. This one 
seemed too obvouis for me though; I had it on two hosts..

Cheers!

>
> Thanks.
>
>>
>> If you think this is not right will stop doing so.
>>
>>>
>>> - Original Message -
>>>> From: "Daniel Helgenberger" 
>>>> To: Users@ovirt.org
>>>> Sent: Wednesday, June 17, 2015 2:21:58 PM
>>>> Subject: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot
>>>> find a valid baseurl for repo: base/7/x86_64
>>>>
>>>> Hello,
>>>>
>>>> I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host
>>>> deploy seens to fail on CentOS7 if there is no baseurl setting in yum
>>>> repos:
>>>>
>>>> RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
>>>>
>>>> [BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714
>>>>
>>>> -8<-
>>>>> 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77
>>>>> preparing 'Yum Transaction'
>>>>> Loaded plugins: fastestmirror
>>>>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage
>>>>> internal_packages METHOD
>>>>> otopi.plugins.otopi.network.hostname.Plugin._internal_packages
>>>>> 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager
>>>>> yumpackager.verbose:88 Yum queue package iproute for install
>>>>> Loading mirror speeds from cached hostfile
>>>>> 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager
>>>>> yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a
>>>>> valid
>>>>> baseurl for repo: base/7/x86_64
>>>>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method
>>>>> exception
>>>>> Traceback (most recent call last):
>>>>> File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in
>>>>> _executeMethod
>>>>>   method['method']()
>>>>> File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py",
>>>>> line 66, in _internal_packages
>>>>>   self.packager.install(packages=('iproute',))
>>>>> File
>>>>> "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py",
>>>>> line 303, in install
>>>>>   ignoreErrors=ignoreErrors
>>>>> File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in
>>>>> install
>>>>>   **kwargs
>>>>> File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in
>>>>> _queue
>>>>>   provides = self._queryProvides(packages=(package,))
>>>>> File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in
>>>>> _queryProvides
>>>>>   for po in self._yb.searchPackageProvides(args=packages):
>>>>> File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in
>>>>> searchPackageProvides
>>>>>   where = self.returnPackagesByDep(arg)
>>>>> File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in
>>>>> returnPackagesByDep
>>>>>   return self.pkgSack.searchProvides(depstring)
>>>>> File "/usr/lib/python2.7/site-packages/yum/__ini

Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[Alon Bar-Lev]

- Original Message -
> From: "Daniel Helgenberger" 
> To: "Alon Bar-Lev" 
> Cc: Users@ovirt.org
> Sent: Wednesday, June 17, 2015 2:26:18 PM
> Subject: Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot 
> find a valid baseurl for repo:
> base/7/x86_64
> 
> Hello Alon,
> 
> On 17.06.2015 13:22, Alon Bar-Lev wrote:
> > Please do not use multiple channels to discuss the same issue.
> 
> I just make a habit of posting bug links on the ML as well. I see this
> as an 'FYI', since I often miss BZ if not posted on the list Of course,
> further discussion sould continue in BZ.

Please do not do that. Discuss in list first, then if a bug should be opened 
you will instructed to do so.
If you open a bug, avoid discussion in other mediums.

Thanks.

> 
> If you think this is not right will stop doing so.
> 
> >
> > - Original Message -
> >> From: "Daniel Helgenberger" 
> >> To: Users@ovirt.org
> >> Sent: Wednesday, June 17, 2015 2:21:58 PM
> >> Subject: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot
> >> find a valid baseurl for repo: base/7/x86_64
> >>
> >> Hello,
> >>
> >> I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host
> >> deploy seens to fail on CentOS7 if there is no baseurl setting in yum
> >> repos:
> >>
> >> RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
> >>
> >> [BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714
> >>
> >> -8<-
> >>> 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77
> >>> preparing 'Yum Transaction'
> >>> Loaded plugins: fastestmirror
> >>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage
> >>> internal_packages METHOD
> >>> otopi.plugins.otopi.network.hostname.Plugin._internal_packages
> >>> 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager
> >>> yumpackager.verbose:88 Yum queue package iproute for install
> >>> Loading mirror speeds from cached hostfile
> >>> 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager
> >>> yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a
> >>> valid
> >>> baseurl for repo: base/7/x86_64
> >>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method
> >>> exception
> >>> Traceback (most recent call last):
> >>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in
> >>>_executeMethod
> >>>  method['method']()
> >>>File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py",
> >>>line 66, in _internal_packages
> >>>  self.packager.install(packages=('iproute',))
> >>>File
> >>>"/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py",
> >>>line 303, in install
> >>>  ignoreErrors=ignoreErrors
> >>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in
> >>>install
> >>>  **kwargs
> >>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in
> >>>_queue
> >>>  provides = self._queryProvides(packages=(package,))
> >>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in
> >>>_queryProvides
> >>>  for po in self._yb.searchPackageProvides(args=packages):
> >>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in
> >>>searchPackageProvides
> >>>  where = self.returnPackagesByDep(arg)
> >>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in
> >>>returnPackagesByDep
> >>>  return self.pkgSack.searchProvides(depstring)
> >>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1079, in
> >>>
> >>>  pkgSack = property(fget=lambda self: self._getSacks(),
> >>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 784, in
> >>>_getSacks
> >>>  self.repos.populateSack(which=repos)
> >>>File "/usr/lib/python2.7/site-packages/yum/repos.py", line 344, in
> >>>populateSack
> >>>  self.doSetup()
> &g

Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[Daniel Helgenberger]

Hello Alon,

On 17.06.2015 13:22, Alon Bar-Lev wrote:
> Please do not use multiple channels to discuss the same issue.

I just make a habit of posting bug links on the ML as well. I see this 
as an 'FYI', since I often miss BZ if not posted on the list Of course, 
further discussion sould continue in BZ.

If you think this is not right will stop doing so.

>
> - Original Message -
>> From: "Daniel Helgenberger" 
>> To: Users@ovirt.org
>> Sent: Wednesday, June 17, 2015 2:21:58 PM
>> Subject: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find 
>> a valid baseurl for repo: base/7/x86_64
>>
>> Hello,
>>
>> I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host
>> deploy seens to fail on CentOS7 if there is no baseurl setting in yum repos:
>>
>> RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
>>
>> [BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714
>>
>> -8<-
>>> 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77
>>> preparing 'Yum Transaction'
>>> Loaded plugins: fastestmirror
>>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage
>>> internal_packages METHOD
>>> otopi.plugins.otopi.network.hostname.Plugin._internal_packages
>>> 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager
>>> yumpackager.verbose:88 Yum queue package iproute for install
>>> Loading mirror speeds from cached hostfile
>>> 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager
>>> yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a valid
>>> baseurl for repo: base/7/x86_64
>>> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method
>>> exception
>>> Traceback (most recent call last):
>>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in
>>>_executeMethod
>>>  method['method']()
>>>File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py",
>>>line 66, in _internal_packages
>>>  self.packager.install(packages=('iproute',))
>>>File
>>>"/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py",
>>>line 303, in install
>>>  ignoreErrors=ignoreErrors
>>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in
>>>install
>>>  **kwargs
>>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in
>>>_queue
>>>  provides = self._queryProvides(packages=(package,))
>>>File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in
>>>_queryProvides
>>>  for po in self._yb.searchPackageProvides(args=packages):
>>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in
>>>searchPackageProvides
>>>  where = self.returnPackagesByDep(arg)
>>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in
>>>returnPackagesByDep
>>>  return self.pkgSack.searchProvides(depstring)
>>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1079, in
>>>
>>>  pkgSack = property(fget=lambda self: self._getSacks(),
>>>File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 784, in
>>>_getSacks
>>>  self.repos.populateSack(which=repos)
>>>File "/usr/lib/python2.7/site-packages/yum/repos.py", line 344, in
>>>populateSack
>>>  self.doSetup()
>>>File "/usr/lib/python2.7/site-packages/yum/repos.py", line 158, in
>>>doSetup
>>>  self.ayum.plugins.run('postreposetup')
>>>File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 188, in run
>>>  func(conduitcls(self, self.base, conf, **kwargs))
>>>File "/usr/lib/yum-plugins/fastestmirror.py", line 197, in
>>>postreposetup_hook
>>>  if downgrade_ftp and _len_non_ftp(repo.urls) == 1:
>>>File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 871, in
>>>
>>>  urls = property(fget=lambda self: self._geturls(),
>>>File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 868, in
>>>_geturls
>>>  self._baseurlSetup()
>>>File "/usr/lib/python2.7/site-pac

[ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[Daniel Helgenberger]

Hello,

I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host 
deploy seens to fail on CentOS7 if there is no baseurl setting in yum repos:

RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714

-8<-
> 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77 preparing 
> 'Yum Transaction'
> Loaded plugins: fastestmirror
> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage 
> internal_packages METHOD 
> otopi.plugins.otopi.network.hostname.Plugin._internal_packages
> 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager 
> yumpackager.verbose:88 Yum queue package iproute for install
> Loading mirror speeds from cached hostfile
> 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager 
> yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a valid 
> baseurl for repo: base/7/x86_64
> 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method 
> exception
> Traceback (most recent call last):
>   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in 
> _executeMethod
> method['method']()
>   File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py", line 
> 66, in _internal_packages
> self.packager.install(packages=('iproute',))
>   File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py", 
> line 303, in install
> ignoreErrors=ignoreErrors
>   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in 
> install
> **kwargs
>   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in _queue
> provides = self._queryProvides(packages=(package,))
>   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in 
> _queryProvides
> for po in self._yb.searchPackageProvides(args=packages):
>   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in 
> searchPackageProvides
> where = self.returnPackagesByDep(arg)
>   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in 
> returnPackagesByDep
> return self.pkgSack.searchProvides(depstring)
>   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1079, in 
> 
> pkgSack = property(fget=lambda self: self._getSacks(),
>   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 784, in 
> _getSacks
> self.repos.populateSack(which=repos)
>   File "/usr/lib/python2.7/site-packages/yum/repos.py", line 344, in 
> populateSack
> self.doSetup()
>   File "/usr/lib/python2.7/site-packages/yum/repos.py", line 158, in doSetup
> self.ayum.plugins.run('postreposetup')
>   File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 188, in run
> func(conduitcls(self, self.base, conf, **kwargs))
>   File "/usr/lib/yum-plugins/fastestmirror.py", line 197, in 
> postreposetup_hook
> if downgrade_ftp and _len_non_ftp(repo.urls) == 1:
>   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 871, in 
> 
> urls = property(fget=lambda self: self._geturls(),
>   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 868, in 
> _geturls
> self._baseurlSetup()
>   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 834, in 
> _baseurlSetup
> self.check()
>   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 554, in check
> 'Cannot find a valid baseurl for repo: %s' % self.ui_id
> RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
> 2015-06-17 12:27:37 ERROR otopi.context context._executeMethod:161 Failed to 
> execute stage 'Environment packages setup': Cannot find a valid baseurl for 
> repo: base/7/x86_64
> 2015-06-17 12:27:37 DEBUG otopi.transaction transaction.abort:131 aborting 
> 'Yum Transaction'
> 2015-06-17 12:27:37 INFO otopi.plugins.otopi.packagers.yumpackager 
> yumpackager.info:92 Yum Performing yum transaction rollback
> Could not retrieve mirrorlist 
> http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error 
> was
> 14: curl#7 - "Failed connect to mirrorlist.centos.org:80; No route to host"
> Loaded plugins: fastestmirror
> 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:490 
> ENVIRONMENT DUMP - BEGIN
> 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:500 ENV 
> BASE/error=bool:'True'
> 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:500 ENV 
> BASE/exceptionInfo=list:'[(, RepoError(), 
> )]'
> 2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:504 
> ENVIRONMENT DUMP - END
> 2015-06-17 12:27:37 INFO otopi.context context.runSequence:417 Stage: 
> Pre-termination

-8<-



-- 
Daniel Helgenberger
m box bewegtbild GmbH

P: +49/30/2408781-22
F: +49/30/2408781-10

ACKERSTR. 19
D-10115 BERLIN


www.m-box.de  www.monkeymen.tv

Geschäftsführer: Martin Retschitzegger / Michaela Göllner
Handeslregister: Amtsgericht Charlottenburg / HRB 112767
_

Re: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a valid baseurl for repo: base/7/x86_64

[Alon Bar-Lev]

Please do not use multiple channels to discuss the same issue.

- Original Message -
> From: "Daniel Helgenberger" 
> To: Users@ovirt.org
> Sent: Wednesday, June 17, 2015 2:21:58 PM
> Subject: [ovirt-users] Bug in hostdeploy / baseurl - RepoError: Cannot find a 
> valid baseurl for repo: base/7/x86_64
> 
> Hello,
> 
> I just went ahead and filed [BZ1232714] because with ovirt 3.5.3 host
> deploy seens to fail on CentOS7 if there is no baseurl setting in yum repos:
> 
> RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
> 
> [BZ1232714] https://bugzilla.redhat.com/show_bug.cgi?id=1232714
> 
> -8<-
> > 2015-06-17 12:27:37 DEBUG otopi.transaction transaction._prepare:77
> > preparing 'Yum Transaction'
> > Loaded plugins: fastestmirror
> > 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:138 Stage
> > internal_packages METHOD
> > otopi.plugins.otopi.network.hostname.Plugin._internal_packages
> > 2015-06-17 12:27:37 DEBUG otopi.plugins.otopi.packagers.yumpackager
> > yumpackager.verbose:88 Yum queue package iproute for install
> > Loading mirror speeds from cached hostfile
> > 2015-06-17 12:27:37 ERROR otopi.plugins.otopi.packagers.yumpackager
> > yumpackager.error:97 Yum Cannot queue package iproute: Cannot find a valid
> > baseurl for repo: base/7/x86_64
> > 2015-06-17 12:27:37 DEBUG otopi.context context._executeMethod:152 method
> > exception
> > Traceback (most recent call last):
> >   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/context.py", line 142, in
> >   _executeMethod
> > method['method']()
> >   File "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/network/hostname.py",
> >   line 66, in _internal_packages
> > self.packager.install(packages=('iproute',))
> >   File
> >   "/tmp/ovirt-s3ofZ9o6Pq/otopi-plugins/otopi/packagers/yumpackager.py",
> >   line 303, in install
> > ignoreErrors=ignoreErrors
> >   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 865, in
> >   install
> > **kwargs
> >   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 509, in
> >   _queue
> > provides = self._queryProvides(packages=(package,))
> >   File "/tmp/ovirt-s3ofZ9o6Pq/pythonlib/otopi/miniyum.py", line 447, in
> >   _queryProvides
> > for po in self._yb.searchPackageProvides(args=packages):
> >   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 3406, in
> >   searchPackageProvides
> > where = self.returnPackagesByDep(arg)
> >   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4232, in
> >   returnPackagesByDep
> > return self.pkgSack.searchProvides(depstring)
> >   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1079, in
> >   
> > pkgSack = property(fget=lambda self: self._getSacks(),
> >   File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 784, in
> >   _getSacks
> > self.repos.populateSack(which=repos)
> >   File "/usr/lib/python2.7/site-packages/yum/repos.py", line 344, in
> >   populateSack
> > self.doSetup()
> >   File "/usr/lib/python2.7/site-packages/yum/repos.py", line 158, in
> >   doSetup
> > self.ayum.plugins.run('postreposetup')
> >   File "/usr/lib/python2.7/site-packages/yum/plugins.py", line 188, in run
> > func(conduitcls(self, self.base, conf, **kwargs))
> >   File "/usr/lib/yum-plugins/fastestmirror.py", line 197, in
> >   postreposetup_hook
> > if downgrade_ftp and _len_non_ftp(repo.urls) == 1:
> >   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 871, in
> >   
> > urls = property(fget=lambda self: self._geturls(),
> >   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 868, in
> >   _geturls
> > self._baseurlSetup()
> >   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 834, in
> >   _baseurlSetup
> > self.check()
> >   File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 554, in
> >   check
> > 'Cannot find a valid baseurl for repo: %s' % self.ui_id
> > RepoError: Cannot find a valid baseurl for repo: base/7/x86_64
> > 2015-06-17 12:27:37 ERROR otopi.context context._executeMethod:161 Failed
> > to execute stage 'Environment packages setup': Cannot find a valid baseurl
> > for repo: base/7/x86_64
> > 2015-06-17 12:27:37 DEBUG otopi.

Re: [ovirt-users] Bug in Snapshot Removing

[Adam Litke]

On 11/06/15 11:00 +, Soeren Malchow wrote:

We are still having this problem and we can not figure out what to do, i
sent the logs already as download, can i do anything else to help ?


Hi.  I'm sorry but I don't have any new information for you yet.  One
thing you could do is create a new bug for this issue so we can track
it better.  Please try to include as much information as possible from
this discussion (including relevant log files) in your report.  So far
you are the only one reporting these issues so we'll want to work to
narrow down the specific scenario that is causing this problem and get
the right people working on the solution.


On 04/06/15 17:08, "Soeren Malchow"  wrote:


Hi,

I would send those, but unfortunately we did not think about the journals
getting deleted after a reboot.

I just made the journals persistent on the servers, we are trying to
trigger the error again last time we only got half way through the VM’s
when removing the snapshots so we have a good chance that it comes up
again.

Also the libvirt logs to the journal not to libvirtd.log, i would send the
journal directly to you and Eric via our data exchange servers


Soeren

On 04/06/15 16:17, "Adam Litke"  wrote:


On 04/06/15 13:08 +, Soeren Malchow wrote:

Hi Adam, Hi Eric,

We had this issue again a few minutes ago.

One machine went down exactly the same way as described, the machine had
only one snapshot and it was the only snapshot that was removed, before
that in the same scriptrun we deleted the snapshots of 15 other Vms,
some
without, some with 1 and some with several snapshots.

Can i provide anything from the logs that helps ?


Let's start with the libvirtd.log on that host.  It might be rather
large so we may need to find a creative place to host it.



Regards
Soeren



On 03/06/15 18:07, "Soeren Malchow"  wrote:


Hi,

This is not happening every time, the last time i had this, it was a
script runnning, and something like th 9. Vm and the 23. Vm had a
problem,
and it is not always the same VMS, it is not about the OS (happen for
Windows and Linux alike)

And as i said it also happened when i tried to remove the snapshots
sequentially, here is the code (i know it is probably not the elegant
way,
but i am not a developer) and the code actually has correct indentions.

<― snip ―>

print "Snapshot deletion"
try:
   time.sleep(300)
   Connect()
   vms = api.vms.list()
   for vm in vms:
   print ("Deleting snapshots for %s ") % vm.name
   snapshotlist = vm.snapshots.list()
   for snapshot in snapshotlist:
   if snapshot.description != "Active VM":
   time.sleep(30)
   snapshot.delete()
   try:
   while
api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status
==
"locked":
   print("Waiting for snapshot %s on %s deletion
to
finish") % (snapshot.description, vm.name)
   time.sleep(60)
   except Exception as e:
   print ("Snapshot %s does not exist anymore") %
snapshot.description
   print ("Snapshot deletion for %s done") % vm.name
   print ("Deletion of snapshots done")
   api.disconnect()
except Exception as e:
   print ("Something went wrong when deleting the snapshots\n%s") %
str(e)



<― snip ―>


Cheers
Soeren





On 03/06/15 15:20, "Adam Litke"  wrote:


On 03/06/15 07:36 +, Soeren Malchow wrote:

Dear Adam

First we were using a python script that was working on 4 threads and
therefore removing 4 snapshots at the time throughout the cluster,
that
still caused problems.

Now i took the snapshot removing out of the threaded part an i am
just
looping through each snapshot on each VM one after another, even with
³sleeps² inbetween, but the problem remains.
But i am getting the impression that it is a problem with the amount
of
snapshots that are deleted in a certain time, if i delete manually
and
one
after another (meaning every 10 min or so) i do not have problems, if
i
delete manually and do several at once and on one VM the next one
just
after one finished, the risk seems to increase.


Hmm.  In our lab we extensively tested removing a snapshot for a VM
with 4 disks.  This means 4 block jobs running simultaneously.  Less
than 10 minutes later (closer to 1 minute) we would remove a second
snapshot for the same VM (again involving 4 block jobs).  I guess we
should rerun this flow on a fully updated CentOS 7.1 host to see about
local reproduction.  Seems your case is much simpler than this though.
Is this happening every time or intermittently?


I do not think it is the number of VMS because we had this on hosts
with
only 3 or 4 Vms running

I will try restarting the libvirt and see what happens.

We are not using RHEL 7.1 only CentOS 7.1

Is there anything else we can look at when this happens again ?


I'll defer to Eric Blake for the libvirt side of this.  Eric, would
enabling debug logging in libvirtd help to shine some light on the
pro

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

We are still having this problem and we can not figure out what to do, i
sent the logs already as download, can i do anything else to help ?




On 04/06/15 17:08, "Soeren Malchow"  wrote:

>Hi,
>
>I would send those, but unfortunately we did not think about the journals
>getting deleted after a reboot.
>
>I just made the journals persistent on the servers, we are trying to
>trigger the error again last time we only got half way through the VM’s
>when removing the snapshots so we have a good chance that it comes up
>again.
>
>Also the libvirt logs to the journal not to libvirtd.log, i would send the
>journal directly to you and Eric via our data exchange servers
>
>
>Soeren 
>
>On 04/06/15 16:17, "Adam Litke"  wrote:
>
>>On 04/06/15 13:08 +, Soeren Malchow wrote:
>>>Hi Adam, Hi Eric,
>>>
>>>We had this issue again a few minutes ago.
>>>
>>>One machine went down exactly the same way as described, the machine had
>>>only one snapshot and it was the only snapshot that was removed, before
>>>that in the same scriptrun we deleted the snapshots of 15 other Vms,
>>>some
>>>without, some with 1 and some with several snapshots.
>>>
>>>Can i provide anything from the logs that helps ?
>>
>>Let's start with the libvirtd.log on that host.  It might be rather
>>large so we may need to find a creative place to host it.
>>
>>>
>>>Regards
>>>Soeren
>>>
>>>
>>>
>>>On 03/06/15 18:07, "Soeren Malchow"  wrote:
>>>
Hi,

This is not happening every time, the last time i had this, it was a
script runnning, and something like th 9. Vm and the 23. Vm had a
problem,
and it is not always the same VMS, it is not about the OS (happen for
Windows and Linux alike)

And as i said it also happened when i tried to remove the snapshots
sequentially, here is the code (i know it is probably not the elegant
way,
but i am not a developer) and the code actually has correct indentions.

<― snip ―>

print "Snapshot deletion"
try:
time.sleep(300)
Connect()
vms = api.vms.list()
for vm in vms:
print ("Deleting snapshots for %s ") % vm.name
snapshotlist = vm.snapshots.list()
for snapshot in snapshotlist:
if snapshot.description != "Active VM":
time.sleep(30)
snapshot.delete()
try:
while
api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status
==
"locked":
print("Waiting for snapshot %s on %s deletion
to
finish") % (snapshot.description, vm.name)
time.sleep(60)
except Exception as e:
print ("Snapshot %s does not exist anymore") %
snapshot.description
print ("Snapshot deletion for %s done") % vm.name
print ("Deletion of snapshots done")
api.disconnect()
except Exception as e:
print ("Something went wrong when deleting the snapshots\n%s") %
str(e)



<― snip ―>


Cheers
Soeren





On 03/06/15 15:20, "Adam Litke"  wrote:

>On 03/06/15 07:36 +, Soeren Malchow wrote:
>>Dear Adam
>>
>>First we were using a python script that was working on 4 threads and
>>therefore removing 4 snapshots at the time throughout the cluster,
>>that
>>still caused problems.
>>
>>Now i took the snapshot removing out of the threaded part an i am
>>just
>>looping through each snapshot on each VM one after another, even with
>>³sleeps² inbetween, but the problem remains.
>>But i am getting the impression that it is a problem with the amount
>>of
>>snapshots that are deleted in a certain time, if i delete manually
>>and
>>one
>>after another (meaning every 10 min or so) i do not have problems, if
>>i
>>delete manually and do several at once and on one VM the next one
>>just
>>after one finished, the risk seems to increase.
>
>Hmm.  In our lab we extensively tested removing a snapshot for a VM
>with 4 disks.  This means 4 block jobs running simultaneously.  Less
>than 10 minutes later (closer to 1 minute) we would remove a second
>snapshot for the same VM (again involving 4 block jobs).  I guess we
>should rerun this flow on a fully updated CentOS 7.1 host to see about
>local reproduction.  Seems your case is much simpler than this though.
>Is this happening every time or intermittently?
>
>>I do not think it is the number of VMS because we had this on hosts
>>with
>>only 3 or 4 Vms running
>>
>>I will try restarting the libvirt and see what happens.
>>
>>We are not using RHEL 7.1 only CentOS 7.1
>>
>>Is there anything else we can look at when this happens again ?
>
>I'll defer to Eric Blake for the libvirt side of this.  Eric, would
>ena

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Hi,

I would send those, but unfortunately we did not think about the journals
getting deleted after a reboot.

I just made the journals persistent on the servers, we are trying to
trigger the error again last time we only got half way through the VM’s
when removing the snapshots so we have a good chance that it comes up
again.

Also the libvirt logs to the journal not to libvirtd.log, i would send the
journal directly to you and Eric via our data exchange servers


Soeren 

On 04/06/15 16:17, "Adam Litke"  wrote:

>On 04/06/15 13:08 +, Soeren Malchow wrote:
>>Hi Adam, Hi Eric,
>>
>>We had this issue again a few minutes ago.
>>
>>One machine went down exactly the same way as described, the machine had
>>only one snapshot and it was the only snapshot that was removed, before
>>that in the same scriptrun we deleted the snapshots of 15 other Vms, some
>>without, some with 1 and some with several snapshots.
>>
>>Can i provide anything from the logs that helps ?
>
>Let's start with the libvirtd.log on that host.  It might be rather
>large so we may need to find a creative place to host it.
>
>>
>>Regards
>>Soeren
>>
>>
>>
>>On 03/06/15 18:07, "Soeren Malchow"  wrote:
>>
>>>Hi,
>>>
>>>This is not happening every time, the last time i had this, it was a
>>>script runnning, and something like th 9. Vm and the 23. Vm had a
>>>problem,
>>>and it is not always the same VMS, it is not about the OS (happen for
>>>Windows and Linux alike)
>>>
>>>And as i said it also happened when i tried to remove the snapshots
>>>sequentially, here is the code (i know it is probably not the elegant
>>>way,
>>>but i am not a developer) and the code actually has correct indentions.
>>>
>>><― snip ―>
>>>
>>>print "Snapshot deletion"
>>>try:
>>>time.sleep(300)
>>>Connect()
>>>vms = api.vms.list()
>>>for vm in vms:
>>>print ("Deleting snapshots for %s ") % vm.name
>>>snapshotlist = vm.snapshots.list()
>>>for snapshot in snapshotlist:
>>>if snapshot.description != "Active VM":
>>>time.sleep(30)
>>>snapshot.delete()
>>>try:
>>>while
>>>api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status
>>>==
>>>"locked":
>>>print("Waiting for snapshot %s on %s deletion to
>>>finish") % (snapshot.description, vm.name)
>>>time.sleep(60)
>>>except Exception as e:
>>>print ("Snapshot %s does not exist anymore") %
>>>snapshot.description
>>>print ("Snapshot deletion for %s done") % vm.name
>>>print ("Deletion of snapshots done")
>>>api.disconnect()
>>>except Exception as e:
>>>print ("Something went wrong when deleting the snapshots\n%s") %
>>>str(e)
>>>
>>>
>>>
>>><― snip ―>
>>>
>>>
>>>Cheers
>>>Soeren
>>>
>>>
>>>
>>>
>>>
>>>On 03/06/15 15:20, "Adam Litke"  wrote:
>>>
On 03/06/15 07:36 +, Soeren Malchow wrote:
>Dear Adam
>
>First we were using a python script that was working on 4 threads and
>therefore removing 4 snapshots at the time throughout the cluster,
>that
>still caused problems.
>
>Now i took the snapshot removing out of the threaded part an i am just
>looping through each snapshot on each VM one after another, even with
>³sleeps² inbetween, but the problem remains.
>But i am getting the impression that it is a problem with the amount
>of
>snapshots that are deleted in a certain time, if i delete manually and
>one
>after another (meaning every 10 min or so) i do not have problems, if
>i
>delete manually and do several at once and on one VM the next one just
>after one finished, the risk seems to increase.

Hmm.  In our lab we extensively tested removing a snapshot for a VM
with 4 disks.  This means 4 block jobs running simultaneously.  Less
than 10 minutes later (closer to 1 minute) we would remove a second
snapshot for the same VM (again involving 4 block jobs).  I guess we
should rerun this flow on a fully updated CentOS 7.1 host to see about
local reproduction.  Seems your case is much simpler than this though.
Is this happening every time or intermittently?

>I do not think it is the number of VMS because we had this on hosts
>with
>only 3 or 4 Vms running
>
>I will try restarting the libvirt and see what happens.
>
>We are not using RHEL 7.1 only CentOS 7.1
>
>Is there anything else we can look at when this happens again ?

I'll defer to Eric Blake for the libvirt side of this.  Eric, would
enabling debug logging in libvirtd help to shine some light on the
problem?

--
Adam Litke
>>>
>>>___
>>>Users mailing list
>>>Users@ovirt.org
>>>http://lists.ovirt.org/mailman/listinfo/users
>>
>
>-- 
>Adam Litke

___
Users mailing list
Users@ovirt.org

Re: [ovirt-users] Bug in Snapshot Removing

[Adam Litke]

On 04/06/15 13:08 +, Soeren Malchow wrote:

Hi Adam, Hi Eric,

We had this issue again a few minutes ago.

One machine went down exactly the same way as described, the machine had
only one snapshot and it was the only snapshot that was removed, before
that in the same scriptrun we deleted the snapshots of 15 other Vms, some
without, some with 1 and some with several snapshots.

Can i provide anything from the logs that helps ?


Let's start with the libvirtd.log on that host.  It might be rather
large so we may need to find a creative place to host it.



Regards
Soeren



On 03/06/15 18:07, "Soeren Malchow"  wrote:


Hi,

This is not happening every time, the last time i had this, it was a
script runnning, and something like th 9. Vm and the 23. Vm had a problem,
and it is not always the same VMS, it is not about the OS (happen for
Windows and Linux alike)

And as i said it also happened when i tried to remove the snapshots
sequentially, here is the code (i know it is probably not the elegant way,
but i am not a developer) and the code actually has correct indentions.

<― snip ―>

print "Snapshot deletion"
try:
   time.sleep(300)
   Connect()
   vms = api.vms.list()
   for vm in vms:
   print ("Deleting snapshots for %s ") % vm.name
   snapshotlist = vm.snapshots.list()
   for snapshot in snapshotlist:
   if snapshot.description != "Active VM":
   time.sleep(30)
   snapshot.delete()
   try:
   while
api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status ==
"locked":
   print("Waiting for snapshot %s on %s deletion to
finish") % (snapshot.description, vm.name)
   time.sleep(60)
   except Exception as e:
   print ("Snapshot %s does not exist anymore") %
snapshot.description
   print ("Snapshot deletion for %s done") % vm.name
   print ("Deletion of snapshots done")
   api.disconnect()
except Exception as e:
   print ("Something went wrong when deleting the snapshots\n%s") %
str(e)



<― snip ―>


Cheers
Soeren





On 03/06/15 15:20, "Adam Litke"  wrote:


On 03/06/15 07:36 +, Soeren Malchow wrote:

Dear Adam

First we were using a python script that was working on 4 threads and
therefore removing 4 snapshots at the time throughout the cluster, that
still caused problems.

Now i took the snapshot removing out of the threaded part an i am just
looping through each snapshot on each VM one after another, even with
³sleeps² inbetween, but the problem remains.
But i am getting the impression that it is a problem with the amount of
snapshots that are deleted in a certain time, if i delete manually and
one
after another (meaning every 10 min or so) i do not have problems, if i
delete manually and do several at once and on one VM the next one just
after one finished, the risk seems to increase.


Hmm.  In our lab we extensively tested removing a snapshot for a VM
with 4 disks.  This means 4 block jobs running simultaneously.  Less
than 10 minutes later (closer to 1 minute) we would remove a second
snapshot for the same VM (again involving 4 block jobs).  I guess we
should rerun this flow on a fully updated CentOS 7.1 host to see about
local reproduction.  Seems your case is much simpler than this though.
Is this happening every time or intermittently?


I do not think it is the number of VMS because we had this on hosts with
only 3 or 4 Vms running

I will try restarting the libvirt and see what happens.

We are not using RHEL 7.1 only CentOS 7.1

Is there anything else we can look at when this happens again ?


I'll defer to Eric Blake for the libvirt side of this.  Eric, would
enabling debug logging in libvirtd help to shine some light on the
problem?

--
Adam Litke


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users




--
Adam Litke
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Hi Adam, Hi Eric,

We had this issue again a few minutes ago.

One machine went down exactly the same way as described, the machine had
only one snapshot and it was the only snapshot that was removed, before
that in the same scriptrun we deleted the snapshots of 15 other Vms, some
without, some with 1 and some with several snapshots.

Can i provide anything from the logs that helps ?

Regards
Soeren 



On 03/06/15 18:07, "Soeren Malchow"  wrote:

>Hi,
>
>This is not happening every time, the last time i had this, it was a
>script runnning, and something like th 9. Vm and the 23. Vm had a problem,
>and it is not always the same VMS, it is not about the OS (happen for
>Windows and Linux alike)
>
>And as i said it also happened when i tried to remove the snapshots
>sequentially, here is the code (i know it is probably not the elegant way,
>but i am not a developer) and the code actually has correct indentions.
>
><― snip ―>
>
>print "Snapshot deletion"
>try:
>time.sleep(300)
>Connect()
>vms = api.vms.list()
>for vm in vms:
>print ("Deleting snapshots for %s ") % vm.name
>snapshotlist = vm.snapshots.list()
>for snapshot in snapshotlist:
>if snapshot.description != "Active VM":
>time.sleep(30)
>snapshot.delete()
>try:
>while
>api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status ==
>"locked":
>print("Waiting for snapshot %s on %s deletion to
>finish") % (snapshot.description, vm.name)
>time.sleep(60)
>except Exception as e:
>print ("Snapshot %s does not exist anymore") %
>snapshot.description
>print ("Snapshot deletion for %s done") % vm.name
>print ("Deletion of snapshots done")
>api.disconnect()
>except Exception as e:
>print ("Something went wrong when deleting the snapshots\n%s") %
>str(e)
>
>
>
><― snip ―> 
>
>
>Cheers
>Soeren
>
>
>
>
>
>On 03/06/15 15:20, "Adam Litke"  wrote:
>
>>On 03/06/15 07:36 +, Soeren Malchow wrote:
>>>Dear Adam
>>>
>>>First we were using a python script that was working on 4 threads and
>>>therefore removing 4 snapshots at the time throughout the cluster, that
>>>still caused problems.
>>>
>>>Now i took the snapshot removing out of the threaded part an i am just
>>>looping through each snapshot on each VM one after another, even with
>>>³sleeps² inbetween, but the problem remains.
>>>But i am getting the impression that it is a problem with the amount of
>>>snapshots that are deleted in a certain time, if i delete manually and
>>>one
>>>after another (meaning every 10 min or so) i do not have problems, if i
>>>delete manually and do several at once and on one VM the next one just
>>>after one finished, the risk seems to increase.
>>
>>Hmm.  In our lab we extensively tested removing a snapshot for a VM
>>with 4 disks.  This means 4 block jobs running simultaneously.  Less
>>than 10 minutes later (closer to 1 minute) we would remove a second
>>snapshot for the same VM (again involving 4 block jobs).  I guess we
>>should rerun this flow on a fully updated CentOS 7.1 host to see about
>>local reproduction.  Seems your case is much simpler than this though.
>>Is this happening every time or intermittently?
>>
>>>I do not think it is the number of VMS because we had this on hosts with
>>>only 3 or 4 Vms running
>>>
>>>I will try restarting the libvirt and see what happens.
>>>
>>>We are not using RHEL 7.1 only CentOS 7.1
>>>
>>>Is there anything else we can look at when this happens again ?
>>
>>I'll defer to Eric Blake for the libvirt side of this.  Eric, would
>>enabling debug logging in libvirtd help to shine some light on the
>>problem?
>>
>>-- 
>>Adam Litke
>
>___
>Users mailing list
>Users@ovirt.org
>http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Hi,

This is not happening every time, the last time i had this, it was a
script runnning, and something like th 9. Vm and the 23. Vm had a problem,
and it is not always the same VMS, it is not about the OS (happen for
Windows and Linux alike)

And as i said it also happened when i tried to remove the snapshots
sequentially, here is the code (i know it is probably not the elegant way,
but i am not a developer) and the code actually has correct indentions.

<― snip ―>

print "Snapshot deletion"
try:
time.sleep(300)
Connect()
vms = api.vms.list()
for vm in vms:
print ("Deleting snapshots for %s ") % vm.name
snapshotlist = vm.snapshots.list()
for snapshot in snapshotlist:
if snapshot.description != "Active VM":
time.sleep(30)
snapshot.delete()
try:
while
api.vms.get(name=vm.name).snapshots.get(id=snapshot.id).snapshot_status ==
"locked":
print("Waiting for snapshot %s on %s deletion to
finish") % (snapshot.description, vm.name)
time.sleep(60)
except Exception as e:
print ("Snapshot %s does not exist anymore") %
snapshot.description
print ("Snapshot deletion for %s done") % vm.name
print ("Deletion of snapshots done")
api.disconnect()
except Exception as e:
print ("Something went wrong when deleting the snapshots\n%s") % str(e)



<― snip ―> 


Cheers
Soeren





On 03/06/15 15:20, "Adam Litke"  wrote:

>On 03/06/15 07:36 +, Soeren Malchow wrote:
>>Dear Adam
>>
>>First we were using a python script that was working on 4 threads and
>>therefore removing 4 snapshots at the time throughout the cluster, that
>>still caused problems.
>>
>>Now i took the snapshot removing out of the threaded part an i am just
>>looping through each snapshot on each VM one after another, even with
>>³sleeps² inbetween, but the problem remains.
>>But i am getting the impression that it is a problem with the amount of
>>snapshots that are deleted in a certain time, if i delete manually and
>>one
>>after another (meaning every 10 min or so) i do not have problems, if i
>>delete manually and do several at once and on one VM the next one just
>>after one finished, the risk seems to increase.
>
>Hmm.  In our lab we extensively tested removing a snapshot for a VM
>with 4 disks.  This means 4 block jobs running simultaneously.  Less
>than 10 minutes later (closer to 1 minute) we would remove a second
>snapshot for the same VM (again involving 4 block jobs).  I guess we
>should rerun this flow on a fully updated CentOS 7.1 host to see about
>local reproduction.  Seems your case is much simpler than this though.
>Is this happening every time or intermittently?
>
>>I do not think it is the number of VMS because we had this on hosts with
>>only 3 or 4 Vms running
>>
>>I will try restarting the libvirt and see what happens.
>>
>>We are not using RHEL 7.1 only CentOS 7.1
>>
>>Is there anything else we can look at when this happens again ?
>
>I'll defer to Eric Blake for the libvirt side of this.  Eric, would
>enabling debug logging in libvirtd help to shine some light on the
>problem?
>
>-- 
>Adam Litke

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Adam Litke]

On 03/06/15 07:36 +, Soeren Malchow wrote:

Dear Adam

First we were using a python script that was working on 4 threads and
therefore removing 4 snapshots at the time throughout the cluster, that
still caused problems.

Now i took the snapshot removing out of the threaded part an i am just
looping through each snapshot on each VM one after another, even with
³sleeps² inbetween, but the problem remains.
But i am getting the impression that it is a problem with the amount of
snapshots that are deleted in a certain time, if i delete manually and one
after another (meaning every 10 min or so) i do not have problems, if i
delete manually and do several at once and on one VM the next one just
after one finished, the risk seems to increase.


Hmm.  In our lab we extensively tested removing a snapshot for a VM
with 4 disks.  This means 4 block jobs running simultaneously.  Less
than 10 minutes later (closer to 1 minute) we would remove a second
snapshot for the same VM (again involving 4 block jobs).  I guess we
should rerun this flow on a fully updated CentOS 7.1 host to see about
local reproduction.  Seems your case is much simpler than this though.
Is this happening every time or intermittently?


I do not think it is the number of VMS because we had this on hosts with
only 3 or 4 Vms running

I will try restarting the libvirt and see what happens.

We are not using RHEL 7.1 only CentOS 7.1

Is there anything else we can look at when this happens again ?


I'll defer to Eric Blake for the libvirt side of this.  Eric, would
enabling debug logging in libvirtd help to shine some light on the
problem?

--
Adam Litke
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Dear Adam

First we were using a python script that was working on 4 threads and
therefore removing 4 snapshots at the time throughout the cluster, that
still caused problems.

Now i took the snapshot removing out of the threaded part an i am just
looping through each snapshot on each VM one after another, even with
³sleeps² inbetween, but the problem remains.
But i am getting the impression that it is a problem with the amount of
snapshots that are deleted in a certain time, if i delete manually and one
after another (meaning every 10 min or so) i do not have problems, if i
delete manually and do several at once and on one VM the next one just
after one finished, the risk seems to increase.

I do not think it is the number of VMS because we had this on hosts with
only 3 or 4 Vms running

I will try restarting the libvirt and see what happens.

We are not using RHEL 7.1 only CentOS 7.1

Is there anything else we can look at when this happens again ?

Regards
Soeren 



On 02/06/15 18:53, "Adam Litke"  wrote:

>Hello Soeren.
>
>I've started to look at this issue and I'd agree that at first glance
>it looks like a libvirt issue.  The 'cannot acquire state change lock'
>messages suggest a locking bug or severe contention at least.  To help
>me better understand the problem I have a few questions about your
>setup.
>
>From your earlier report it appears that you have 15 VMs running on
>the failing host.  Are you attempting to remove snapshots from all VMs
>at the same time?  Have you tried with fewer concurrent operations?
>I'd be curious to understand if the problem is connected to the
>number of VMs running or the number of active block jobs.
>
>Have you tried RHEL-7.1 as a hypervisor host?
>
>Rather than rebooting the host, does restarting libvirtd cause the VMs
>to become responsive again?  Note that this operation may cause the
>host to move to Unresponsive state in the UI for a short period of
>time.
>
>Thanks for your report.
>
>On 31/05/15 23:39 +, Soeren Malchow wrote:
>>And sorry, another update, it does kill the VM partly, it was still
>>pingable when i wrote the last mail, but no ssh and no spice console
>>possible
>>
>>From: Soeren Malchow
>>mailto:soeren.malc...@mcon.net>>
>>Date: Monday 1 June 2015 01:35
>>To: Soeren Malchow
>>mailto:soeren.malc...@mcon.net>>,
>>"libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>"
>>mailto:libvirt-us...@redhat.com>>, users
>>mailto:users@ovirt.org>>
>>Subject: Re: [ovirt-users] Bug in Snapshot Removing
>>
>>Small addition again:
>>
>>This error shows up in the log while removing snapshots WITHOUT
>>rendering the Vms unresponsive
>>
>>‹
>>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]:
>>Timed out during operation: cannot acquire state change lock
>>Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm
>>vm.Vm ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting
>>block job info
>> 
>>Traceback (most recent call last):
>>File
>>"/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobsŠ
>>
>>‹
>>
>>
>>
>>From: Soeren Malchow
>>mailto:soeren.malc...@mcon.net>>
>>Date: Monday 1 June 2015 00:56
>>To: "libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>"
>>mailto:libvirt-us...@redhat.com>>, users
>>mailto:users@ovirt.org>>
>>Subject: [ovirt-users] Bug in Snapshot Removing
>>
>>Dear all
>>
>>I am not sure if the mail just did not get any attention between all the
>>mails and this time it is also going to the libvirt mailing list.
>>
>>I am experiencing a problem with VM becoming unresponsive when removing
>>Snapshots (Live Merge) and i think there is a serious problem.
>>
>>Here are the previous mails,
>>
>>http://lists.ovirt.org/pipermail/users/2015-May/033083.html
>>
>>The problem is on a system with everything on the latest version, CentOS
>>7.1 and ovirt 3.5.2.1 all upgrades applied.
>>
>>This Problem did NOT exist before upgrading to CentOS 7.1 with an
>>environment running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the
>>libvirt-preview repo activated.
>>
>>I think this is a bug in libvirt, not ovirt itself, but i am not sure.
>>The actual file throwing the exception is in VDSM
>>(/usr/share/vdsm/virt/vm.py, line 697).
>>
>>We are very willing to help, test and supply log files in anyway we can.
>>
>>Regards
>>Soeren
>>
>
>>___
>>Users mailing list
>>Users@ovirt.org
>>http://lists.ovirt.org/mailman/listinfo/users
>
>
>-- 
>Adam Litke

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Adam Litke]

Hello Soeren.

I've started to look at this issue and I'd agree that at first glance
it looks like a libvirt issue.  The 'cannot acquire state change lock'
messages suggest a locking bug or severe contention at least.  To help
me better understand the problem I have a few questions about your
setup.

From your earlier report it appears that you have 15 VMs running on
the failing host.  Are you attempting to remove snapshots from all VMs
at the same time?  Have you tried with fewer concurrent operations?
I'd be curious to understand if the problem is connected to the
number of VMs running or the number of active block jobs.

Have you tried RHEL-7.1 as a hypervisor host?

Rather than rebooting the host, does restarting libvirtd cause the VMs
to become responsive again?  Note that this operation may cause the
host to move to Unresponsive state in the UI for a short period of
time.

Thanks for your report.

On 31/05/15 23:39 +, Soeren Malchow wrote:

And sorry, another update, it does kill the VM partly, it was still pingable 
when i wrote the last mail, but no ssh and no spice console possible

From: Soeren Malchow mailto:soeren.malc...@mcon.net>>
Date: Monday 1 June 2015 01:35
To: Soeren Malchow mailto:soeren.malc...@mcon.net>>, 
"libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>" 
mailto:libvirt-us...@redhat.com>>, users mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Bug in Snapshot Removing

Small addition again:

This error shows up in the log while removing snapshots WITHOUT rendering the 
Vms unresponsive

—
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed out 
during operation: cannot acquire state change lock
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.Vm 
ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block job info
 Traceback 
(most recent call last):
   File 
"/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs…

—



From: Soeren Malchow mailto:soeren.malc...@mcon.net>>
Date: Monday 1 June 2015 00:56
To: "libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>" 
mailto:libvirt-us...@redhat.com>>, users 
mailto:users@ovirt.org>>
Subject: [ovirt-users] Bug in Snapshot Removing

Dear all

I am not sure if the mail just did not get any attention between all the mails 
and this time it is also going to the libvirt mailing list.

I am experiencing a problem with VM becoming unresponsive when removing 
Snapshots (Live Merge) and i think there is a serious problem.

Here are the previous mails,

http://lists.ovirt.org/pipermail/users/2015-May/033083.html

The problem is on a system with everything on the latest version, CentOS 7.1 
and ovirt 3.5.2.1 all upgrades applied.

This Problem did NOT exist before upgrading to CentOS 7.1 with an environment 
running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview repo 
activated.

I think this is a bug in libvirt, not ovirt itself, but i am not sure. The 
actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, line 
697).

We are very willing to help, test and supply log files in anyway we can.

Regards
Soeren




___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



--
Adam Litke
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Allon Mureinik]

Adam, can you take a look at this please? 

Thanks! 

- Original Message -

> From: "Soeren Malchow" 
> To: "Soeren Malchow" , libvirt-us...@redhat.com,
> "users" 
> Sent: Monday, June 1, 2015 2:39:24 AM
> Subject: Re: [ovirt-users] Bug in Snapshot Removing

> And sorry, another update, it does kill the VM partly, it was still pingable
> when i wrote the last mail, but no ssh and no spice console possible

> From: Soeren Malchow < soeren.malc...@mcon.net >
> Date: Monday 1 June 2015 01:35
> To: Soeren Malchow < soeren.malc...@mcon.net >, " libvirt-us...@redhat.com "
> < libvirt-us...@redhat.com >, users < users@ovirt.org >
> Subject: Re: [ovirt-users] Bug in Snapshot Removing

> Small addition again:

> This error shows up in the log while removing snapshots WITHOUT rendering the
> Vms unresponsive

> —
> Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed
> out during operation: cannot acquire state change lock
> Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.Vm
> ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block job
> info
> Traceback (most recent call last):
> File "/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs…

> —

> From: Soeren Malchow < soeren.malc...@mcon.net >
> Date: Monday 1 June 2015 00:56
> To: " libvirt-us...@redhat.com " < libvirt-us...@redhat.com >, users <
> users@ovirt.org >
> Subject: [ovirt-users] Bug in Snapshot Removing

> Dear all

> I am not sure if the mail just did not get any attention between all the
> mails and this time it is also going to the libvirt mailing list.

> I am experiencing a problem with VM becoming unresponsive when removing
> Snapshots (Live Merge) and i think there is a serious problem.

> Here are the previous mails,

> http://lists.ovirt.org/pipermail/users/2015-May/033083.html

> The problem is on a system with everything on the latest version, CentOS 7.1
> and ovirt 3.5.2.1 all upgrades applied.

> This Problem did NOT exist before upgrading to CentOS 7.1 with an environment
> running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview repo
> activated.

> I think this is a bug in libvirt, not ovirt itself, but i am not sure. The
> actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py,
> line 697).

> We are very willing to help, test and supply log files in anyway we can.

> Regards
> Soeren

> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

And sorry, another update, it does kill the VM partly, it was still pingable 
when i wrote the last mail, but no ssh and no spice console possible

From: Soeren Malchow mailto:soeren.malc...@mcon.net>>
Date: Monday 1 June 2015 01:35
To: Soeren Malchow mailto:soeren.malc...@mcon.net>>, 
"libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>" 
mailto:libvirt-us...@redhat.com>>, users 
mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Bug in Snapshot Removing

Small addition again:

This error shows up in the log while removing snapshots WITHOUT rendering the 
Vms unresponsive

—
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed out 
during operation: cannot acquire state change lock
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.Vm 
ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block job info
  Traceback 
(most recent call last):
File 
"/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs…

—



From: Soeren Malchow mailto:soeren.malc...@mcon.net>>
Date: Monday 1 June 2015 00:56
To: "libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>" 
mailto:libvirt-us...@redhat.com>>, users 
mailto:users@ovirt.org>>
Subject: [ovirt-users] Bug in Snapshot Removing

Dear all

I am not sure if the mail just did not get any attention between all the mails 
and this time it is also going to the libvirt mailing list.

I am experiencing a problem with VM becoming unresponsive when removing 
Snapshots (Live Merge) and i think there is a serious problem.

Here are the previous mails,

http://lists.ovirt.org/pipermail/users/2015-May/033083.html

The problem is on a system with everything on the latest version, CentOS 7.1 
and ovirt 3.5.2.1 all upgrades applied.

This Problem did NOT exist before upgrading to CentOS 7.1 with an environment 
running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview repo 
activated.

I think this is a bug in libvirt, not ovirt itself, but i am not sure. The 
actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, line 
697).

We are very willing to help, test and supply log files in anyway we can.

Regards
Soeren

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Small addition again:

This error shows up in the log while removing snapshots WITHOUT rendering the 
Vms unresponsive

—
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net libvirtd[1657]: Timed out 
during operation: cannot acquire state change lock
Jun 01 01:33:45 mc-dc3ham-compute-02-live.mc.mcon.net vdsm[6839]: vdsm vm.Vm 
ERROR vmId=`56848f4a-cd73-4eda-bf79-7eb80ae569a9`::Error getting block job info
  Traceback 
(most recent call last):
File 
"/usr/share/vdsm/virt/vm.py", line 5759, in queryBlockJobs…

—



From: Soeren Malchow mailto:soeren.malc...@mcon.net>>
Date: Monday 1 June 2015 00:56
To: "libvirt-us...@redhat.com<mailto:libvirt-us...@redhat.com>" 
mailto:libvirt-us...@redhat.com>>, users 
mailto:users@ovirt.org>>
Subject: [ovirt-users] Bug in Snapshot Removing

Dear all

I am not sure if the mail just did not get any attention between all the mails 
and this time it is also going to the libvirt mailing list.

I am experiencing a problem with VM becoming unresponsive when removing 
Snapshots (Live Merge) and i think there is a serious problem.

Here are the previous mails,

http://lists.ovirt.org/pipermail/users/2015-May/033083.html

The problem is on a system with everything on the latest version, CentOS 7.1 
and ovirt 3.5.2.1 all upgrades applied.

This Problem did NOT exist before upgrading to CentOS 7.1 with an environment 
running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview repo 
activated.

I think this is a bug in libvirt, not ovirt itself, but i am not sure. The 
actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, line 
697).

We are very willing to help, test and supply log files in anyway we can.

Regards
Soeren

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Bug in Snapshot Removing

[Soeren Malchow]

Dear all

I am not sure if the mail just did not get any attention between all the mails 
and this time it is also going to the libvirt mailing list.

I am experiencing a problem with VM becoming unresponsive when removing 
Snapshots (Live Merge) and i think there is a serious problem.

Here are the previous mails,

http://lists.ovirt.org/pipermail/users/2015-May/033083.html

The problem is on a system with everything on the latest version, CentOS 7.1 
and ovirt 3.5.2.1 all upgrades applied.

This Problem did NOT exist before upgrading to CentOS 7.1 with an environment 
running ovirt 3.5.0 and 3.5.1 and Fedora 20 with the libvirt-preview repo 
activated.

I think this is a bug in libvirt, not ovirt itself, but i am not sure. The 
actual file throwing the exception is in VDSM (/usr/share/vdsm/virt/vm.py, line 
697).

We are very willing to help, test and supply log files in anyway we can.

Regards
Soeren

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug: Spice port changed!!!!!

[Vinzenz Feenstra]

On 09/23/2014 12:22 PM, Vinzenz Feenstra wrote:

On 09/23/2014 10:15 AM, PaulCheung wrote:

Dear David:

This problem have been solve!Using the vm ID to find the 
spice port!



/#!/bin/bash/
/curl -k -v -u 'admin@internal:password!' -H "Content-type: 
application/xml" -X GET 
https://172.16.1.115/api/vms/ea273653-b083-4114-9ed4-bbb0bb5d38c1 > 
./vm.info/

/p1=$(cat ./vm.info|grep '')/
/p2=$(cat ./vm.info|grep '')/
/port1=${p1:0-11:4}/
/port2=${p2:0-18:4}/
/spicy -h 172.16.1.115 -w 123456 -p $port1 -s $port2 -f 
--spice-ca-file=/home/cubie/ca.crt >/dev/null 2>&1 &/


You could try POST with content type: application/json 
/https://172.16.1.115/api/vms/ea273653-b083-4114-9ed4-bbb0bb5d38c1//start

Oh I forgot to add: The body should be sufficient if it is '{}'


Hope that helps. :-)




It is awesome! * But dou you know what command can start the VM if 
the VM stop/power off   ?*





Sincerely yours,
PaulCheung


 tel: 180-8882-7173


> Subject: Re: [ovirt-users] Bug: Spice port changed!
> From: dj...@redhat.com
> To: eq2...@msn.com
> CC: users@ovirt.org
> Date: Mon, 22 Sep 2014 14:44:03 +0200
>
> Paul,
>
> Short answer: your approach will not work. I mentioned the custom hooks
> and engine-config/UserDefinedVMProperties for a reason. Please 
follow my

> advice first before asking further advice.
>
>
> Longer answer: your changes to the libvirt domains would apply on next
> domain cold start but that will never happen because vdsm always 
creates

> libvirt domains as transient ones so the libvirt domain will disappear
> on guest OS shutdown. On next start of the same oVirt VM, vdsm will
> creates a new domain XML that will be used to start a new libvirt
> transient domain.
>
> In order to make this new libvirt domain use your desired parameters,
> you have to edit the XML before it is used to start the libvirt domain
> and because we humans are too slow to do that and too annoyed to do 
that

> on every VM start, vdsm hooks mechanism was devised and a script in
> before_vm_start can do that changes for you (with input variables
> defined in engine-config and set in VM's custom properties).
>
>
> So back to my original suggestion: do you still think that it is 
wise to

> try method that is more complicated and less secure than the custom
> launcher method?
>
>
> Regards,
>
> David
>
> On Po, 2014-09-22 at 11:11 +0800, PaulCheung wrote:
> > Dear David:
> >
> >
> > I am trying figure it out using my way. So I used "virsh edit vm",
> > I change the port the 5980 & 5981, but still not work!!!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I found after virsh edit, there is a xml file here /etc/libvirt/qemu
> > which I edit using "virsh edit vm".
> >
> >
> > And I also run this command : "virsh define vm.xml"
> >
> >
> > also not work. Can you tell me where is the file I can fixed the
> > spice port.
> >
> >
> >
> >
> > Sincerely yours,
> > PaulCheung
> >
> >
> > tel: 180-8882-7173
> >
> >
> >
> > > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > > From: dj...@redhat.com
> > > To: eq2...@msn.com
> > > CC: users@ovirt.org
> > > Date: Thu, 18 Sep 2014 15:27:50 +0200
> > >
> > > Hi,
> > >
> > > 2) is not a file, it's a key in engine-config
> > > 3) is a VDSM custom hook that needs to be in all the hypervisors in
> > DC/Cluster
> > >
> > > Follow vdsm custom hook documentation (I don't have a link from top
> > of my head but web or ML archives will surely help).
> > >
> > > David
> > >
> > > On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> > > > Dear David,
> > > >
> > > >
> > > > Thank you for your help . Your answer is very professional.
> > > >
> > > >
> > > > I still can't not find a way to stick with static port 
assignments

> > > > For I don't understand you telling me , 2&3, where I can find the
> > > > file to modify?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > However, if you _really_ want to stick with static port
> > assignments,
> > > > do
> > > > > the following:
> > > > > 1) designate the port range so that it doesn't collide with
> > other
> > > > ranges
> > > > > in use (e.g. RHEV 

Re: [ovirt-users] Bug: Spice port changed!!!!!

[Vinzenz Feenstra]

On 09/23/2014 10:15 AM, PaulCheung wrote:

Dear David:

This problem have been solve!Using the vm ID to find the 
spice port!



/#!/bin/bash/
/curl -k -v -u 'admin@internal:password!' -H "Content-type: 
application/xml" -X GET 
https://172.16.1.115/api/vms/ea273653-b083-4114-9ed4-bbb0bb5d38c1 > 
./vm.info/

/p1=$(cat ./vm.info|grep '')/
/p2=$(cat ./vm.info|grep '')/
/port1=${p1:0-11:4}/
/port2=${p2:0-18:4}/
/spicy -h 172.16.1.115 -w 123456 -p $port1 -s $port2 -f 
--spice-ca-file=/home/cubie/ca.crt >/dev/null 2>&1 &/


You could try POST with content type: application/json 
/https://172.16.1.115/api/vms/ea273653-b083-4114-9ed4-bbb0bb5d38c1//start


Hope that helps. :-)




It is awesome! * But dou you know what command can start the VM if the 
VM stop/power off   ?*





Sincerely yours,
PaulCheung


 tel: 180-8882-7173


> Subject: Re: [ovirt-users] Bug: Spice port changed!
> From: dj...@redhat.com
> To: eq2...@msn.com
> CC: users@ovirt.org
> Date: Mon, 22 Sep 2014 14:44:03 +0200
>
> Paul,
>
> Short answer: your approach will not work. I mentioned the custom hooks
> and engine-config/UserDefinedVMProperties for a reason. Please follow my
> advice first before asking further advice.
>
>
> Longer answer: your changes to the libvirt domains would apply on next
> domain cold start but that will never happen because vdsm always creates
> libvirt domains as transient ones so the libvirt domain will disappear
> on guest OS shutdown. On next start of the same oVirt VM, vdsm will
> creates a new domain XML that will be used to start a new libvirt
> transient domain.
>
> In order to make this new libvirt domain use your desired parameters,
> you have to edit the XML before it is used to start the libvirt domain
> and because we humans are too slow to do that and too annoyed to do that
> on every VM start, vdsm hooks mechanism was devised and a script in
> before_vm_start can do that changes for you (with input variables
> defined in engine-config and set in VM's custom properties).
>
>
> So back to my original suggestion: do you still think that it is wise to
> try method that is more complicated and less secure than the custom
> launcher method?
>
>
> Regards,
>
> David
>
> On Po, 2014-09-22 at 11:11 +0800, PaulCheung wrote:
> > Dear David:
> >
> >
> > I am trying figure it out using my way. So I used "virsh edit vm",
> > I change the port the 5980 & 5981, but still not work!!!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I found after virsh edit, there is a xml file here /etc/libvirt/qemu
> > which I edit using "virsh edit vm".
> >
> >
> > And I also run this command : "virsh define vm.xml"
> >
> >
> > also not work. Can you tell me where is the file I can fixed the
> > spice port.
> >
> >
> >
> >
> > Sincerely yours,
> > PaulCheung
> >
> >
> > tel: 180-8882-7173
> >
> >
> >
> > > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > > From: dj...@redhat.com
> > > To: eq2...@msn.com
> > > CC: users@ovirt.org
> > > Date: Thu, 18 Sep 2014 15:27:50 +0200
> > >
> > > Hi,
> > >
> > > 2) is not a file, it's a key in engine-config
> > > 3) is a VDSM custom hook that needs to be in all the hypervisors in
> > DC/Cluster
> > >
> > > Follow vdsm custom hook documentation (I don't have a link from top
> > of my head but web or ML archives will surely help).
> > >
> > > David
> > >
> > > On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> > > > Dear David,
> > > >
> > > >
> > > > Thank you for your help . Your answer is very professional.
> > > >
> > > >
> > > > I still can't not find a way to stick with static port assignments
> > > > For I don't understand you telling me , 2&3, where I can find the
> > > > file to modify?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > However, if you _really_ want to stick with static port
> > assignments,
> > > > do
> > > > > the following:
> > > > > 1) designate the port range so that it doesn't collide with
> > other
> > > > ranges
> > > > > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > > > > 2) add a custom VM properties to the engine for setting of po

Re: [ovirt-users] Bug: Spice port changed!!!!!

[PaulCheung]

Dear David:
This problem have been solve!Using the vm ID to find the spice port!

#!/bin/bashcurl -k -v -u 'admin@internal:password!' -H "Content-type: 
application/xml" -X GET 
https://172.16.1.115/api/vms/ea273653-b083-4114-9ed4-bbb0bb5d38c1 > 
./vm.infop1=$(cat ./vm.info|grep '')p2=$(cat ./vm.info|grep 
'')port1=${p1:0-11:4}port2=${p2:0-18:4}spicy -h 172.16.1.115 -w 
123456 -p $port1 -s $port2 -f --spice-ca-file=/home/cubie/ca.crt >/dev/null 
2>&1 &


It is awesome!But dou you know what command can start the VM if the VM 
stop/power off   ?




Sincerely yours,
PaulCheung


 tel: 180-8882-7173


> Subject: Re: [ovirt-users] Bug:  Spice port changed!
> From: dj...@redhat.com
> To: eq2...@msn.com
> CC: users@ovirt.org
> Date: Mon, 22 Sep 2014 14:44:03 +0200
> 
> Paul,
> 
> Short answer: your approach will not work. I mentioned the custom hooks
> and engine-config/UserDefinedVMProperties for a reason. Please follow my
> advice first before asking further advice.
> 
> 
> Longer answer: your changes to the libvirt domains would apply on next
> domain cold start but that will never happen because vdsm always creates
> libvirt domains as transient ones so the libvirt domain will disappear
> on guest OS shutdown. On next start of the same oVirt VM, vdsm will
> creates a new domain XML that will be used to start a new libvirt
> transient domain.
> 
> In order to make this new libvirt domain use your desired parameters,
> you have to edit the XML before it is used to start the libvirt domain
> and because we humans are too slow to do that and too annoyed to do that
> on every VM start, vdsm hooks mechanism was devised and a script in
> before_vm_start can do that changes for you (with input variables
> defined in engine-config and set in VM's custom properties).
> 
> 
> So back to my original suggestion: do you still think that it is wise to
> try method that is more complicated and less secure than the custom
> launcher method?
> 
> 
> Regards,
> 
> David
> 
> On Po, 2014-09-22 at 11:11 +0800, PaulCheung wrote:
> > Dear David:
> > 
> > 
> > I am trying figure it out using my way.   So I used "virsh edit vm",
> > I change the port the 5980 & 5981,   but still not work!!!
> > 
> > 
> >   
> > 
> >  
> > 
> > 
> > 
> > 
> > I found after virsh edit,  there is a xml file here  /etc/libvirt/qemu
> > which I edit using "virsh edit vm".
> > 
> > 
> > And I also run this command :"virsh define vm.xml"
> > 
> > 
> > also not work.Can you tell me where is the file I can fixed the
> > spice port.
> > 
> > 
> > 
> > 
> > Sincerely yours,
> > PaulCheung
> > 
> > 
> >  tel: 180-8882-7173
> > 
> > 
> > 
> > > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > > From: dj...@redhat.com
> > > To: eq2...@msn.com
> > > CC: users@ovirt.org
> > > Date: Thu, 18 Sep 2014 15:27:50 +0200
> > > 
> > > Hi,
> > > 
> > > 2) is not a file, it's a key in engine-config
> > > 3) is a VDSM custom hook that needs to be in all the hypervisors in
> > DC/Cluster
> > > 
> > > Follow vdsm custom hook documentation (I don't have a link from top
> > of my head but web or ML archives will surely help).
> > > 
> > > David
> > > 
> > > On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> > > > Dear David,
> > > > 
> > > > 
> > > > Thank you for your help . Your answer is very professional.
> > > > 
> > > > 
> > > > I still can't not find a way to stick with static port assignments
> > > > For I don't understand you telling me , 2&3, where I can find the
> > > > file to modify?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > However, if you _really_ want to stick with static port
> > assignments,
> > > > do
> > > > > the following:
> > > > > 1) designate the port range so that it doesn't collide with
> > other
> > > > ranges
> > > > > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > > > > 2) add a custom VM properties to the engine for setting of port
> > and
> > > > > tls-port
> > > > > 3) add a vdsm hook to before_vm_start directory on each host
> > th

Re: [ovirt-users] Bug: Spice port changed!!!!!

[David Jaša]

Paul,

Short answer: your approach will not work. I mentioned the custom hooks
and engine-config/UserDefinedVMProperties for a reason. Please follow my
advice first before asking further advice.


Longer answer: your changes to the libvirt domains would apply on next
domain cold start but that will never happen because vdsm always creates
libvirt domains as transient ones so the libvirt domain will disappear
on guest OS shutdown. On next start of the same oVirt VM, vdsm will
creates a new domain XML that will be used to start a new libvirt
transient domain.

In order to make this new libvirt domain use your desired parameters,
you have to edit the XML before it is used to start the libvirt domain
and because we humans are too slow to do that and too annoyed to do that
on every VM start, vdsm hooks mechanism was devised and a script in
before_vm_start can do that changes for you (with input variables
defined in engine-config and set in VM's custom properties).


So back to my original suggestion: do you still think that it is wise to
try method that is more complicated and less secure than the custom
launcher method?


Regards,

David

On Po, 2014-09-22 at 11:11 +0800, PaulCheung wrote:
> Dear David:
> 
> 
> I am trying figure it out using my way.   So I used "virsh edit vm",
> I change the port the 5980 & 5981,   but still not work!!!
> 
> 
>   
> 
>  
> 
> 
> 
> 
> I found after virsh edit,  there is a xml file here  /etc/libvirt/qemu
> which I edit using "virsh edit vm".
> 
> 
> And I also run this command :"virsh define vm.xml"
> 
> 
> also not work.Can you tell me where is the file I can fixed the
> spice port.
> 
> 
> 
> 
> Sincerely yours,
> PaulCheung
> 
> 
>  tel: 180-8882-7173
> 
> 
> 
> > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > From: dj...@redhat.com
> > To: eq2...@msn.com
> > CC: users@ovirt.org
> > Date: Thu, 18 Sep 2014 15:27:50 +0200
> > 
> > Hi,
> > 
> > 2) is not a file, it's a key in engine-config
> > 3) is a VDSM custom hook that needs to be in all the hypervisors in
> DC/Cluster
> > 
> > Follow vdsm custom hook documentation (I don't have a link from top
> of my head but web or ML archives will surely help).
> > 
> > David
> > 
> > On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> > > Dear David,
> > > 
> > > 
> > > Thank you for your help . Your answer is very professional.
> > > 
> > > 
> > > I still can't not find a way to stick with static port assignments
> > > For I don't understand you telling me , 2&3, where I can find the
> > > file to modify?
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > However, if you _really_ want to stick with static port
> assignments,
> > > do
> > > > the following:
> > > > 1) designate the port range so that it doesn't collide with
> other
> > > ranges
> > > > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > > > 2) add a custom VM properties to the engine for setting of port
> and
> > > > tls-port
> > > > 3) add a vdsm hook to before_vm_start directory on each host
> that
> > > will
> > > > add "port" and "tlsPort" parameters to the graphics element of
> > > libvirt
> > > > domain xml
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Sincerely yours,
> > > PaulCheung
> > > 
> > > 
> > > tel: 180-8882-7173
> > > 
> > > 
> > > 
> > > > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > > > From: dj...@redhat.com
> > > > To: eq2...@msn.com
> > > > CC: users@ovirt.org
> > > > Date: Wed, 17 Sep 2014 10:40:42 +0200
> > > > 
> > > > Hi Paul,
> > > > 
> > > > This behaviour is by design. It is a bad idea to override it. A
> good
> > > > approach to your problem would be to write a launcher script
> that
> > > would:
> > > > 1) connect to the REST API
> > > > 2) get the VM connection details
> > > > 3) get new VM ticket
> > > > 4) write this info down to a temporary .vv file [3]
> > > > 5) launch remote-viewer
> > > > 
> > > > Some info how to use REST API is described here [1] and .vv file
> > > format
> > > > is documented in virt-vie

Re: [ovirt-users] Bug: Spice port changed!!!!!

[PaulCheung]

Dear David:
I am trying figure it out using my way.   So I used "virsh edit vm",   I change 
the port the 5980 & 5981,   but still not work!!!
  

I found after virsh edit,  there is a xml file here  /etc/libvirt/qemu 
which I edit using "virsh edit vm".
And I also run this command :"virsh define vm.xml"
also not work.Can you tell me where is the file I can fixed the spice port.




Sincerely yours,
PaulCheung


 tel: 180-8882-7173


> Subject: Re: [ovirt-users] Bug:  Spice port changed!
> From: dj...@redhat.com
> To: eq2...@msn.com
> CC: users@ovirt.org
> Date: Thu, 18 Sep 2014 15:27:50 +0200
> 
> Hi,
> 
> 2) is not a file, it's a key in engine-config
> 3) is a VDSM custom hook that needs to be in all the hypervisors in DC/Cluster
> 
> Follow vdsm custom hook documentation (I don't have a link from top of my 
> head but web or ML archives will surely help).
> 
> David
> 
> On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> > Dear David,
> > 
> > 
> > Thank you for your help . Your answer is very professional.
> > 
> > 
> > I still can't not find a way to stick with static port assignments
> > For I don't understand you telling me ,  2&3, where I can find the
> > file to modify?
> > 
> > 
> > 
> > 
> > 
> > 
> > > However, if you _really_ want to stick with static port assignments,
> > do
> > > the following:
> > > 1) designate the port range so that it doesn't collide with other
> > ranges
> > > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > > 2) add a custom VM properties to the engine for setting of port and
> > > tls-port
> > > 3) add a vdsm hook to before_vm_start directory on each host that
> > will
> > > add "port" and "tlsPort" parameters to the graphics element of
> > libvirt
> > > domain xml
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Sincerely yours,
> > PaulCheung
> > 
> > 
> >  tel: 180-8882-7173
> > 
> > 
> > 
> > > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > > From: dj...@redhat.com
> > > To: eq2...@msn.com
> > > CC: users@ovirt.org
> > > Date: Wed, 17 Sep 2014 10:40:42 +0200
> > > 
> > > Hi Paul,
> > > 
> > > This behaviour is by design. It is a bad idea to override it. A good
> > > approach to your problem would be to write a launcher script that
> > would:
> > > 1) connect to the REST API
> > > 2) get the VM connection details
> > > 3) get new VM ticket
> > > 4) write this info down to a temporary .vv file [3]
> > > 5) launch remote-viewer
> > > 
> > > Some info how to use REST API is described here [1] and .vv file
> > format
> > > is documented in virt-viewer sources [2]. Please note that [1] is a
> > bit
> > > outdated:
> > > * you can use HTTP header "filter: true" to be able to log in as
> > non-admin
> > > * you only have to use password login once when you use
> > > "prefer: persistent-auth" HTTP header and you send the cookie you
> > got
> > > in a response to first request.
> > > In the future, the steps 2-4 will become a one step of getting a
> > > ready-to-use .vv file from the API [3] but we aren't there yet.
> > > 
> > > [1]
> > http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal
> > > [2]
> > https://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer-file.c#n30
> > > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1128763
> > > 
> > > 
> > > However, if you _really_ want to stick with static port assignments,
> > do
> > > the following:
> > > 1) designate the port range so that it doesn't collide with other
> > ranges
> > > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > > 2) add a custom VM properties to the engine for setting of port and
> > > tls-port
> > > 3) add a vdsm hook to before_vm_start directory on each host that
> > will
> > > add "port" and "tlsPort" parameters to the graphics element of
> > libvirt
> > > domain xml
> > > 
> > > 
> > > Best regards,
> > > 
> > > David
> > > 
> > > On St, 2014-09-17 at 10:41 +0800, PaulCheung wrote:
> > > > Dear all,
> > > > 
> > > > 
>

Re: [ovirt-users] Bug: Spice port changed!!!!!

[David Jaša]

Hi,

2) is not a file, it's a key in engine-config
3) is a VDSM custom hook that needs to be in all the hypervisors in DC/Cluster

Follow vdsm custom hook documentation (I don't have a link from top of my head 
but web or ML archives will surely help).

David

On Thu, 2014-09-18 at 14:51 +0800, PaulCheung wrote:
> Dear David,
> 
> 
> Thank you for your help . Your answer is very professional.
> 
> 
> I still can't not find a way to stick with static port assignments
> For I don't understand you telling me ,  2&3, where I can find the
> file to modify?
> 
> 
> 
> 
> 
> 
> > However, if you _really_ want to stick with static port assignments,
> do
> > the following:
> > 1) designate the port range so that it doesn't collide with other
> ranges
> > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > 2) add a custom VM properties to the engine for setting of port and
> > tls-port
> > 3) add a vdsm hook to before_vm_start directory on each host that
> will
> > add "port" and "tlsPort" parameters to the graphics element of
> libvirt
> > domain xml
> > 
> 
> 
> 
> 
> 
> 
> Sincerely yours,
> PaulCheung
> 
> 
>  tel: 180-8882-7173
> 
> 
> 
> > Subject: Re: [ovirt-users] Bug: Spice port changed!
> > From: dj...@redhat.com
> > To: eq2...@msn.com
> > CC: users@ovirt.org
> > Date: Wed, 17 Sep 2014 10:40:42 +0200
> > 
> > Hi Paul,
> > 
> > This behaviour is by design. It is a bad idea to override it. A good
> > approach to your problem would be to write a launcher script that
> would:
> > 1) connect to the REST API
> > 2) get the VM connection details
> > 3) get new VM ticket
> > 4) write this info down to a temporary .vv file [3]
> > 5) launch remote-viewer
> > 
> > Some info how to use REST API is described here [1] and .vv file
> format
> > is documented in virt-viewer sources [2]. Please note that [1] is a
> bit
> > outdated:
> > * you can use HTTP header "filter: true" to be able to log in as
> non-admin
> > * you only have to use password login once when you use
> > "prefer: persistent-auth" HTTP header and you send the cookie you
> got
> > in a response to first request.
> > In the future, the steps 2-4 will become a one step of getting a
> > ready-to-use .vv file from the API [3] but we aren't there yet.
> > 
> > [1]
> http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal
> > [2]
> https://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer-file.c#n30
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1128763
> > 
> > 
> > However, if you _really_ want to stick with static port assignments,
> do
> > the following:
> > 1) designate the port range so that it doesn't collide with other
> ranges
> > in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> > 2) add a custom VM properties to the engine for setting of port and
> > tls-port
> > 3) add a vdsm hook to before_vm_start directory on each host that
> will
> > add "port" and "tlsPort" parameters to the graphics element of
> libvirt
> > domain xml
> > 
> > 
> > Best regards,
> > 
> > David
> > 
> > On St, 2014-09-17 at 10:41 +0800, PaulCheung wrote:
> > > Dear all,
> > > 
> > > 
> > > After shutdown the VM, then restart the VM the Vm's spice port is
> > > changed!
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Because I have 10 terminal ARM-Box running spice client connected
> to
> > > the vm, but after the VM shutdown and start again, the vm not the
> one
> > > whice the one before.
> > > 
> > > 
> > > I wish you can let us have a option, to let the VM with a fixed
> spice
> > > port, like:
> > > vm1: spice port : 5900 tls:5901
> > > vm2: 5902 5903
> > > 
> > > 
> > > And I have another recommond: have a fuction to do that :
> > > 
> > > 
> > > if the vm shutdown by user, it will start the VM automatic. That
> > > means the VM can not be shutdown!
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > I hope you can have this two fuction! That means a lot to those
> who
> > > are using Terminal box user like me.
> > > 
> > > 
> > > 
> > > 
> > > I am sorry for my poor English. But I hope you all can understand
> > > what I am saying.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Sincerely yours,
> > > PaulCheung
> > > 
> > > 
> > > tel: 180-8882-7173
> > > 
> > > ___
> > > Users mailing list
> > > Users@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/users
> > 
> > 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug: Spice port changed!!!!!

[PaulCheung]

Dear David,
Thank you for your help . Your answer is very professional.
I still can't not find a way to stick with static port assignmentsFor I don't 
understand you telling me ,  2&3, where I can find the file to modify?


> However, if you _really_ want to stick with static port assignments, do
> the following:
> 1) designate the port range so that it doesn't collide with other ranges
> in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> 2) add a custom VM properties to the engine for setting of port and
> tls-port
> 3) add a vdsm hook to before_vm_start directory on each host that will
> add "port" and "tlsPort" parameters to the graphics element of libvirt
> domain xml
> 





Sincerely yours,
PaulCheung


 tel: 180-8882-7173


> Subject: Re: [ovirt-users] Bug:  Spice port changed!
> From: dj...@redhat.com
> To: eq2...@msn.com
> CC: users@ovirt.org
> Date: Wed, 17 Sep 2014 10:40:42 +0200
> 
> Hi Paul,
> 
> This behaviour is by design. It is a bad idea to override it. A good
> approach to your problem would be to write a launcher script that would:
> 1) connect to the REST API
> 2) get the VM connection details
> 3) get new VM ticket
> 4) write this info down to a temporary .vv file [3]
> 5) launch remote-viewer
> 
> Some info how to use REST API is described here [1] and .vv file format
> is documented in virt-viewer sources [2]. Please note that [1] is a bit
> outdated:
>   * you can use HTTP header "filter: true" to be able to log in as non-admin
>   * you only have to use password login once when you use
> "prefer: persistent-auth" HTTP header and you send the cookie you got
> in a response to first request.
> In the future, the steps 2-4 will become a one step of getting a
> ready-to-use .vv file from the API [3] but we aren't there yet.
> 
> [1] http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal
> [2] 
> https://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer-file.c#n30
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1128763
> 
> 
> However, if you _really_ want to stick with static port assignments, do
> the following:
> 1) designate the port range so that it doesn't collide with other ranges
> in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
> 2) add a custom VM properties to the engine for setting of port and
> tls-port
> 3) add a vdsm hook to before_vm_start directory on each host that will
> add "port" and "tlsPort" parameters to the graphics element of libvirt
> domain xml
> 
> 
> Best regards,
> 
> David
> 
> On St, 2014-09-17 at 10:41 +0800, PaulCheung wrote:
> > Dear all,
> > 
> > 
> > After shutdown the VM, then restart the VM the Vm's spice port is
> > changed!
> >   
> > 
> >  
> > 
> > 
> > 
> > 
> > Because I have 10 terminal ARM-Box  running spice client connected to
> > the vm,  but after the VM shutdown and start again, the vm not the one
> > whice the one before.
> > 
> > 
> > I wish you can let us have a option, to let the VM with a fixed spice
> > port,   like:
> > vm1:   spice port : 5900   tls:5901
> > vm2:5902   5903
> > 
> > 
> > And I have another recommond:have a fuction to do that :
> > 
> > 
> > if the vm shutdown by user,   it will start the VM automatic. That
> > means the VM can not be shutdown!
> > 
> > 
> > 
> > 
> > 
> > 
> > I hope you can have this two fuction!   That means a lot to those who
> > are using Terminal box user like me.
> > 
> > 
> > 
> > 
> > I am sorry for my poor English.  But I hope you all can understand
> > what I am saying.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Sincerely yours,
> > PaulCheung
> > 
> > 
> >  tel: 180-8882-7173
> > 
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> 
> 
  ___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Bug: Spice port changed!!!!!

[David Jaša]

Hi Paul,

This behaviour is by design. It is a bad idea to override it. A good
approach to your problem would be to write a launcher script that would:
1) connect to the REST API
2) get the VM connection details
3) get new VM ticket
4) write this info down to a temporary .vv file [3]
5) launch remote-viewer

Some info how to use REST API is described here [1] and .vv file format
is documented in virt-viewer sources [2]. Please note that [1] is a bit
outdated:
  * you can use HTTP header "filter: true" to be able to log in as non-admin
  * you only have to use password login once when you use
"prefer: persistent-auth" HTTP header and you send the cookie you got
in a response to first request.
In the future, the steps 2-4 will become a one step of getting a
ready-to-use .vv file from the API [3] but we aren't there yet.

[1] http://www.ovirt.org/How_to_Connect_to_SPICE_Console_Without_Portal
[2] 
https://git.fedorahosted.org/cgit/virt-viewer.git/tree/src/virt-viewer-file.c#n30
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1128763


However, if you _really_ want to stick with static port assignments, do
the following:
1) designate the port range so that it doesn't collide with other ranges
in use (e.g. RHEV uses 5900-6023, so 5800-5899 could be safe)
2) add a custom VM properties to the engine for setting of port and
tls-port
3) add a vdsm hook to before_vm_start directory on each host that will
add "port" and "tlsPort" parameters to the graphics element of libvirt
domain xml


Best regards,

David

On St, 2014-09-17 at 10:41 +0800, PaulCheung wrote:
> Dear all,
> 
> 
> After shutdown the VM, then restart the VM the Vm's spice port is
> changed!
>   
> 
>  
> 
> 
> 
> 
> Because I have 10 terminal ARM-Box  running spice client connected to
> the vm,  but after the VM shutdown and start again, the vm not the one
> whice the one before.
> 
> 
> I wish you can let us have a option, to let the VM with a fixed spice
> port,   like:
> vm1:   spice port : 5900   tls:5901
> vm2:5902   5903
> 
> 
> And I have another recommond:have a fuction to do that :
> 
> 
> if the vm shutdown by user,   it will start the VM automatic. That
> means the VM can not be shutdown!
> 
> 
> 
> 
> 
> 
> I hope you can have this two fuction!   That means a lot to those who
> are using Terminal box user like me.
> 
> 
> 
> 
> I am sorry for my poor English.  But I hope you all can understand
> what I am saying.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Sincerely yours,
> PaulCheung
> 
> 
>  tel: 180-8882-7173
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Bug: Spice port changed!!!!!

[PaulCheung]

Dear all,
After shutdown the VM, then restart the VM the Vm's spice port is changed!  


Because I have 10 terminal ARM-Box  running spice client connected to the vm,  
but after the VM shutdown and start again, the vm not the one whice the one 
before.
I wish you can let us have a option, to let the VM with a fixed spice port,   
like:vm1:   spice port : 5900   tls:5901vm2:5902   5903
And I have another recommond:have a fuction to do that :
if the vm shutdown by user,   it will start the VM automatic. That means the VM 
can not be shutdown!


I hope you can have this two fuction!   That means a lot to those who are using 
Terminal box user like me.

I am sorry for my poor English.  But I hope you all can understand what I am 
saying.







Sincerely yours,
PaulCheung


 tel: 180-8882-7173
  ___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users