Re: Recent(?) change forces reboot after adding vif

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jul 14, 2025 at 09:25:25AM +0100, Owen Smith wrote:
> This is almost certainly related to UNPLUGv3. Does the daemon.log show
> anything as to why xenvif detected the re-added vif as a new network device
> that requires a reboot? Check for "ConfigRequestReboot" and preceding log
> lines

Where can I find this daemon.log? Do I need to enable some extra logging
somehow?

The exact message I get is "Xen PV Network Class needs to restart the
system to complete installation".


> Owen
> 
> On Sun, Jul 13, 2025 at 4:01 AM Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx> wrote:
> 
> > Hi Marek,
> >
> > On 13/07/2025 01:01, Marek Marczykowski-Górecki wrote:
> > > Hi,
> > >
> > > Some recent(ish) change made Windows want a reboot after adding a vif to
> > > the domU config, even if such vif was there in the past (so, the driver
> > > was installed). While the prompt is there, network clearly works
> > > already.
> > >
> > > The specific workflow is:
> > > 1. Create domU with vif included.
> > > 2. Install Windows (10 or 11 - both seems to be affected)
> > > 3. Install PV drivers
> > > 4. Shutdown Windows
> > > 5. Remove vif from the domU config
> > > 6. Start Windows, wait(?), shutdown
> > > 7. Re-add the vif and start domU
> > >
> > > Such operation used to work perfectly fine without any extra reboot. But
> > > now domU prompts to reboot, like this:
> > >
> > https://openqa.qubes-os.org/tests/146690#step/windows_clipboard_and_filecopy/25
> > >
> > > Note that network actually works already at the point then reboot is
> > > prompted - so it seems the reboot isn't really necessary?
> > >
> > > This is especially problematic because we have some domUs intentionally
> > > don't persist changes on the disk on reboot. So, this basically means
> > > reboot loop if you do a change to vif config...
> > >
> > > The old/new versions are:
> > >
> > >      xenvif updated from 9fd1af to 4608bc
> > >      xennet updated from ad7717 to 0b1a93
> > >
> > > Full version differences can be seen at
> > > https://github.com/QubesOS/qubes-vmm-xen-windows-pvdrivers/pull/4/files
> > >
> >
> > It's probably Unplug v3 (xenvif 4608bc) since that's the only recent
> > significant change on the unplug side. Though this change is pretty much
> > required due to Microsoft's new rules on driver isolation.
> >
> > Although I'm surprised that PV networking worked with your old driver
> > combination, since xennet ad7717 requires Unplug v3 which xenvif never
> > exposed until 4608bc. Are you sure you're not falling back to emulated
> > networking?

That's a good point, indeed it's emulated network still.

> > I'm trying to simplify the situation with forced unplug, with which you
> > can just inject the drivers and have them work out-of-box, but there's
> > still some work to do wrt active device.
> >
> >
> > Ngoc Tu Dinh | Vates XCP-ng Developer
> >
> > XCP-ng & Xen Orchestra - Vates solutions
> >
> > web: https://vates.tech
> >
> >
> >
> >

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature