Bug 851630 - Guests fail when autostarted by libvirtd.
Guests fail when autostarted by libvirtd.
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
17
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-24 10:21 EDT by Ian Dall
Modified: 2012-10-27 13:24 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-27 13:24:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Custom libvirtd.service to ensure libvirtd starts after network is up. (101 bytes, application/octet-stream)
2012-08-24 10:21 EDT, Ian Dall
no flags Details

  None (edit)
Description Ian Dall 2012-08-24 10:21:13 EDT
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 13:24:35 EDT
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.

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