X-Git-Url: http://git.annexia.org/?a=blobdiff_plain;f=virt-what.pod;h=8fd9bc40fcabc890a6f3ece3273ce9802c4147a4;hb=243928da395080d7895111d5e5c0f1ff5f9e95fb;hp=0a724d4b8e3350c4c7574fe61e3c129d7a302f87;hpb=c9622b6019744e7fe13bd8ccd93374abc7770683;p=virt-what.git diff --git a/virt-what.pod b/virt-what.pod index 0a724d4..8fd9bc4 100644 --- a/virt-what.pod +++ b/virt-what.pod @@ -25,6 +25,12 @@ don't know about or cannot detect. =over 4 +=item B + +This is a Docker container. + +Status: confirmed by Charles Nguyen + =item B This is Microsoft Hyper-V hypervisor. @@ -62,10 +68,28 @@ Status: confirmed by RWMJ using a Fedora guest running in z/VM =item B +This is printed for backwards compatibility with older virt-what which +could not distinguish between a Linux VServer container guest and +host. + +=item B + This process is running in a Linux VServer container. Status: contributed by Barış Metin +=item B + +This process is running as the Linux VServer host (VxID 0). + +Status: contributed by Barış Metin and Elan Ruusamäe + +=item B + +This process is running in a Linux LXC container. + +Status: contributed by Marc Fournier + =item B This guest is running on the KVM hypervisor using hardware @@ -95,7 +119,8 @@ Status: contributed by Justin Clift The guest is running inside IBM PowerVM Lx86 Linux/x86 emulator. -Status: data supplied by Jeffrey Scheel, not confirmed +Status: data originally supplied by Jeffrey Scheel, confirmed by +Yufang Zhang and RWMJ =item B @@ -112,6 +137,15 @@ This is a User-Mode Linux (UML) guest. Status: contributed by Laurent Léonard +=item B + +Some sort of virtualization appears to be present, but we are not sure +what it is. In some very rare corner cases where we know that +virtualization is hard to detect, we will try a timing attack to see +if certain machine instructions are running much more slowly than they +should be, which would indicate virtualization. In this case, the +generic fact C is printed. + =item B This is Hitachi Virtualization Manager (HVM) Virtage @@ -163,6 +197,40 @@ Status: confirmed by RWMJ =back +=head1 EXIT STATUS + +Programs that use or wrap C should check that the exit +status is 0 before they attempt to parse the output of the command. + +A non-zero exit status indicates some error, for example, an +unrecognized command line argument. If the exit status is non-zero +then the output "facts" (if any were printed) cannot be guaranteed and +should be ignored. + +The exit status does I have anything to do with whether the +program is running on baremetal or under virtualization, nor with +whether C managed detection "correctly" (which is basically +unknowable given the large variety of virtualization systems out there +and that some systems deliberately emulate others). + +=head1 RUNNING VIRT-WHAT FROM OTHER PROGRAMS + +C is designed so that you can easily run it from +other programs or wrap it up in a library. + +Your program should check the exit status (see the section above). + +Some programming languages (notably Python: issue 1652) erroneously +mask the C signal and do not restore it when executing +subprocesses. C is a shell script and some shell commands +do not work correctly when you do this. You may see warnings from +C similar to this: + + echo: write error: Broken pipe + +The solution is to set the C signal handler back to C +before running C. + =head1 IMPORTANT NOTE Most of the time, using this program is the I thing to do. @@ -185,6 +253,13 @@ tool. You might include this information in status and monitoring programs. +=item System tuning (sometimes) + +You might use this program to tune an operating system so it runs +better as a virtual machine of a particular hypervisor. However if +installing paravirtualized drivers, it's better to check for the +specific features your drivers need (eg. for the presence of PCI devices). + =back =head1 SEE ALSO