Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Thanks very much, it turns out to be the problem of modules.conf. I turn
the xen module off for mistake, I'm very sorry for the time you spend.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] unable to create domain after enabling XSM

[Konrad Rzeszutek Wilk]

On Tue, May 17, 2016 at 04:58:03PM +0800, Big Strong wrote:
> I should add the xsm=policy option to the end of the xen.cfg instead of as
> an option. Sorry for the fault.
> 
> However, another problem is that when I modified the policy and reload it
> using '*xl loadpolicy*', the policy seemed not working.
> 
> The policy I add is *'allow domU_t security_t:security check_context; allow
> domU_t domU_t_self:hvm gethvmc;*', and it is successfully loaded.
> 
> But executing XEN_DOMCTL_gethvmcontext_partial in domU_t would still cause
> the following violations:
> 
> *(XEN) avc:  denied  { gethvmc } for domid=1
> scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
> tclass=hvm*
> 
> Rebooting xen with the new policy doesn't work too. BTW, the domU_t I
> created is a HVM, I hope that is not the problem.

Rebootin meaning you put the policy on the boot partition and your xen.cfg
has xsm=?

And it loads the policy? You can see that Xen has loaded it?

I am going to assume that the policy is loaded just fine - it just that the
policy you wrote is not doing what it is expected.

And oddly enough, you did not CC the XSM maintainer here. He may
be able to help.

> 
> 2016-05-17 16:33 GMT+08:00 Jan Beulich :
> 
> > >>> On 16.05.16 at 17:00,  wrote:
> > > Actually I did that, but the policy is not loaded at all. 'xl list -Z'
> > show
> > > no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0'
> > is
> > > ingnored during booting. (the policy file is moved to the same directory
> > as
> > > xen.cfg)
> >
> > If you suspect it to be ignored, then please provide logs so we
> > can identify _where_ it gets ignored: The early EFI loader should
> > be pulling it into memory (note that the respective messages will
> > only be visible in a serial log if you also enable serial output for
> > EFI itself), and then XSM should be consuming it. Which of the
> > two goes wrong would be quite helpful to know, the more that it
> > looks like this works for others (e.g. Konrad).
> >
> > Jan
> >
> >

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

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

I should add the xsm=policy option to the end of the xen.cfg instead of as
an option. Sorry for the fault.

However, another problem is that when I modified the policy and reload it
using '*xl loadpolicy*', the policy seemed not working.

The policy I add is *'allow domU_t security_t:security check_context; allow
domU_t domU_t_self:hvm gethvmc;*', and it is successfully loaded.

But executing XEN_DOMCTL_gethvmcontext_partial in domU_t would still cause
the following violations:

*(XEN) avc:  denied  { gethvmc } for domid=1
scontext=system_u:system_r:domU_t tcontext=system_u:system_r:domU_t_self
tclass=hvm*

Rebooting xen with the new policy doesn't work too. BTW, the domU_t I
created is a HVM, I hope that is not the problem.

2016-05-17 16:33 GMT+08:00 Jan Beulich :

> >>> On 16.05.16 at 17:00,  wrote:
> > Actually I did that, but the policy is not loaded at all. 'xl list -Z'
> show
> > no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0'
> is
> > ingnored during booting. (the policy file is moved to the same directory
> as
> > xen.cfg)
>
> If you suspect it to be ignored, then please provide logs so we
> can identify _where_ it gets ignored: The early EFI loader should
> be pulling it into memory (note that the respective messages will
> only be visible in a serial log if you also enable serial output for
> EFI itself), and then XSM should be consuming it. Which of the
> two goes wrong would be quite helpful to know, the more that it
> looks like this works for others (e.g. Konrad).
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] unable to create domain after enabling XSM

[Jan Beulich]

>>> On 16.05.16 at 17:00,  wrote:
> Actually I did that, but the policy is not loaded at all. 'xl list -Z' show
> no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0' is
> ingnored during booting. (the policy file is moved to the same directory as
> xen.cfg)

If you suspect it to be ignored, then please provide logs so we
can identify _where_ it gets ignored: The early EFI loader should
be pulling it into memory (note that the respective messages will
only be visible in a serial log if you also enable serial output for
EFI itself), and then XSM should be consuming it. Which of the
two goes wrong would be quite helpful to know, the more that it
looks like this works for others (e.g. Konrad).

Jan


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

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Actually I did that, but the policy is not loaded at all. 'xl list -Z' show
no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0' is
ingnored during booting. (the policy file is moved to the same directory as
xen.cfg)

2016-05-16 21:43 GMT+08:00 Konrad Rzeszutek Wilk :

