Mailing List Archive

Have you check that the interface is up on guest1?

What I mean is have you configured the interface inside of guest1?
ifconfig/ip

On Thu, Mar 3, 2022, 5:32 AM Andrea Stevanato <
Andrea.Stevanato@santannapisa.it> wrote:

> Hi all,
> I'm trying to configure two guests that can communicate with each other
> using a "virtual" network card exploiting the netback and netfront driver.
>
> The first guest is created with the following configuration:
>
> name = "guest0"
> kernel = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory = 1024
> vcpus = 2
>
> Once it is up and running, I create and setup the bridge:
>
> # brctl addbr xenbr0
> # ip addr add 10.0.3.1/24 dev xenbr0
> # ip link set dev xenbr0 up
>
> Then I configure the udhcpd server with the following configuration
> (/etc/udhcpd.conf):
>
> start 10.0.3.15
> end 10.0.3.254
> interface xenbr0
> option subnet 255.255.255.0
>
> And start it with: `# udhcpd`?.
>
> The second guest is created with the following configuration:
>
> name = "guest1"
> kernel = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory = 1024
> vcpus = 2
> vif = [ 'bridge=xenbr0, backend=guest0' ]
>
> Once it is up and running on the guest0 the new interface (vifX.0) is
> created correctly, however on the guest1 the eth0 interface is not present.
>
> If I do the exact same thing on dom0, instead of guest0 (without attaching
> the eth0 to the bridge, since I do not need to reach outside), the eth0 on
> the guest is created correctly and get the 10.0.3.15 IP address.
>
> What I'm doing wrong?
>
> Andrea
>

Hi Andrea,

Can you access the network from the driver domain? I guess not because I see you are not using a PCI passthrough network device in the driver domain. You are not even using a virtual network in the driver domain. Therefore, even if you can connect the guest domain (guest1) with the diver domain, you will not have access to the network to talk to the outside world.

I was able to make the driver domain work using the Ethernet PCI passthrough. Detail on PCI passthrough can be found in the following link.

https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough

I was not able to make the driver domain work having the virtual network in the driver domain (guest0). It creates a nested paravirtualized network, which is a little complicated. But, there should be some way to make it work.

On top of that, to make a domain work as driver domain, you need to run the following command to launch the driver domain daemon (guest0) before you launch the guest domain (guest1).

#xl devd

If you do not have access to this daemon, we need to install it first in the driver domain (guest0). One way to install this is to install Xen hypervisor on the driver domain, but skip booting the Xen by selecting other option, say Ubuntu, from the boot menu.

I hope this helps.

Bests,
Mehrab
 




On Thursday, March 3, 2022, 07:30:05 AM EST, WebDawg <webdawg@gmail.com> wrote:





Have you check that the interface is up on guest1?

What I mean is have you configured the interface inside of guest1? ifconfig/ip

On Thu, Mar 3, 2022, 5:32 AM Andrea Stevanato <Andrea.Stevanato@santannapisa.it> wrote:
>  
>  
>  
>  
> Hi all,
> I'm trying to configure two guests that can communicate with each other using a "virtual" network card exploiting the netback and netfront driver.
>
> The first guest is created with the following configuration:
>
> name    = "guest0"
> kernel  = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory  = 1024
> vcpus   = 2
>
> Once it is up and running, I create and setup the bridge:
>
> # brctl addbr xenbr0
> # ip addr add 10.0.3.1/24 dev xenbr0
> # ip link set dev xenbr0 up
>
> Then I configure the udhcpd server with the following configuration (/etc/udhcpd.conf):
>
> start 10.0.3.15
> end 10.0.3.254
> interface xenbr0
> option subnet 255.255.255.0
>
> And start it with: `# udhcpd`?.
>
> The second guest is created with the following configuration:
>
> name    = "guest1"
> kernel  = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory  = 1024
> vcpus   = 2
> vif = [ 'bridge=xenbr0, backend=guest0' ]
>
> Once it is up and running on the guest0 the new interface (vifX.0) is created correctly, however on the guest1 the eth0 interface is not present.
>
> If I do the exact same thing on dom0, instead of guest0 (without attaching the eth0 to the bridge, since I do not need to reach outside), the eth0 on the guest is created correctly and get the 10.0.3.15 IP address.
>
> What I'm doing wrong?
>
> Andrea
>
>
>

