search for: virutil

...We have managed to work around this by setting the flag to include “VIR_MIGRATE_TUNNELLED”. However, it is noticebaly slower than non tunnelled. We were hoping that setting the listen_addr would get libvirt to return the listen_addr rather than the hostname but virGetHostname in libvirt/src/util/virutil.c doesn’t have access to the config structure. I was wondering if libvirt can be patched in a way to return the ip address of the destination instead of the hostname during migration? Regards, Yagmur Akbulut

Hi there, Sorry for the cross-post, but I seeked help on this issue before on those lists, but nobody answered. :-( I'm trying to use virsh and virt-viewer on Windows. I'm running the latest binaries from http://spice-space.org/download.html, that is, virt-viewer-x64-0.5.7.msi on a Windows 7 64-bits computer. So far I got remote-viewer.exe to work, after some pain. But have no

netstat -lptu gives me tcp6 0 0 [::]:16514 [::]:* LISTEN 1314/libvirtd so the server is correctly listening on interfaces. My /etc/libvirt/libvirtd settings are defaulted. My /etc/default/libvirt-bin has "-d -l" options so server is listening. If I do virsh -c qemu://143.225.229.190/system (that is my ip or an ip belonging to my network) I

...fter that. But I can't find any FC host with: #virsh nodedev-list --cap fc_host SCSI hosts can be found for above "nodedev-list --cap scsi_host". The libvirt I am working on is based ver 1.0.5, I checked the code and found below function is seems related with this issue: src/util/virutil.c: int virIsCapableVport(const char *sysfs_prefix, int host) This function looks up if there is "vport_create" file under /sys/class/fc_host/host20, as the way to decide if a HBA device is capable of vport operation. But seems this file is not compiled and virsh doe...

...ny FC host with: > #virsh nodedev-list --cap fc_host > > SCSI hosts can be found for above "nodedev-list --cap scsi_host". > > The libvirt I am working on is based ver 1.0.5, I checked the code and found > below function is seems related with this issue: > src/util/virutil.c: > int > virIsCapableVport(const char *sysfs_prefix, > int host) > > This function looks up if there is "vport_create" file under > /sys/class/fc_host/host20, as the way to decide if a HBA device is capable of > vport operation. > > But see...

...ne interested enough submits patches. > > Even then virsh can't connect: > > virsh # connect qemu://kvmhost/system > error: Failed to connect to the hypervisor > error: Unable to set close-on-exec flag: Success Here, I wonder if we can't improve the situation; src/util/virutil.c:virSetInherit() does nothing, and its wrapper virSetCloseExec() should therefore always return 0, which makes it very suspicious - the message in src/rpc/virnetsocket.c about close-on-exec not working should never be reached. What version of virsh is included in that msi? Maybe it's just a...

...an 10 yeas. :-( >> Even then virsh can't connect: >> >> virsh # connect qemu://kvmhost/system >> error: Failed to connect to the hypervisor >> error: Unable to set close-on-exec flag: Success > Here, I wonder if we can't improve the situation; > src/util/virutil.c:virSetInherit() does nothing, and its wrapper > virSetCloseExec() should therefore always return 0, which makes it very > suspicious - the message in src/rpc/virnetsocket.c about close-on-exec > not working should never be reached. If you (or someone else) sends me testing or debuging b...

...then virsh can't connect: > >> > >> virsh # connect qemu://kvmhost/system > >> error: Failed to connect to the hypervisor > >> error: Unable to set close-on-exec flag: Success > > Here, I wonder if we can't improve the situation; > > src/util/virutil.c:virSetInherit() does nothing, and its wrapper > > virSetCloseExec() should therefore always return 0, which makes it very > > suspicious - the message in src/rpc/virnetsocket.c about close-on-exec > > not working should never be reached. > > If you (or someone else) sends...

...} + /* Handling a single connection on stdin/stdout. */ if (listen_stdin) { change_user (); @@ -752,3 +806,60 @@ parsegroup (const char *id) return grp->gr_gid; } + +/* Returns 0 if no socket activation, or the number of FDs. + * See also virGetListenFDs in libvirt.org:src/util/virutil.c + */ +static unsigned int +get_socket_activation (void) +{ + const char *s; + unsigned int pid; + unsigned int nr_fds; + unsigned int i; + int fd; + + s = getenv ("LISTEN_PID"); + if (s == NULL) + return 0; + if (sscanf (s, "%u", &pid) != 1) { + fprintf (stde...

...9;/> <domain type='qemu'/> <domain type='qemu'/> and by extension, running VMs as regular user works fine via qemu:///session , but qemu:///system does not work. It seems like setgroups is failing: https://github.com/libvirt/libvirt/blob/v5.5.0/src/util/virutil.c#L1045-L1051 Is this the expected behaviour? Marcus. -- Marcus Furlong

This is an incomplete port to Windows. Currently the server compiles and starts up successfully, but goes into an infinite loop when you connect to it. Nevertheless I think the approach is ready for feedback. This being Windows the changes go quite deep. Rich.