Created attachment 635575 [details] Domain XML that should fails to start Description of problem: Version-Release number of selected component (if applicable): libvirt-0.10.2-5.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. Create an XML file for domain with specified UUID, that can be defined but not started (due to any reason) 2. Define the domain # virsh define test.xml Domain demo defined from test.xml 3. Create the domain (start temporarily), this will fail as expected # virsh create test.xml error: Failed to create domain from test.xml error: internal error Failed to open socket to sanlock daemon: Permission denied 4. Check if the domain exists # virsh dumpxml test.xml error: failed to get domain 'test.xml' error: Domain not found: no domain with matching name 'test.xml' Actual results: There is no error in step 3 that would mention the domain already exists and the domain is undefined due to the fact that it didn't get started and hence cannot be found in step 4. Expected results: Step 3 will report error due to existing domain and Step 4 will find the domain. Additional info: Works alright when UUID is not specified and is generated while defining and creating. Also I don't think this is a regression since this issue is here since the dawn of times.
Domain cannot be found in step 4 even when using 'virsh dumpxml test' (without the mistake in comment #0).
Tested with libvirt-0.10.2-18.el6. # cat /home/rhel64.xml |grep uuid <uuid>510d9494-e4d3-531e-d8bc-d0bbf391e4e3</uuid> # virsh define /home/rhel64.xml Domain rhel64-1 defined from /home/rhel64.xml # virsh list --all Id Name State ---------------------------------------------------- - rhel64-1 shut off # virsh create /home/rhel64.xml Domain rhel64-1 created from /home/rhel64.xml # virsh list --all Id Name State ---------------------------------------------------- 3 rhel64-1 running # virsh dumpxml rhel64-1|grep uuid <uuid>510d9494-e4d3-531e-d8bc-d0bbf391e4e3</uuid> After I destroy the domain, the defined one is still there. # virsh destroy rhel64-1 Domain rhel64-1 destroyed # virsh list --all Id Name State ---------------------------------------------------- - rhel64-1 shut off So I think the domain becomes to persistent one after define and create. It should be the same as: define->start->undefine, then the domain becomes to the transient one, yes ?
You missed the step 1, you have to create domain xml that can be defined but not started on hypervisor level (e.g. specifying unknown device). I should also add that creating a domain from xml when the domain should be possible (my mistake in the description), because that can be used for starting a domain with temporary settings, but the domain shouldn't be deleted in any case.
(In reply to comment #5) > You missed the step 1, you have to create domain xml that can be defined but > not started on hypervisor level (e.g. specifying unknown device). > > I should also add that creating a domain from xml when the domain should be > possible (my mistake in the description), because that can be used for > starting a domain with temporary settings, but the domain shouldn't be > deleted in any case. Yes, that's it. Please ignore the comment 4.
I think I know where the problem is. I'm taking this one and will work on it.
Patches proposed upstream: https://www.redhat.com/archives/libvir-list/2015-September/msg00817.html
Pushed upstream: commit a2ac63af0e60c667d8bc95c185a007eb540ac8ef Author: Michal Privoznik <mprivozn> AuthorDate: Wed Sep 23 14:13:53 2015 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Thu Sep 24 10:52:38 2015 +0200 virDomainRestore: Don't keep transient domains around So while working on my previous patches, I've noticed that virDomainRestore implementation in qemu and test drivers has the same problem as I am fixing. Signed-off-by: Michal Privoznik <mprivozn> commit f41be2963517d82bac8e980a96abcfd6b5393bf1 Author: Michal Privoznik <mprivozn> AuthorDate: Tue Sep 22 15:25:00 2015 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Thu Sep 24 10:52:38 2015 +0200 qemu: Move vm->persistent check into qemuDomainRemoveInactive So far we have the following pattern occurring over and over again: if (!vm->persistent) qemuDomainRemoveInactive(driver, vm); It's safe to put the check into the function and save some LoC. Signed-off-by: Michal Privoznik <mprivozn> commit c99b8cec82a53f091ca3de7532d305a93765b467 Author: Michal Privoznik <mprivozn> AuthorDate: Tue Sep 22 16:57:52 2015 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Thu Sep 24 10:52:38 2015 +0200 virDomainCreateXML: Make domain definition transient https://bugzilla.redhat.com/show_bug.cgi?id=871452 So, you want to create a domain from XML. The domain already exists in libvirt's database of domains. It's okay, because name and UUID matches. However, on domain startup, internal representation of the domain is overwritten with your XML even though we claim that the XML you've provided is a transient one. The bug is to be found across nearly all the drivers. Le sigh. Signed-off-by: Michal Privoznik <mprivozn> commit 37405b910907bd1ad338fb0d6a967bfd23529cf6 Author: Michal Privoznik <mprivozn> AuthorDate: Tue Sep 22 16:52:03 2015 +0200 Commit: Michal Privoznik <mprivozn> CommitDate: Thu Sep 24 10:52:37 2015 +0200 virDomainCreateXML: Don't remove persistent domains on error https://bugzilla.redhat.com/show_bug.cgi?id=871452 Okay, so we allow users to 'virsh create' an already existing domain, providing completely different XML than the one stored in Libvirt. Well, as long as name and UUID matches. However, in some drivers the code that handles errors unconditionally removes the domain that failed to start even though the domain might have been persistent. Fortunately, the domain is removed just from the internal list of domains and the config file is kept around. Steps to reproduce: 1) virsh dumpxml $dom > /tmp/dom.xml 2) change XML so that it is still parse-able but won't boot, e.g. change guest agent path to /foo/bar 3) virsh create /tmp/dom.xml 4) virsh dumpxml $dom 5) Observe "No such domain" error Signed-off-by: Michal Privoznik <mprivozn> v1.2.19-124-ga2ac63a