Re: [Xen-devel] [PATCH 5/6] tools/libxl: Allow dom0 to be destroyed

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 03/05/2014 07:02 AM, Ian Jackson wrote:
> Daniel De Graaf writes ("[PATCH 5/6] tools/libxl: Allow dom0 to be destroyed"):
> > When dom0 is not the hardware domain, it can be destroyed in the same
> > way as any other service domain. Since the hypervisor already prevents a
> > domain from destroying itself, this patch only changes behavior when
> > used in a disaggregated environment.
> Thanks for this patch.  You must be doing something very interesting
> to want this :-).
>
> I have a concern though: I wonder what the error behaviour is in the
> case where you try to destroy dom0 from itself.  Does it get halfway
> through, breaking the system, and then fail ?
>
> Ian.
It gets partway though, with the most important (bad) action being the
removal of /local/domain/0 from xenstore succeeds. Testing on my
development system to destroy a hardware domain (domid 3) from itself:

# xl destroy 3
libxl: error: libxl.c:1411:libxl__destroy_domid: xc_domain_pause failed for 3
libxl: error: libxl_device.c:894:device_backend_callback: unable to remove 
device with path /local/domain/8/backend/vtpm/3/0
libxl: error: libxl.c:1451:devices_destroy_cb: libxl__devices_destroy failed 
for 3
libxl: error: libxl.c:1456:devices_destroy_cb: xs_rm failed for /vm/3: No such 
file or directory
libxl: error: libxl.c:1471:devices_destroy_cb: xc_domain_destroy failed for 3
libxl: error: libxl.c:1342:domain_destroy_callback: unable to destroy guest 
with domid 3
libxl: error: libxl.c:1269:domain_destroy_cb: destruction of domain 3 failed
destroy failed (rc=-3)
# xl li
Name                                        ID   Mem VCPUs      State   Time(s)
xenstore                                     1    20     1     -b----       2.9
vtpm-mgr                                     2     5     1     -b----       3.2
(null)                                       3   489     1     r-----    9308.7
db-server                                    4    16     1     -b----       1.7
vtpm-os                                      5     5     1     -b----       2.4
ctl                                          6     4     1     -b----       0.3
os-ctl                                       7  5000     1     -b----   72923.1
vtpm-hw                                      8     5     1     -b----       2.3
(The domain with ID 0 was already destroyed during bootup).

The system still works after this, although I would expect possible
issues to come up if I were to do if{up,down} on a guest or take other
actions that cause Linux to read xenstore keys.  If a domain were being
started up during the destroy, it would become broken.

In reply to both this and Jan's earlier email:
> So this gets deleted without replacement? How is the hardware
> domain being protected from (accidental or malicious) deletion
> then? Even if this is being dealt with in the hypervisor, I'd be
> afraid of the failure resulting in a cryptic error message instead
> of the very clear one above.
The existing check seems to be a useful guard against accidentally
breaking parts of a running system.  Would requiring a -f flag on the
destroy operation to work on domain 0 be preferable?


--
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel