@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

Also, you are consistently confused on how things are working.

The question is who's confused or ignorant ... I stated above 2 or 3 times, I am absolute clear what makes a HVM a so "called PvHVM", just the driver addon afterwards

But you are confused in saying it is not possible to install Windows on "unknown" hardware, where Windows doesn't have drivers builtin. This is in fact possible since Windows NT 4.0 times back in the 1990s. It is is easily possible to inject drivers right at the start of installation, all kind of, not only block storage drivers ...

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

You can't have "PVHVM ready template" without having an Operating System running with drivers enabled.

Well, sorry, I disagree here, you can, but then you need to have parallel a second virtual CD-ROM drive with the drivers on it. No problem, we are defining virtual hardware with a mouse click, just set 2 CD-ROM devices and give the drivers to Windows right at fresh installation ...

A XL based definition might look like this:

name = "winserv"
type = "hvm"
firmware = "uefi"
device_model_version = "qemu-xen"
device_model_override = "/usr/bin/qemu-system-x86_64"
xen_platform_pci = 1
vcpus = 4
memory = 8192
#maxmem = 16384
vga = "stdvga"
vif = [ 'mac=AA:BB:CC:DD:EE:FF, bridge=xenbr0, type=vif' ]
disk = [
         '/dev/vg/winserv-disk1,,xvda',
         '/srv/xen/iso_import/de_windows_server_2019_essentials_updated_sept_2019_x64_dvd_1a60868a.iso,,xvdc:cdrom',
         '/srv/xen/iso_import/Xen64drivers.iso,,xvdd:cdrom'
       ]
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot = "dc"
usb = 1
usbdevice = [ 'tablet' ]
usbctrl = [ 'version=3, ports=4' ]
usbdev = [ 'hostbus=4, hostaddr=2' ]
vnc = 1
vncconsole = 1
vncdisplay = 10
vnclisten = "0.0.0.0"
keymap = 'de'
localtime = 1
viridian = 1

After installation disk line like that:

disk = [ '/dev/vg/winserv-disk1,,xvda', ',,xvdc:cdrom', ',,xvdd:cdrom' ]

Pop & un-pop ISO using "xl cd-insert/cd-eject ..."

Same procedure within VMWare, define virtio for everything and mount proper driver ISO in parallel while installation from scratch.

And that common practise, similar to real HW installation, where devices are builtin and Windows doesn't know about drivers at installation time ...

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

no hint?

Yes, no hint in any description, that after a new install, the Windows HVM does come up with "QEMU NVMe disk" and "Intel E1000". And then installation of "XCP-ng Windows Guest Tools" does push "QEMU NVMe disk" to become "XENSRC PVDISK SCSI disk drive" and "Intel E1000" to become "XCP-ng PV Network".

More common here is, the Windows HVM comes up with some "blank devices", where drives need to be installed, to become finally a so called "PvHVM" ...

One topic to be clarified, is it possible to retrofit an Windows Image backup from an other virtual environment to become a HVM with PV drivers ...

And I'm still not totally happy with XOA, bit overloaded for my purpose, does eat 2GiB memory of my by purpose tight calculated home server and additional hassle if my single server does need e.g. a reboot. For a setup like mine, off-band management with "XCP-ng Center" does have some advantages ...

@olivierlambert Well there was no hint that "XCP-ng Windows Guest Tools" does bend standard fully virtualized QEMU devices into Xen PV devices. Windows admins normally prefer to see unconfigured devices looking for drivers ...

On thing I still don't get, I always thought the HVM templates are on XenServer/XCP-ng itself. Why does "XCP-ng Center" create a different WS2019 HVM compared to XOA?

Center's HVM does provide QEMU ATA disks, XOA "QEMU NVMe disks", what might then be the key for the "XCP-ng Windows Guest Tools" installation ...

Oh man, it does just work setting up a fresh Windows Server 2019 as HVM using XOA ... obviously not anymore with "XCP-NG Center".

That XOA-HVM has been created with QEMU NVMe disks and I could install "XCP-ng Windows Guest Tools" succesfully, very first time. This did bend "Intel E1000" & "QEMU NVMe disk" into "XCP-ng PV Network" & "XENSRC PVDISK SCSI disk drive" ...

Too bad, "XCP-ng Center" would have been my preference ... don't have a Server/Cloud Farm to manage. And yes, with XOA I can define UEFI boot for Linux HVMs.