Am 03.03.22 um 11:32 schrieb Andrea Stevanato:
> Hi all,
> I'm trying to configure two guests that can communicate with
> each other using a "virtual" network card exploiting the netback and
> netfront driver.
>
> The first guest is created with the following configuration:
>
> name    = "guest0"
> kernel  = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory  = 1024
> vcpus   = 2
>
> Once it is up and running, I create and setup the bridge:
>
> # brctl addbr xenbr0
> # ip addr add 10.0.3.1/24 dev xenbr0
> # ip link set dev xenbr0 up
>
> Then I configure the udhcpd server with the following configuration
> (/etc/udhcpd.conf):
>
> start 10.0.3.15
> end 10.0.3.254
> interface xenbr0
> option subnet 255.255.255.0
>
> And start it with: `# udhcpd`?.
>
> The second guest is created with the following configuration:
>
> name    = "guest1"
> kernel  = "/media/sd-mmcblk0p1/Image"
> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
> memory  = 1024
> vcpus   = 2
> vif = [ 'bridge=xenbr0, backend=guest0' ]
>
> Once it is up and running on the guest0 the new interface (vifX.0) is
> created correctly, however on the guest1 the eth0 interface is not
> present.
>
> If I do the exact same thing on dom0, instead of guest0 (without
> attaching the eth0 to the bridge, since I do not need to reach
> outside), the eth0 on the guest is created correctly and get the
> 10.0.3.15 IP address.
>
> What I'm doing wrong?
>
> Andrea

Hi Andrea,

I think this might be related to problems with the VIF hotplugging on
"guest0".

Since the vifX.0 on guest0 is successfully created, some of the
hotplugging at least works, but maybe a failure to setup it correctly
leads to the problem in "guest1".


A few questions for further investigation:

Is the vifX.0 device up and having "master xenbr0" (see ip link show)?
If not, there is definitely a problem with the bridge hotplugging.

Which daemon handles the vif hotplugging? xl devd? is /etc/xen/xl.conf
configured correctly (usually having vif.default.script="vif-bridge" and
run_hotplug_scripts=1)?

Do the hotplugging scripts exist, esp. /etc/xen/scripts/vif-bridge ? Can
you see any log messages from this script in /var/log/xen/xen-hotplug.log?


Usually I would expect one of these to have a notable error causing the
script to not be called or not run properly.
Otherwise, some more log output from guest0 would be helpful, dmesg, log
messages about the hotplugging, ...

Best Regards
Felix

Hi,

On 03/03/2022 19:18, tosher 1 wrote:
> Hi Andrea,
>
> Can you access the network from the driver domain? I guess not because I see you are not using a PCI passthrough network device in the driver domain. You are not even using a virtual network in the driver domain. Therefore, even if you can connect the guest domain (guest1) with the diver domain, you will not have access to the network to talk to the outside world.

Well that is actually what I'm trying to achieve, the guests have just
to be able to communicate with each other.

>
> I was able to make the driver domain work using the Ethernet PCI passthrough. Detail on PCI passthrough can be found in the following link.
>
> https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough
>
> I was not able to make the driver domain work having the virtual network in the driver domain (guest0). It creates a nested paravirtualized network, which is a little complicated. But, there should be some way to make it work.
>
> On top of that, to make a domain work as driver domain, you need to run the following command to launch the driver domain daemon (guest0) before you launch the guest domain (guest1).
>
> #xl devd
>
> If you do not have access to this daemon, we need to install it first in the driver domain (guest0). One way to install this is to install Xen hypervisor on the driver domain, but skip booting the Xen by selecting other option, say Ubuntu, from the boot menu.

Btw it finds out that there is a BUG,
https://lists.xenproject.org/archives/html/xen-devel/2022-03/msg00279.html

