diff --git a/docs/api/testapi.html b/docs/api/testapi.html index 3282213cd4b..5b30927cbb3 100644 --- a/docs/api/testapi.html +++ b/docs/api/testapi.html @@ -2078,7 +2078,7 @@
backend_get_wait_still diff --git a/docs/current.pdf b/docs/current.pdf index b2a30980a55..c5509ee0f0d 100644 Binary files a/docs/current.pdf and b/docs/current.pdf differ diff --git a/docs/index.html b/docs/index.html index 3be9671c227..3d8260654ac 100644 --- a/docs/index.html +++ b/docs/index.html @@ -9836,8 +9836,9 @@

Multi-machine test setup

Note
-Another way to setup the environment with iptables and firewalld is described -on the Fedora wiki. +Another way to setup the environment with iptables and firewalld is +described on the +Fedora wiki. @@ -9849,9 +9850,11 @@

Multi-machine test setup

Note
-Alternatively salt-states-openqa contains -necessities to establish such a setup and configure it for all workers with the tap -worker class. They also cover GRE tunnels (that are explained in the next section). +Alternatively +salt-states-openqa contains +necessities to establish such a setup and configure it for all workers with the +tap worker class. They also cover GRE tunnels (that are explained in the next +section). @@ -10032,10 +10035,10 @@
Configure openQA workers

Verify the setup

-

Simply run a MM test scenario. For openSUSE, you can find many relevant tests -on o3, e.g. look for networking-related tests like -wicked-tests. To test GRE tunnels, you may want to change the jobs worker classes -so the different jobs are executed on different workers.

+

Simply run a MM test scenario. For openSUSE, you can find many relevant tests on +o3, e.g. look for networking-related tests like +wicked-tests. To test GRE tunnels, you may want to change the jobs worker +classes so the different jobs are executed on different workers.

So you could call openqa-clone-job like this:

@@ -10051,11 +10054,12 @@

Verify the setup

-

It will print an openqa-cli call. You can modify it to change the worker classes of -the jobs individually and then invoke it.

+

It will print an openqa-cli call. You can modify it to change the worker +classes of the jobs individually and then invoke it.

-

Also be sure to reboot the worker host to make sure the setup is actually persistent.

+

Also be sure to reboot the worker host to make sure the setup is actually +persistent.

Start test VMs manually

@@ -10063,37 +10067,44 @@

Start test VMs manually

You may also start VMs manually to verify the setup.

-

First, download a suitable image and launch a VM in the same way os-autoinst would do -for MM jobs:

+

First, download a suitable image and launch a VM in the same way os-autoinst +would do for MM jobs:

wget http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minimal-VM.x86_64-Cloud.qcow2
 qemu-system-x86_64 -m 2048 -enable-kvm -vnc :42 -snapshot \
-  -netdev tap,id=qanet0,ifname=tap39,script=no,downscript=no -device virtio-net,netdev=qanet0,mac=00:00:00:00:00:01 \
+  -netdev tap,id=qanet0,ifname=tap40,script=no,downscript=no \
+  -device virtio-net,netdev=qanet0,mac=52:54:00:13:0b:4a \
   openSUSE-Tumbleweed-Minimal-VM.x86_64-Cloud.qcow2
-

The image used here is of course just an example. Within the VM configure the network -like this (you may need to adjust concrete IP addresses, subnets and interface names):

+

The image used here is of course just an example. You need to make sure to +assign a unique MAC address (e.g. by adjusting the last two figures in the +example; this will not conflict with MAC addresses used by os-autoinst) and use +a tap device not used at the same time by a SUT-VM.

+
+
+

Within the VM configure the network like this (you may need to adjust concrete +IP addresses, subnets and interface names):

-
ip a add dev eth0 10.0.2.15/24
+
ip link set dev eth0 up mtu 1458
+ip a add dev eth0 10.0.2.15/24
 ip r add default via 10.0.2.2
-ip link set dev eth0 mtu 1458
 echo 'nameserver 8.8.8.8' > /etc/resolv.conf
-

The MTU is chosen in accordance with what the openSUSE test distribution uses for MM -tests and should be below the MTU set on the Open vSwitch bridge device (e.g. via -os-autoinst-setup-multi-machine).

+

The MTU is chosen in accordance with what the openSUSE test distribution uses +for MM tests and should be below the MTU set on the Open vSwitch bridge device +(e.g. via os-autoinst-setup-multi-machine).

-

After this it should be possible to reach other hosts. You may also launch a 2nd VM to -see whether the VMs can talk to each other.

+

After this it should be possible to reach other hosts. You may also launch a 2nd +VM to see whether the VMs can talk to each other.

@@ -10108,7 +10119,8 @@

Debugging Open vSwitch Configurat

openvswitch (as above)

  • -

    wicked - creates the bridge br1 and tap devices, adds tap devices to the bridge,

    +

    wicked - creates the bridge br1 and tap devices, adds tap devices to the +bridge,

  • firewalld (or SuSEfirewall2 in older setups)

    @@ -10221,7 +10233,8 @@

    Debugging Open vSwitch Configurat

    empty output indicates a problem with os-autoinst-openvswitch service

  • -

    zero packet count or missing rules in table=1 indicate problem with tap devices

    +

    zero packet count or missing rules in table=1 indicate problem with tap +devices

    • @@ -12449,7 +12462,7 @@

    Developing tests with container