[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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?

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.