Re: VIF network definition does not work with backend=domnet

[Norbert Ronecker <norbert@xxxxxxxxxxxxx>]

Hello again,

i promise i'm working on it since yesterday to get anything useful 
done... Now i tried it with a new vif and set vif.default.backend in 
xl.conf...
Now it does work...
But i dont know if it does, because i did once another try... or by 
putting type=vif in there...
What i tried:

1. set vif.default.backend = netbackend and vif = [ 
'backend=netbackend,bridge=dmz' ]
2. vif = [ 'type=vif,script=vif-nat' ]
3. vif = [ 'type=vif,bridge=dmz' ]

It does work now. Like i said. I dont know if it does now. because of 
the vif-nat middle step. Or because i did start the network with 
vif.default.backend and omit the backend setting in the domu.cfg
However, i'll try it, with a reboot later that day (the xenhost also 
hosts my opnsense firewall with all networks with a separate network 
card from the others).
So wish me luck for later that day.

Best regards
Shen Long

Am 21.03.25 um 20:59 schrieb Shen Long:
> Hello,
>
> I use XEN on a gentoo home-lab/home-network server. I installed the Dom0 
> with gentoo with a dedicated network card. I gave a spare network card 
> on the machine to a dedicated network driver domain which also runs gentoo.
> Now i discovered an issue with the VIF spec for new domUs.
>
> Following problem. If i start a domu with a vif spec to connect to a 
> backend domu it does fail with an error.
> If i omit the vif spec, create the domu and immediately attach a network 
> card with xl network-attach backend=netbackend it works.
> Here's the netbackend.cfg, if i may forgot something:
>
> > name = "netbackend"
> > builder = "hvm"
> > vcpus = 4
> > memory = 4096
> > pci = [ '03:00.0' ]
> > disk = [ 'phy:/dev/mapper/xenhost-netbackend,xvda,w' ]
> > netif="yes"
> > usbdevice = [ "tablet" ]
> > serial = "pty"
> > on_poweroff = "destroy"
> > on_reboot = "restart"
> > on_crash = "restart"
> My backend have several bridge-networks configured with associated 
> network-vlans on my physical interface.
> - home
> - dmz
> - foo
> - infra
>
> Here the test.cfg domu which "works":
>
> > name = "test"
> > builder = "hvm"
> > vcpus = 1
> > memory = 4096
> > #vif = [ 'backend=netbackend,bridge=dmz' ]
> > disk = [ 'file:/isos/systemrescue-11.03-amd64.iso,hda:cdrom,r' ]
> > usbdevice = [ "tablet" ]
> > serial = "pty"
> > on_poweroff = "destroy"
> > on_reboot = "restart"
> > on_crash = "restart"
> It does not have a proper disk yet, because testing.
> The Problem is, if i remove the hash from the vif spec, i get this error 
> on `xl create test.cfg`:
> > # xl create /etc/xen/domuconfig/test.cnf
> > Parsing config from /etc/xen/domuconfig/test.cnf
> > libxl: error: libxl_dm.c:3157:device_model_spawn_outcome: Domain 
> 89:domain 89 device model: spawn failed (rc=-3)
> > libxl: error: libxl_dm.c:3377:device_model_postconfig_done: Domain 
> 89:Post DM startup configs failed, rc=-3
> > libxl: error: libxl_create.c:1937:domcreate_devmodel_started: Domain 
> 89:device model did not start: -3
> > libxl: error: libxl_aoutils.c:646:libxl__kill_xs_path: Device Model 
> already exited
> > libxl: error: libxl_xshelp.c:206:libxl__xs_read_mandatory: xenstore 
> read failed: `/libxl/89/type': No such file or directory
> > libxl: warning: libxl_dom.c:49:libxl__domain_type: unable to get 
> domain type for domid=89, assuming HVM
> > libxl: error: libxl_domain.c:1616:domain_destroy_domid_cb: Domain 
> 89:xc_domain_destroy failed: No such process
> > libxl: error: libxl_domain.c:1133:domain_destroy_callback: Domain 
> 89:Unable to destroy guest
> > libxl: error: libxl_domain.c:1060:domain_destroy_cb: Domain 
> 89:Destruction of domain failed
>
> As mentioned, i can comment out the vif spec and attach a network card 
> with `xl network-attach test bridge=dmz backend=netbackend` which works 
> perfectly fine. But i according to the man-page it is possible to define 
> the networks with a netbackend in the domu cfg files and autostart it 
> with that.
> If you need more information, just ask me.
>
> Do i have an error in my setup or overlooked something?
> Do we have a proper bug in this scenario?
> Or is it not implemented in that way, a missing feature or do i overlook 
> something?
> Best regards
> Shen Long