engine: Disable iSCSI multipathing for datacenters < 3.4

I had to fix a few issues in VDSM 3.4 in order to support configuration of
iSCSI multipathing, therefore this feature should be disabled for earlier
datacenter versions.

Change-Id: I623cd917ca0871a9d3d09c2d30ec2dfc114d383e
Signed-off-by: Sergey Gotliv <sgotliv@redhat.com>
engine: Send ifaceName and tpgt in connectStorageServer

Engine mistakenly sent initiatorName instead of ifaceName which overwrote
existing initiatorName configured in the host. Wrong initiatorName caused
host fail to perform iSCSI connection.

In case of tpgt the problem is terminology. Engine sent it as a "portal"
and its value is integer,  but from the iSCSI perspective portal is an
access point to one or more targets, while this integer actually
represents a tpgt - target portal group tag which is numeric representation
of which IP addresses a target is allowed to bind on.

Bug-Url: https://bugzilla.redhat.com/1078137
Change-Id: Ife467feb8aad9711da5d6a5df305e50fe6bf51e9
Signed-off-by: Sergey Gotliv <sgotliv@redhat.com>
engine: Set default tpgt value to 1

Engine uses wrong iSCSI terminology, portal instead of tpgt (target
portal group tag) which only purpose at this stage impose iSCSI layer to
create node record in the new format supporting multipathing.

Tpgt default value in VDSM is 1 so it should be the same here.

Change-Id: I7ebfc1335b051e02f62b9544d2500416818940d0
Signed-off-by: Sergey Gotliv <sgotliv@redhat.com>
core: fix sysprep architecture values

arch values don't match the OS ini question - x86 instead of
amd64 for OSs which are 64 bit

Change-Id: Id61fea5f128de054bfe143d9888751205fa080e4
Bug-Url: https://bugzilla.redhat.com/1066884
Signed-off-by: Roy Golan <rgolan@redhat.com>
tools: add missing fields to snmp notifier.

Change-Id: I4f2941a9af206e85fe15f9bb2372f4b44669699e
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1081420
Signed-off-by: Mooli Tayer <mtayer@redhat.com>
core: set vm exit status to error on fencing

As part of fence operation, we set the VM status to down using
SetVmStatusVDSCommand. This command did not filled the exit status of
the VM which should be ERROR in this case. So this patch adds that
missing part by passing the exit status that should be set for the VM
while changing its status through the parameters of the command.

Change-Id: If541c6d33a7cfa310ba776e4bc7fa0f1e45aa077
Bug-Url: https://bugzilla.redhat.com/1077706
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: Correct error message

The error message ACTION_NOT_SUPPORTED_FOR_CLUSTER_POOL_LEVEL lacked the
type parameter which resulted in message like "The Action add is not
supported" instead of "add Disk" for instance.

Change-Id: I5517297e0de3350f3d62ab67cb908b4525e306d8
Related-To: https://bugzilla.redhat.com/1074254
Signed-off-by: Tal Nisan <tnisan@redhat.com>
webadmin: Fixed message when adding Posix domain when not supported

The message when adding a Posix domain when it's not supported on the
cluster was broken and lacking the action type and entity type

Change-Id: I237e40dd325c7b36c4413eab48e3aed41c090c4f
Bug-Url: https://bugzilla.redhat.com/1074254
Signed-off-by: Tal Nisan <tnisan@redhat.com>
core: make migrate commands non-transactive

Patch 94e48a02 removed the global transaction during RunVmCommand.
Global transactions should also be removed from the migrate commands
for the same reasons and because it prevents us from migrating multiple
VMs from different hosts to the same host while one of the migrations
is in its execute phase or start a VM on a host while another VM is
migrating to that host and the migration is in its execute phase.

Change-Id: I4894ebd5f062174f9780926a0ce6b499fcc0fc7b
Bug-Url: https://bugzilla.redhat.com/1064931
Signed-off-by: Arik Hadas <ahadas@redhat.com>
tools: adding missing space to fix type

Bug-Url: https://bugzilla.redhat.com/1058957
Change-Id: I663852b5ab9617e864413f760afe56e79cbdf3cb
Signed-off-by: Yair Zaslavsky <yzaslavs@redhat.com>
webadmin: Overload ListModel.setItems() with selectedItem

Added an overload that includes an argument specifying the desired
selectedItem after the items are set; previously this was being set to
null, which could cause problems if the ListModel is associated with
an editor that implements HasConstrainedValue (because then
UiCommonEditorVisitor would override the null value and select the
first item in the collection).

Change-Id: Id6de644297cdd5eb965720fc64aea1a5a735ea24
Bug-Url: https://bugzilla.redhat.com/1070835
Signed-off-by: Lior Vernia <lvernia@redhat.com>
webadmin: Only set cluster once when opening VM dialog

Previously the cluster could potentially be called twice in the
initialization of the dialog: once UiCommonEditorVisitor set the
selected item to be the first in the collection, then if the VM
belonged to another cluster the selection would change. This would
cause issues due to asynchronous tasks, triggered by the
selectedItemChangedEvent, returning in reversed order.