So, let's see if I can retrofit my VM Windows backups into XCP-ng HVM with Guest tools.

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

Or even when you create your VM, select UEFI.

Hmm, I don't have UEFI as an option for Linux templated HVMs in "XCP-NG Center" ... ? Just "BIOS Boot" ...

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

You MUST install them yourself.

Just in case you didn't understand, I did install them ... but no Xen PV devices do show up inside that Windows (WS2019 or Win10) installation, only "xenbus" under "System devices" ...

Drivers from here:

https://xenproject.org/downloads/windows-pv-drivers/windows-pv-drivers-9-series/windows-pv-drivers-9-0-0/

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

So when you said "HVM templates for Windows don't provide PVHVM", it doesn't make sense.

Yepp, sorry for confusion, I meant really the same, HVM with inside PV drivers, shortly spoken/written "PvHVM" ...

@olivierlambert said in windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess:

That's why HVM with modern (ie <10y hardware) and PV drivers will almost every time beat PV guests.

I agree, at the end good old plain PVs proofed it, despite odd booting (PyGrub) or expensiv memory accesses ...

But I see that approach only inside Linux HVMs but not in HVMs for Windows. Easy to check in "Device Manager", disks are "QEMU ATA" type so fully virtualized, as also Network, either RTL8169 or Intel E1000, ditto fully virtualized. A fresh windows installation inside XCP-NG 8.2.0 doesn't search for drivers of Xen devices (Net or IO) ... just "xenbus" seems kind of a matter ...

Am I doing same on Debian based Xen Hypervisor (Kernel 4.19 & Xen 4.11), creating HVMs using .cfg files, I need to have xenvif, xennet and xenvbd available right at time of fresh Windows installation, no big deal, thanks to you guys. I am missing that approach in XCP-NG ... I want to have Windows in HVM based on Xen PV devices.

And please enable UEFI for Linux HVMs ...

@olivierlambert Well if XCP-NG would really bring what you postulate, it would be great.

But IMHO the truth looks different, at least for me today. HVM templates for Windows usage don't provide PvHVM capability, it is just fully virtualized. Only xenbus drivers are installed, everything else is QEMU fully virtualized, IO & Network, so does burn needless Hypervisor CPU time and power. Looking to this, makes arguments against PVs so called disadvantages on memory access questionable ...

Underlying XenProject stack does provide fully PvHVM capability for Windows in HVM and there are drivers for all of that. "Xen PV Storage Host Adapter", "XENSRC PVDISK SCSI Disk Device", "Xen PV Network Device", "Xen PV Network Class", "Xen PV Console", "Xen PV Bus", on top USB3 capability for HVM. And yes, those Windows (Pv)HVMs are lightning fast, tested with Debian & Ubuntu included XenProject 4.11 stack ...

On top I don't find any installable host agent for Windows HVMs inside XCP-NG, not on WS2019 or WIN10.

So, only Linux guests can be installed as PvHVM, but does that make senses? Every Linux Kernel since version 2.6 brings xen device/driver capabilities, there was never any need to modify any kernel of any known Linux distribution, runable inside a PV. Sure, not all bring XenProject Hypervisor, but that is not the question here.

Killing PV in favor to Linux PvHVM kills Xen's biggest differentiator over other virtualizations, one of its beauties. Xen on ARM is e.g. only possible with good old PV capability ...

I had the plan to restructure my home IT back to my roots, fully open source, happy seeing XenServer as XCP-NG still alive. Great, with an relatively actual kernel, fully 64-bit, UEFI bootable. After testing a while I am rather disenchanted, looking to HVMs for Windows just being fully virtualized, but UEFI capable, and Linux no PV just HVM/PvHVM, not UEFI capable, but what is standard today. Try to to install Ubuntu Server 20.04.2 inside that HVM ...

Not even talking about server managment, ok, good old Windows Center software still available, not ideal, would prefer a sneek HTML5 GUI. XOA looks like vSphere vCenter's ugly sister, bothering permanently with pay options.

Don't get me wrong, I fully understand open source developers cannot live from air and love, but that is absolutely no base to hassle users permanently poking to pay options. And overall the GUI structure is complex and convoluted ... why can't it be easy and good structured like the XCP-NG Center ... ?