[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] RFC decoupling VM NIC provisioning from VM NIC connection to backend networks



Hi,

In its current implementation Libvirt makes sure that the network
interfaces that it passes/provision to a VM (for example to qemu[-kvm])
are already connected to its backend (interfaces/networks) by the time
the VM starts its boot process. In a non virtualized setup it would be
like booting a machine with the Ethernet cable already plugged into a
router/switch port. While in a non virtualized setup you can boot a
machine first (with no physical connection to a router/switch) and later
connect its NIC/s to the switch/router, when you boot a VM via Libvirt
it is not possible to decouple the two actions (VM boot, cable
plug/unplug).

An example of case where the capability of decoupling the two actions
mentioned above is a requirement in Quantum/NetStack which is the
network service leveraged by OpenStack. The modular design of OpenStack
allows you to:
- provision VMs with NIC/s
- create networks
- create ports on networks
- plug/unplug a VM NIC into/from a given port on a network (at runtime)

Note that this runtime plug/unplug requirement has nothing to do with
hot plug/unplug of NICs.
The idea is more that of decoupling the provisioning of a VM from the
connection of the VM to the network/s.
This would make it possible to change (at run-time too) the networks the
NIC/s of a given VM are connected to.

For example, when a VM boots, its interfaces should be in link down
state if the network admin has not connected the VM NIC/s to any
"network" yet.
Even though libvirt already provides a way to change the link state of
an a VM NIC, link state and physical connection are two different things
and should be manageable independently.

Ideally the configuration syntax should be interface type and hypervisor
type agnostic.

Let's take QEMU[-kvm] as an example - when Libvirt starts a QEMU VM, it
passes to QEMU a number of file descriptors that map to host backend
interfaces (for example macvtap interfaces).

In order to introduce this runtime plug/unplug capability, we need a
mechanism that permits to delay the binding between the host macvtap
interfaces and the guest taps (because you cannot know the fd of the
macvtap interfaces before you create them). This means you need a
mechanism that allows you to change such fd/s at runtime:

- you can close/reset an fd (ie, when you disconnect a VM NIC from its
network)
- you can open/set an fd (ie, when you connect a VM NIC to a network)

This could probably be a libvirt command that translates to a QEMU
monitor command.

Can the runtime plug/unplug capability described above be achieved
(cleanly) with another mechanism?

Is anybody working on implementing something similar?

[For more information on OpenStack/NetStack/Quantum and the above
requirements please refer to the network model used therein:

http://docs.openstack.org/incubation/openstack-network/admin/content/Wha
tIsQuantum.html (information on network, port, and attachment
abstractions)

http://www.slideshare.net/danwent/quantum-diablo-summary (slides 7 & 8)]

Thanks,
~Sumit Naiksatam.
(On behalf of OpenStack/Quantum team)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]