Bug 730937

Summary:	libvirtd reloads the guest config from both running status file and persistent config for the same domain many times.
Product:	Red Hat Enterprise Linux 6	Reporter:	dyuan
Component:	libvirt	Assignee:	Osier Yang <jyang>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	dallan, eblake, jyang, laine, mzhan, rwu, whuang, ydu
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-16 17:43:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description dyuan 2011-08-16 10:12:19 UTC

Description of problem:
libvirtd reloads the guest config from both running status file and persistent config for the same domain many times.

Version-Release number of selected component (if applicable):
libvirt-0.9.4-4.el6

How reproducible:
100%

Steps to Reproduce:
1. # virsh list --all
 Id Name                 State
----------------------------------
  - dom                  shut off

# ls /var/run/libvirt/qemu/
dom.pid
# ls /etc/libvirt/qemu
dom.xml  networks

2. # cp dom-create.xml /etc/libvirt/qemu

3. # kill -SIGHUP `pidof libvirtd`

4. # virsh list --all
 Id Name                 State
----------------------------------
  - dom                  shut off
  - dom-create           shut off

# ls /etc/libvirt/qemu
dom-create.xml  dom.xml  networks


5. repeat the "kill -SIGHUP"

6. # virsh list --all
 Id Name                 State
----------------------------------
  - dom                  shut off
  - dom-create           shut off
  - dom-create           shut off

7. start the dom-create
# virsh start dom-create
Domain dom-create started

# virsh list --all
 Id Name                 State
----------------------------------
  2 dom-create           running
  - dom                  shut off
  - dom-create           running

# ls /var/run/libvirt/qemu/
dom-create.pid  dom-create.xml  dom.pid
# ls /etc/libvirt/qemu
dom-create.xml  dom.xml  networks


8. repeat the "kill -SIGHUP"

9. # virsh list --all
 Id Name                 State
----------------------------------
  2 dom-create           running
  - dom                  shut off
  - dom-create           running
  - dom-create           running

# ls /var/run/libvirt/qemu/
dom-create.pid  dom-create.xml  dom.pid
# ls /etc/libvirt/qemu
dom-create.xml  dom.xml  networks
  
Actual results:
reload and list the same domain even for the running domain many times.

Expected results:
reload without list the same domain name many times.

Additional info:

Comment 2 Osier Yang 2011-08-16 13:52:08 UTC

The only cause I can get is there is no UUID specified in the /etc/libvirt/qemu/dom-create.xml, libvirt checks if the domain is already managed by the domain UUID while loading all the domain configs, however, for a domain conf which has no UUID, libvirt will generate one for it, that's why the dom-create is listed again and again with reloading. Libvirt check if a domain is uniq only by the UUID.

@dyuan, can you confirm if dom-create's persistent config has no UUID specified?

Comment 3 Eric Blake 2011-08-16 15:00:37 UTC

(In reply to comment #0)
> Description of problem:
> libvirtd reloads the guest config from both running status file and persistent
> config for the same domain many times.
> 
> Version-Release number of selected component (if applicable):
> libvirt-0.9.4-4.el6
> 
> How reproducible:
> 100%
> 
> 
> 2. # cp dom-create.xml /etc/libvirt/qemu

Wrong.  This is going behind libvirt's back, and is therefore unsupported.  Users are not allowed to directly modify /etc/libvirt/qemu - they are only allowed to use libvirt APIs which in turn modify this directory as a side effect.  If you follow the rules of always going through libvirt APIs instead of going behind libvirt's back, then you should never be able to get into the inconsistent situation where you have a domain definition in /etc with no uuid.

I'm inclined to close this bug as invalid.

Comment 4 Laine Stump 2011-08-16 17:41:41 UTC

(In reply to comment #3)
> 
> I'm inclined to close this bug as invalid.

I agree (unless a similar result can be shown via using the official API).

The location of the config files isn't even a part of the public API, and there are many well known situations where directly modifying the files has "unexpected results".

Comment 5 Dave Allan 2011-08-16 17:43:43 UTC

(In reply to comment #3)

> Wrong.  This is going behind libvirt's back, and is therefore unsupported. 
> Users are not allowed to directly modify /etc/libvirt/qemu - they are only
> allowed to use libvirt APIs which in turn modify this directory as a side
> effect.  If you follow the rules of always going through libvirt APIs instead
> of going behind libvirt's back, then you should never be able to get into the
> inconsistent situation where you have a domain definition in /etc with no uuid.
> 
> I'm inclined to close this bug as invalid.

This is absolutely not a bug.  See:

http://wiki.libvirt.org/wiki/index.php?title=FAQ#Where_are_VM_config_files_stored.3F_How_do_I_edit_a_VM.27s_XML_config.3F