RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
Target Upstream Version:
Embargoed:

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.