xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Glenn Enright <glenn@rimuhosting.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>,
	xen-devel@lists.xen.org
Cc: Juergen Gross <jgross@suse.com>
Subject: Re: null domains after xl destroy
Date: Wed, 12 Apr 2017 10:45:31 +1200	[thread overview]
Message-ID: <05cd7b43-153a-8b51-8fd9-e8ae4a8b5287@rimuhosting.com> (raw)
In-Reply-To: <6e150a33-576b-5cf8-7abc-2cba584602ff@citrix.com>

On 12/04/17 10:23, Andrew Cooper wrote:
> On 11/04/2017 23:13, Glenn Enright wrote:
>> On 11/04/17 21:49, Dietmar Hahn wrote:
>>> Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
>>>> On 11/04/17 17:59, Juergen Gross wrote:
>>>>> On 11/04/17 07:25, Glenn Enright wrote:
>>>>>> Hi all
>>>>>>
>>>>>> We are seeing an odd issue with domu domains from xl destroy, under
>>>>>> recent 4.9 kernels a (null) domain is left behind.
>>>>>
>>>>> I guess this is the dom0 kernel version?
>>>>>
>>>>>> This has occurred on a variety of hardware, with no obvious
>>>>>> commonality.
>>>>>>
>>>>>> 4.4.55 does not show this behavior.
>>>>>>
>>>>>> On my test machine I have the following packages installed under
>>>>>> centos6, from https://xen.crc.id.au/
>>>>>>
>>>>>> ~]# rpm -qa | grep xen
>>>>>> xen47-licenses-4.7.2-4.el6.x86_64
>>>>>> xen47-4.7.2-4.el6.x86_64
>>>>>> kernel-xen-4.9.21-1.el6xen.x86_64
>>>>>> xen47-ocaml-4.7.2-4.el6.x86_64
>>>>>> xen47-libs-4.7.2-4.el6.x86_64
>>>>>> xen47-libcacard-4.7.2-4.el6.x86_64
>>>>>> xen47-hypervisor-4.7.2-4.el6.x86_64
>>>>>> xen47-runtime-4.7.2-4.el6.x86_64
>>>>>> kernel-xen-firmware-4.9.21-1.el6xen.x86_64
>>>>>>
>>>>>> I've also replicated the issue with 4.9.17 and 4.9.20
>>>>>>
>>>>>> To replicate, on a cleanly booted dom0 with one pv VM, I run the
>>>>>> following on the VM
>>>>>>
>>>>>> {
>>>>>> while true; do
>>>>>>  dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
>>>>>> done
>>>>>> }
>>>>>>
>>>>>> Then on the dom0 I do this sequence to reliably get a null domain.
>>>>>> This
>>>>>> occurs with oxenstored and xenstored both.
>>>>>>
>>>>>> {
>>>>>> xl sync 1
>>>>>> xl destroy 1
>>>>>> }
>>>>>>
>>>>>> xl list then renders something like ...
>>>>>>
>>>>>> (null)                                       1     4     4     --p--d
>>>>>> 9.8     0
>>>>>
>>>>> Something is referencing the domain, e.g. some of its memory pages are
>>>>> still mapped by dom0.
>>>
>>> You can try
>>> # xl debug-keys q
>>> and further
>>> # xl dmesg
>>> to see the output of the previous command. The 'q' dumps domain
>>> (and guest debug) info.
>>> # xl debug-keys h
>>> prints all possible parameters for more informations.
>>>
>>> Dietmar.
>>>
>>
>> I've done this as requested, below is the output.
>>
>> <snip>
>> (XEN) Memory pages belonging to domain 1:
>> (XEN)     DomPage 0000000000071c00: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c01: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c02: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c03: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c04: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c05: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c06: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c07: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c08: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c09: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0a: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0b: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0c: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0d: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0e: caf=00000001, taf=7400000000000001
>> (XEN)     DomPage 0000000000071c0f: caf=00000001, taf=7400000000000001
>
> There are 16 pages still referenced from somewhere.
>
> Can you grab all of `xenstore-ls -f` in dom0?  There is probably a
> backend still attached.
>
> ~Andrew
>

Note this is under oxenstored presently.

# xenstore-ls -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/control = ""
/local/domain/0/control/feature-poweroff = "1"
/local/domain/0/control/feature-reboot = "1"
/local/domain/0/control/feature-suspend = "1"
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/vm = ""
/libxl = ""

# xl list
Name                                        ID   Mem VCPUs      State 
Time(s)
Domain-0                                     0  1512     2     r----- 
   35.0
(null)                                       1     8     4     --p--d 
    8.5

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

  reply	other threads:[~2017-04-11 22:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11  5:25 null domains after xl destroy Glenn Enright
2017-04-11  5:59 ` Juergen Gross
2017-04-11  8:03   ` Glenn Enright
2017-04-11  9:49     ` Dietmar Hahn
2017-04-11 22:13       ` Glenn Enright
2017-04-11 22:23         ` Andrew Cooper
2017-04-11 22:45           ` Glenn Enright [this message]
2017-04-18  8:36             ` Juergen Gross
2017-04-19  1:02               ` Glenn Enright
2017-04-19  4:39                 ` Juergen Gross
2017-04-19  7:16                   ` Roger Pau Monné
2017-04-19  7:35                     ` Juergen Gross
2017-04-19 10:09                     ` Juergen Gross
2017-04-19 16:22                       ` Steven Haigh
2017-04-21  8:42                         ` Steven Haigh
2017-04-21  8:44                           ` Juergen Gross
2017-05-01  0:55                       ` Glenn Enright
2017-05-03 10:45                         ` Steven Haigh
2017-05-03 13:38                           ` Juergen Gross
2017-05-03 15:53                           ` Juergen Gross
2017-05-03 16:58                             ` Steven Haigh
2017-05-03 22:17                               ` Glenn Enright
2017-05-08  9:10                                 ` Juergen Gross
2017-05-09  9:24                                   ` Roger Pau Monné
2017-05-13  4:02                                     ` Glenn Enright
2017-05-15  9:57                                       ` Juergen Gross
2017-05-16  0:49                                         ` Glenn Enright
2017-05-16  1:18                                           ` Steven Haigh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=05cd7b43-153a-8b51-8fd9-e8ae4a8b5287@rimuhosting.com \
    --to=glenn@rimuhosting.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dietmar.hahn@ts.fujitsu.com \
    --cc=jgross@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).