> On Mon, May 16, 2016 at 10:43:49AM +0100, Andrew Cooper wrote:
> > On 16/05/16 09:54, Big Strong wrote:
> > > Problem solved by booting xen with grub instead of efi. The deep
> > > reason is unknown.
> >
> > Ah - that is very useful to know, and now obvious.  EFI has no concept
> > of modules, which probably means the XSM policy doesn't get loaded.
>
> It does. You just add in xen.cfg:
> [konrad@x230 efi]$ more xen.cfg
> [global]
> default=xtt
>
> [xtt]
> options=console=com1,vga com1=115200,8n1 loglvl=all guest_loglvl=all
> kernel=vmlinuz console=hvc0
> ramdisk=initramfs.cpio.gz
> xsm=xenpolicy
>
> The 'xsm' attribute.
> ?
> >
> > FWIW, there is a plan to change how XSM policies are done in the future,
> > by embedding the policy at build time.
> >
> > ~Andrew
>
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] unable to create domain after enabling XSM

[Konrad Rzeszutek Wilk]

On Mon, May 16, 2016 at 10:43:49AM +0100, Andrew Cooper wrote:
> On 16/05/16 09:54, Big Strong wrote:
> > Problem solved by booting xen with grub instead of efi. The deep
> > reason is unknown.
> 
> Ah - that is very useful to know, and now obvious.  EFI has no concept
> of modules, which probably means the XSM policy doesn't get loaded.

It does. You just add in xen.cfg:
[konrad@x230 efi]$ more xen.cfg 
[global]
default=xtt

[xtt]
options=console=com1,vga com1=115200,8n1 loglvl=all guest_loglvl=all
kernel=vmlinuz console=hvc0
ramdisk=initramfs.cpio.gz
xsm=xenpolicy

The 'xsm' attribute.
?
> 
> FWIW, there is a plan to change how XSM policies are done in the future,
> by embedding the policy at build time.
> 
> ~Andrew

> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


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

Re: [Xen-devel] unable to create domain after enabling XSM

[Andrew Cooper]

On 16/05/16 09:54, Big Strong wrote:
> Problem solved by booting xen with grub instead of efi. The deep
> reason is unknown.

Ah - that is very useful to know, and now obvious.  EFI has no concept
of modules, which probably means the XSM policy doesn't get loaded.

FWIW, there is a plan to change how XSM policies are done in the future,
by embedding the policy at build time.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Problem solved by booting xen with grub instead of efi. The deep reason is
unknown.

2016-05-16 11:08 GMT+08:00 Big Strong :

> As you suggested, I used xen 4.7.0-rc2 to test it again and the problem
> still exists.
>
> $ sudo xl create xen-config/win7
>> Parsing config from xen-config/win7
>> libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
>> device with path /local/domain/0/backend/vbd/1/51712
>> libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add disk
>> devices
>> libxl: error: libxl_device.c:1033:device_backend_callback: unable to
>> remove device with path /local/domain/0/backend/vbd/1/51712
>> libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
>> failed for 1
>> libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
>> libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
>> guest with domid 1
>> libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1
>> failed
>
>
> Denied behaviors:
>
> ~$ sudo xl dmesg | grep avc
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>> (XEN) avc:  denied  { send } for domid=0
>> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:dom0_t
>> tclass=event
>
>
> Corresponding rules:
>
> ~$ sudo xl dmesg | grep avc | audit2allow
>> #= dom0_t ==
>> allow dom0_t self:event send;
>
>
> When I tried to add this rule to xen.te, it says
>
> libsepol.check_assertion_helper: neverallow on line 2023 violated by allow
>> dom0_t dom0_t:event { send };
>>
>
> So I comment the following restriction in policy.conf and recompile flask
> policy with the new rule added.
>
> neverallow * ~event_type:event { create send status };
>
>
> This time no rule violations are generated by checking 'xl dmesg| grep
> avc', but the errors in the very first place when creating domU (both hvm
> and pv, with or without seclabel) still exist.
>
> Basic info of xen configuration:
>
> $ sudo xl info
>> host   : storage
>> release: 3.19.0
>> version: #1 SMP Tue Dec 8 09:27:36 CST 2015
>> machine: x86_64
>> nr_cpus: 6
>> max_cpu_id : 143
>> nr_nodes   : 1
>> cores_per_socket   : 6
>> threads_per_core   : 1
>> cpu_mhz: 1600
>> hw_caps:
>> b7ebfbff:77fef3ff:2c100800:0021:0001:37ab:
>>
>>:0100
>> virt_caps  : hvm hvm_directio
>> total_memory   : 32667
>> free_memory: 24046
>> sharing_freed_memory   : 0
>> sharing_used_memory: 0
>> outstanding_claims : 0
>> free_cpus  : 0
>> xen_major  : 4
>> xen_minor  : 7
>> xen_extra  : .0-rc
>> 

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

