Why..or How...could dom0 not be running paravirtualized?
-
Hello,
I have a very...odd...situation. I currently have 3 xcp-ng hosts; two of them report they're not running paravirtualized dom0 according to lscpu.
I've tried digging around for possible reasons how this could happen...AFAIK the dom0 is a paravirtualized thing and that's about all I can read on the subject. There is a lot of noise in search results involving this and I've made efforts to try to require "dom0"...but I keep getting 99.9% responses about domU.
The one thing I haven't tried is "turning it off and turning it off again"; that will take some planning and a late night so I can do this without interrupting everything. I'm trying to gather some information should that not fix things.
The two hosts are default xcp-ng installs from the 8.2 ISO. The one thing I will say is I accidently interrupted their power last week; but I don't know if that had anything to do with it. The one host is a Xeon X3450; the other is actually a Pentium N3710 that I wanted to see "what would happen".
The only thing I'm noticing is maybe the dom0 usage likes to spike on the two machines reporting non paravirtualized. The one I would suspect due to being such an old lousy slow processor.
The third host, that is currently reporting proper paravirtualization of domU...is actually a Celeron N5095 that I had to use a slightly modified installer due to issues with 11th gen NUC. This is actually the best performing machine out of my hosts.
Anyway..if anyone has anything to try before I start reinstalling xcp-ng on the two hosts one night; I'd appreciate it.
-
No, it's not possible to get a dom0 that's not a PV domain for now. There's some work to get a PVH dom0, but it can't be HVM by definition (there's no emulation possible at boot time).
I'm not sure to understand how do you are checking that, there's maybe a confusion between a host that's hardware virtualization capable and the dom0 virt mode.
-
So what started this was an unrelated project in trying to determine a machine that had multiple threads per core so I could limit a script to just physical cores. The only thing I have with Hyperthreading is the Xeon. So I decided to see what lscpu told me:
[14:05 localhost ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 4 Core(s) per socket: 1 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 30 Model name: Intel(R) Xeon(R) CPU X3450 @ 2.67GHz Stepping: 5 CPU MHz: 2666.702 BogoMIPS: 5333.32 Hypervisor vendor: Xen Virtualization type: none L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ssbd ibrs ibpb stibpThis looked okay...except the Virtualization type threw me off; so I checked my other two hosts:
[14:05 xcp-laptop1 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 4 Core(s) per socket: 1 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 76 Model name: Intel(R) Pentium(R) CPU N3710 @ 1.60GHz Stepping: 4 CPU MHz: 1599.948 BogoMIPS: 3199.89 Hypervisor vendor: Xen Virtualization type: none L1d cache: 24K L1i cache: 32K L2 cache: 1024K Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 movbe popcnt aes rdrand hypervisor lahf_lm 3dnowprefetch ibrs ibpb stibp erms[18:04 xcp-nuc ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 4 Core(s) per socket: 1 Socket(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 156 Model name: Intel(R) Celeron(R) N5095 @ 2.00GHz Stepping: 0 CPU MHz: 1996.847 BogoMIPS: 3993.69 Hypervisor vendor: Xen Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 1536K L3 cache: 4096K Flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 movbe popcnt aes xsave rdrand hypervisor lahf_lm 3dnowprefetch cpuid_fault ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase erms rdseed clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 gfni rdpid arch_capabilitiesOne of these three is not like the other two...and what I admit I don't know is if any of this actually means anything in regards to dom0.
-
lscpuis indeed a dom0/Linux command.What matters in your case is
xl infocommand
-
okay. I was just going with lscpu because this was not anything xcp-ng specific target wise (in fact I have no clue what the script target environment is).
I'll just ignore whatever lscpu says then and look elsewhere for why that Xeon machine is running so poorly; it took 30 seconds before I got a prompt over ssh login earlier.
thanks.
-
Have you check
dmesg? DNS config?xl dmesg? -
@olivierlambert not deeply. it's something on my list of things to do when I can safely poke around that machine and not worry about everyone's TV going down. It does appear...for some reason...a number of NICs on that host keep going offline and coming back.
[983824.149675] e1000e 0000:00:19.0 eth0: NIC Link is Down [983831.242805] e1000e 0000:00:19.0 eth0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RxI think that port is plugged into a switch. I see them for eth1 and eth3 as well in the backlog; eth2 is pci passthrough.
I seem to recall I may have had a few issues during the install. I think between now and this weekend I will back all the VMs up and reinstall. I just partially feel like I should be able to pfsense on this machine without using the equivalent of two full cores to saturate the link. Not to mention I've been questioning advantages to passthrough vs virtual. Things I didn't want to bother the community about as...I keep reminding myself...I'm having fun learning the depths of this stuff.
Appreciate the pointers.
-
Hmm I would also check for BIOS/firmware update
