From owner-freebsd-xen@freebsd.org Wed Apr 12 18:07:10 2017 Return-Path: Delivered-To: freebsd-xen@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 26BA8D3B70D for ; Wed, 12 Apr 2017 18:07:10 +0000 (UTC) (envelope-from jlott@averesystems.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E017D1D4 for ; Wed, 12 Apr 2017 18:07:09 +0000 (UTC) (envelope-from jlott@averesystems.com) Received: by mail-oi0-x232.google.com with SMTP id b187so41189820oif.0 for ; Wed, 12 Apr 2017 11:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=averesystems.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nJ0KGsJT2tJw/oqhsQGl/R9DkO0JfStaSP6HKc+2MWE=; b=gPEIy1f5Z5qDl0D6Kx+KqdLfNzhP+S/AqcdWOcWEvY32IFw/gdvIhXfuILTsJf0Vj/ tCHZctY+q16ukgCMmWYAGBdNxbySeqAuyZXAGw4DrB2qV9wSGV9DvDjoyjRWTXsZPbj/ ZFyGatZlQJ5pTLWsgJJ/MybJnuzGMSpESwnhI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nJ0KGsJT2tJw/oqhsQGl/R9DkO0JfStaSP6HKc+2MWE=; b=ecQC2Lo1OTePBVjYngwtarF2N0mdDUyQjMlE1AWujjZFDhn3DSCmxlrXGNn/H9ZK3z p04B3P8mIZQ9A4hQbhckKsou6K9i6deupRKYbHMZ+l9a/XQHGyBeMd6wNvty5ik0LLeO pfT3/pHlCCM9Tl5IJE9vo33umk7Sk4kxb2/0aHyJHHxDB7b2Lcu2Sk+aAB6xduE3iDFX DC9Uo5v1Shvq5/oKvTgoq8zHi7SysHjn7YpZMFJR1b0kRKiUvrRDMYz5j4GCgM4iqUJo bdR+9zqBbdipn5udSPpjtrSZELdH4pKt0oz/SYxoeo/0qz2n74UoxHYDEPksuFQmH2Fw +u5A== X-Gm-Message-State: AN3rC/6BNc9tDLQ4RNScXbG4SP9gp9Dq5cPIhcZYhJI2ScI8pBA8PYPSxbJKOQ4v/tKgKg2vVQr2RDQ2+QZZ1j7p X-Received: by 10.157.14.248 with SMTP id 111mr7117582otj.143.1492020428092; Wed, 12 Apr 2017 11:07:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.17.168 with HTTP; Wed, 12 Apr 2017 11:07:07 -0700 (PDT) In-Reply-To: References: <0100015b6070c546-05c6cf24-36e1-487f-be5e-b2bb6efd4472-000000@email.amazonses.com> From: Jeremiah Lott Date: Wed, 12 Apr 2017 14:07:07 -0400 Message-ID: Subject: Re: amazon/xen... any way at all to pass a message/signal/semaphoere/morse-code to the boot loader? To: freebsd-cloud@freebsd.org, freebsd-xen@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 18:07:10 -0000 On Wed, Apr 12, 2017 at 1:30 AM, Leif Pedersen wrote: > I keep an extra EBS volume handy that has a simple recovery image. If I get > stuck into a trouble, I change the normal boot disk to sdb, and attach my > recovery volume as sda1. Essentially, the extra volume is my "recovery > partition". To make it cheaper, keep only a snapshot of it. > I tried for a while to get some sort of bootloader-based recovery plan in place for our cloud-based systems, like what was originally asked for. We already have a primary and a backup partition in our boot disk, but there was no way I found in EC2 to easily switch the partition to boot from. In the end, I gave up on passing information to the bootloader and used something like the above with multiple images. I actually wrote a script at one point using the aws CLI that you could run from any FreeBSD VM in the same availability zone. It detached the original boot volume from the "broken" instance; attached it as a secondary disk to the recovery image, changed the boot partition, detached it from the recovery image, then re-attached it to the original image. It took a while to run, but required little user input. We kind of kept that as "good enough" for the rare case that a instance became un-bootable and we cared to recover it rather than replace it. I'm not sure we actually ever used it on a customer system. It was used more during development when you are more likely to break stuff (and want to recover coredumps, etc. so you can fix the broken code). If you go down the route of implementing EC2 network driver(s) in the bootloader, then you could read the instance metadata via http and use a tag to control the boot behavior. However, a bootloader driver, even a very simplistic one, for xn0 (and potentially for both ixv and ena, if you support EC2 Enhanced Networking) was more work that we wanted to undertake for this. Jeremiah Lott Avere Systems