Bug 1109832

I chatted with Antoine about this and there appears to be a logic bug in the patterns spec file wrt SLE vs openSUSE. Antoine said he would fix it...

(In reply to Richard Brown from comment #0)
> As discussed in https://progress.opensuse.org/issues/41093
> 
> yast vm installs patterns-server-kvm_server
> 
> patterns-server-kvm_server does not install libvirt-daemon-config-network
> 
> libvirt-daemon-config-network is only required by libvirt, which is a
> suggests for the kvm_server pattern
> 
> Therefore any libvirt/yast vm installation doesn't have the default network,
> which is required by a great many use cases and tools, such as virt-install
> 
> Expected behaviour
> 
> patterns-server-kvm_server should install libvirt-daemon-config-network
> and/or libvirt

i don't think there is a patterns-server-kvm_tools and patterns-server-xen_tools in openSUSE, and in these patterns there is a requires for libvirt-daemon-config-network, so we don't have the issue on SLE. The split was made on purpose to be able to install only the basement of KVM and XEN hypervisor. So maybe it could be a good idea to get this patterns available in openSUSE and use them.

(In reply to Antoine Ginies from comment #2)
> i don't think there is a patterns-server-kvm_tools and
> patterns-server-xen_tools in openSUSE, and in these patterns there is a
> requires for libvirt-daemon-config-network, so we don't have the issue on
> SLE. The split was made on purpose to be able to install only the basement
> of KVM and XEN hypervisor. So maybe it could be a good idea to get this
> patterns available in openSUSE and use them.

The distinction doesn't make sense to me. Does openSUSE prefer a limited number of patterns? If the goal is a "base" KVM or Xen setup then the SLE {kvm,xen}_server pattern is the way to go. This gives you the most basic components required to run a KVM or Xen VM. If you want all the basic tools to create and manage VMs as well, then go with the {kvm,xen}_tools. IMO openSUSE should provide the same patterns as SLE.

so in leap kvm/xen_server and kvm/xen_tools are available.
Not in TW. So the quick fix is to get them in TW and use them.

SR#639622

Charles could you fix yast2-vm and install the new pattern under openSUSE.
Now we have the same patterns as SLES, but the name differ a bit.

so we need a deps on:
patterns-server-kvm_tools
patterns-server-xen_tools

I have issued a pull request for this change. It is pending a review.

(In reply to Charles Arnold from comment #7)
> I have issued a pull request for this change. It is pending a review.

Charles, do you have an SR number to share, please?

(In reply to Guillaume GARDET from comment #8)
> (In reply to Charles Arnold from comment #7)
> > I have issued a pull request for this change. It is pending a review.
> 
> Charles, do you have an SR number to share, please?

No, the pull request is still waiting review. Once accepted it will
automatically be sent to Factory and on to a Tumbleweed release.

(In reply to Charles Arnold from comment #9)
> (In reply to Guillaume GARDET from comment #8)
> > (In reply to Charles Arnold from comment #7)
> > > I have issued a pull request for this change. It is pending a review.
> > 
> > Charles, do you have an SR number to share, please?
> 
> No, the pull request is still waiting review. Once accepted it will
> automatically be sent to Factory and on to a Tumbleweed release.

Can we have a link to the pull request then please? Who is the review waiting on?

(In reply to Richard Brown from comment #10)
> (In reply to Charles Arnold from comment #9)
> > (In reply to Guillaume GARDET from comment #8)
> > > (In reply to Charles Arnold from comment #7)
> > > > I have issued a pull request for this change. It is pending a review.
> > > 
> > > Charles, do you have an SR number to share, please?
> > 
> > No, the pull request is still waiting review. Once accepted it will
> > automatically be sent to Factory and on to a Tumbleweed release.
> 
> Can we have a link to the pull request then please? Who is the review
> waiting on?

Seems to be https://github.com/yast/yast-vm/pull/36

@Charles, your PR has been reviewed. Could you update it accordingly, please?

(In reply to Guillaume GARDET from comment #12)
> @Charles, your PR has been reviewed. Could you update it accordingly, please?

Charles updated the PR, which is now merged on github.

And the SR to Factory is available: https://build.opensuse.org/request/show/648687

It would be nice to get the full log of the libvirtd starting.
# journalctl -u libvirtd > libvirtd.log

Sounds like there is an issue with starting the network.
Please check:

# virsh net-list

default network should be available

# virsh netinfo default

to get info on this network

if not started you should do it by hand:
# virsh net-autostart default
# virsh net-start default

Any update?

(In reply to Antoine Ginies from comment #16)
> Any update?

Happy New Year....any update?

(In reply to Richard Brown from comment #17)
> (In reply to Antoine Ginies from comment #16)
> > Any update?
> 
> Happy New Year....any update?

From my perspective this bug is fixed and may be closed. The issue
brought up by Antoine in comment #15 seems to be unrelated to whether
libvirt-daemon-config-network is installed by yast2-vm.

If there are problems with libvirt starting the network (assuming
libvirt-daemon-config-netwok is installed), that would be a new
bug and it probably should be assigned to Jim Fehlig.

Created attachment 794144 [details]
virsh net-info

(In reply to Antoine Ginies from comment #15)
> It would be nice to get the full log of the libvirtd starting.
> # journalctl -u libvirtd > libvirtd.log
> 
> Sounds like there is an issue with starting the network.
> Please check:
> 
> # virsh net-list

The list is empty.

> default network should be available
> 
> # virsh netinfo default

as the attached image.

Created attachment 794145 [details]
journal

journal log.

The interesting part can be,


    Jan 10 09:59:13 susetest systemd[1]: Starting Virtualization daemon...
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.355+0000: 24917: info : libvirt version: 4.10.0
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.355+0000: 24917: info : hostname: susetest
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.355+0000: 24917: warning : virGetHostnameImpl:714 : getaddrinfo failed for 'susetest': Name or service not known
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.387+0000: 24917: info : libvirt version: 4.10.0
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.387+0000: 24917: info : hostname: susetest
    Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.387+0000: 24917: warning : netcfIfaceRegister:1275 : Failed to intialize libnetcontrol.  Management of interface devices is disabled

The issue sounds not matching to the subject here, perhaps we should create another ticket.

(In reply to Max Lin from comment #19)
> > # virsh net-list
> 
> The list is empty.

'virsh net-list' only shows active networks. You would see the network named 'default' if you added the --all option.

> > default network should be available
> > 
> > # virsh netinfo default
> 
> as the attached image.

Note that default network is not active. You can activate it with 'virsh net-start default'. To activate it at boot, set the autostart property. E.g. 'virsh net-autostart default'.

(In reply to Max Lin from comment #20)
> Jan 10 09:59:13 susetest libvirtd[24917]: 2019-01-10 14:59:13.387+0000:
> 24917: warning : netcfIfaceRegister:1275 : Failed to intialize
> libnetcontrol.  Management of interface devices is disabled

libvirt uses libnetcontrol for management of interface devices, e.g. the 'virsh iface-*' commands. libnetcontrol is not compatible with NetworkManager. Are you using NetworkManager? If you want to manage interface devices (bridges, vlans, bonds, etc) with libvirt, then you must use wicked and disable NetworkManager.

But I doubt you want to use libvirt to manage interface devices. NetworkManager is a better tool for that task. And yast is a better tool if using wicked. libvirt is great for managing virtual networks (virsh net-*), but platform tools are much better for managing devices.

Yes, it was NetworkManager there, make this clear, the topic here is started from https://progress.opensuse.org/issues/41093 , NetworkManager is now the default management tool for desktop environment, not per workstation or laptop anymore, therefore we're looking for an technical solution to have virtualization thingy works with NetworkManager on openQA, then should works on user's machine as well.

So the question still remained is: Why does libvirt network 'default' get activated when wicked is the default network stack, but not with NM?

It's a little bit far from this bugreport though.

So is the original bug report about the patterns resolved?
The other issue with virt-install not working with NM needs a separate bug report I guess?

https://progress.opensuse.org/issues/41093#note-12

(In reply to Max Lin from comment #24)
> So the question still remained is: Why does libvirt network 'default' get
> activated when wicked is the default network stack, but not with NM?

Are you encountering problems activating the default network when using NM? Does 'virsh net-start default' fail?

As I already wrote, you can't use libvirt to manage *interface* devices when using NM, but there should be no problems managing virtual networks.

Verified manually on Tumbleweed Snapshot 20190125 that libvirt-daemon-config-network is installed when yast2 virtualzation is used to install the virtualization stack.