Re: [gentoo-user] installing Gentoo in a xen VM

[lee]

thegeezer <thegeezer@×××××××××.net> writes:

> On 08/12/14 22:17, lee wrote:
>> "J. Roeleveld" <joost@××××××××.org> writes:
>>
>>> create 1 bridge per physical network port
>>> add the physical ports to the respective bridges
>> That tends to make the ports disappear, i. e. become unusable, because
>> the bridge swallows them.
> and if you pass the device then it becomes unusable to the host

The VM uses it instead, which is what I wanted :)

>>> pass virtual NICs to the VMs which are part of the bridges.
>> Doesn't that create more CPU load than passing the port?  And at some
>> point, you may saturate the bandwidth of the port.
>
> some forward planning is needed. obviously if you have two file servers
> using the same bridge and that bridge only has one physical port and the
> SAN is not part of the host then you might run into trouble. however,
> you can use bonding in various ways to group connections -- and in this
> way you can have a virtual nic that actually has 2x 1GB bonded devices,
> or if you choose to upgrade at a later stage you can start putting in
> 10GbE cards and the virtual machine sees nothing different, just access
> is faster.
> on the flip side you can have four or more relatively low bandwidth
> requirement virtual machines running on the same host through the same
> single physical port
> think of the bridge as an "internal, virtual, network switch"... you
> wouldn't load up a switch with 47 high bandwidth requirement servers and
> then create a single uplink to the SAN / other network without seriously
> considering bonding or partitioning in some way to reduce the 47into1
> bottleneck, and the same is true of the virtual-switch (bridge)
>
> the difference is that you need to physically be there to repatch
> connections or to add a new switch when you run out of ports. these
> limitations are largely overcome.

That all makes sense; my situation is different, though.  I plugged a
dual port card into the server and wanted to use one of the ports for
another internet connection and the other one for a separate network,
with firewalling and routing in between.  You can't keep the traffic
separate when it all goes over the same bridge, can you?

And the file server could get it's own physical port --- not because
it's really needed but because it's possible.  I could plug in another
dual-port card for that and experiment with bonding.

However, I've changed plans and intend to use a workstation as a hybrid
system to reduce power consumption and noise, and such a setup has other
advantages, too.  I'll put Gentoo on it and probably use containers for
the VMs.  Then I can still use the server for experiments and/or run
distcc on it when I want to.

>> The only issue I have with passing the port is that the kernel module
>> must not be loaded from the initrd image.  So I don't see how fighting
>> with the bridges would make things easier.
>>
>>
>
> vif=[ 'mac=de:ad:be:ef:00:01,bridge=br0' ]
>
> am i missing where the fight is ?

setting up the bridges

no documentation about in which order a VM will see the devices

a handful of bridges and VMs

a firewall/router VM with it's passed-through port for pppoe and three
bridges

the xen documentation being an awful mess

an awful lot of complexity required


Guess what, I still haven't found out how to actually back up and
restore a VM residing in an LVM volume.  I find it annoying that LVM
doesn't have any way of actually copying a LV.  It could be so easy if
you could just do something like 'lvcopy lv_source
other_host:/backups/lv_source_backup' and 'lvrestore
other_host:/backups/lv_source_backup vg_target/lv_source' --- or store
the copy of the LV in a local file somewhere.

Just why can't you?  ZFS apparently can do such things --- yet what's
the difference in performance of ZFS compared to hardware raid?
Software raid with MD makes for quite a slowdown.

> the only issue with bridges is that if eth0 is in the bridge, if you try
> to use eth0 directly with for example an IP address things go a bit
> weird, so you have to use br0 instead
> so don't do that.

Yes, it's very confusing.

> perhaps you don't need a full bridge and you might just prefer to lookup
> macvlan instead.
> this lets you create a new virtual device that behaves much more like a
> secondary nic
> e.g. in /etc/conf.d/net
>
> macvlan_xenguest1="eth0"
> mode_xenguest1="private"
> mac_xenguest1="de:ad:be:ef:00:01"
> config_xenguest1="192.168.1.12/24"
> routes_xenguest1="default via 192.168.1.1"
> modules_xenguest1="!ifplugd"
>
> you can then
> /etc/init.d/net.xenguest1 start
>
> i'm not big into xen but i believe you should be able to pass this as a
> "physical" device to xen and it then comes out on network interface eth0
> this way you get to keep your port without it being eaten by the bridge
> do let me know if this works with xen i'll add it to my toolbox

Hmm, and where's the other end of it?  Some physical port?  So it's like
plugging in several virtual cables into the same physical port, with a
built-in firewall and router?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.