[Engine-devel] Failed to configure management network on the host
by Kanagaraj
Hi,
After adding a host to a 3.2 cluster, bootstrap went through fine and
in the end it failed with the following error.
"Host s2 installation failed. Failed to configure manamgent network on
the host."
Attached engine.log and vdsm.log
Vdsm rpms:
vdsm-4.10.2-22.2.el6rhs.x86_64
vdsm-python-4.10.2-22.2.el6rhs.x86_64
vdsm-cli-4.10.2-22.2.el6rhs.noarch
vdsm-gluster-4.10.2-22.2.el6rhs.noarch
vdsm-xmlrpc-4.10.2-22.2.el6rhs.noarch
Engine rpms: recent code from master
Can someone please help in resolving this issue,
Thanks,
Kanagaraj
12 years
[Engine-devel] static header only in VM dialog?
by Einav Cohen
when reviewing the code for the "redesign of vm related dialogs", Daniel has
raised an interesting question: Why do we want the static header only in VM dialog?
(I assume that he refers to the top section of the New VM dialog as seen in [1], which
contains the DC/Cluster, Quota, etc information, and is "static", i.e., it is always
displayed, regardless of the selected side-tab within the dialog)
I agree with what Daniel is implying here: for consistency, we would probably want to
introduce this static header to other dialogs, at least to the ones that also contain
side-tabs in which it makes sense to turn the "header" to static
[e.g.
"New Host" (which contains a DC + Cluster "header") - see http://oi39.tinypic.com/2z84xnp.jpg,
"New Cluster" (which contains a DC "header") - see http://oi40.tinypic.com/2vmyj2x.jpg]
[I assume, of course, that all the VM-like dialogs (e.g. New/Edit VM-Pool) will also have
static headers - I don't know if the patch already takes care of that or not]
Thoughts?
[@Daniel - if you had something else in mind, and/or other dialogs in mind - please feel free
to add/amend/etc]
----
Thanks,
Einav
[1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
----- Original Message -----
> From: derez(a)redhat.com
> To: "Tomas Jelinek" <tjelinek(a)redhat.com>
> Cc: "Vojtech Szocs" <vszocs(a)redhat.com>, "Einav Cohen" <ecohen(a)redhat.com>, "Frank Kobzik" <fkobzik(a)redhat.com>,
> "Eldan Hildesheim" <info(a)eldanet.com>
> Sent: Tuesday, May 28, 2013 5:05:38 PM
> Subject: Change in ovirt-engine[master]: userportal,webadmin: redesign of vm related dialogs
>
> Daniel Erez has posted comments on this change.
>
> Change subject: userportal,webadmin: redesign of vm related dialogs
> ......................................................................
>
>
> Patch Set 5: (1 inline comment)
>
> Code looks good.
> A few questions regarding the design:
> 1. Why do we want the static header only in VM dialog?
> 2. DC/Host are really relevant for all tabs?
> 3. Is it just a preparation for the final instance type dialog?
> 4. If it's indeed merely preparation, shouldn't it be merged only once we
> have the full picture of the new dialog?
>
> ....................................................
> File
> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> Line 21:
> Line 22: .header {
> Line 23: background-color: #D3D3D3;
> Line 24: border-bottom: 1px solid #CED8DF;
> Line 25: margin-bottom: 15px;
> is it supposed to be that large?
> Line 26: padding-top: 6px;
> Line 27: margin-top: 4px;
> Line 28: margin-right: 3px;
> Line 29: display: none;
>
>
> --
> To view, visit http://gerrit.ovirt.org/14635
> To unsubscribe, visit http://gerrit.ovirt.org/settings
>
> Gerrit-MessageType: comment
> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> Gerrit-PatchSet: 5
> Gerrit-Project: ovirt-engine
> Gerrit-Branch: master
> Gerrit-Owner: Tomas Jelinek <tjelinek(a)redhat.com>
> Gerrit-Reviewer: Daniel Erez <derez(a)redhat.com>
> Gerrit-Reviewer: Einav Cohen <ecohen(a)redhat.com>
> Gerrit-Reviewer: Eldan Hildesheim <info(a)eldanet.com>
> Gerrit-Reviewer: Frank Kobzik <fkobzik(a)redhat.com>
> Gerrit-Reviewer: Tomas Jelinek <tjelinek(a)redhat.com>
> Gerrit-Reviewer: Vojtech Szocs <vszocs(a)redhat.com>
>
12 years
Re: [Engine-devel] Odd Host Activation with mgmt-if
by Dead Horse
Still puzzling on this all I get for an error when I see it is:
WARN [org.ovirt.engine.core.bll.
network.host.SetupNetworksCommand] (pool-5-thread-42) [21543ac] CanDoAction
of action SetupNetworks failed.
Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
ovirtmgmt
Nothing is logged VDSM wise other then the above standard host activation
probe.
- DHC
On Mon, May 13, 2013 at 1:19 PM, Dead Horse
<deadhorseconsulting(a)gmail.com>wrote:
> Seeing this as of late when activating hosts. The odd this is that it
> reports a failure to activate the host (EL6.4) but still does it anyways.
>
> Engine side:
>
> 2013-05-13 12:53:38,547 INFO
> [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (pool-5-thread-42)
> [21543ac] Running command: HandleVdsVersionCommand internal: true. Entities
> affected : ID: 15f11023-9746-49de-b33f-e3cc7dca6f65 Type: VDS
> 2013-05-13 12:53:38,549 INFO
> [org.ovirt.engine.core.vdsbroker.ActivateVdsVDSCommand] (pool-5-thread-42)
> [21543ac] FINISH, ActivateVdsVDSCommand, return: Host[durotar], log id:
> 3796a7bd
> 2013-05-13 12:53:38,625 WARN
> [org.ovirt.engine.core.bll.network.host.SetupNetworksCommand]
> (pool-5-thread-42) [21543ac] CanDoAction of action SetupNetworks failed.
> Reasons:VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,NETWORKS_ALREADY_ATTACHED_TO_IFACES,$NETWORKS_ALREADY_ATTACHED_TO_IFACES_LIST
> ovirtmgmt
> 2013-05-13 12:53:39,368 INFO
> [org.ovirt.engine.core.bll.ActivateVdsCommand] (pool-5-thread-42) [21543ac]
> Activate finished. Lock released. Monitoring can run now for host durotar
> from data-center Azeroth
>
> VDSM Side:
>
> Thread-13::DEBUG::2013-05-13
> 12:53:37,841::BindingXMLRPC::933::vds::(wrapper) return getCapabilities
> with {'status': {'message': 'Done', 'code': 0}, 'info': {'HBAInventory':
> {'iSCSI': [{'InitiatorName': 'iqn.2012-09.net.azeroth:durotar'}], 'FC':
> []}, 'packages2': {'kernel': {'release': '358.6.1.el6.x86_64', 'buildtime':
> 1366751713.0, 'version': '2.6.32'}, 'glusterfs-rdma': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'},
> 'glusterfs-fuse': {'release': '0.3.alpha3.el6', 'buildtime': 1367604893L,
> 'version': '3.4.0'}, 'spice-server': {'release': '12.el6', 'buildtime':
> 1361573005L, 'version': '0.12.0'}, 'vdsm': {'release': '17.el6',
> 'buildtime': 1368196305L, 'version': '4.10.3'}, 'qemu-kvm': {'release':
> '2.355.el6_4.2', 'buildtime': 1362691270L, 'version': '0.12.1.2'},
> 'qemu-img': {'release': '2.355.el6_4.2', 'buildtime': 1362691270L,
> 'version': '0.12.1.2'}, 'libvirt': {'release': '18.el6_4.4', 'buildtime':
> 1366301801L, 'version': '0.10.2'}, 'glusterfs': {'release':
> '0.3.alpha3.el6', 'buildtime': 1367604893L, 'version': '3.4.0'}, 'mom':
> {'release': '1.el6', 'buildtime': 1349470062L, 'version': '0.3.0'},
> 'glusterfs-server': {'release': '0.3.alpha3.el6', 'buildtime': 1367604893L,
> 'version': '3.4.0'}}, 'cpuModel': 'Intel(R) Xeon(R) CPU X5570 @
> 2.93GHz', 'hooks': {'before_vm_start': {'50_sriov': {'md5':
> '3ebc60cd2e4eb089820102285fad7c45'}, '50_pincpu': {'md5':
> '0b5fb99ff0e7acb9ad534b87c02c59e3'}, '50_qos': {'md5':
> '18b596a6b4e4bad80357f240ba122a5e'}, '50_vmfex': {'md5':
> '9f5abb892ddb6b3daa779985d38d9f55'}, '50_scratchpad': {'md5':
> '7db25a4b8cb04f6e7132cb7c2300c111'}, '50_numa': {'md5':
> '5008c2826714ac5b63748780aabd2f25'}, '50_floppy': {'md5':
> '202fe18705a7d4c50c40c126e8f8dbe8'}, '50_qemucmdline': {'md5':
> 'a884929ad6f5eb039887157288867409'}, '50_macspoof': {'md5': '25deea559772719
>
> - DHC
>
12 years
[Engine-devel] Disk BE very small refactoring
by Vered Volansky
Hi All,
Please express your opinion if you have any -
Currently Disk BE has a plugged property, which should be a property of the relationship between vm(or template) and a disk.
I plan to remove this property from the Disk entity, and add new entity, called DeviceDisk.
This should inherit from Disk and contain the vm/template guid and the plugged property at first round.
At second round it'll also contain the readOnly property, for RO disks, TBD right after.
Appreciate any input,
Vered
12 years
[Engine-devel] cannot execute command in the class of InitVdsOnUpCommand
by Chen, Wei D
Hi,
We suppose when one VDS is added into cluster, executeCommand method in InitVdsOnUpCommand.java will be invoked, so, some logic will be checked there. But per our experiment, this is depended on what we actually did.
Here are some cases:
1. when reboot VDS, the logic in " executeCommand" will be invoked.
2. when re-deploy engine, the logic in " executeCommand" will be invoked.
3. when we add a new VDS (vdsm is running) into cluster, the logic in " executeCommand" will not be invoked.
What we expect is the logic will also be invoked in the third case, but why it's not invoked? What's behind all of these?
Best Regards,
Dave Chen
12 years