>
> I hope this helps.
>
> Bests,
> Mehrab
>
>
>
>
>
> On Thursday, March 3, 2022, 07:30:05 AM EST, WebDawg <webdawg@gmail.com> wrote:
>
>
>
>
>
> Have you check that the interface is up on guest1?
>
> What I mean is have you configured the interface inside of guest1? ifconfig/ip
>
> On Thu, Mar 3, 2022, 5:32 AM Andrea Stevanato <Andrea.Stevanato@santannapisa.it> wrote:
>>
>>
>>
>>
>> Hi all,
>> I'm trying to configure two guests that can communicate with each other using a "virtual" network card exploiting the netback and netfront driver.
>>
>> The first guest is created with the following configuration:
>>
>> name    = "guest0"
>> kernel  = "/media/sd-mmcblk0p1/Image"
>> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
>> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
>> memory  = 1024
>> vcpus   = 2
>>
>> Once it is up and running, I create and setup the bridge:
>>
>> # brctl addbr xenbr0
>> # ip addr add 10.0.3.1/24 dev xenbr0
>> # ip link set dev xenbr0 up
>>
>> Then I configure the udhcpd server with the following configuration (/etc/udhcpd.conf):
>>
>> start 10.0.3.15
>> end 10.0.3.254
>> interface xenbr0
>> option subnet 255.255.255.0
>>
>> And start it with: `# udhcpd`?.
>>
>> The second guest is created with the following configuration:
>>
>> name    = "guest1"
>> kernel  = "/media/sd-mmcblk0p1/Image"
>> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
>> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
>> memory  = 1024
>> vcpus   = 2
>> vif = [ 'bridge=xenbr0, backend=guest0' ]
>>
>> Once it is up and running on the guest0 the new interface (vifX.0) is created correctly, however on the guest1 the eth0 interface is not present.
>>
>> If I do the exact same thing on dom0, instead of guest0 (without attaching the eth0 to the bridge, since I do not need to reach outside), the eth0 on the guest is created correctly and get the 10.0.3.15 IP address.
>>
>> What I'm doing wrong?
>>
>> Andrea
>>
>>
>>

Andrea

On 3/3/22 23:37, Felix Kuperjans wrote:
> Am 03.03.22 um 11:32 schrieb Andrea Stevanato:
>> Hi all,
>> I'm trying to configure two guests that can communicate with
>> each other using a "virtual" network card exploiting the netback and
>> netfront driver.
>>
>> The first guest is created with the following configuration:
>>
>> name    = "guest0"
>> kernel  = "/media/sd-mmcblk0p1/Image"
>> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
>> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
>> memory  = 1024
>> vcpus   = 2
>>
>> Once it is up and running, I create and setup the bridge:
>>
>> # brctl addbr xenbr0
>> # ip addr add 10.0.3.1/24 dev xenbr0
>> # ip link set dev xenbr0 up
>>
>> Then I configure the udhcpd server with the following configuration
>> (/etc/udhcpd.conf):
>>
>> start 10.0.3.15
>> end 10.0.3.254
>> interface xenbr0
>> option subnet 255.255.255.0
>>
>> And start it with: `# udhcpd`?.
>>
>> The second guest is created with the following configuration:
>>
>> name    = "guest1"
>> kernel  = "/media/sd-mmcblk0p1/Image"
>> ramdisk = "/media/sd-mmcblk0p1/rootfs.cpio.gz"
>> extra   = "console=hvc0 rdinit=/sbin/init root=/dev/ram0"
>> memory  = 1024
>> vcpus   = 2
>> vif = [ 'bridge=xenbr0, backend=guest0' ]
>>
>> Once it is up and running on the guest0 the new interface (vifX.0) is
>> created correctly, however on the guest1 the eth0 interface is not
>> present.
>>
>> If I do the exact same thing on dom0, instead of guest0 (without
>> attaching the eth0 to the bridge, since I do not need to reach
>> outside), the eth0 on the guest is created correctly and get the
>> 10.0.3.15 IP address.
>>
>> What I'm doing wrong?
>>
>> Andrea
>
> Hi Andrea,
>
> I think this might be related to problems with the VIF hotplugging on
> "guest0".
>
> Since the vifX.0 on guest0 is successfully created, some of the
> hotplugging at least works, but maybe a failure to setup it correctly
> leads to the problem in "guest1".
>
>
> A few questions for further investigation:
>
> Is the vifX.0 device up and having "master xenbr0" (see ip link show)?

