[clug] Cockpit vs Network Manager
Steve Walsh
steve at nerdvana.org.au
Thu Aug 15 15:25:05 UTC 2019
Hello George
My answer was rushed, and, of course, Cockpit is not a virtualisation
tool, but a management tools.
I've since watched a number of videos on the Red Hat Video channel on
youtube, and whilst one of them does not directly explain how to create
a bridge, there is an option under the network tab to create a bridge.
If you have a VM that you can easily recover from poking and prodding,
you can probably work out how to do it on that.
Keep in mind the bridge that libvirt creates is intended as a NAT
bridge, and thus involves both the bridge, and a dnsmasq instance
attached to it. You'll need to be careful when fiddling with this bridge
that you don't make things worse by attempting to make them better.
I've also found this video regarding managing storage in cockpit -
https://www.youtube.com/watch?v=mP8YAHuLc2M
On 16/8/19 1:17 am, George at Clug via linux wrote:
> Steve,
>
> I guess I should not confess that one of my first things after building a new server is to stop, and uninstall Network-Manger.
>
> And I had found that Virt-Manager was way better than myself at creating Bridges to Network Interfaces.
>
> Network Manager seemed to have a bad habit of altering network configurations at seemingly random times, not so enjoyable on long running servers.
>
> I believe Network Manager has improved since then, and I now realise I must mend my ways, and learn how to use it, not dispose of it.
>
> ; )
>
> George
>
>
> On Friday, 16-08-2019 at 01:05 Steve Walsh wrote:
>> Hello George
>>
>> One of your original emails included this snippet from a virt-manager
>> team member
>>
>> Nowadays NetworkManager can handle bridging natively and is much more powerful than what virt-manager/libvirt/netcf provide. The virt-manager UI was more likely to shoot you in the foot than make things simple. And it had become increasingly clear that virt-manager was not the place to maintain host network config UI.
>>
>> So we made the decision to drop all this from virt-manager in 2.0.0. netcf and the libvirt interface APIs still exist. If you're interested in some more history on the interface API/netcf difficulties, check out Laine's email to virt-tools-list.
>> https://www.redhat.com/archives/virt-tools-list/2018-October/msg00049.html
>>
>>
>> I'm guessing Cockpit followed that lead, and all that's now pushed down
>> to NetworkManager to handle, as they make good points about
>> virtualisation tools managing host machine network configuration.
>>
>> regards
>>
>> On 16/8/19 12:31 am, George at Clug via linux wrote:
>>> Steve,
>>>
>>> Good video on creating a VM.
>>>
>>> Do you know of any Cockpit videos on creating bridges to a network interface, and/or on managing storage (particularly when you have more than one local disk drive) ? (I will do a search on YouTube later, but I am not always successful at finding 'quality' videos)
>>>
>>> I am enjoying fumbling around the UI and discovering features, comparing how management differs between managing a local Cockpit hypervisor to managing a remote Cockpit hypervisor.
>>>
>>> I stumbled a bit with the 'default' network (which I guess was created by virtinst/qemu-kvm, not Cockpit). Because I am running my tests using Virt-Manager on my laptop, my test environment's virtual network address space is my virtinst/qemu-kvm 'default' virtual network of 192.168.122.0/24, and of course whenever I created a VM and installed Cockpit, it created its own 'default' virtual network using the same 192.168.122.0/24 address space, which caused a conflict, stopping me from being able to create a VM in Cockpit. I resolved this by changing the Cockpit server's 'default' virtual network to 192.168.123.0/24, using the below instructions. I think it would be easier and faster if I had just changed the address space of my Virt-Manager's 'default' network, less work. (Note: all the below IPs only exist in a test environment)
>>>
>>> (from a terminal on my Cockpit server (ip address of 192.168.122.15), which is running as a virtual machine via Virt-Manager on my laptop)
>>>
>>> # ip -4 a show enp1s0
>>> 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
>>> inet 192.168.122.15/24 brd 192.168.122.255 scope global enp1s0
>>> valid_lft forever preferred_lft forever
>>>
>>> # virsh net-list --all
>>> Name State Autostart Persistent
>>> ----------------------------------------------
>>> default inactive yes yes
>>>
>>> # virsh net-dumpxml default
>>> <network>
>>> <name>default</name>
>>> <uuid>3c85f255-6a39-4364-b987-c2789c8bc284</uuid>
>>> <forward mode='nat'/>
>>> <bridge name='virbr0' stp='on' delay='0'/>
>>> <mac address='52:54:00:d0:b9:5b'/>
>>> <ip address='192.168.122.1' netmask='255.255.255.0'>
>>> <dhcp>
>>> <range start='192.168.122.2' end='192.168.122.254'/>
>>> </dhcp>
>>> </ip>
>>> </network>
>>>
>>> # virsh net-edit default
>>>
>>> Select an editor. To change later, run 'select-editor'.
>>> 1. /bin/nano <---- easiest
>>> 2. /usr/bin/vim.tiny
>>>
>>> Choose 1-2 [1]: 1
>>> Network default XML configuration edited.
>>>
>>> # virsh net-dumpxml default
>>> <network>
>>> <name>default</name>
>>> <uuid>3c85f255-6a39-4364-b987-c2789c8bc284</uuid>
>>> <forward mode='nat'/>
>>> <bridge name='virbr0' stp='on' delay='0'/>
>>> <mac address='52:54:00:d0:b9:5b'/>
>>> <ip address='192.168.123.1' netmask='255.255.255.0'>
>>> <dhcp>
>>> <range start='192.168.123.2' end='192.168.123.254'/>
>>> </dhcp>
>>> </ip>
>>> </network>
>>>
>>> # virsh net-start default
>>> Network default started
>>>
>>> # virsh net-list --all
>>> Name State Autostart Persistent
>>> --------------------------------------------
>>> default active yes yes
>>>
>>>
>>> To allow nested virtualisation I used;
>>>
>>> # cat /sys/module/kvm_intel/parameters/nested
>>> N
>>>
>>> # echo options kvm_intel nested=1 > /etc/modprobe.d/kvm.conf
>>> options kvm_intel nested=1
>>>
>>> # systemctl reboot
>>>
>>> # cat /sys/module/kvm_intel/parameters/nested
>>> Y
>>>
>>>
>>>
>>> On Thursday, 15-08-2019 at 22:04 Steve Walsh wrote:
>>>> There’s a 190 second demo of VM management with cockpit on the Red Hat Video YouTube channel
>>>>
>>>> https://youtu.be/eBJCpOrmPPs
>>>>
>>>> Sent from a mobile device, please confirm any errors or omissions
>>>>
>>>>> On 15 Aug 2019, at 9:14 pm, Stephen Hocking via linux <linux at lists.samba.org> wrote:
>>>>>
>>>>> I use virt-manager a fair bit. Wouldn't mind some demos on cockpit.
>>>>>
>>>>> On Thu, 15 Aug 2019 at 20:53, George at Clug via linux <
>>>>> linux at lists.samba.org> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>> I have been reviewing RedHat's Cockpit as available in Debian Buster.
>>>>>>
>>>>>>
>>>>>> I am curious about the following;
>>>>>>
>>>>>>
>>>>>> 1) Is anyone on the CLUG list using Virt-Manager?
>>>>>>
>>>>>>
>>>>>> 2) Is anyone on the CLUG list using Cockpit?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 3) Is anyone considering or is curious about using Cockpit?
>>>>>>
>>>>>>
>>>>>> 4) Is anyone interested in a demo of Cockpit at a CLUG meeting ? If
>>>>>> no one else wants to give the demo, I could demonstrate Cockpit
>>>>>> working an the test environment that I am using to review Cockpit,
>>>>>> though it might be some time next year.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://access.redhat.com/solutions/3935841
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> George.
>>>>>> --
>>>>>> linux mailing list
>>>>>> linux at lists.samba.org
>>>>>> https://lists.samba.org/mailman/listinfo/linux
>>>>>>
>>>>> --
>>>>>
>>>>> "I and the public know
>>>>> what all schoolchildren learn
>>>>> Those to whom evil is done
>>>>> Do evil in return" W.H. Auden, "September 1, 1939"
>>>>> --
>>>>> linux mailing list
>>>>> linux at lists.samba.org
>>>>> https://lists.samba.org/mailman/listinfo/linux
More information about the linux
mailing list