Alvin,
Thanks for that. I disabled the xendomains service (I had to do it
twice, as it seemed to re-enable itself after the first reboot) and it
now starts libvirtd automatically on startup.
However, all is not well!
"xl list" and "virsh list" will just hang
"systemctl stop libvirtd" just hangs and after this "ps aux" lists the
process as defunct
root 673 0.0 0.0 0 0 ? Zsl 08:04 0:00
[libvirtd] <defunct>
"kill -KILL 673" has no effect
"shutdown -r now" also hangs (I have to physically power off the
machine) irrespectively of whether I have tried to stop the service
before shutdown or not.
None of this happened yesterday when I manually started libvirtd after
bootup (when xendomains was still running).
The logs show nothing in error or warning category, just a heap of info
(I have the logs set to level 2). Is there anything in particular that I
should be looking for in the logs?
Regarding the use of a VM to access the host in a remote location... I
had considered this and there was little choice. The machine is on the
end of a VDSL line and was installed to consolidate a few servers in
that location in order to save power. I figured that automatically
starting a VM that ran the networking was not much more risk than a
physical server that had to start up its networking, and that has (so
far) proven to be true with all of the remote restarts & power outages
to date. The only other option is an expensive second link to the host,
and I've decided to live with the possibility of having to talk someone
through a restart over the phone rather than go down that route.
Interestingly, with the NBN in Australia (the country-wide rollout of
fibre or broadband to every premises) they have effectively converted
all our phone lines to VoIP. This has resulted in the old physical
landline now requiring one of the VMs to be running as well, so if I
ever need to talk someone through a restart it will need to be on a
mobile phone.
Thank you
GC
On 27/07/2017 5:47 AM, Alvin Starr wrote:
I addressed the fix to Jim but I should have addressed it to you.
Try systemctl disable xendomains.service
It is conflicting with libvirtd.service.
I found it by using
"systemd-analyze dot libvirtd.service | dot -Tgif > /tmp/dot1.gif"
It looks like libvirt-daemon-driver-xen or
libvirt-daemon-driver-libxl should disable the xendomains.service
On 07/26/2017 06:46 AM, G Crowe 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@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/Fedora_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:00000121: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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