This is fixed by using the new overload of ListModel.setItems(), to
make sure that the selected cluster is properly selected the first
time and so won't trigger dual sets of backend queries.

Change-Id: I5b4dd3328f207dadb73ee93d27f084249f3f9704
Bug-Url: https://bugzilla.redhat.com/1070835
Signed-off-by: Lior Vernia <lvernia@redhat.com>
engine: event should contain the iface which exceeded defined threshold

A general event was reported per host when any of the host's NICs exceeded
the threshold (based TX or RX values). The event didn't contain the nics
name. And containd just the max TX or RX from all the interfaces.
This patch extends it to a specific event per interface.

Change-Id: I22b3510398ac6fa3acf93fcb596dd6ea10b26366
Bug-Url: https://bugzilla.redhat.com/1070667
Signed-off-by: Alona Kaplan <alkaplan@redhat.com>
engine: fix interface high network use script number

Change-Id: I65b539a7ad15517c76cb663d9fc02088ea83f530
Signed-off-by: Alona Kaplan <alkaplan@redhat.com>
host-deploy: node-upgrade: apply artificial eof for vdsm-upgrade

apply artificial end-of-file.

there is no way in java to use non blocking
InputStream.

there is no way to interrupt the blocking.

and we cannot terminate thread as the connection
pool will get messy.

so we should detect eof based on data.

Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1080594
Change-Id: I093357933d2f10c0d90864f53977b832a58dafbd
Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>
REST: Adding validation for snapshot id on preview

Adding validation for snapshot id, when issuing PREVIEW on a VM.

Change-Id: Ib325c7d1a23eb0558f360cc0916bb0fcca981186
Signed-off-by: Maor Lipchuk <mlipchuk@redhat.com>
core: make ClearNonResponsiveVdsVms non-transactive

ClearNonResponsiveVdsVmsCommand basically do the following things:
1. Change all the VMs that ran on the host to DOWN
2. Update the VDS attributes as if no VM is running on the host
3. Run HA VMs that ran on the host

Since this command used to be transactive, the DOWN state on the VMs was
not committed at stage #3. The RunVmCommands triggered in stage #3 still
worked because we were doing the canDoAction checks in the same
transaction (in the multiple action runner). If on the other hand we were
just executing the command one-by-one it would not work because
RunVmCommand is non-transactive so in the canDoAction checks we were
thinking the VMs are in UNKNOWN state - and this is wrong.

There is no real reason for this command to be transactive since after
the user confirmed that the host has been booted, we assume the VMs are
DOWN anyway so the right thing to do is changed their status to DOWN.

The only problematic case of changing the status of the VMs outside of a
transaction scope will be if the host was powered off and we didn't
reach stage #3 (run the HA VMs) after doing stage #1 (this is very
unlikely to happen though) - The VMs will be DOWN and their runningOnVds
field will be blank so VURTI won't try to rerun them when the host will
go up. The good side is that the user will be able to run them manually
if the host is not going to restart (as opposed to keep them in UNKNOWN
state).

So for a conclusion: this patch is not ideal, it solved an issue and
creates another minor issue which is very not likely to happen, and
should probably be fixed by another mechanism that will rerun HA VMs
which are DOWN because of an error and AutoStartVmsRunner didn't try
to rerun.

Change-Id: Ia8728e56f21ff6dcf6e103b1d450eecfaa36e809
Bug-Url: https://bugzilla.redhat.com/1080961
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: Fix AuditLog check for existing log entries

The audit log check for existing element in the cache,
If the entry exist, then there is no need for another log message.
This is how the anti flooding mechanism works.
For that we use Infinispan cache and the putIfAbsent method,
which updates the lifespan(time to keep in cache).
For our use of the cache, we don't want this update.

The fix changes the putIfAbsent and replace it with two othe API methods,
Contains and Put.

Change-Id: I94b777911eb1ff667be3dc8362bde5746d84824c
Bug-Url: https://bugzilla.redhat.com/1079920
Signed-off-by: Kobi Ianko <kobi@redhat.com>
core: rerun HA VMs on automatic fence using AutoStartVmsRunner

Before the engine sends fence request to VDSM, it tries to rerun the
highly available VMs that ran on the host by invoking RunVmCommand
directly. The problem is that we won't try to rerun the VM again if the
RunVmCommand fails (and in case the host which is being fenced in the
only one that was active in the cluster the command will fail for sure).
The solution is to rerun the highly available VMs using
AutoStartVmsRunner job in this flow as well.

Change-Id: Ic259ff22c4b6f24b09eb973de6e31ebc51aa966b
Bug-Url: https://bugzilla.redhat.com/1077706
Signed-off-by: Arik Hadas <ahadas@redhat.com>
core: Physically disconnecting blade from chass...

Physically disconnecting blade from chassis does not trigger HA VMs to
restart

This patch verifies that if a Stop PM operation fails and the Host on
which the fencing was performed had running VMs, those VMs will be set
to the UNKNOWN status just after the Stop PM operation failed.

This way, the user can confirm manually that Host has been rebooted and
start HA VMs on another host.

Change-Id: I7d638d574bfe9195e56bdc5970544f97af15af6c
Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1063432
Signed-off-by: Eli Mesika <emesika@redhat.com>