Re: [ovirt-users] bug with ConsoleWriter ?

2017-04-22 Thread 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 ?

2017-04-22 Thread 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


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

2016-12-22 Thread 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 <a.ghela...@iontrading.com>
Cc: users <Users@ovirt.org>
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 
<a.ghela...@iontrading.com<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

2016-12-21 Thread 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

2016-04-05 Thread 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 
> > 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

2016-04-05 Thread 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

2016-03-30 Thread 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

2016-03-27 Thread 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


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

2016-01-18 Thread 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

2016-01-18 Thread 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

2016-01-17 Thread 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

2016-01-15 Thread 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


Re: [ovirt-users] Bug?

2015-11-27 Thread 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 

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

2015-06-17 Thread 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 daniel.helgenber...@m-box.de
 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
lambda
  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
lambda
  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=7arch=x86_64repo=osinfra=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 

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

2015-06-17 Thread Alon Bar-Lev
Please do not use multiple channels to discuss the same issue.

- Original Message -
 From: Daniel Helgenberger daniel.helgenber...@m-box.de
 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
lambda
  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
lambda
  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=7arch=x86_64repo=osinfra=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:'[(class 'yum.Errors.RepoError', RepoError(),
  traceback object at 0x2e26200)]'
  2015-06-17 12:27:37 DEBUG otopi.context context.dumpEnvironment:504
  ENVIRONMENT DUMP - END
  2015-06-17 12:27:37 INFO 

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

2015-06-17 Thread Alon Bar-Lev


- Original Message -
 From: Daniel Helgenberger daniel.helgenber...@m-box.de
 To: Alon Bar-Lev alo...@redhat.com
 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 daniel.helgenber...@m-box.de
  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
 lambda
   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
 lambda
   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

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

2015-06-17 Thread Daniel Helgenberger


On 17.06.2015 13:28, Alon Bar-Lev wrote:


 - Original Message -
 From: Daniel Helgenberger daniel.helgenber...@m-box.de
 To: Alon Bar-Lev alo...@redhat.com
 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 daniel.helgenber...@m-box.de
 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
 lambda
   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
 lambda
   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

Re: [ovirt-users] Bug in Snapshot Removing

2015-06-11 Thread 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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

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


Re: [ovirt-users] Bug in Snapshot Removing

2015-06-11 Thread 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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 

Re: [ovirt-users] Bug in Snapshot Removing

2015-06-04 Thread 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 ali...@redhat.com 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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

2015-06-04 Thread 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 soeren.malc...@mcon.net 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 ali...@redhat.com 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

2015-06-03 Thread 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 ali...@redhat.com 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
soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 01:35
To: Soeren Malchow
soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net,
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users
users@ovirt.orgmailto: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.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 00:56
To: libvirt-us...@redhat.commailto:libvirt-us...@redhat.com
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users
users@ovirt.orgmailto: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

2015-06-03 Thread 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

2015-06-02 Thread Allon Mureinik
Adam, can you take a look at this please? 

Thanks! 

- Original Message -

 From: Soeren Malchow soeren.malc...@mcon.net
 To: Soeren Malchow soeren.malc...@mcon.net, libvirt-us...@redhat.com,
 users users@ovirt.org
 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

2015-06-02 Thread 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 soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 01:35
To: Soeren Malchow soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net, 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users users@ovirt.orgmailto: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.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 00:56
To: libvirt-us...@redhat.commailto:libvirt-us...@redhat.com 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users 
users@ovirt.orgmailto: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

2015-05-31 Thread 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 soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 01:35
To: Soeren Malchow soeren.malc...@mcon.netmailto:soeren.malc...@mcon.net, 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users 
users@ovirt.orgmailto: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.netmailto:soeren.malc...@mcon.net
Date: Monday 1 June 2015 00:56
To: libvirt-us...@redhat.commailto:libvirt-us...@redhat.com 
libvirt-us...@redhat.commailto:libvirt-us...@redhat.com, users 
users@ovirt.orgmailto: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: Spice port changed!!!!!

2014-09-23 Thread 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 'port')p2=$(cat ./vm.info|grep 
'secure_port')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 
21 


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 , 23, 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

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

2014-09-23 Thread 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 'port')/
/p2=$(cat ./vm.info|grep 'secure_port')/
/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 21 /


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 , 23, 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

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

2014-09-23 Thread 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 'port')/
/p2=$(cat ./vm.info|grep 'secure_port')/
/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 21 /


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 , 23, 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

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

2014-09-21 Thread 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 ,  23, 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

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

2014-09-18 Thread 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 ,  23, 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!!!!!

2014-09-18 Thread 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 ,  23, 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