Bug 1016140 - VirtualDomain will not start lxc container that is shut off
VirtualDomain will not start lxc container that is shut off
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: resource-agents (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: David Vossel
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2013-10-07 11:12 EDT by michal novacek
Modified: 2015-07-27 11:00 EDT (History)
4 users (show)

See Also:
Fixed In Version: resource-agents-3.9.5-16.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-13 08:53:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description michal novacek 2013-10-07 11:12:47 EDT
Description of problem:
VirtualDomain resource agent will not start lxc container that is shut off only (instead of not being defined at all for virsh) after disabling the resource. 

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. have lxc container generated by lxc_autogen.sh
2. start it as a resource v-lxc1 and verify that it runs and is recognized as
	remote node lxc1 
3. pcs resource disable v-lxc1
4. virsh -c lxc:/// define /var/lib/pacemaker/cts/lxc/lxc1.xml 
5. pcs resource enable v-lxc1

Actual results: resource will never start 

Expected results: started resource

Additional info:
It will start correctly that lxc container that is not defined in virsh.

Selinux is off, virtual containers are created with pacemaker-cts lxc_autogen.sh.
Comment 2 David Vossel 2013-10-07 13:31:05 EDT
libvirt domains managed by the VirtualDomain agent shouldn't be modified outside of the VirtualDomain agent.

The VirtualDomain agent starts domains with the 'virsh create <domain.xml>' command.  Domains initialized with this command are undefined on shutdown automatically.  This means as long as this agent is used, no cluster lxc container should be defined anywhere except on the cluster it is currently active on.

We do need to be able to handle the case where a user defines the domain outside of the agent.  I believe the only way to handle this correctly is to undefine the domain on start, then enable the domain again using 'virsh create'.  I'll write up a patch.
Comment 6 michal novacek 2014-03-28 10:42:17 EDT
I have verified that VirtualDomain resource can be enabled and starts correctly
after being disabled in pacemaker after the domain has been started outside of
pacemaker in resource-agents-3.9.5-26.el7.x86_64.


[root@duck-03 ~]# pcs resource
 R-duck-03-node01-lxc   (ocf::heartbeat:VirtualDomain): Started 
[root@duck-03 ~]# pcs resource show R-duck-03-node01-lxc
 Resource: R-duck-03-node01-lxc (class=ocf provider=heartbeat type=VirtualDomain)
  Attributes: hypervisor=lxc:/// config=/var/lib/libvirt/lxc/duck-03-node01.xml force_stop=true 
  Meta Attrs: remote-node=duck-03-node01 
  Operations: start interval=0s timeout=90000 (R-duck-03-node01-lxc-start-timeout-90000)
              stop interval=0s timeout=90000 (R-duck-03-node01-lxc-stop-timeout-90000)
              monitor interval=10 timeout=30 (R-duck-03-node01-lxc-monitor-interval-10)
[root@duck-03 ~]# pcs resource disable R-duck-03-node01-lxc
[root@duck-03 ~]# pcs resource
 R-duck-03-node01-lxc   (ocf::heartbeat:VirtualDomain): Stopped 
[root@duck-03 ~]# virsh -c lxc:/// list
 Id    Name                           State

[root@duck-03 ~]# virsh -c lxc:/// list --all
 Id    Name                           State

[root@duck-03 ~]# virsh -c lxc:/// define /var/lib/libvirt/lxc/duck-03-node01.xml
Domain duck-03-node01 defined from /var/lib/libvirt/lxc/duck-03-node01.xml

[root@duck-03 ~]# pcs resource enable R-duck-03-node01-lxc
[root@duck-03 ~]# pcs resource
 R-duck-03-node01-lxc   (ocf::heartbeat:VirtualDomain): Started
Comment 7 Ludek Smid 2014-06-13 08:53:48 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.