qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
To: qemu-devel@nongnu.org
Cc: aliguori@us.ibm.com, armbru@redhat.com, lcapitulino@redhat.com,
	Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
	snaiksat@cisco.com
Subject: [Qemu-devel]  [RFC PATCH 0/2] Decouple netdev from nic
Date: Wed,  2 May 2012 18:06:40 +0200	[thread overview]
Message-ID: <1335974802-12984-1-git-send-email-vasilis.liaskovitis@profitbricks.com> (raw)

Virtualization management layers would like to decouple host network device
(netdev) creation/deletion/setup from guest network adapters.

This would allow to independently:
- provision VMs with NIC(s)
- create and manage network devices on the host

First discussed here:
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg03614.html

Explicit plug/unplug of a backend netdev device to a VM NIC at runtime would be
needed.  This patch introduces a command "netdev_set" to attach a netdev device
to a guest nic. This allows the following use cases:

1) qemu can start with detached nic and backend netdevs
E.g. at boot time nic0 and netdev are not connected:

-netdev type=tap,id=netdev0 -device virtio-net-pci,id=nic0
Warning: netdev guest0 has no peer
Warning: nic net0 has no peer

The following sequence would connect backend device netdev0 to nic nic0

(qemu) set_link nic0 off
(qemu) netdev_set nic0 netdev0
(qemu) set_link nic0 up

Setting the link up/down is done separately with the existing set_link command,
but could be added to the semantics of the new command if desired.

2) change of backend netdev at runtime. 
E.g. at boot time, nic0 is connected to netdev netdev0:

-netdev type=tap,id=netdev0 -device virtio-net-pci,netdev=netdev0,id=nic0

The following sequence would change the backend device for nic0 to netdev1:

(qemu) set_link nic0 off
(qemu) netdev_del netdevnic0
(qemu) netdev_add id=netdev1,type=tap
(qemu) netdev_set nic0 netdev1
(qemu) set_link nic0 up

(netdev_del will currently call the link_status_changed callback for the guest
 device it is attached to, so afaict the first step "set_link off" for the guest
 device is not strictly needed in this example)

- is this feature of interest upstream? If yes, what's the desired way to implement
it in qom? Is there a legitimate way to change a qdev property after a device has
been initialized? The netdev property of a guest nic is set at nic
initialization time - if we attach a new backend device, how can we update the
netdev property?

- A link property for a nic device (link=up/down) which denotes initial status of a
nic can also be implemented (not yet in this patch). This way a nic could be
initialized with disabled carrier at the command line using link=down.

thoughts, comments welcome.

series is based on 
http://repo.or.cz/w/qemu/qmp-unstable.git/qmp-wip/qapi-commands-conv/netdev-add/v2
and can be found here:
https://github.com/vliaskov/qemu-kvm/commits/netdev-decouple

Vasilis Liaskovitis (2):
  Implement netdev_set command
  virtio-net: re-initialize tap device for new netdev

 hmp-commands.hx  |   14 +++++++++++++
 hmp.c            |   10 +++++++++
 hmp.h            |    1 +
 hw/virtio-net.c  |   30 +++++++++++++++++++++++++++
 net.c            |   58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 net.h            |    1 +
 qapi-schema.json |   16 ++++++++++++++
 qmp-commands.hx  |   25 +++++++++++++++++++++++
 8 files changed, 155 insertions(+), 0 deletions(-)

-- 
1.7.9

             reply	other threads:[~2012-05-02 16:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 16:06 Vasilis Liaskovitis [this message]
2012-05-02 16:06 ` [Qemu-devel] [RFC PATCH 1/2] Implement netdev_set command Vasilis Liaskovitis
2012-05-02 16:06 ` [Qemu-devel] [RFC PATCH 2/2] virtio-net: re-initialize tap device for new netdev Vasilis Liaskovitis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1335974802-12984-1-git-send-email-vasilis.liaskovitis@profitbricks.com \
    --to=vasilis.liaskovitis@profitbricks.com \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=snaiksat@cisco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).