The vifX.0 do not have "master xenbr0".

> If not, there is definitely a problem with the bridge hotplugging.
>
> Which daemon handles the vif hotplugging? xl devd? is /etc/xen/xl.conf
> configured correctly (usually having vif.default.script="vif-bridge" and
> run_hotplug_scripts=1)?

The configuration file is all commented, actually also in dom0 it is the
same.

> Do the hotplugging scripts exist, esp. /etc/xen/scripts/vif-bridge ? Can
> you see any log messages from this script in /var/log/xen/xen-hotplug.log?

Yes, the vif-bridge script exists. No, the /var/log/xen directory is empty.

> Usually I would expect one of these to have a notable error causing the
> script to not be called or not run properly.
> Otherwise, some more log output from guest0 would be helpful, dmesg, log
> messages about the hotplugging, ...

Please have a look at
https://lore.kernel.org/xen-devel/1d00a228-a699-5743-69ae-4dbadee5ebb9@santannapisa.it/T/#m50eed0b51f2fc8b0ac26bc269dd5119f83041dd0
where I posted the full
log of xl -vvv devd -F executed on guest0.

> Best Regards
> Felix

Cheers,
Andrea

Am 07.03.22 um 11:27 schrieb Andrea Stevanato:
> On 3/3/22 23:37, Felix Kuperjans wrote:
>> Hi Andrea,
>>
>> I think this might be related to problems with the VIF hotplugging on
>> "guest0".
>>
>> Since the vifX.0 on guest0 is successfully created, some of the
>> hotplugging at least works, but maybe a failure to setup it correctly
>> leads to the problem in "guest1".
>>
>>
>> A few questions for further investigation:
>>
>> Is the vifX.0 device up and having "master xenbr0" (see ip link show)?
>
> The vifX.0 do not have "master xenbr0".
>
>> If not, there is definitely a problem with the bridge hotplugging.
>>
>> Which daemon handles the vif hotplugging? xl devd? is
>> /etc/xen/xl.conf configured correctly (usually having
>> vif.default.script="vif-bridge" and run_hotplug_scripts=1)?
>
> The configuration file is all commented, actually also in dom0 it is the
> same.
>
>> Do the hotplugging scripts exist, esp. /etc/xen/scripts/vif-bridge ?
>> Can you see any log messages from this script in
>> /var/log/xen/xen-hotplug.log?
>
> Yes, the vif-bridge script exists. No, the /var/log/xen directory is
> empty.
>
>> Usually I would expect one of these to have a notable error causing
>> the script to not be called or not run properly.
>> Otherwise, some more log output from guest0 would be helpful, dmesg,
>> log messages about the hotplugging, ...
>
> Please have a look at
> https://lore.kernel.org/xen-devel/1d00a228-a699-5743-69ae-4dbadee5ebb9@santannapisa.it/T/#m50eed0b51f2fc8b0ac26bc269dd5119f83041dd0
> where I posted the full
> log of xl -vvv devd -F executed on guest0.
>
>> Best Regards
>> Felix
>
> Cheers,
> Andrea


Hi Andrea,

Thank you for your message and pointing to the Xen devel communication.
I've also been reading the thread on Xen Devel already out of curiosity.

I was actually surprised that your distribution (petalinux) seems to
include a very restrictive XSM by default - normally I would consider
XSM something you only enable if you know what you're doing and you know
exactly how your use case looks like.

Seems like you got it working by switching to a default XSM
configuration. I think petalinux should include a warning to its users
that many Xen functions will be prevented by them changing the default
to the very restricted SILO mode (like e.g. all backend/driver domains).
If you want to, I think you could develop a proper XSM configuration for
this setup, which only allows the "guest0" to act as a network backend
domain and use it - but this requires setting it up in the policy
properly additionally to the configuration in the domain's configuration
file.

Cheers
Felix