From users-return-31498-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Thu Oct 18 11:32:59 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 538AB180674 for ; Thu, 18 Oct 2018 11:32:59 +0200 (CEST) Received: (qmail 59247 invoked by uid 500); 18 Oct 2018 09:32:58 -0000 Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cloudstack.apache.org Delivered-To: mailing list users@cloudstack.apache.org Received: (qmail 59144 invoked by uid 99); 18 Oct 2018 09:32:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Oct 2018 09:32:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 1C413C8C97 for ; Thu, 18 Oct 2018 09:32:57 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.402 X-Spam-Level: *** X-Spam-Status: No, score=3.402 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_INFOUSMEBIZ=0.75, SPF_NEUTRAL=0.652] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id ql1LD85Z5bEY for ; Thu, 18 Oct 2018 09:32:56 +0000 (UTC) Received: from mailmx2.worldsupport.info (h1-89.worldsupport.info [46.107.239.89]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 8A2875F1CF for ; Thu, 18 Oct 2018 09:32:55 +0000 (UTC) Received: from pps.filterd (mail-mx4.corp.int [127.0.0.1]) by mail-mx4.corp.int (8.16.0.22/8.16.0.22) with SMTP id w9I9WmmO016384 for ; Thu, 18 Oct 2018 12:32:48 +0300 Received: from mail.worldsupport.info ([172.16.65.31]) by mail-mx4.corp.int with ESMTP id 2n35w0027n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 18 Oct 2018 12:32:46 +0300 Received: from ex-db2.corp.int (172.16.31.104) by ex-edge1.corp.int (172.16.65.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Thu, 18 Oct 2018 12:32:46 +0300 Received: from ex-db1.corp.int (172.16.31.103) by ex-db2.corp.int (172.16.31.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1034.26; Thu, 18 Oct 2018 12:32:46 +0300 Received: from ex-db1.corp.int ([fe80::c456:820:559d:b83a]) by ex-db1.corp.int ([fe80::c456:820:559d:b83a%3]) with mapi id 15.01.1034.033; Thu, 18 Oct 2018 12:32:46 +0300 From: Yordan Kostov To: users Subject: Cloudstack database and orphaned entities Thread-Topic: Cloudstack database and orphaned entities Thread-Index: AdRmwudkQgXM5m+eR4iKQ9HU/7637w== Date: Thu, 18 Oct 2018 09:32:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.28.82] Content-Type: multipart/alternative; boundary="_000_f395a749ecc0446b960000406e482a15worldsupportinfo_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-17_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=spam_outbound_notspam policy=spam_outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=761 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810180091 --_000_f395a749ecc0446b960000406e482a15worldsupportinfo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, While testing different setups and also deleting them I not= iced that it is occasional/common occurrence that orphaned system VMs or ho= sts remain in the database. For example - during removal of a zone (system VMs, seconda= ry storages, host, cluster, pod, networks and then the zone) if not execute= d in the correct order system VMs are left orphaned in the DB (no seen in t= he GUI) and thus preventing deletion of the POD. The error (quoted by memor= y) says "there are existing hosts so operation cannot proceed". Other times= the orphaned VMs lock public IPs preventing deletion of zone networks. What I did to go around the issues is go inside the DB and = tweak the cloud -> vm_instance & hosts table settings for the particular s= ystem instance to mimic the one for other already removed instances (changi= ng the status to "removed", setings modification date etc). What is the best way to approach such issue in production? Also what is the reasoning for the system VMs are both pres= ent in VM_instance table hosts tables at the same time? It feels counter in= tuitive to look for/insert VMs in the hosts table. Best regards, Jordan Kostov --_000_f395a749ecc0446b960000406e482a15worldsupportinfo_--