Cannot destroy a domain created with Xen-API

Cannot destroy a domain created with Xen-API

[Jacek Konieczny]

Hello,

I use Xen-API to manage may virtual machines. But sometimes something
goes wrong and I gen an undestroyable VM.

"xm list" shows no domain id for this virtual machine, so, I guess, it
doesn't take hardware resources.

# xm list
Name                                      ID   Mem VCPUs      State   Time(s)
Domain-0                                   0   459     4     r-----    508.0
vm-1                                           160     1                 0.3

That seems normal for any domain which is created with Xen-API and not running. 

But a "normal" domain can be destroyed with Xen-API  VM.destroy() call.  When
xm is configured to use Xen-API it shows:

# xm list
Name                                      ID   Mem VCPUs      State   Time(s)
Domain-0                                   0   459     4     r-----      0.0
vm-1                                    -1     0     0     ------      0.0
# xm destroy vm-1
# xm list
Name                                      ID   Mem VCPUs      State   Time(s)
Domain-0                                   0   459     4     r-----      0.0
vm-1                                    -1     0     0     ------      0.0

The same with my own test script:

Logging-in to the Xen-API server... OK
Calling VM.get_by_name_label(session, 'vm-1')... got: vms=['792ef852-0998-997d-2702-7f77446a0404']
Calling VM.get_record(session, '792ef852-0998-997d-2702-7f77446a0404')... got:
  {'PV_args': '/dev/hda2 ro', 'VIFs': ['f4e3293f-6788-9d4d-531f-c0d1a58e2ed5'],
  'PV_bootloader': '', 'VTPMs': [], 'domid': '-1', 'name_description': 'vm-1',
  'PCI_bus': '', 'actions_after_crash': 'preserve', 'uuid':
  '792ef852-0998-997d-2702-7f77446a0404', 'PV_ramdisk':
  '/etc/vm/images/1.3r5136/initramfs.cpio', 'is_control_domain': False,
  'name_label': 'vm-1', 'VCPUs_at_startup': '1', 'HVM_boot_params': {},
  'platform': {'rtc_timeoffset': '0'}, 'PV_kernel':
  '/etc/vm/images/1.3r5136/vmlinuz', 'power_state': 'Halted', 'VCPUs_params':
  {}, 'memory_static_min': '167772160', 'HVM_boot_policy': '', 'VCPUs_max': '1',
  'memory_static_max': '167772160', 'actions_after_shutdown': 'restart',
  'tools_version': {}, 'metrics': '21a3141e-bafc-bcad-3ac7-6357ec34b932',
  'memory_dynamic_max': '167772160', 'user_version': '1',
  'actions_after_suspend': 'restart', 'is_a_template': False,
  'memory_dynamic_min': '167772160', 'PV_bootloader_args': '', 'other_config':
  {}, 'auto_power_on': False, 'consoles':
  ['0e750b42-a6fd-2b5f-0805-d1133af28452'], 'actions_after_reboot': 'restart',
  'resident_on': '06109400-eef7-e403-d0ab-86a676244ab9', 'VBDs':
  ['85bacdde-24bd-f228-d947-f7ca18f4868f',
  '97d740e5-2184-52a8-5fa6-69b14e543b60',
  '550142de-480b-0d13-3d60-409c14154ee4']}
Calling VM.destroy(session, '792ef852-0998-997d-2702-7f77446a0404')... OK
Calling VM.get_by_name_label(session, 'vm-1')... got: vms=['792ef852-0998-997d-2702-7f77446a0404']
Calling VM.get_record(session, '792ef852-0998-997d-2702-7f77446a0404')... got:
  {'PV_args': '/dev/hda2 ro', 'VIFs': ['f4e3293f-6788-9d4d-531f-c0d1a58e2ed5'],
  'PV_bootloader': '', 'VTPMs': [], 'domid': '-1', 'name_description': 'vm-1',
  'PCI_bus': '', 'actions_after_crash': 'preserve', 'uuid':
  '792ef852-0998-997d-2702-7f77446a0404', 'PV_ramdisk':
  '/etc/vm/images/1.3r5136/initramfs.cpio', 'is_control_domain': False,
  'name_label': 'vm-1', 'VCPUs_at_startup': '1', 'HVM_boot_params': {},
  'platform': {'rtc_timeoffset': '0'}, 'PV_kernel':
  '/etc/vm/images/1.3r5136/vmlinuz', 'power_state': 'Halted', 'VCPUs_params':
  {}, 'memory_static_min': '167772160', 'HVM_boot_policy': '', 'VCPUs_max': '1',
  'memory_static_max': '167772160', 'actions_after_shutdown': 'restart',
  'tools_version': {}, 'metrics': '21a3141e-bafc-bcad-3ac7-6357ec34b932',
  'memory_dynamic_max': '167772160', 'user_version': '1',
  'actions_after_suspend': 'restart', 'is_a_template': False,
  'memory_dynamic_min': '167772160', 'PV_bootloader_args': '', 'other_config':
  {}, 'auto_power_on': False, 'consoles':
  ['0e750b42-a6fd-2b5f-0805-d1133af28452'], 'actions_after_reboot': 'restart',
  'resident_on': '06109400-eef7-e403-d0ab-86a676244ab9', 'VBDs':
  ['85bacdde-24bd-f228-d947-f7ca18f4868f',
  '97d740e5-2184-52a8-5fa6-69b14e543b60',
  '550142de-480b-0d13-3d60-409c14154ee4']}


How can I get rid of such domain without rebooting the machine or restarting xend? 

Greets,
        Jacek

More info on 'Cannot destroy a domain created with Xen-API'

[Jacek Konieczny]

On Wed, Jul 04, 2007 at 01:50:56PM +0200, Jacek Konieczny wrote:
> Hello,
> 
> I use Xen-API to manage may virtual machines. But sometimes something
> goes wrong and I gen an undestroyable VM.

Now I know exactly when it happens. I had 'actions_after_shutdown' 
for the virtual machines set to 'preserve'. When such domain where
halted withing guest system, it got power_state='Halted', but it still
had a domain_id set. When such domain is destroyed with Xen-API
VM.destroy() call, then some cleanup is missing and the domain stays in
Xend forever, taking some resources (like loop devices).

If I call VM.hard_shutdown() before VM.destroy() (no matter if guest OS
was running or halted), then the problem doesn't occur -- the VM is
destroyed completely. If I don't call hard_shutdown() then VM.destroy()
fails to fully do its job.

Greets,
        Jacek