ActiveXperts Network Monitor continuously monitors Citrix XenServer servers and/or associated virtual machines. ActiveXperts provides centralized control and visibility into various levels of the XenServer virtual infrastructure, with real-time monitoring of dynamic XenServer virtual elements. ActiveXperts has deep awareness of all virtual. Forwarding serial to VMware, Hyper-V or any other environments makes the serial port hardware usage more efficient. If you or any applications on the virtual machine you are working on have to have access to a serial port on host OS, Serial to Ethernet Connector is one of the easiest ways to connect COM port in virtual machine.

1. But XenServer show Server Serial number and CPU Serial. I guess that I can't use any tool like CPUz on guess OS for find it too. Must I open Server and read Memory Serial?
2. Serial Port Helper. You can connect any serial port used to read / write data. Serial Port View; Serial Port Config; TX / RX; Send Hex Buffer: Press send button, and then input @hex or @hex: to send Hex Buffer; Send File: Press send button, and then input @file or @file: to send file. Release Notes 0.0.7.

XCP has various options for accessing VM consoles. This document describes some of the ways to access those consoles.

Xen has (at least) two distinct ways to access VM consoles. One - using the xc (XenConsole) device (in paravirtualized environment) and second - using a framebuffer (for PV) and/or VGA adapter (for HVM) serializing via VNC. Main idea behind XCP (the open source version of XenServer) is uniform access to all VM regardless their type, so to accomplish this an enterprise management API (xapi) uses vncterm to emulate VNC connection to console for text consoles. Unfortunately, due strict to security, VNCterm only listens on localhost of XCP host. When management tools such as XenCenter or OpenXenManager display the console, they using a special service that requires XenAPI session token and normal authorization. In this case VNC traffic is wrapped in HTTP and is difficult to access manually.

There is (at least) three ways to gain access to VM consoles: using HTTP connection with suitable software, creating custom tunnels with vncterm connections from the XCP host to your own host, and direct access to the console (for PV only).

Access via management software

You can use management tools such as XenCenter, OpenXenManager, or Xen VNC Proxy (XVP) to access consoles. XenCenter is currently only available for Windows platforms. OpenXenManager (and its web counterpart XenWebManager) are under active development. Some limitations may include needing direct access to the system and needed to open ports on the server, making PNAT and DMZ scenarios more challenging. Another issue is that you need to configure server pools according to your needs. For example, by default the console is only available only for the pool master, so if you are running XCP on single computer, this computer will be the master, and if you using two or more hosts in single pool, by default, the first server in pool will be the master.

• XenCenter (www.citrix.com/xenserver) is available free from Citrix and as of version XCP 1.0 and XenCenter 5.6 FP1 is able manage XCP as well as Citrix XenServer.
• OpenXenManager is available for download: http://www.openxenmanager.com/
• XVP is available from http://www.xvpsource.org/
• See also: XCP Projects

Custom SSH tunneling

Note: this is not an official way to access consoles, but it is a relatively safe work around. It is extremely useful when requiring console access and you are not using XenCenter and have yet been able to set up something like XVP.

The main problem is that the VNC server for the console listens only on localhost on the host. So you cannot say something like 'vncviewer myxcphost:5901'. It will not work.

You must create a ssh tunnel to the XCP host and setup TCP forwarding from your localhost ports to the localhost ports on the remote SSH server (XCP host in this case). It seems that the default settings for the SSH server (at least on XCP 6.1) do not allow TCP forwarding, so this needs to be enabled before being able to get the TCP ports to forward properly to connect to the console.

Change /etc/ssh/sshd_config to include:

Then restart SSHd. If you are connected via SSH, this will obviously cut you off.

You can now remotely connect to the XCP host and setup SSH port linking to access both the text and graphical consoles. The ports used for VNC console are 5901-5999, and the ports used for text console are 9501-9599. It will look like this:

After that you can gain direct access to the VM consoles by using a vncviewer clinet (for example, xnvcviewer localhost:59XX). To determine what to fill in for XX, see below. Note: the command above creates mapping between the 'localhost' port on the host and the 'localhost' port on your machine. You can use any VNC client, but be aware that some may not work well (for example, users have reported problems with tkvnc on Linux) and users have reported that xvncviewer works well.

You can also connect to the text console (VT100) on localhost:9501...9599.

Now we need find 'XX' value for host. This is pretty tricky, as the port changes every time the VM migrates, shuts down, etc.

On the XCP host do command:

You can use name-label or uuid or any other attributes to distinguish one VM from other.

Examples:

You will get output like this:

(note: value '-1' means no console avaible, usually meaning that VM is not running, use xe vm-list (without params) to see current status).

Now we have the dom-id. Let's look to xenstore:

(no slash at end)

Example:

You will get reply like this:

