[TestDay] xen 4.4 FC3 xl create error

[TestDay] xen 4.4 FC3 xl create error

[Eric Houby]

Xen list,

I have a clean F20 install with the RC3 RPMs and see an error when
starting a VM.  A similar issue was seen with the RC2 RPMs.


[root@xen ~]# xl create f20.xl
Parsing config from f20.xl
libxl: error: libxl_create.c:1054:domcreate_launch_dm: unable to add
disk devices
libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device
model pid in /local/domain/2/image/device-model-pid
libxl: error: libxl.c:1425:libxl__destroy_domid:
libxl__destroy_device_model failed for 2
libxl: error: libxl_device.c:780:libxl__initiate_device_remove: unable
to get my domid
libxl: error: libxl.c:1461:devices_destroy_cb: libxl__devices_destroy
failed for 2
[root@xen ~]# 
[root@xen ~]# /usr/bin/xenstore-write "/local/domain/0/domid" 0
[root@xen ~]# 
[root@xen ~]# xl create f20.xl
Parsing config from f20.xl
[root@xen ~]# 
[root@xen ~]# 
[root@xen ~]# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0  2047     2     r-----
19.7
f20                                          3  4095     1     r-----
4.1


After running the xenstore-write command VMs start up without issue.

Thanks,

Eric

Re: [TestDay] xen 4.4 FC3 xl create error

[Ian Campbell]

On Tue, 2014-02-04 at 08:26 -0700, Eric Houby wrote:
> Xen list,
> 
> I have a clean F20 install with the RC3 RPMs and see an error when
> starting a VM.  A similar issue was seen with the RC2 RPMs.

Thanks for the report.

> [root@xen ~]# xl create f20.xl
> Parsing config from f20.xl
> libxl: error: libxl_create.c:1054:domcreate_launch_dm: unable to add
> disk devices
> libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device
> model pid in /local/domain/2/image/device-model-pid
> libxl: error: libxl.c:1425:libxl__destroy_domid:
> libxl__destroy_device_model failed for 2
> libxl: error: libxl_device.c:780:libxl__initiate_device_remove: unable
> to get my domid
> libxl: error: libxl.c:1461:devices_destroy_cb: libxl__devices_destroy
> failed for 2
> [root@xen ~]# 
> [root@xen ~]# /usr/bin/xenstore-write "/local/domain/0/domid" 0
> [root@xen ~]# 
> [root@xen ~]# xl create f20.xl
> Parsing config from f20.xl
> [root@xen ~]# 
> [root@xen ~]# 
> [root@xen ~]# xl list
> Name                                        ID   Mem VCPUs	State	Time(s)
> Domain-0                                     0  2047     2     r-----
> 19.7
> f20                                          3  4095     1     r-----
> 4.1
> 
> 
> After running the xenstore-write command VMs start up without issue.

This is a bug in the Fedora versions of the initscripts (or I suppose
these days they are systemd unit files or whatever). The sysvinit
scripts shipped with Xen itself have this write in already.

I see you've already CCd the appropriate Fedora list so I'll leave it to
them to let you know what the end fix should be...

We should probably consider taking some unit files into the xen tree, if
someone wants to submit a set?

Ian.

Re: [TestDay] xen 4.4 FC3 xl create error

[M A Young]

On Tue, 4 Feb 2014, Ian Campbell wrote:

> On Tue, 2014-02-04 at 08:26 -0700, Eric Houby wrote:
>> Xen list,
>>
>> I have a clean F20 install with the RC3 RPMs and see an error when
>> starting a VM.  A similar issue was seen with the RC2 RPMs.
>
> Thanks for the report.
>
>> [root@xen ~]# xl create f20.xl
>> Parsing config from f20.xl
>> libxl: error: libxl_create.c:1054:domcreate_launch_dm: unable to add
>> disk devices
>> libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device
>> model pid in /local/domain/2/image/device-model-pid
>> libxl: error: libxl.c:1425:libxl__destroy_domid:
>> libxl__destroy_device_model failed for 2
>> libxl: error: libxl_device.c:780:libxl__initiate_device_remove: unable
>> to get my domid
>> libxl: error: libxl.c:1461:devices_destroy_cb: libxl__devices_destroy
>> failed for 2
>> [root@xen ~]#
>> [root@xen ~]# /usr/bin/xenstore-write "/local/domain/0/domid" 0
>> [root@xen ~]#
>> [root@xen ~]# xl create f20.xl
>> Parsing config from f20.xl
>> [root@xen ~]#
>> [root@xen ~]#
>> [root@xen ~]# xl list
>> Name                                        ID   Mem VCPUs	State	Time(s)
>> Domain-0                                     0  2047     2     r-----
>> 19.7
>> f20                                          3  4095     1     r-----
>> 4.1
>>
>>
>> After running the xenstore-write command VMs start up without issue.
>
> This is a bug in the Fedora versions of the initscripts (or I suppose
> these days they are systemd unit files or whatever). The sysvinit
> scripts shipped with Xen itself have this write in already.

I am puzzled by this as the systemd files in the Fedora RC3 test build do 
indeed run
/usr/bin/xenstore-write "/local/domain/0/domid" 0
so I am not sure why it isn't being set in this case. It certainly works 
for me.

> We should probably consider taking some unit files into the xen tree, if
> someone wants to submit a set?

I can submit a set, which start services individually rather than a 
unified xencommons style start file. I didn't find a good way to reproduce 
the xendomains script, so I ended running an edited version of the 
sysvinit script with a systemd wrapper file.

