Bug 730937 - libvirtd reloads the guest config from both running status file and persistent config for the same domain many times.
Summary: libvirtd reloads the guest config from both running status file and persisten...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Osier Yang
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-16 10:12 UTC by dyuan
Modified: 2011-08-17 01:44 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-08-16 17:43:43 UTC


Attachments (Terms of Use)

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


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