Bug 851630
Summary: | Guests fail when autostarted by libvirtd. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ian Dall <ian> | ||||
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 17 | CC: | berrange, clalancette, crobinso, itamar, jforbes, jyang, laine, libvirt-maint, veillard, virt-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-10-27 17:24:35 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Hmm, I'm a bit confused, stock libvirtd.service on F17 has this: [Unit] Description=Virtualization daemon Before=libvirt-guests.service After=network.target Isn't After=network.target sufficient then? I see you added syslog and tgt but those seem separate additions from this issue. Closing as NOTABUG. Ian, please reopen if I'm misunderstanding and we can go from there. |
Created attachment 606888 [details] Custom libvirtd.service to ensure libvirtd starts after network is up. Description of problem: I find that guests started by libvirtd fail because a vlan bridge has not (yet) been created. Version-Release number of selected component (if applicable): libvirt-daemon-0.9.11.4-3.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a network bridge (say br0) 2. Create a VM with a network device on br0 3. Set VM boot options to "start virtual machine on host boot up" Actual results: libvirtd[1739]: 2012-08-23 14:24:49.386+0000: 1760: erro r : virNetDevGetMTU:347 : Cannot get interface MTU on 'br0': No such device libvirtd[1739]: 2012-08-23 14:24:49.435+0000: 1760: erro r : qemuAutostartDomain:177 : Failed to autostart VM 'hex': Cannot get interface MTU on 'br0': No such device [...] info network[1843]: Bringing up interface br0: [ OK ] Expected results: VM starts successfully Additional info: The issue is the libvirtd starts befor br0 is up. This is because libvirtd.service is net scheduled after network.service. libvirt-guests.service IS configured to start after network.service but this client is being started by libvirtd not libvirt-guests.service. The libvirtd-guests service only starts guests which where runing at a clean shutdown. If a service crashes or goes down due to a power failure, guests which were running will not be re-started. If there are guests which are required (perhaps because they run essential services) the only supported way to reliably start them is from libvirtd. This can be fixed by a local customisation, which I can live with, but this must be a common enough case to support.