[libvirt-users] libvirtd vs XDG_RUNTIME_DIR
by Lars Kellogg-Stedman
I ran into an odd problem today. I wanted to share it here in the
hopes of maybe saving someone else some lost time.
When you run libvirtd as an unprivileged user (e.g., if you target
qemu:///session from a non-root account), then libvirt will open a
unix domain socket in one of two places:
- If XDG_RUNTIME_DIR is defined, then inside
$XDG_RUNTIME_DIR/libvirt/libvirt-sock
- If XDG_RUNTIME_DIR is *not* defined, then inside
$HOME/.cache/libvirt/libvirt-sock
With a CentOS 7 system, at least, if you ssh directly into an
account, XDG_RUNTIME_DIR is set. But! If you `su -` to the account
from root, e.g:
# su - stack
Then XDG_RUNTIME_DIR is *not* set. The problem is a little subtle,
because most operations you will perform will work just fine in both
cases: you can query for defined but not active guests, storagep
pools, volumes, and so forth without a problem and you'll get the same
answer.
The problem crops up when you start a guest, which results in a
persistent libvirtd process. Now, depending on how you got to your
account, you will either (a) talk to the persistent process, and
you'll be able to see the running guests, or (b) you'll end up
spawning a new ephemeral libvirtd process listening in the *other*
location, and you won't see anything, and you will wonder why there is
a qemu process running for your guest but it's not showing up in
"virsh list" and what the heck is going on here.
I don't know if there's a good solution to this, but the failure mode
is really non-obvious.
Cheers,
--
Lars Kellogg-Stedman <lars(a)redhat.com> | larsks @ {freenode,twitter,github}
Cloud Engineering / OpenStack | http://blog.oddbit.com/
8 years, 7 months
[libvirt-users] (no subject)
by nidhi d
How is tunnelled option specified during migratiion different than an
ordinary ssh connection specified as:- virsh migrate vmName
qemu+ssh://user@remotesys/system?
8 years, 7 months
[libvirt-users] Domain, volume and storage-pool
by Shahar Havivi
Hi,
I am using virStorageVolDownload to download volumes for the VDSM project.
What is the best approch to know domains volume?
Is there an api for associating domain to its pool and then to its volumes?
I was able to do that by iterating the pools and then iterating all its
volume..., is there a better way?
Thank you,
Shahar Havivi.
8 years, 7 months
[libvirt-users] Encrytped USB devices
by Daniel Vázquez
Hi here!
How libvirt virsh solves attachment of hot plug/unplug encrytped USB devices??
We've no problems attaching full encrypted(LUKS) usb disk or memory
pen to guest using virsh attach-disk command. But not working using
virsh attach-device to use USB pass-through and hot plug/unplug
features. USB pass-through works properly without encryption.
Any procedure to make it working?, attach-disk expects for a static
source (for example /dev/sdX), and we need some dynamical source
assigment due USB temporal and different host target, it's why we're
trying the attachment via attach-device to take advantage of
plug/unplug via USB pass-through, but only works on non-encrypted usb
devices.
We unknow if exist any alternatively way to make attach-disk more
dinamically, maybe by udev script or uuid source identification and
some re-attach procedure, any recommendation?? or virsh command direct
solution??
Thanks
P.D. Please be free to move at libvir-list(a)redhat.com (for
development) if it's a new requested feature or fixing.
8 years, 7 months
[libvirt-users] Can you get page dirtying information on non-migrating VMs?
by tfcyundlim dehasawzdg
Hello everyone,
I've been looking through the libvirt API to get information about
memory page dirtying of VMs. I need these to aid decisions on which VM
to migrate.
The only thing I found is
virDomainGetJobStats()
with
VIR_DOMAIN_JOB_MEMORY_DIRTY_RATE
but that only works when a migration is already running.
Is there a way to get information on VMs which are not already migrating?
Thanks and best regards,
Dave
8 years, 7 months
[libvirt-users] LXC don't support network type of ethernet
by Pradeep kumar
Hi All,
Applied patch from below link in order to add ethernet network type support
to LXC.
https://www.redhat.com/archives/libvir-list/2016-January/msg00318.html
Launching LXC based VM using openstack Icehouse release which uses libvirt
in background fails with below error:
LOG shows "*error : virNetDevVethCreate:196 : internal error: Failed to
allocate free veth pair after 10 attempts*" and also gives* ret == -1
for* *virNetDevVethCreate
which depicts that "**virNetDevVethCreate" failed.*
But by defining XML file manually using *virsh* *utility* I am able to
launch LXC based VM successfully with network type Ethernet.
*Something went wrong while launching the same with openstack nova. *
Please help as I am quite new to this virtualization world. Its urgent any
help/pointers are welcome.
Thanks
Pradeep Kumar
Regards
Pradeep Kumar
8 years, 7 months
[libvirt-users] hanging libvirtd 1.2.17 centos7
by Philippe D'Anjou
Hi,I am having an issue on several KVM hosts which run CentOs7 and libvirt-daemon-1.2.17-13.el7_2.3.x86_64 .About once a week the libvirtd hangs forever and becomes unresponsive, the only help is to restart it. I attached gdb to it and the output of it can be seen at the end of the mail. Laine from the irc channel suggests it has to do with dbus/policykit. If anybody got an idea what it could be and point me in the right direction or help further analyzing this issue I'd be very grateful.
kind regards
Philippe d'Anjou
(gdb) thread apply all bt
Thread 16 (Thread 0x7f275e916700 (LWP 1973)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 15 (Thread 0x7f275e115700 (LWP 1974)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 14 (Thread 0x7f275d914700 (LWP 1975)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 13 (Thread 0x7f275d113700 (LWP 1976)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 12 (Thread 0x7f275c912700 (LWP 1977)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 11 (Thread 0x7f275c111700 (LWP 1978)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df325ab in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 10 (Thread 0x7f275b910700 (LWP 1979)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df325ab in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 9 (Thread 0x7f275b10f700 (LWP 1980)):
#0 0x00007f276b2bfc3d in poll () from /lib64/libc.so.6
#1 0x00007f276c5bc770 in socket_do_iteration () from /lib64/libdbus-1.so.3
#2 0x00007f276c5bb5ef in _dbus_transport_do_iteration () from /lib64/libdbus-1.so.3
#3 0x00007f276c5a4d7c in _dbus_connection_do_iteration_unlocked () from /lib64/libdbus-1.so.3
#4 0x00007f276c5a583c in _dbus_connection_block_pending_call () from /lib64/libdbus-1.so.3
#5 0x00007f276c5a5d3a in dbus_connection_send_with_reply_and_block () from /lib64/libdbus-1.so.3
#6 0x00007f276deea258 in virDBusCallMethod () from /lib64/libvirt.so.0
#7 0x00007f276df1fd14 in virPolkitCheckAuth () from /lib64/libvirt.so.0
#8 0x00007f276ec1d83a in remoteDispatchAuthPolkitHelper ()
#9 0x00007f276e03c4e2 in virNetServerProgramDispatch () from /lib64/libvirt.so.0
#10 0x00007f276e03775d in virNetServerHandleJob () from /lib64/libvirt.so.0
#11 0x00007f276df324f5 in virThreadPoolWorker () from /lib64/libvirt.so.0
#12 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#13 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 8 (Thread 0x7f275a90e700 (LWP 1981)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df325ab in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 7 (Thread 0x7f275a10d700 (LWP 1982)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df325ab in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 6 (Thread 0x7f2754c89700 (LWP 1985)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
---Type <return> to continue, or q <return> to quit---
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 5 (Thread 0x7f2754488700 (LWP 1986)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 4 (Thread 0x7f2753c87700 (LWP 1987)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 3 (Thread 0x7f2753486700 (LWP 1988)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 2 (Thread 0x7f2752c85700 (LWP 1989)):
#0 0x00007f276b5a06d5 in pthread_cond_wait@(a)GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007f276df31c86 in virCondWait () from /lib64/libvirt.so.0
#2 0x00007f276df3258b in virThreadPoolWorker () from /lib64/libvirt.so.0
#3 0x00007f276df31a18 in virThreadHelper () from /lib64/libvirt.so.0
#4 0x00007f276b59cdc5 in start_thread () from /lib64/libpthread.so.0
#5 0x00007f276b2ca28d in clone () from /lib64/libc.so.6
Thread 1 (Thread 0x7f276eb7a8c0 (LWP 1971)):
#0 0x00007f276b2bfc3d in poll () from /lib64/libc.so.6
#1 0x00007f276def0556 in virEventPollRunOnce () from /lib64/libvirt.so.0
#2 0x00007f276deef032 in virEventRunDefaultImpl () from /lib64/libvirt.so.0
#3 0x00007f276e037035 in virNetDaemonRun () from /lib64/libvirt.so.0
#4 0x00007f276ebfc524 in main ()
8 years, 7 months
[libvirt-users] dynamic_ownership behavior with volumes
by Hyeonseop Lee
Hi,
I'm having troubles with volume ownership.
When I configure domain with disk type='file', dynamic_ownership works
fine, the owner of image file changes into libvirt-qemu:kvm. However when I
add the image file as a libvirt volume (in default pool) and configure
domain with disk type=volume, the owner of image file remains root:root.
Actually, libvirt seems to be changing the owner into root:root even after
I manually changed it. Is this intended behavior?
If so, what is preferred way to set ownership of volume image files,
instead of running qemu as root?
FYI, I'm using libvirt 1.2.2 on Ubuntu 14.04.
Thank you!
8 years, 7 months
[libvirt-users] Using virDomainInterfaceAddresses
by Marin Bek
Hi,
I'm trying to use virDomainInterfaceAddresses to get interface info for XEN
DOMs but keep getting following error:
libvirt: Domain Config error : this function is not supported by the
connection driver: virDomainInterfaceAddresses
I tried recompiling libvirt with ./configure --with-interface
--with-network and it all went fine but still no luck.
Am i missing something?
Thanks,
Marin
8 years, 7 months
[libvirt-users] How is calculate the lock with lockd_manager
by villeneu＠kassis.univ-brest.fr
Hello
I use lock_manager with libvirt 1.3 and
I would like to know how is exactly calculate the hash SHA256. I would
create a table
to retreive the name with the hash in case of crash to release manualy the
lock.
I do an sha256 hash from /var/lib/libvirt/images/lock/MyVM.img but I
don't get the same hash code
form virtlockd ?
Any Ideas ?
Best regards
-----
PS:
sorry for my previous mail it was in a wrong thread
8 years, 7 months