Would it make sense to have some sort of configure option tools to choose 
between sysvinit and systemd?

 	Michael Young

Re: [TestDay] xen 4.4 FC3 xl create error

[M A Young]

On Tue, 4 Feb 2014, M A Young wrote:

> I am puzzled by this as the systemd files in the Fedora RC3 test build do 
> indeed run
> /usr/bin/xenstore-write "/local/domain/0/domid" 0
> so I am not sure why it isn't being set in this case. It certainly works for 
> me.

I have now worked out what the problem is. There are alternate 
systemd files, one for xenstored and one for oxenstored (if it is 
installed) and I only added the line
/usr/bin/xenstore-write "/local/domain/0/domid" 0
to the xenstored one, so if the rpm containing oxenstored was installed 
it would produce the behaviour as reported in this thread.

 	Michael Young

Re: [TestDay] xen 4.4 FC3 xl create error

[Ian Campbell]

On Tue, 2014-02-04 at 18:41 +0000, M A Young wrote:
> > We should probably consider taking some unit files into the xen tree, if
> > someone wants to submit a set?
> 
> I can submit a set, which start services individually rather than a 
> unified xencommons style start file. I didn't find a good way to reproduce 
> the xendomains script, so I ended running an edited version of the 
> sysvinit script with a systemd wrapper file.

I don't know what is conventional in systemd land but I have no problem
with that approach.

> Would it make sense to have some sort of configure option tools to choose 
> between sysvinit and systemd?

AIUI systemd will DTWT and ignore the initscript if there is a systemd
unit file, so installing both seems to be fine to me, and is certain to
be less error prone.

Although perhaps the xencommons vs split units breaks that suppression
logic?

What depends on the xenstored & xenconsole modules? Is it possible to
have a "metaunit" xencommons which a) causes everything to be started
and b) suppresses the initscript by having the same name?

Or maybe there is a systemd syntax you can use to suppress
xencommons.init?

Ian.

Re: [TestDay] xen 4.4 FC3 xl create error

[Jacek Konieczny]

On 02/05/14 10:28, Ian Campbell wrote:
> On Tue, 2014-02-04 at 18:41 +0000, M A Young wrote:
>>> We should probably consider taking some unit files into the xen tree, if
>>> someone wants to submit a set?
>>
>> I can submit a set, which start services individually rather than a 
>> unified xencommons style start file. I didn't find a good way to reproduce 
>> the xendomains script, so I ended running an edited version of the 
>> sysvinit script with a systemd wrapper file.
> 
> I don't know what is conventional in systemd land but I have no problem
> with that approach.

For systemd the much more natural way is to start and monitor each
daemon with
a separate systemd unit. If some extra scripting is needed (like the
setting xenstore values for dom0), that should be coded in a separate
script and one of the two:

– Called via ExecStartPre or ExecStartPost in the unit of the daemon the
scripting is for (e.g. filling xenstore would go to ExecStartPost of
xenstored.service)
– Called via ExecStart in its own service unit.

Writing extra scripts may be not necessary when just a few commands
have to be started.

e.g. the xenstored.service from PLD Linux (based on some unit for xenstored
found on the Internet):

[Unit]
Description=Xenstored - daemon managing xenstore file system
Requires=proc-xen.mount var-lib-xenstored.mount
After=proc-xen.mount var-lib-xenstored.mount
Before=libvirtd.service libvirt-guests.service xendomains.service
xend.service
RefuseManualStop=true
ConditionPathExists=/proc/xen

[Service]
Type=forking
Environment=XENSTORED_ARGS=
Environment=XENSTORED_ROOTDIR=/var/lib/xenstored
EnvironmentFile=-/etc/sysconfig/xenstored
PIDFile=/var/run/xenstored.pid
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=-/bin/rm -f "$XENSTORED_ROOTDIR"/tdb*
ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid
$XENSTORED_ARGS
ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

[Install]
WantedBy=multi-user.target

-- 
Greets,
  Jacek

Re: [TestDay] xen 4.4 FC3 xl create error

[M A Young]

On Wed, 5 Feb 2014, Ian Campbell wrote:

> On Tue, 2014-02-04 at 18:41 +0000, M A Young wrote:
>>> We should probably consider taking some unit files into the xen tree, if
>>> someone wants to submit a set?
>>
>> I can submit a set, which start services individually rather than a
>> unified xencommons style start file. I didn't find a good way to reproduce
>> the xendomains script, so I ended running an edited version of the
>> sysvinit script with a systemd wrapper file.
>
> I don't know what is conventional in systemd land but I have no problem
> with that approach.
>
>> Would it make sense to have some sort of configure option tools to choose
>> between sysvinit and systemd?
>
> AIUI systemd will DTWT and ignore the initscript if there is a systemd
> unit file, so installing both seems to be fine to me, and is certain to
> be less error prone.
>
> Although perhaps the xencommons vs split units breaks that suppression
> logic?
>
> What depends on the xenstored & xenconsole modules? Is it possible to
> have a "metaunit" xencommons which a) causes everything to be started
> and b) suppresses the initscript by having the same name?
>
> Or maybe there is a systemd syntax you can use to suppress
> xencommons.init?

I don't know of an alternate way to suppress and init.d script, so I agree 
it makes sense to have a dummy xencommons.service unit which will start 
any other xen units, but doesn't do anything functional itself.

 	Michael Young