From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 325E9C43381 for ; Tue, 19 Mar 2019 21:20:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C5E920850 for ; Tue, 19 Mar 2019 21:20:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726832AbfCSVUE (ORCPT ); Tue, 19 Mar 2019 17:20:04 -0400 Received: from mail-qt1-f195.google.com ([209.85.160.195]:41611 "EHLO mail-qt1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726712AbfCSVUD (ORCPT ); Tue, 19 Mar 2019 17:20:03 -0400 Received: by mail-qt1-f195.google.com with SMTP id w30so114973qta.8 for ; Tue, 19 Mar 2019 14:20:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=axpqAe1Iux1pSMbf38wPJDg7BCVtdjgNY0L5AwysMJc=; b=UIA3beSB+BIOpf8sK+y6wH6T6YwU1DTE6C/ufrJU2BvSwcEQCt3zdSy1vRHMh1qM91 CwDI0aTwVS/sPsJDaPogkNEmU8nJ/yNgIgL6s35yWpDdHbi6fxyMPC2rgR1Ow2j9F1V8 uOVZsHL9+ouUpTrD5ymiJrJXFz3bJghUcAsD0heu76MBF2rw5qlJ9lNdBe41sbacLUKH xNYMllWI5oA0Olq9YpFw8t5g+p2ZGAVrHJvm519lC6xQ6CG5vNRWcdwSxtCA7mBeXSNw ZLtqg4H+lJPUgQ5A+/rUe2v7GskcSk1X8+sjOPmocEq0JhTNMqblKVF7wXt8XVO1emMy xg7g== X-Gm-Message-State: APjAAAWDY2/XyxOb1/7qiVhIxSgAQ+Rw1kp9lwfhTDUkhmztwZhR9O+X U/5ZRhJFF2Cm34C/V8xRQiTsmw== X-Google-Smtp-Source: APXvYqyuN7o2S8/y0XCp/rlYynlws5sGgOqrdOo77afaXzrvW8f+kpEdUgQImJc4xYs3zxOJy3DDwQ== X-Received: by 2002:ac8:140b:: with SMTP id k11mr3901850qtj.48.1553030402927; Tue, 19 Mar 2019 14:20:02 -0700 (PDT) Received: from redhat.com ([195.39.71.253]) by smtp.gmail.com with ESMTPSA id h186sm110457qkd.15.2019.03.19.14.19.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Mar 2019 14:20:01 -0700 (PDT) Date: Tue, 19 Mar 2019 17:19:55 -0400 From: "Michael S. Tsirkin" To: Stephen Hemminger Cc: Liran Alon , Si-Wei Liu , Sridhar Samudrala , Alexander Duyck , Jakub Kicinski , Jiri Pirko , David Miller , Netdev , virtualization@lists.linux-foundation.org, boris.ostrovsky@oracle.com, vijay.balakrishna@oracle.com, jfreimann@redhat.com, ogerlitz@mellanox.com, vuhuong@mellanox.com Subject: Re: [summary] virtio network device failover writeup Message-ID: <20190319171638-mutt-send-email-mst@kernel.org> References: <20190317095052-mutt-send-email-mst@kernel.org> <54E7C3AF-C3C5-4AF2-86C9-AA50389F855F@oracle.com> <20190319084647.727f8dcf@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190319084647.727f8dcf@shemminger-XPS-13-9360> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Mar 19, 2019 at 08:46:47AM -0700, Stephen Hemminger wrote: > On Tue, 19 Mar 2019 14:38:06 +0200 > Liran Alon wrote: > > > b.3) cloud-init: If configured to perform network-configuration, it attempts to configure all available netdevs. It should avoid however doing so on net-failover slaves. > > (Microsoft has handled this by adding a mechanism in cloud-init to blacklist a netdev from being configured in case it is owned by a specific PCI driver. Specifically, they blacklist Mellanox VF driver. However, this technique doesn’t work for the net-failover mechanism because both the net-failover netdev and the virtio-net netdev are owned by the virtio-net PCI driver). > > Cloud-init should really just ignore all devices that have a master device. > That would have been more general, and safer for other use cases. Given lots of userspace doesn't do this, I wonder whether it would be safer to just somehow pretend to userspace that the slave links are down? And add a special attribute for the actual link state. -- MST