The 'vnc-port =' line is our port.

Now (from you local machine, since that is where the SSH tunnel was created, from above) run `xvncviwer localhost:5911.`

(note, every reboot you will need to reconnect and reestablish the SSH tunnel(s)).

Hacking a vncterm

Note: this is very risky, you will expose unprotected console to 'wild world' and any 'hacker kids' will able to send you 'Alt-SysRq b' keys (regardless of vm login prompt) to reboot your VM.

Theory: vnterm listen on 127.0.0.1 and this is defined in helers code. You can change it to any address you like. File is /opt/xensource/libexec/vncterm-wrapper, variable is export VNCTERM_LISTEN='-v 127.0.0.1:1'.

After that you shall allow connection in firewall to tcp ports 5901..5999 and restart host. After reboot consoles of your VM will be exposed to wild cruel world where anyone can be able to connect to you VM consoles without password.

Direct access to text consoles of PV domains

There is undocumented key in vmops.ml source code:

So it simple:

xe vm-param-set uuid=UUID other-config:disable_pv_vnc=true

before starting PV virtual machine, and you will be able to access console via xl console DOMID.

Other way is accessing console of currently running machine without prior reboot. This way may change in the future, so please check for updates on the xen-api mailing list. Also be careful as this methods disrupts normal XCP console access from management tools. So, beware and USE CAUTION (I repeat: you will not be able to connect to this consoles with OpenXenManager or XenCenter).

Serial Port 25 Pin

Also note this method is only available for PV guests with text consoles. It will not work for HVM and PV with framebuffer.

The basic idea is that VNCterm takes the text console and draws them in graphics. So, if we terminate the VNCterm associated with the guest console, we will be able to access text console (instead of VNCterm). Using QEMU to access guest terminals is also being discussed among the xapi developers.

Here simple script, doing all you need:

simply run it with uuid of machine you like to see and you will get access to console OR get message about which host it resides.

Note that the VNCterm sessions are setup by Xapi, which calls the vncterm-wrapper which then runs vncterm.

• http://community.citrix.com/display/ocb/2011/02/18/Using+VNC+to+Connect+to+a+XenServer+VM's+Console

◆Multiple Serial Ports
[Xen-changelog] [xen master] libxl: Allow multiple serial ports onHVM domain creation
http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00102.html

This patch allows an HVM domain to be created with multiple serial ports.

[Xen-changelog] [xen master] xl: Accept a list for serial in configfile
http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00103.html

Allow the 'serial' key to accept a list of serial ports, and pass them in using the new serial_list domain build element.

[Xen-changelog] [xen master] xl.cfg: add 'cmdline' in config file
http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00105.html

Currently in xl.cfg, use 'root' and 'extra' to generate the command line.

◆Other
[Xen-changelog] [xen master] xen: pass kernel initrd to qemu
http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00104.html

Direct kernel boot allows booting directly from a kernel and initrd
stored in the host physical machine OS, allowing command line arguments
to be passed directly. PV guest direct kernel boot is supported. HVM
guest direct kernel boot is supported with limitation (it's supported
when using qemu-xen and default BIOS 'seabios'; not supported in case of
stubdom-dm and old rombios.)

[Xen-changelog] [xen master] x86/hvm: treat non-instruction fetchnested page faults also as read violations

Serial Port Rs-232

Serial Port Function

http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00110.html

As pointed out by Jan Beulich in
http://lists.xen.org/archives/html/xen-devel/2014-08/msg01269.html:
'Read-modify-write instructions absolutely need to be treated as read
accesses, yet hardware doesn't guarantee to tell us so (they may
surface as just write accesses).' This patch addresses the issue in
both the VMX and the SVM side.
VMX: Treat all write data access violations also as read violations (in
addition to those that were already reported as read violations).
SVM: Refine the meaning of read data access violations to distinguish
between read/write and instruction fetch access violations.
With this patch both VMX and SVM specific nested page fault handling code
reports violations the same way, thus abstracting the hardware specific
behaviour from the layers above.

[Xen-changelog] [xen master] update pvSCSI protocol description
http://lists.xen.org/archives/html/xen-changelog/2014-08/msg00113.html

Update the protocol description of the pvSCSI framework used to pass through
SCSI devices to a guest (pv or hvm).
The main changes are:
- added comments
- add support for larger SG-lists by putting them in an own granted page
- deprecate VSCSIIF_ACT_SCSI_SG_PRESET action with related structures
- add ref_rqid for action VSCSIIF_ACT_SCSI_ABORT to be able to specify the
request to abort
- deprecate timeout_per_command as this really should be handled by the
backend in case of default settings or by the guest domain by aborting a
long running command
This update is related to the rework of the pvSCSI backend and frontend drivers
in the Linux kernel. This interface version is included in that rework, too.