[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 ?


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.