[libvirt-users] Xen died - Fedora upgrade from 21 to 26
Dominik Psenner
dpsenner at gmail.com
Wed Jul 26 15:35:29 UTC 2017
[off topic]
One day someone had the idea to test a disaster scenario and plugged the
power supply on the server that guarded the security doors. All went quite
well until that someone wanted to enter the server room to power on that
server again. At this moment he noticed that the doors would no longer open
and there was no lock to put a key in. :-D That was a really good lesson to
learn and today it is a good joke that we can laugh about.
It is simple to have a second network cable to provide a fallback mechanism
to log into a critical component of a system. Think about such things, the
day will come when you'll be happy to have it.
[eof off topic]
For me, on the latest ubuntu lts, the libvirtd service starts up fine along
with all guests and shutdown works just fine too in the sense that the host
shuts down the guests by ACPI power off. This might be a regression in the
Fedora dist?
2017-07-26 16:28 GMT+02:00 Alvin Starr <alvin at netvel.net>:
> I believe this problem also exists in F25.
>
> There are upsides to having a vm do the networking and I have used that
> scheme for something like a decade.
>
> The point is that libvirt should start up and start its VM's correctly.
>
> If you cannot depend on the system starting correctly then very quickly
> you cannot depend on the system at all and then your backing out to your
> switches and network cables and power supplies .....
>
> My guess is that its related to libvirt trying to start before the xen
> subsystems have come up.
>
>
>
> On 07/26/2017 09:32 AM, Dominik Psenner wrote:
>
> Note that this does not help with the original problem but points out a
> critical design flaw.
>
> To me your it infrastructure design has no working disaster recovery plan.
> You should always be able to access critical functionality and from there
> be able to restore complete functionality step by step. In your case the
> outermost functionality is the vm host. You should always be able to log
> into that machine once it has all cables plugged in, regardless of what
> runs on it (or not).
>
> This means that even though you might get this to work you should rethink
> your design so that you do not have to rely on the vm that does the
> networking.
>
> On 26 Jul 2017 12:50 p.m., "G Crowe" <gclvirtlist at crowie.net> wrote:
>
> Jim,
> Thanks for that, I had manually installed libvirt-daemon-driver-xen,
> but also needed to install libvirt-daemon-driver-libxl. I can now create
> VMs and convert config formats.
>
> However the daemon still fails to start on bootup. It starts fine when I
> manually start it with "systemctl start libvirtd" but setting it to
> autostart with "systemctl enable libvirtd" seems to have no effect. When I
> look at the status, it tells me that the service is "enabled" which means
> that it starts on bootup (well, that's what it means for any other service).
>
> This is rather critical on this PC, as it has unattended restarts and the
> VPN/routing is done in one of the VMs (i.e. I can't get to it unless it
> auto-starts at least one VM).
>
> Unfortunatley there is nothing appearing in the libvirtd log over a reboot
> to help diagnose.
>
> Any suggestions?
>
>
> Thank you
>
> GC
>
>
> [root at testhost ~]# systemctl status libvirtd
> ● libvirtd.service - Virtualization daemon
> Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled;
> vendor preset: enabled)
> Active: inactive (dead)
> Docs: man:libvirtd(8)
> http://libvirt.org
>
>
>
>
>
> On 25/07/2017 1:20 AM, Jim Fehlig wrote:
>
>> On 07/23/2017 04:25 PM, G Crowe wrote:
>>
>>> Hi,
>>> I am trying to upgrade my Xen host (Dom0) and are having troubles
>>> getting it to work.
>>>
>>> I think that it has booted into a kernel that supports Xen (running 'xl
>>> info' does list some Xen capabilities), but I have three problems (that I
>>> have found so far).
>>>
>>> Firstly, the "libvirtd" daemon doesn't start on bootup (and as a result
>>> all 'virsh' commands fail). It is set to auto-start (systemctl enable
>>> libvirtd), and can be manually started (systemctl start libvirtd), but it
>>> will not auto-start on reboot.
>>>
>>> Secondly, Once I have manually started libvirtd, when I try to define a
>>> domain it gives me an error "could not find capabilities for arch=x86_64
>>> domaintype=xen" and I haven't yet been able to define any domains. This
>>> domain type works fine on Fedora 21.
>>>
>>> Thirdly, I am unable to convert to/from xml config format, it gives me
>>> the error "error: invalid argument: unsupported config type xen-xl" however
>>> the format "xen-xl" works fine on the Fedora 21 machine.
>>>
>>
>> It sounds like the libvirt libxl driver is not loaded. Is the
>> libvirt-daemon-driver-libxl package installed? If it's installed, enabling
>> debug logging in libvirtd can provide hints why it is not loading
>>
>> http://libvirt.org/logging.html
>>
>> Regards,
>> Jim
>>
>>
>>> I had these same issues when I tried to upgrade to Fedora 25 and assumed
>>> that something had been broken and so abandoned further attempts to
>>> upgrade, however since Fedora 26 is the same I am now assuming that I have
>>> stuffed something up myself (or missed something).
>>>
>>> Fedora 21 uses kernel 3.19.3 and xen 4.4.1
>>> Fedora 26 uses kernel 4.11.8 and xen 4.8.1
>>>
>>> I have tried following the info on https://wiki.xen.org/wiki/Fedo
>>> ra_Host_Installation but it appears to be out of date now (I used this
>>> site when I started using Xen under Fedora 19, and when I upgraded to
>>> Fedora 21)
>>>
>>> Does anyone have any suggestions? outputs from "xl info" and the domain
>>> config are below. I have also tried disabling SELinux, but it made no
>>> difference.
>>>
>>>
>>> Thanks
>>>
>>> GC
>>>
>>> -----------------------------------------------
>>> On the fedora 26 box.....
>>> # xl info
>>> host : family.mydomain.mytld
>>> release : 4.11.8-300.fc26.x86_64
>>> version : #1 SMP Thu Jun 29 20:09:48 UTC 2017
>>> machine : x86_64
>>> nr_cpus : 4
>>> max_cpu_id : 3
>>> nr_nodes : 1
>>> cores_per_socket : 4
>>> threads_per_core : 1
>>> cpu_mhz : 2712
>>> hw_caps : b7ebfbff:77faf3bf:2c100800:000
>>> 00121:0000000f:009c67af:00000000:00000100
>>> virt_caps : hvm hvm_directio
>>> total_memory : 8072
>>> free_memory : 128
>>> sharing_freed_memory : 0
>>> sharing_used_memory : 0
>>> outstanding_claims : 0
>>> free_cpus : 0
>>> xen_major : 4
>>> xen_minor : 8
>>> xen_extra : .1
>>> xen_version : 4.8.1
>>> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
>>> hvm-3.0-x86_32p hvm-3.0-x86_64
>>> xen_scheduler : credit
>>> xen_pagesize : 4096
>>> platform_params : virt_start=0xffff800000000000
>>> xen_changeset :
>>> xen_commandline : placeholder
>>> cc_compiler : gcc (GCC) 7.0.1 20170421 (Red Hat 7.0.1-0.15)
>>> cc_compile_by : mockbuild
>>> cc_compile_domain : [unknown]
>>> cc_compile_date : Wed May 3 21:23:49 UTC 2017
>>> build_id : 1c6e5a40165e05837303942b54757ae1f2d5033d
>>> xend_config_format : 4
>>>
>>> ---------------------------------------------------
>>> # cat vmtest.xml
>>> <domain type='xen' id='21'>
>>> <name>testVM</name>
>>> <memory unit='KiB'>2097152</memory>
>>> <currentMemory unit='KiB'>2097152</currentMemory>
>>> <vcpu placement='static'>1</vcpu>
>>> <os>
>>> <type arch='x86_64' machine='xenfv'>hvm</type>
>>> <loader type='rom'>/usr/lib/xen/boot/hvmloader</loader>
>>> <boot dev='network'/>
>>> </os>
>>> <features>
>>> <acpi/>
>>> <apic/>
>>> <pae/>
>>> </features>
>>> <clock offset='variable' adjustment='0' basis='utc'/>
>>> <on_poweroff>destroy</on_poweroff>
>>> <on_reboot>restart</on_reboot>
>>> <on_crash>restart</on_crash>
>>> <devices>
>>> <interface type='bridge'>
>>> <mac address='02:02:00:03:00:00'/>
>>> <source bridge='enp1s0'/>
>>> <script path='vif-bridge'/>
>>> </interface>
>>> <serial type='pty'>
>>> <target port='0'/>
>>> </serial>
>>> <console type='pty'>
>>> <target type='serial' port='0'/>
>>> </console>
>>> <input type='mouse' bus='ps2'/>
>>> <input type='keyboard' bus='ps2'/>
>>> <graphics type='vnc' port='5901' autoport='no'
>>> listen='192.168.131.54'>
>>> <listen type='address' address='192.168.131.54'/>
>>> </graphics>
>>> </devices>
>>> </domain>
>>>
>>> --------------------------------------
>>>
>>> _______________________________________________
>>> libvirt-users mailing list
>>> libvirt-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/libvirt-users
>>>
>>>
>>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>
>
>
>
> _______________________________________________
> libvirt-users mailing listlibvirt-users at redhat.comhttps://www.redhat.com/mailman/listinfo/libvirt-users
>
>
> --
> Alvin Starr || land: (905)513-7688
> Netvel Inc. || Cell: (416)806-0133alvin at netvel.net ||
>
>
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>
--
Dominik Psenner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20170726/7bb8496f/attachment.htm>
More information about the libvirt-users
mailing list