Search Engine: Elastic

Article ID: 133037, created on Aug 10, 2018, last review on Aug 10, 2018

  • Applies to:
  • Operations Automation

Symptoms

An attempt to create an HTTP Load Balancer results in a failure.

In /var/log/pa/vps.vm2vf.log where the LB was getting created:

// callback restore_ve_image_cb done_with_message
{
  "rc" : -2147282891,
  "node_timestamp" : 3293826746620576631,
  "msg" : "An internal error occurred when performing the operation. Try to migrate the Container again. If the problem persists, contact the Parallels support team for assistance."
}</payload></Envelope> to destination queue://client

The following message also appears on the same node:

Aug 10 01:47:27.412 vzmdest[1022567]: Target private area /vz/private/103 already exists and resides on cluster

/vz/private directory is a link to cluster storage:

[root@vz01 ~]# ls -ald /vz/private
lrwxrwxrwx 1 root root 13 Jan 22  2018 /vz/private -> /pcs/private/

Cause

/vz/private directory is used for creating VEs on local storage, which is true for LB creation. In case the directory is linked with the cluster storage, a VEID conflict may appear with some other node in cluster.

Resolution

The resolution of this issue should be applied carefully:

  1. Analyze what VEs on the current node actually have local storage in OACI.
  2. Move such VEs to a local location with VZ tools, usage example:

    # vzmlocal 10001:10001:/vz/localprivate/10001 --online
    
  3. For other VEs on the current node that have cluster storage configured in OACI, configure the home directory to cluster storage explicitly, replacing the VE_PRIVATE line in ve.conf, usage example:

    # sed -i 's|VE_PRIVATE="/vz/private/$VEID"|VE_PRIVATE="/pcs/private/$VEID"|' /vz/private/10002/ve.conf
    
  4. Remove the link:

    # unlink /vz/private
    
  5. Create a local directory:

    # mkdir /vz/private
    
  6. Move the VEs into this directory:

    # vzmlocal 10001:10001:/vz/private/10001 --online
    

The actions above should resolve the inconsistency completely.

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF