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
next 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).