Bug 506527 - Expectations for kvm networking in RHEL 5.4
Summary: Expectations for kvm networking in RHEL 5.4
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: doc-Virtualization_Guide
Version: 5.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Christopher Curran
QA Contact: Lawrence Lim
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-06-17 16:08 UTC by Gurhan Ozen
Modified: 2014-03-26 00:58 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-09 04:15:15 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gurhan Ozen 2009-06-17 16:08:29 UTC
Description of problem:
This bug is a spin-off from #504839 . 

"For xen verses kvm are the network bridging are setup
differently while Xen will bridge all the guests to the network the host is
running on, and forward all traffic, including DHCP, DNS, etc. to the outside
network kvm defaults to a private network on the host for guests that gets
NAT'd to the outside network."

What are the expectations here? Are we going to ship default kvm networking as it is , or should we have something like xen's networking? If we decide to ship it as it is , are there any suggested methods to set up kvm guests' networking? 

We would like to know this so we can test and automate testing of kvm guests in the way we'll ship and/or in the way setup preferred. 


Version-Release number of selected component (if applicable):
5.4 kvm

Comment 1 Eduardo Habkost 2009-06-17 16:20:40 UTC
I don't see what made you conclude the defaults are different. The network configuration options depend on the way you tell libvirt to set up the guest networking.

I am not familiar with the libvirt network setup code, but I expect both modes (bridge and NAT) to work  both hypervisors (KVM and Xen), you just need to give libvirt the corresponding configuration to the mode you want.

Comment 2 Gurhan Ozen 2009-06-17 20:31:16 UTC
I guess we didn't articulate this correctly. 

Basically in xen, the default network configuration is such that when a guest is started, the xen network scripts create a virtual interface for the guest and using the bridged networking, all network is forwarded so that the guest has a hostname etc. Whereas with kvm, the default is to create a local private network and nothing is bridged over to the guest so it has no dns etc.

Is this how we're intending to ship whereas users installing/running guest will have to do more configuration to make their guests available online, or are we intending to ship it  the way we xen is shipped as far as networking is concerned. 

Did this clear things up?

Comment 3 Eduardo Habkost 2009-06-17 20:46:33 UTC
There is no default network configuration as you described on KVM, unless you run qemu-kvm directly. But running qemu-kvm directly isn't recommended and won't be supported (see bug #503955).

You should use libvirt, and libvirt doesn't have a default networking configuration (as far as I know). But it is better to clarify this with the libvirt folks.

Comment 4 Martin Jenner 2009-06-18 15:31:31 UTC
I think the real symptom this bz is trying to address is how does a RHEL 5.4 system installed and started with the KVM hypervisor get similar public pass-through networking running akin to the way a sytem booted with the Xen Hypervisor does by default (not talking implementation here I am taking functionality).

I understand there are many possibe networkng options through libvirt but as far as I understand it the default networking option we provide out the box when booting the Xen hypervisor in RHEL is the one most of our customers use and probably what they expect when using kvm.

I guess the question are;

- what is the optimal procedure to set the Xen style of bridging (term used loosly) with libvirt for RHEL5.4 with kvm ?

- can we setup RHEL 5.4 to setup this style of network bridging to be the default ?

Comment 6 Daniel Berrangé 2009-06-18 17:35:18 UTC
This page describes the 2 recommended setups with libvirt, and is applicable to both Xen and KVM (though users can optionally continue with xen's network-bridge if desired):

  http://wiki.libvirt.org/page/Networking

Comment 7 Eduardo Habkost 2009-06-19 21:30:46 UTC
This is a libvirt question, not a KVM question. Both modes are supported by KVM, and if there are anything that can be called "default settings", they are upper in the stack.

Comment 13 Daniel Veillard 2009-07-08 11:34:48 UTC
This really has not been worked upstream, and there isn't a clear resolution
for this. In any case this can't make Update 4 at this point so updating the
flags accordingly,

Daniel

Comment 17 Christopher Curran 2009-07-22 06:14:16 UTC
I've incorporated the content from libvirt.org with a bit of paraphrasing.

http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/chap-Virtualization-Network_Configuration.html

It still needs a better edit which it shall receive after QE tests it against RHEL 5.4. In my view though, this chapter is a big improvement on the previous bridging information.

Terms in the config files need more description. If time permits I would like to describe each individual variable and what it actually does.

I also intend to get the network architecture diagrams beautified for the end release. That should enhance understanding of how libvirt, kvm, xen and the network mesh together. (https://bugzilla.redhat.com/show_bug.cgi?id=512655)

Chris

Comment 18 Christopher Curran 2009-08-06 06:54:55 UTC
Marking this Modified. The libvirt section covers networking in RHEL5.4. The Xen stuff has been kept for 5.0-1 but marked as legacy.

Comment 22 Christopher Curran 2009-09-16 23:42:42 UTC
Has this bug been tested by QE yet?

Please test the two procedures in this chapter:
http://documentation-stage.bne.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/chap-Virtualization-Network_Configuration.html

Comment 23 Andrew Ross 2009-10-09 01:29:00 UTC
Ran through the procedures as part of Documentation review. No problems.


Note You need to log in before you can comment on or make changes to this bug.