MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Remote_usage_of_the_Dell_console_switches",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "1548": {
                "pageid": 1548,
                "ns": 0,
                "title": "Rebooting XCP VMs the hard way",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "It could happen that a machine becomes unresponsive. Services appear down, sometimes ping still works but ssh doesn't. If the machine in question is a virtual machine, this guide will explain where the virtual power switch is and how to toggle it.\n\nThis guide strictly discusses the XCP cluster setup.\n\n== Step 1: find the host ==\n\nProduction machines run on the XCP pool 'piet', and logging in to the pool is done with\n ssh root@pool-piet.inst.ipmi.nikhef.nl\n\nThe XCP commands all start with 'xe'. On-line help is available by typing\n xe help --all\nand\n xe help <command>\n\nTo find the unresponsive host (called 'laars' for the sake of an example) type\n xe vm-list name-label=laars.nikhef.nl\n uuid ( RO)           : bc60eb6c-2d1c-4d24-18c5-38c1d525d5ea\n      name-label ( RW): laars.nikhef.nl\n     power-state ( RO): running\n\ntake note of the uuid; some commands require the uuid for reference.\n\n== Step 2: try the console ==\n\nMachines are configured with a serial console, and sometimes it is possible to log in even when other services fail.\n\n xe console name-label=laars.nikhef.nl\n\nIf this does not help, try a shutdown of the machine\n\n xe vm-shutdown name-label=laars.nikhef.nl\n\nfollowed (later) by a vm-start command.\n\nIn some cases the OOM killer has such a stranglehold over the system not even a shutdown comes through. In that case, the only way is a forced shutdown with a low-level command from the host where the VM is running.\n\n== Step 3: find the host of the VM ==\n\nList the parameters of the vm (use the UUID here):\n xe vm-param-list uuid=bc60eb6c-2d1c-4d24-18c5-38c1d525d5ea\n\nTake note of the 'resident-on' value (the uuid of the host) and the dom-id, e.g.\n resident-on ( RO): 7e6fe2e5-6d63-4865-8739-b50608a3e37a\n dom-id ( RO): 20\nFind the host with the host-list command\n\n xe host-list uuid=7e6fe2e5-6d63-4865-8739-b50608a3e37a\n uuid ( RO)                : 7e6fe2e5-6d63-4865-8739-b50608a3e37a\n           name-label ( RW): vms-piet-15.inst.ipmi.nikhef.nl\n     name-description ( RW): Default install of XenServer\n\nSo in this example vms-piet-15.inst.ipmi.nikhef.nl is where we have to log on.\n\n== Step 4: kill and resurrect the VM ==\n\nSsh to root@vms-piet-15.inst.ipmi.nikhef.nl and find the host\n\n xn list\n \n erf.nikhef.nl                                17   8192  2         Running \n tbn08.nikhef.nl                              19   2048  4         Running \n Control domain on host: vms-piet-15.inst.ipmi.nikhef.nl0    744   0          Running  \n laars.nikhef.nl                              20   8192  2         Running \n bosui.nikhef.nl                              18   2048  2         Running \n gasbel.nikhef.nl                             15   2048  1         Running \n\nKill the host\n /opt/xensource/debug/destroy_domain -domid 20\n\nTo resurrect, the host can be restarted again with the high-level xe commands. '''However...''' sometimes the virtual block device remains locked, and the host won't restart.\n\n== Step 5: forget the virtual disk, and find it again ==\n\nIn case the VM won't restart, the VDIs (virtual disk images) that were attached to the machine need to be reset. The command 'vdi-forget' will make XCP forget all about a VDI,\nincluding that it was ever associated with a VM! So note the UUID of the VDI and of the storage repository (SR) before forgetting it.\n\n vmname=tbn05.nikhef.nl\n xe vm-disk-list name-label=$vmname\nNote the VDI(s), and their SRs. '''Store this information for later reference.'''\n vmuuid=`xe vm-list name-label=$vmname | sed -n 's/^uuid.*: \\(.*\\)$/\\1/p'`\n vbduuid=`xe vbd-list vm-name-label=$vmname | sed -n 's/^uuid.*: \\(.*\\)$/\\1/p'`\n vdiuuid=`xe vbd-list vm-name-label=$vmname | sed -n 's/.*vdi-uuid.*: \\(.*\\)$/\\1/p'`\n sruuid=`xe vdi-list uuid=$vdiuuid | sed -n 's/.*sr-uuid.*: \\(.*\\)$/\\1/p'`\n xe vdi-forget uuid=$vdiuuid\n\nPerform a rescan of the SR to make the VDI available again.\n\n xe sr-scan uuid=<UUID-of-SR>\n\nThis step may complain about not being able to deactivate the SR because it is shared. But the\nnext step seems to work anyway.\n\nRe-add the VDI to the VM.\n\n vbduuid=`xe vbd-create vdi-uuid=$vdiuuid device=1 vm-uuid=$vmuuid`\n\nThe 'device' is one of the allowed vbd device numbers which can be obtained from\n xe vm-param-get param-name=allowed-VBD-devices uuid=$vmuuid\nbut unless the machine has more than one disk, this is usually just '1'.\n\nIt might be necessary to set the bootable flag on the block device.\n\n xe vbd-param-set uuid=$vbduuid bootable=true\n\nThen start the machine and cross fingers\n\n xe vm-start uuid=$vmuuid\n\n\n'''Note''' there is a command vdi-unlock, don't know if it works."
                    }
                ]
            },
            "1088": {
                "pageid": 1088,
                "ns": 0,
                "title": "Remote Location",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "= The remote location =\n\n= Hardware =\n\nCavia.nikhefhousing.nl: Dell Poweredge 1950, 2x Intel E5440, 16GB ram, 1TB raid 1\n          IP: 195.140.241.226, IP intern: 10.250.0.1, IPMI: 10.250.0.11, OpenVPN 10.250.0.20 t/m 39\n\nKonijn.nikhefhousing.nl: Dell Poweredge 1950, 2x Intel E5440, 16GB ram, 1TB raid 1\n          IP: 195.140.241.227, IP intern: 10.250.0.2, IPMI: 10.250.0.12, OpenVPN 10.250.0.40 t/m 59"
                    }
                ]
            }
        }
    }
}