windows + (PV | HVM | PVHVM | PVHv1 | PVHv2) , a little mess
-
So you said you disagree but you are giving an example with
xlwhich isn't the toolstack for XCP-ng
I'm answering for XCP-ng, not for something else.
Also, you are consistently confused on how things are working. Even by having the drivers installed during OS installation, you can't have a PVHVM template, such thing doesn't exist. Period.
When you boot, you will use emulation UNTIL an operating system will take it from there. Yes, you can do that with any Ubuntu Live CD that won't install anything in any hard drive. But still, up to grub, you are using emulation (HVM). The VM is still HVM. It will be HVM forever (as long you didn't convert to PV). We use the PVHVM terms, it just means that now your HVM guest is able to talk with PV drivers. But PVHVM mode doesn't exist in Xen code base. Search for it if you like.
-
@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 ...
-
I never said THAT was impossible, as long the OS kernel started, you can use whatever drivers you like. I was just answering the fact PVHVM was a real mode since the start, and it's not. You can't have a PVHVM template, it doesn't make sense (unless you have already an OS installed).
That's all I said
You are moving the goalposts every time.
