- Users - libvirt List Archives

[libvirt-users] virsh dump
by Leekitty 11 Apr '16

11 Apr '16

Hi I want to use “virsh dump ”to only get the memory of a domain,but I do not know the image format 。 Questions: How can I get the memory by using “virsh dump” Wen Lee

3 2

[libvirt-users] create a network such as default network
by Mohsen Pahlevanzadeh 11 Apr '16

11 Apr '16

Dear All, When user uses `virsh net-define xmlfile` , User only define an xml file in `/etc/libvirt/qemu/networks`. I created an uuid and another bridge in related xml file. But I need to create the following files for my network: `default.addnhosts default.conf default.hostsfile virbr0.status` Question is , can I create them via cmd? --Best regards mohsen

2 1

[libvirt-users] libvirtd vs XDG_RUNTIME_DIR
by Lars Kellogg-Stedman 09 Apr '16

09 Apr '16

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/

4 4

[libvirt-users] (no subject)
by nidhi d 07 Apr '16

07 Apr '16

How is tunnelled option specified during migratiion different than an ordinary ssh connection specified as:- virsh migrate vmName qemu+ssh://user@remotesys/system?

5 18

[libvirt-users] Domain, volume and storage-pool
by Shahar Havivi 07 Apr '16

07 Apr '16

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.

2 1

[libvirt-users] Encrytped USB devices
by Daniel Vázquez 05 Apr '16

05 Apr '16

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.

1 0

[libvirt-users] Can you get page dirtying information on non-migrating VMs?
by tfcyundlim dehasawzdg 05 Apr '16

05 Apr '16

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

2 1

[libvirt-users] LXC don't support network type of ethernet
by Pradeep kumar 04 Apr '16

04 Apr '16

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

1 0

[libvirt-users] hanging libvirtd 1.2.17 centos7
by Philippe D'Anjou 04 Apr '16

04 Apr '16

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@@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@@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@@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@@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@@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@@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@@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@@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@@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@@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@@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@@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@@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@@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 ()

1 0

[libvirt-users] dynamic_ownership behavior with volumes
by Hyeonseop Lee 02 Apr '16

02 Apr '16

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!

1 0