As you suggested, I used xen 4.7.0-rc2 to test it again and the problem
still exists.

$ sudo xl create xen-config/win7
> Parsing config from xen-config/win7
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add disk
> devices
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
> failed for 1
> libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
> libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
> guest with domid 1
> libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1
> failed


Denied behaviors:

~$ sudo xl dmesg | grep avc
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event


Corresponding rules:

~$ sudo xl dmesg | grep avc | audit2allow
> #= dom0_t ==
> allow dom0_t self:event send;


When I tried to add this rule to xen.te, it says

libsepol.check_assertion_helper: neverallow on line 2023 violated by allow
> dom0_t dom0_t:event { send };
>

So I comment the following restriction in policy.conf and recompile flask
policy with the new rule added.

neverallow * ~event_type:event { create send status };


This time no rule violations are generated by checking 'xl dmesg| grep
avc', but the errors in the very first place when creating domU (both hvm
and pv, with or without seclabel) still exist.

Basic info of xen configuration:

$ sudo xl info
> host   : storage
> release: 3.19.0
> version: #1 SMP Tue Dec 8 09:27:36 CST 2015
> machine: x86_64
> nr_cpus: 6
> max_cpu_id : 143
> nr_nodes   : 1
> cores_per_socket   : 6
> threads_per_core   : 1
> cpu_mhz: 1600
> hw_caps:
> b7ebfbff:77fef3ff:2c100800:0021:0001:37ab:
>
>:0100
> virt_caps  : hvm hvm_directio
> total_memory   : 32667
> free_memory: 24046
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 7
> xen_extra  : .0-rc
> xen_version: 4.7.0-rc
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-
>  x86_32p
> hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> 

Re: [Xen-devel] unable to create domain after enabling XSM

[Andrew Cooper]

On 15/05/16 15:25, Big Strong wrote:
> Hi,
>
> I've configured xen 4.6.0 with xsm enabled and use the default flask
> policy to boot the dom0.

For issues like this, please always use the latest stable branch, in
this case making that Xen 4.6.1+.  It is entirely possible that bugfixes
have been backported.

In this case, can you try current master (or 4.7.0-rc2)? Some of these
errors have definitely been fixed in the 4.7 dev period.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Hi,

I've configured xen 4.6.0 with xsm enabled and use the default flask policy
to boot the dom0.
However, when I tried to create a domU, it will fail for following reasons:

>
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  granted  { load_policy } for domid=0
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:security_t
> tclass=security
> (XEN) avc:  granted  { load_policy } for domid=0
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:security_t
> tclass=security


So I added following rules to xen.te, which is achived by 'sudo xl dmesg |
grep avc | audit2allow'

>
> allow dom0_t xen_t:domain getdomaininfo;
> allow dom0_t xen_t:event send;
> allow dom0_t xen_t:grant copy;
> allow dom0_t xen_t:hvm { trackdirtyvram irqlevel };
> allow dom0_t xen_t:domain { destroy pause };
> allow dom0_t self:event send;


And recompiled the flask policy and load it using 'xl loadpolicy', however,
the creation of domU (both hvm and pv, with or without seclable) will still
fail for the following reasons, even though there are no avc violations.

$ sudo xl create ~/xen-config/ubuntu-hvm3
> Parsing config from /home/john/xen-config/ubuntu-hvm
> libxl: error: libxl_device.c:952:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/5/51712
> libxl: error: libxl_device.c:952:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/5/5632
> libxl: error: libxl_create.c:1174:domcreate_launch_dm: unable to add disk
> devices
> libxl: error: libxl_dm.c:1956:kill_device_model: unable to find device
> model pid in /local/domain/5/image/device-model-pid
> libxl: error: libxl.c:1628:libxl__destroy_domid:
> libxl__destroy_device_model failed for 5
> libxl: error: libxl_device.c:952:device_backend_callback: unable to remove
> device with path /local/domain/0/backend/vbd/5/51712
> libxl: error: libxl_device.c:952:device_backend_callback: unable to remove
> device with path /local/domain/0/backend/vbd/5/5632
> libxl: error: libxl.c:1665:devices_destroy_cb: libxl__devices_destroy
> failed for 5
> libxl: error: libxl.c:1591:libxl__destroy_domid: non-existant domain 5
> libxl: error: libxl.c:1549:domain_destroy_callback: unable to destroy
> guest with domid 5
> libxl: error: libxl.c:1476:domain_destroy_cb: destruction of domain 5
> failed


When the xsm is disabled, the creation succeed. What are these errors mean
anyway?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel