Difference between revisions of "GSP Virtualisation with Xen"
From PDP/Grid Wiki
Jump to navigationJump to search (Add how to boot from DVD iso image.) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 378: | Line 378: | ||
See [http://support.citrix.com/article/CTX121875 http://support.citrix.com/article/CTX121875]. | See [http://support.citrix.com/article/CTX121875 http://support.citrix.com/article/CTX121875]. | ||
| + | |||
| + | The page suggests to manually create an initrd file with the Xen drivers (and minus the SCSI drivers). This needs some explaining. | ||
| + | |||
| + | The normal process when installing a kernel is that the initrd is populated with whatever is relevant for the ''current'' context of the system. So a system that is not running paravirtualized will normally not install an initrd with Xen drivers. Also, the Grub menu settings are weird, containing a 'kernel' that points to a xen.gz file and 'modules' for the real kernel and initrd. These must be edited to look like ordinary entries. The default entry number must be set to 0, to use the Xen kernel at next boot. | ||
| + | |||
| + | Manually creating an initrd is a maintenance nightmare, but once the system is running paravirtualized, subsequent kernel upgrades will generate the correct initrd automatically so this is a one-time action only. | ||
== Wrong VM type - or resetting the boot loader == | == Wrong VM type - or resetting the boot loader == | ||
| Line 645: | Line 651: | ||
* the /var/patches/applied files will result in the "updates" field in XenCenter being updated. This window will also show the reboot-required status if the patches/applied meta-data so indicates | * the /var/patches/applied files will result in the "updates" field in XenCenter being updated. This window will also show the reboot-required status if the patches/applied meta-data so indicates | ||
* reboot nodes if needed (rotating and moving VMs as needed) | * reboot nodes if needed (rotating and moving VMs as needed) | ||
| + | |||
| + | |||
| + | == Connecting to the graphical console of a VM via VNC == | ||
| + | |||
| + | When a VM becomes unreachable, but is still running, as a last resort one could try to connect to the graphical console that every machine still has. It's nicely tucked away in the innards of XenServer, but the following little script should help. It's available on pool-piet.inst.ipmi.nikhef.nl as connect-to-vm-console.sh. | ||
| + | |||
| + | #!/bin/sh | ||
| + | |||
| + | # locate the host with the graphical console for the given vm | ||
| + | # find the vnc port and connect the vnc viewer | ||
| + | |||
| + | vm="$1" | ||
| + | |||
| + | vmuuid=`xe vm-list name-label="$1" --minimal` | ||
| + | |||
| + | if [ -z $vmuuid ]; then | ||
| + | echo "Could not find VM named $vm" >&2 | ||
| + | exit 1 | ||
| + | fi | ||
| + | |||
| + | residenton=`xe vm-param-get uuid=$vmuuid param-name=resident-on` | ||
| + | |||
| + | residenthost=`xe host-list uuid=$residenton params=name-label --minimal` | ||
| + | |||
| + | vncport=`ssh $residenthost xn console-list $vm | awk '$1 == "RFB" { print $2 }'` | ||
| + | |||
| + | if [ -z $vncport ]; then | ||
| + | echo "Could not find VNC console for $vm" | ||
| + | exit 1 | ||
| + | fi | ||
| + | |||
| + | echo "Issue the following command from your workstation: | ||
| + | |||
| + | ssh -L 5901:localhost:$vncport -f -N root@$residenthost | ||
| + | vncviewer localhost:5901 | ||
| + | " | ||
