Pkg xen devel - Jul 2012 - Bug#680102: More fixes for xen-api in Wheezy

(CC'ing George Shulkin, and the #680102 bug list)

On Sat, Jul 7, 2012 at 4:37 PM, Thomas Goirand <thomas at goirand.fr>
wrote:
> Hi Mike and Jon,
>
> It would be really nice if you could have a look at these 3 pending
> issues in the Debian bug tracker:
>
> #675052: xe vm-memory-target-set does not write target to xenstore
> #678723: vif-interfaces added to database as PIF's
> #680102: xcp fails eject host from pool (no /etc/firstboot.d found)
>
> It be great to have it fix asap, before the deep freeze of Wheezy.
>
> I've been able to fix others already. Other than that, only #680102 is
a
> concern.
So 680102 is due to there not being an /etc/firstboot.d/ directory (as
the ticket explains). I think we can fix this issue simply by
mkdir'ing the directory /etc/firstboot.d/data at some point in xapi's
installation. This would allow the pool-eject to proceed, but I think
that there might be problems when the host reboots: since none of the
firstboot scripts will be called, the host might not reinitialise
properly.

I think at this point that's all we can hope for. George, can you test
that creating the /etc/firstboot.d/data directory gets you past the
current exception your having? If this works good enough, let's make
this the fix for now.

Jon, do you have any other thoughts on this bug?

Mike

On 07/08/2012 04:22 AM, Mike McClurg wrote:
> (CC'ing George Shulkin, and the #680102 bug list)
> 
> On Sat, Jul 7, 2012 at 4:37 PM, Thomas Goirand <thomas at goirand.fr>
wrote:
>> Hi Mike and Jon,
>>
>> It would be really nice if you could have a look at these 3 pending
>> issues in the Debian bug tracker:
>>
>> #675052: xe vm-memory-target-set does not write target to xenstore
>> #678723: vif-interfaces added to database as PIF's
>> #680102: xcp fails eject host from pool (no /etc/firstboot.d found)
>>
>> It be great to have it fix asap, before the deep freeze of Wheezy.
>>
>> I've been able to fix others already. Other than that, only #680102
is a
>> concern.
> 
> So 680102 is due to there not being an /etc/firstboot.d/ directory (as
> the ticket explains). I think we can fix this issue simply by
> mkdir'ing the directory /etc/firstboot.d/data at some point in
xapi's
> installation. This would allow the pool-eject to proceed, but I think
> that there might be problems when the host reboots: since none of the
> firstboot scripts will be called, the host might not reinitialise
> properly.
Well, writing in /etc dynamically is *forbidden* by the Debian policy.
The /etc folder is for configuration, not something else! If you were
using /var/lib/xcp-xapi, ok, but not /etc.

Could you think about a better way to fix?

Cheers,

Thomas

On 08.07.2012 00:22, Mike McClurg wrote:
> (CC'ing George Shulkin, and the #680102 bug list)
>
> On Sat, Jul 7, 2012 at 4:37 PM, Thomas Goirand <thomas at goirand.fr>
wrote:
>> Hi Mike and Jon,
>>
>> It would be really nice if you could have a look at these 3 pending
>> issues in the Debian bug tracker:
>>
>> #675052: xe vm-memory-target-set does not write target to xenstore
>> #678723: vif-interfaces added to database as PIF's
>> #680102: xcp fails eject host from pool (no /etc/firstboot.d found)
>>
>> It be great to have it fix asap, before the deep freeze of Wheezy.
>>
>> I've been able to fix others already. Other than that, only #680102
is a
>> concern.
> So 680102 is due to there not being an /etc/firstboot.d/ directory (as
> the ticket explains). I think we can fix this issue simply by
> mkdir'ing the directory /etc/firstboot.d/data at some point in
xapi's
> installation. This would allow the pool-eject to proceed, but I think
> that there might be problems when the host reboots: since none of the
> firstboot scripts will be called, the host might not reinitialise
> properly.
>
> I think at this point that's all we can hope for. George, can you test
> that creating the /etc/firstboot.d/data directory gets you past the
> current exception your having? If this works good enough, let's make
> this the fix for now.
>
> Jon, do you have any other thoughts on this bug?
>
> Mike

Here results:
# mkdir  /etc/firstboot.d/
# mkdir  /etc/firstboot.d/data
# xe pool-eject host-uuid=a6806a39-442d-f17d-b7a0-59161d18f562

WARNING: Ejecting a host from the pool will reinitialise that host's 
local SRs.
WARNING: Any data contained with the local SRs will be lost.
Type 'yes' to continue
yes
The server failed to handle your request, due to an internal error. The 
given message may give details useful for debugging the problem.
message: Failure("Error while calling xen-cmdline script")


log snippet:

[20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|xapi] Raised at forkhelpers.ml:181.30-76 -> 
pervasiveext.ml:22.2-9
[20120707T21:55:24.695Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|backtrace] Raised at pervasives.ml:22.22-33 -> 
list.ml:57.20-23 -> xapi_pool.ml:830.9-125 -> rbac.ml:229.16-23
[20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|backtrace] Raised at rbac.ml:238.10-15 -> 
server_helpers.ml:72.10-22
[20120707T21:55:24.697Z|debug|lab-xh3|699 INET 127.0.0.1:80|pool.eject 
R:a16c35a5d1d4|dispatcher] Server_helpers.exec exception_handler: Got 
exception INTERNAL_ERROR: [ Failure("Error while calling xen-cmdline 
script")


My opinion about 'eject' on debian:
1) Clear running VM's
2) Unplug all VBD
3) Unplug all PIF's but management
4) Wipe /var/lib/xcp/state.db
5) Wipe /var/lib/xcp/local.db
6) Keep only management interface data in /var/xcp/network.db
7) restart all xcp services.

During playing with bug lack of '-onsystemboot' flag for xcp I've
done
that operation many times, seems it working without specific problems.

It even works fine without host reboot.