On 29/01/13 08:04, Dustin C. Hatch wrote: > On 1/28/2013 17:52, Michael Mol wrote: >> On Mon, Jan 28, 2013 at 5:35 PM, Randy Barlow >> <ra...@electronsweatshop.com> wrote: >>> On 01/20/2013 12:37 AM, William Kenworthy wrote: >>>> So what is usually recommended and works for this scenario? >>> >>> I personally use a bridged interface that allows my VMs to be on the >>> "physical" network. That works out pretty well. In my use case, it's >>> the same subnet as the host, but it should be possible to use VLANs to >>> accomplish having them on a separate subnet. > I've got a Gentoo-based libvirt/qemu-kvm host running with several > VMs, also using bridged TAP adapters. It works really well for > servers/other "always on" systems that run in the background. > virt-manager can handle everything for you, you just have to know the > name of the bridge to which you want to the VM to join. >> >> There's no requirement that they be on separate layer 2 segments if >> you want them to be on separate layer 3 subnets. >> >> Either statically configure the IPs, or: >> >> For IPv4: Have DHCP grant IPs from different pools based on source MAC >> or declared hostname. >> >> For IPv6: Use DHCPv6 rather than SLAAC, and follow the same principles >> as for DHCP-for-IPv4. >> >> Sure, giving them separate layer 2 segments helps encapsulation (and >> may make things easier from an autoconfiguration standpoint, >> depending), but it's not strictly necessary from a technology point of >> view. >> > While that's all true, I personally think 802.1Q VLANs are *much* > easier to configure than DHCP and especially DHCPv6. Definitely > sysadmin's prerogative, though. >> -- >> :wq >> > :x > I went with openvswitch and a tap on the host so I could route into the rest of the network. The vmś will have to use fixed IP addresses (servers one of which will be dns/dhcp for the clients) I will be using vlans eventually, but need a managed switch with more ports which is in the ¨plan¨
BillK
