From users-return-33870-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Fri Jan 10 16:45:54 2020 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 [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 62871180657 for ; Fri, 10 Jan 2020 17:45:54 +0100 (CET) Received: (qmail 96398 invoked by uid 500); 10 Jan 2020 16:45:50 -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 96150 invoked by uid 99); 10 Jan 2020 16:45:49 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Jan 2020 16:45:49 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 548051813C9 for ; Fri, 10 Jan 2020 16:45:42 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id t8xmZEuVxAgS for ; Fri, 10 Jan 2020 16:45:41 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.208.65; helo=mail-ed1-f65.google.com; envelope-from=andrija.panic@gmail.com; receiver= Received: from mail-ed1-f65.google.com (mail-ed1-f65.google.com [209.85.208.65]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 96608BC574 for ; Fri, 10 Jan 2020 16:45:40 +0000 (UTC) Received: by mail-ed1-f65.google.com with SMTP id bx28so2122638edb.11 for ; Fri, 10 Jan 2020 08:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JsFof8gXajqSgs8TUTTqEU9Q9YQo8AvRZTZF1afktts=; b=QgMT49BT4QedXs+nmYmeio+ZDQ8MwfYRWYc46wTK1avjsppJAeWSG5JUFJBBuqjBK/ Ps8flmos6AIwvBKXKwx/V3ucFDHChhI5Ry844R92faU7l1Iygc/eSOH1N8gjlfyeYXgS cKpiCiF1G7vwPMpYNa7S3rGSuhWqEAX7Ei+NZhyVqxrTYpVuUshhHQjuz0eesc6Cp/EH qDm9VIQJDqodqXKdr83O517LTeMiq26LdTr0tp+6xubTPmVkJ9Suuplv46Mmz0hNhwSf 3s4Q0ZH3Ccyw7510A9zloPm1hxyX1Quooiy+Jlxk7nw6zp2VNz3PDBu6cn27hwNSszFP iXPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JsFof8gXajqSgs8TUTTqEU9Q9YQo8AvRZTZF1afktts=; b=RLyDy8Std37okcpQgEoucra4lUqs7G17xKms9bkcKGJKPwgoNqSw/vYHhknqIbQZoc RJhfnd+tgnM2U6rLJYtfq915fXf25hev5d1Xfvyc6svIrRCmzXUxupdBxwz4MC81A6HV afhQmxj39cevyQps9aoMfXTssAhIaR7X0UJYOj32fLTn0RXyvbA9p9dto41v7v/pS+Ab oGc8mQFoswYj9vRbTwPsFScMALS37ExWzn6cPgJILIPzI3jtyZICgW7WlZuNdxoem762 yNcnlJ6hKWdIbnlCERWxbPLIYvZRgUHhUxuo0H5uHsdZwX9Nt5+VGu1759g7VaVKD/Yi dHGA== X-Gm-Message-State: APjAAAUU1pHoZhhKT7E3JVc+CGcpY7XfoTCKeD2rZ2DX4sbPIJUIg2se VQ3QjUP4MzPjI9ZVqedjrK53zqHzFjsWJdaancCd0Fxn X-Google-Smtp-Source: APXvYqxVoMH3aAIMxt/rS+mu+e3J1xHeEsp3NLCn9b0Q3hI3U8b0ZPBoRuRbmbSZlF4bG/YLcGcmlRZMnSTMNywmUGc= X-Received: by 2002:a05:6402:1771:: with SMTP id da17mr4592351edb.68.1578674739626; Fri, 10 Jan 2020 08:45:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrija Panic Date: Fri, 10 Jan 2020 17:45:21 +0100 Message-ID: Subject: Re: new primary storage To: users Content-Type: multipart/alternative; boundary="0000000000001245c9059bcbdbf8" --0000000000001245c9059bcbdbf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are some known issues in (4.13?) where KVM host is asked to report statistics for other hypervisors storage pools, and that can cause silly errors in the log - I would ignore those for now. Better spin a **new** VM on that new storage pool (not migrate over existing VM) and give it some time and see if your original problem (stats missing) is fixed. best On Fri, 10 Jan 2020 at 17:24, Charlie Holeowsky wrote: > Hi all, > I keep getting the following error about a volume that has been migrated: > > 2020-01-10 11:21:28,701 DEBUG [c.c.a.t.Request] > (AgentManager-Handler-2:null) (logid:) Seq 15-6725563093524421010: > Processing: { Ans: , MgmtId: 220777304233416, via: 15, Ver: v1, Flags: 1= 0, > > [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils= .exception.CloudRuntimeException: > Can't find volume:d93d3c0a-3859-4473-951d-9b5c5912c767\n\tat > > com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(Libvi= rtStoragePool.java:149)\n\tat > > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtGetVolumeStatsCommandWra= pper.getVolumeStat(LibvirtGetVolumeStatsCommandWrapper.java:63)\n\tat > > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtGetVolumeStatsCommandWra= pper.execute(LibvirtGetVolumeStatsCommandWrapper.java:52)\n\tat > > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtGetVolumeStatsCommandWra= pper.execute(LibvirtGetVolumeStatsCommandWrapper.java:40)\n\tat > > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtRequestWrapper.execute(L= ibvirtRequestWrapper.java:78)\n\tat > > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest= (LibvirtComputingResource.java:1450)\n\tat > com.cloud.agent.Agent.processRequest(Agent.java:645)\n\tat > com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:1083)\n\tat > com.cloud.utils.nio.Task.call(Task.java:83)\n\tat > com.cloud.utils.nio.Task.call(Task.java:29)\n\tat > java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java= :1149)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav= a:624)\n\tat > java.lang.Thread.run(Thread.java:748)\n","wait":0}}] } > 2020-01-10 11:21:28,701 DEBUG [c.c.a.m.AgentManagerImpl] > (StatsCollector-1:ctx-9766c817) (logid:5715358a) Details from executing > class com.cloud.agent.api.GetVolumeStatsCommand: > com.cloud.utils.exception.CloudRuntimeException: Can't find > volume:d93d3c0a-3859-4473-951d-9b5c5912c767 > > what could happen if I create a symbolic link between the file currently = in > use (the actual path of volume in use) and what cloudstack is looking for > (the d93d3c0a-3859-4473-951d-9b5c5912c767, the uuid of volume in use) so > that it can collect the data of the file? > > Il giorno mar 7 gen 2020 alle ore 17:57 Charlie Holeowsky < > charlie.holeowsky@gmail.com> ha scritto: > > > Hi all, > > on a host that use this new storage I found a problem that could be > > related to the fact that the statistics are not being updated. > > > > After migrating a newly created VM to the new storage server, a series = of > > messages like the following appear in the agent logs: > > > > 2020-01-07 17:30:45,868 WARN [cloud.agent.Agent] > > (agentRequest-Handler-2:null) (logid:c023b7f8) Caught: > > com.cloud.utils.exception.CloudRuntimeException: Can't find > > volume:d93d3c0a-3859-4473-951d-9b5c5912c767 > > at > > > com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(Libvi= rtStoragePool.java:149) > > at > > > com.cloud.hypervisor.kvm.resource.wrapper.LibvirtGetVolumeStatsCommandWra= pper.getVolumeStat(LibvirtGetVolumeStatsCommandWrapper.java:63) > > > > Looking for the volume uuid "d93d3c0a-3859-4473-951d-9b5c5912c767" I > found > > that it belongs to the VM just migrated but has a different "path" colu= mn > > value (normally I see that the values of the two tables coincide). > > > > On the other hand, there is another record in the volumes table with uu= id > > =3D NULL and path =3D d93d3c0a-3859-4473-951d-9b5c5912c767 with > state=3DExpunged. > > > > Could this be the cause of the failure to update the volume data > > statistics? > > > > Il giorno mar 17 dic 2019 alle ore 15:32 charlie Holeowsky < > > charlie.holeowsky@gmail.com> ha scritto: > > > >> Hi, > >> any idea about about this problem? > >> > >> > >> Il giorno mar 10 dic 2019 alle ore 17:23 charlie Holeowsky < > >> charlie.holeowsky@gmail.com> ha scritto: > >> > >>> Hi users, > >>> I recently added a new primary nfs storage to my cluster (cloudstack > >>> 4.11.2 with kvm on the Ubuntu system). > >>> > >>> It works well but on the metrics of the VM storage volume the "physic= al > >>> size" and "usage" columns are empty while in the rows of the VM of th= e > >>> other primary storage I can see the right data. > >>> > >>> Where can i go to look to see where the problem is? > >>> > >>> Thanks > >>> Charlie > >>> > >> > --=20 Andrija Pani=C4=87 --0000000000001245c9059bcbdbf8--