From owner-freebsd-virtualization@freebsd.org Wed Feb 8 16:59:07 2017 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B374CD6AA2; Wed, 8 Feb 2017 16:59:07 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.dweimer.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E33931FD9; Wed, 8 Feb 2017 16:59:04 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from www.dweimer.net (opnsense.dweimer.local [10.9.5.1]) (authenticated bits=0) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTPSA id v18Gx1Ki004364 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Feb 2017 10:59:02 -0600 (CST) (envelope-from dweimer@dweimer.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dweimer.net; s=2017.01.31; t=1486573142; bh=k83mNDH1gCOsZinWl+TJDerw4EEkEL+Z5jQMg3TlTRM=; h=Date:From:To:Cc:Subject:Reply-To:In-Reply-To:References; b=w1FHk3mPC3oIqWsHM+Z/jZ+EHI8em89+Tj1Ft+GrMEjMXro1+ndkXk/P9HO8EQIyk Yt1pQauvIbI1Fu7d5RFIjoaljK/Qr/NXjjbKXtElCJ02XkwEauYNT0FlNElVVpqPBa KFujshIDIZvhP2z7EPsscEGWczQzmRfY9gf32INEWoMd20Lc1iL0pJnLDJAJSGAHyX apuDUVnKxvC6G+mBMrCFds7sYwKuRblhjJNGuDn68aYz1LS6ovfGH8LlsbMgbWhBom pu2+HSy1l0HmOOMHxNIq1iu7opNOjpUAt6SfVjyPTguLmtVcu4Nc/XEUTm4SC4r7Ry xgqVKBQddhMRA== MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 08 Feb 2017 10:58:56 -0600 From: "Dean E. Weimer" To: Allan Jude Cc: freebsd-virtualization@freebsd.org, owner-freebsd-virtualization@freebsd.org Subject: Re: Resizing ZVOL used for bhyve VM. Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <495d71a8-b4e0-fe9a-401f-a2ef607fbd3d@freebsd.org> References: <495d71a8-b4e0-fe9a-401f-a2ef607fbd3d@freebsd.org> Message-ID: <6377c5cd376f0111e0e8e186c4ef4a41@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.3-beta X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:59:07 -0000 On 2017-02-08 9:24 am, Allan Jude wrote: > On 2017-02-08 00:23, Dean E. Weimer wrote: >> I am trying to resize a secondary data disk on a Debian Linux Virtual >> machine. The data really isn't all that important, its video from IP >> security cameras. Since nothing has happened that needs reviewed I >> could >> scrap it and start over. However I can't even do that. >> >> I tried just setting the volsize to a larger value while the vm is >> shutdown. zfs excepts the command, I boot up the VM but it is not >> recognizing the volume properly I can see that its grown, but it >> errors >> trying to update the GPT partition table with the new size. I gave up >> shutdown VM and tried to delete the zvol so I could create a new one. >> However it believes the zvol is in use and wont let me destroy it. So >> something funky seems to be going on. oddly enough I set the zvol back >> to the original size boot up the vm, all the data is intact and >> functioning just fine. So somehow I can't break it despite doing all >> kinds of things that could have and probably should have destroyed the >> data. >> >> I am going to guess the only thing I have left to try is disable vms >> on >> startup and reboot to see if I can then destroy the zvol and create a >> new larger one. But I was hoping someone else might have another >> suggestion to correctly increase the volume size. >> > > Make sure you actually destroy the bhyve vm, not just shut it down. > > You may also be having issues where GEOM on the host has locked the > device when it saw the disk resize. You likely want to have the zfs > property 'volmode' set to 'dev', instead of the default 'geom', to > prevent this when using bhyve. > > I'd recommend, with the bhyve 'destroyed' (the instance, not your > data), > gpart recover zvol/path/name > > To rewrite the backup copy of the GPT table at the new end of the > drive. > > Then try booting the VM again. I was missing the volmode setting as dev. I had it on the virtual machine's system disk zvol but not its secondary data disk. I went ahead and decided to delete the disk and recreate it after all the messing around just in case I had corrupted something. I did verify though that with this setting I was able to shutdown the VM and then delete the new disk and recreate it. So it definately was the dev volmode setting not being there that was causing the lock, and likely causing the resize to fail. -- Thanks, Dean E. Weimer http://www.dweimer.net/