HP BL680c XenEnterprise Management API - Page 12

VM Lifecycle, VM boot parameters

Get HP BL680c - ProLiant - G5 PDF manuals and user guides
UPC - 884420396314
View all HP BL680c manuals
Add to My Manuals
Save this manual to your list of manuals

Page 12 highlights

1.6. VM LIFECYCLE CHAPTER 1. INTRODUCTION powered down start(paused=true) paused start(paused=false) cleanShutdown / hardShutdown resume pause suspend resume(paused=true) running suspend resume(paused=false) suspended Figure 1.1: VM Lifecycle 1.6 VM Lifecycle Figure 1.1 shows the states that a VM can be in and the API calls that can be used to move the VM between these states. 1.7 VM boot parameters The VM class contains a number of fields that control the way in which the VM is booted. With reference to the fields defined in the VM class (see later in this document), this section outlines the boot options available and the mechanisms provided for controlling them. VM booting is controlled by setting one of the two mutually exclusive groups: "PV", and "HVM". If HVM.boot policy is the empty string, then paravirtual domain building and booting will be used; otherwise the VM will be loaded as an HVM domain, and booted using an emulated BIOS. When paravirtual booting is in use, the PV/bootloader field indicates the bootloader to use. It may be "pygrub", in which case the platform's default installation of pygrub will be used, or a full path within the control domain to some other bootloader. The other fields, PV/kernel, PV/ramdisk, PV/args and PV/bootloader args will be passed to the bootloader unmodified, and interpretation of those fields is then specific to the bootloader itself, including the possibility that the bootloader will ignore some or all of those given values. Finally the paths of all bootable disks are added to the bootloader commandline (a disk is bootable if its VBD has the bootable flag set). There may be zero, one or many bootable disks; the bootloader decides which disk (if any) to boot from. If the bootloader is pygrub, then the menu.lst is parsed if present in the guest's filesystem, otherwise the specified kernel and ramdisk are used, or an autodetected kernel is used if nothing is specified and autodetection is possible. PV/args is appended to the kernel command line, no matter which mechanism is used for finding the kernel. If PV/bootloader is empty but PV/kernel is specified, then the kernel and ramdisk values will be treated as paths within the control domain. If both PV/bootloader and PV/kernel are empty, then the behaviour is as if PV/bootloader was specified as "pygrub". When using HVM booting, HVM/boot policy and HVM/boot params specify the boot handling. 12

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
1.6. VM LIFECYCLE
CHAPTER 1. INTRODUCTION
powered down
paused
start(paused=true)
running
start(paused=false)
resume
suspended
suspend
cleanShutdown /
hardShutdown
pause
suspend
resume(paused=true)
resume(paused=false)
Figure 1.1: VM Lifecycle
1.6
VM Lifecycle
Figure 1.1 shows the states that a VM can be in and the API calls that can be used to move the
VM between these states.
1.7
VM boot parameters
The VM class contains a number of fields that control the way in which the VM is booted. With
reference to the fields defined in the VM class (see later in this document), this section outlines
the boot options available and the mechanisms provided for controlling them.
VM booting is controlled by setting one of the two mutually exclusive groups: “PV”, and “HVM”.
If HVM.boot
policy is the empty string, then paravirtual domain building and booting will be used;
otherwise the VM will be loaded as an HVM domain, and booted using an emulated BIOS.
When paravirtual booting is in use, the PV/bootloader field indicates the bootloader to use. It
may be “pygrub”, in which case the platform’s default installation of pygrub will be used, or
a full path within the control domain to some other bootloader.
The other fields, PV/kernel,
PV/ramdisk, PV/args and PV/bootloader
args will be passed to the bootloader unmodified, and
interpretation of those fields is then specific to the bootloader itself, including the possibility that
the bootloader will ignore some or all of those given values. Finally the paths of all bootable disks
are added to the bootloader commandline (a disk is bootable if its VBD has the bootable flag
set). There may be zero, one or many bootable disks; the bootloader decides which disk (if any)
to boot from.
If the bootloader is pygrub, then the menu.lst is parsed if present in the guest’s filesystem, otherwise
the specified kernel and ramdisk are used, or an autodetected kernel is used if nothing is specified
and autodetection is possible. PV/args is appended to the kernel command line, no matter which
mechanism is used for finding the kernel.
If PV/bootloader is empty but PV/kernel is specified, then the kernel and ramdisk values will be
treated as paths within the control domain.
If both PV/bootloader and PV/kernel are empty,
then the behaviour is as if PV/bootloader was specified as “pygrub”.
When using HVM booting, HVM/boot
policy and HVM/boot
params specify the boot handling.
12