Bug 851630

Summary: Guests fail when autostarted by libvirtd.
Product: [Fedora] Fedora Reporter: Ian Dall <ian>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: 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:
Description Flags
Custom libvirtd.service to ensure libvirtd starts after network is up. none

Description Ian Dall 2012-08-24 14:21:13 UTC
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.

Comment 1 Cole Robinson 2012-10-27 17:24:35 UTC
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.