Node names in NV_VMNODES

This patch populates the list 'NV_VMNODES' with node
names and not node UUIDs, as the backend only uses this
list to identify VM-capable nodes by querying for the
node name.

Signed-off-by: Helga Velroyen <helgav@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>
Renaming NV_VMNODES to NV_NONVMNODES

This patch renames the constant 'NV_VMNODES' to
'NV_NONVMNODES' as it is actually used to store
a list of *non* vm-capable nodes.

Signed-off-by: Helga Velroyen <helgav@google.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>
Fix invalid message from gnt-os

When we still don't have any os scripts installed, running gnt-os
diagnose or gnt-os info foo(whatever) shows an error message "Can't get
the OS list" even if the request has been succeeded.
The OpOsDiagnose can return a blank list, so we should check whether
the result is None.

Signed-off-by: Yuto KAWAMURA(kawamuray) <kawamuray.dadada@gmail.com>
Reviewed-by: Hrvoje Ribicic <riba@google.com>
Fix DRBD version check for non VM capable nodes

Commit 742dc8de revealed a bug concerning DRBD version check during
cluster verify: In case non VM cabables nodes have DRBD not
installed, we get a version mismatch warning.

VerifyNode() updates the NV_DRBDVERSION key in the response message
only if a node is VM capable. Even if noded fails to retrieve the
DRBD version, the error string is returned.

Thus we must first check in _VerifyGroupDRBDVersion() if the
NV_DRBDVERSION key of the response message is updated and
then verify if we have different versions across nodes.

Signed-off-by: Dimitris Aragiorgis <dimara@grnet.gr>
Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Allow _LockList to handle locking.ALL_SET

This patch makes a minor adjustment to _LockList in order for it to
be capable of accepting locking.ALL_SET without issues.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Cherry-picked from: 038a9f8f6c34d78e97cda16f913e267ce92d52f4

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Allow coexistence of adding and acquiring locks

The constraint that locks may not be added and acquired at the same
time was in place before 2.12 only due to the fact that additional
complicated logic was necessary to do so.

With the new locking system, implementing this becomes much easier,
and quite useful at that, as it will allow us to get rid of BGL usage
for instance renames a bit later.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Cherry-picked from: 9261433f5385f2dee65a8de7ce6f1baa0221c547

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Factor out instance existence checks

These checks were repeated in the code, and will have to be reused for
the instance renames.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Partially cherry-picked from: e1798d178dea0503325822df0a30367b9e56a9bb

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

Conflicts:
	lib/cmdlib/instance_utils.py
Remove BGL from LUInstanceRename

Once locks can be both acquired and added simultaneously, the BGL in
LUInstanceRename is no longer needed.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>

Cherry-picked from: 14533030a16af190d613df7784df38d25b9c2a57

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Fix failing BGL whitelist test

A test checking for the use of opcodes in LUs was not updated when the
BGL was removed from OpInstanceRename. This patch removes the opcode
from the BGL whitelist.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

Cherry-picked from: 8b3cd8ffc9400deeed381f541af76f0f809ff2eb

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Ganeti.Daemon: always install SIGHUP handler

Install the SIGHUP handler regardless of the daemonization status. This
fixes issue #755.

Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>
systemd: start kvmd by default

We update the kvmd unit file to start kvmd by default in the ganeti-node
and ganeti targets, to reflect the changes done in the initscript.

Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Petr Pudlak <pudlak@google.com>
ganeti.daemon: fix daemon mode with GnuTLS >= 3.3

Newer GnuTLS versions (>= 3.3.0) use a library constructor for
initialization and open /dev/urandom on library load, way before we
fork(). Closing /dev/urandom on fork causes a failure to re-seed GnuTLS's
random number generator during the first ganeti.http.client request, which
in turn causes the process to silently abort(3).

For more background on this behavior, see this thread at the GnuTLS
mailing list:

http://lists.gnupg.org/pipermail/gnutls-help/2014-April/003429.html

Note that calling pycurl.global_init() at the correct place (as we do) is not
enough, as it does not cause a re-initialization of the GnuTLS library.

As we cannot reliably detect neither the GnuTLS version, nor the socket, we
work our way around this by keeping all fds referring to /dev/urandom open
after fork. We do so using the /proc/self/fd interface.

This fixes issues #961 and #964.

Note that this would not affect the Haskell daemons using cURL + GnuTLS,
because we don't close all file descriptors on fork there.

Signed-off-by: Apollon Oikonomopoulos <apoikos@gmail.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Remove misleading cleanup

The rule of thumb in the Ganeti QA is that we do not attempt to clean
up after ourselves - we clean up in detail before a QA, and attempt to
retain as much state as possible for debugging / hunting purposes.
This patch removes an instance removal which was meant to serve as
cleanup, but ended up reporting false errors.

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Merge branch 'stable-2.9' into stable-2.10

* stable-2.9
  Ganeti.Daemon: always install SIGHUP handler

Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Merge branch 'stable-2.10' into stable-2.11

* stable-2.10
  ganeti.daemon: fix daemon mode with GnuTLS >= 3.3
  Fix DRBD version check for non VM capable nodes
  Fix invalid message from gnt-os
  Renaming NV_VMNODES to NV_NONVMNODES
  Node names in NV_VMNODES

* stable-2.9
  Ganeti.Daemon: always install SIGHUP handler

Signed-off-by: Petr Pudlak <pudlak@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>
Extend the Hypervisor interface by VersionsSafeForMigration

The question which hypervisor versions are safe to migrate between
is hypervisor dependent. The default implementation is that it's
probably fine if the versions are equal and otherwise be safe and
disallow it.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Use HV-specific version comparison function

...to decide if a migration is safe.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Move Xen-specific version test hv_xen

The hypervisor-compatibility test we used was specific to
Xen, so move it to the hv_xen instead of having it in util.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Be optimistic for kvm migration

Already in Ganeti 2.8, the machine_version feature was added to
the kvm hypervisor which allows migration in most cases. In order
not to block legitimate use cases, restore the old behavior and
do not check for version on kvm.

Signed-off-by: Klaus Aehlig <aehlig@google.com>
Reviewed-by: Helga Velroyen <helgav@google.com>
Refactoring: Move options from cli.py to cli_opts.py

The cli.py module exceeded our max-module-lines limit and needs to be
split.

This pulls out all command line option definitions into a separate module.

It uses cli_opts instead of cli.opts since importing a module below
your own path causes problems if you want to re-export everything
from the lower module (which we want in this case).

Signed-off-by: Niklas Hambuechen <niklash@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>