Re: [libvirt] RFC: 'old' event for leaseshelper.c when lease renews
On 06/30/14 22:49, Nehal J Wani wrote:
I'd prefer (i) since that lets libvirt work properly with existing
dnsmasq versions which are deployed.
Regards,
Daniel
I cleared some more queries regarding leasesfile-ro option. Once can
read the conversation at
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008656.html.
TL;DR:
(i) We have to change the leasehelper program to honor the event
'init' and print leases info in dnsmasq leases format (so that dnsmasq
knows about previous leases if it is restarted for some reason).
(ii) Since we support DHCPv6, we will need to modify the JSON format
to store server DUID too. Since we have one custom leases file for
each network, I think it will suffice to store the DUID is just once
in the JSON. Something like this:
[
server-duid: 00:01:00:01:1b:40:8d:94:00:25:
64:8b:e4:2c
{
iaid: 1221229,
ip-address: 2001:db8:ca2:2:1::95,
mac-address: 52:54:00:12:a2:6d,
hostname: Fedora20,
client-id: 00:04:1a:c1:d9:6b:5a:0a:e2:
bc:f8:4b:1e:37:2e:38:22:55
,
expiry-time: 1393244216
},
{
ip-address: 192.168.150.208,
mac-address: 52:54:00:11:56:b3,
hostname: Wani-PC,
client-id: 01:52:54:00:11:56:b3,
expiry-time: 1393244248
}
]
Do we want this in 1.2.6?
It's too late for 1.2.6, the release should happen any time today.
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] odd message from latest libvirt.git
[added Michal] On 07/01/14 06:29, Eric Blake wrote: # ./run daemon/libvirtd 2014-07-01 04:27:19.913+: 1160: info : libvirt version: 1.2.6 2014-07-01 04:27:19.913+: 1160: error : virFileReadAll:1297 : Failed to read file '/sys/class/net/wlp3s0/speed': Invalid argument This is probably a kernel bug in Fedora 20; but we shouldn't be polluting the logs just because of the kernel being unable to read a file that it claims exists: # ls -l /sys/class/net/wlp3s0/speed -r--r--r--. 1 root root 4096 Jun 28 07:41 /sys/class/net/wlp3s0/speed # cat /sys/class/net/wlp3s0/speed cat: /sys/class/net/wlp3s0/speed: Invalid argument Looks like the code detecting network interface link speeds that Michal was adding recently caused this. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: don't break the build on Xen=4.5 because of libxl_vcpu_setaffinity()
On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote: Eric Blake wrote: Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable. Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push. Thanks Eric, pushed now. Cool! Thanks Everyone, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC][scale] new API for querying domains stats
Hi everyone, I'd like to discuss possible APIs and plans for new query APIs in libvirt. I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM; VDSM is the node management daemon, which is in charge, among many other things, to gather the host and statistics per Domain/VM. Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans to scale much more, and to possibly reach thousands in a not so distant future. At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk), and of course this obviously scales poorly. This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously python 2.x behaves very badly with threads. We are already working to improve our code, but I'd like to bring the discussion here and see if and when the querying API can be improved. We currently use these APIs for our sempling: virDomainBlockInfo virDomainGetInfo virDomainGetCPUStats virDomainBlockStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetMetadata What we'd like to have is * asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106) This would be just awesome. Either a single callback or a different one per call is fine (let's discuss this!). please note that we are much more concerned about thread reduction then about performance numbers. We had report of thread number becoming a real harm, while performance so far is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) * bulk APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113116) would be really welcome as well. It is quite independent from the previous bullet point and would help us greatly with scale. So, I'd like to discuss if these additions are (or can be) in the project roadmap, and, if so, how the API could look like and what the possible timeframe could be. Of course I'd be happy to provide any further information about VDSM and its workings. Thoughts very welcome! Thanks and best regards, -- Francesco Romani RedHat Engineering Virtualization R D Phone: 8261328 IRC: fromani -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: raise an error when trying to use readonly ide disks
Martin Kletzander mklet...@redhat.com writes: If the user updates from QEMU without DRIVE_READONLY to newer one, that supports that flag, than XML with readonly IDE HDD will stop working even though it worked before the update *as requested*. That readonly flag does not reflect how the disk is exposed in the guest; as you said IDE does not have any readonly concept, that is only how the device reacts to writes. Changing the behaviour to: if (disk-readonly virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_READONLY) !(disk-bus == VIR_DOMAIN_DISK_BUS_IDE disk-device == VIR_DOMAIN_DISK_DEVICE_DISK)) virBufferAddLit(opt, ,readonly=on); would keep the backward compatibility. This behaviour makes more sense to me. this behaves in a quite different way that my proposed patch but if readonly/ affects also the SELinux label and we allow the process to run anyway by skipping readonly=on for IDE disks, wouldn't qemu fail in weird ways when trying to write to the file? Regards, Giuseppe -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] odd message from latest libvirt.git
On 07/01/2014 06:29 AM, Eric Blake wrote: # ./run daemon/libvirtd 2014-07-01 04:27:19.913+: 1160: info : libvirt version: 1.2.6 2014-07-01 04:27:19.913+: 1160: error : virFileReadAll:1297 : Failed to read file '/sys/class/net/wlp3s0/speed': Invalid argument This is probably a kernel bug in Fedora 20; but we shouldn't be polluting the logs just because of the kernel being unable to read a file that it claims exists: # ls -l /sys/class/net/wlp3s0/speed -r--r--r--. 1 root root 4096 Jun 28 07:41 /sys/class/net/wlp3s0/speed # cat /sys/class/net/wlp3s0/speed cat: /sys/class/net/wlp3s0/speed: Invalid argument Patches 3 and 4 from this series of mine deal with that error: https://www.redhat.com/archives/libvir-list/2014-June/msg01453.html Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] libxl: Implement basic video device selection
being as bad with timely responses. Ok, so how about the following?
One note: it could be the STRDUP's are not strictly needed. But
to me it felt wrong to have two places refer to the same strings
(as MakeVFB copies the struct containing the pointers). If this
is not needed, then all changes now in MakeVFB probably can be
dropped (except setting the keyboard layout, maybe; which I
might miss ;)).
-Stefan
From a95db265fa4c1a231e7c2d70baa360c6a0500e3b Mon Sep 17 00:00:00 2001
From: Stefan Bader stefan.ba...@canonical.com
Date: Thu, 27 Mar 2014 16:01:18 +0100
Subject: [PATCH] libxl: Implement basic video device selection
This started as an investigation into an issue where libvirt (using the
libxl driver) and the Xen host, like an old couple, could not agree on
who is responsible for selecting the VNC port to use.
Things usually (and a bit surprisingly) did work because, just like that
old couple, they had the same idea on what to do by default. However it
was possible that this ended up in a big argument.
The problem is that display information exists in two different places:
in the vfbs list and in the build info. And for launching the device model,
only the latter is used. But that never gets initialized from libvirt. So
Xen allows the device model to select a default port while libvirt thinks
it has told Xen that this is done by libvirt (though the vfbs config).
While fixing that, I made a stab at actually evaluating the configuration
of the video device. So that it is now possible to at least decide between
a Cirrus or standard VGA emulation and to modify the VRAM within certain
limits using libvirt.
[v2: Check return code of VIR_STRDUP and fix indentation]
[v3: Split out VRAM fixup and return error for unsupported video type]
[v4: Re-arrange code and move VFB setup into libxlMakeVfbList]
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
---
src/libxl/libxl_conf.c | 63 ++--
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index 8eeaf82..43cabcf 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1098,10 +1098,21 @@ libxlMakeVfbList(virPortAllocatorPtr graphicsports,
libxl_domain_build_info *b_info = d_config-b_info;
libxl_device_vfb vfb = d_config-vfbs[0];
-if (libxl_defbool_val(vfb.vnc.enable))
+if (libxl_defbool_val(vfb.vnc.enable)) {
memcpy(b_info-u.hvm.vnc, vfb.vnc, sizeof(libxl_vnc_info));
-else if (libxl_defbool_val(vfb.sdl.enable))
+if (VIR_STRDUP(b_info-u.hvm.vnc.listen, vfb.vnc.listen) 0)
+goto error;
+if (VIR_STRDUP(b_info-u.hvm.vnc.passwd, vfb.vnc.passwd) 0)
+goto error;
+} else if (libxl_defbool_val(vfb.sdl.enable)) {
memcpy(b_info-u.hvm.sdl, vfb.sdl, sizeof(libxl_sdl_info));
+if (VIR_STRDUP(b_info-u.hvm.sdl.display, vfb.sdl.display) 0)
+goto error;
+if (VIR_STRDUP(b_info-u.hvm.sdl.xauthority, vfb.sdl.xauthority)
0)
+goto error;
+}
+if (VIR_STRDUP(b_info-u.hvm.keymap, vfb.keymap) 0)
+goto error;
}
return 0;
@@ -1363,6 +1374,45 @@ libxlMakeCapabilities(libxl_ctx *ctx)
return NULL;
}
+static int
+libxlMakeVideo(virDomainDefPtr def, libxl_domain_config *d_config)
+{
+libxl_domain_build_info *b_info = d_config-b_info;
+
+if (d_config-c_info.type != LIBXL_DOMAIN_TYPE_HVM)
+return 0;
+
+/*
+ * Take the first defined video device (graphics card) to display
+ * on the first graphics device (display).
+ * Right now only type and vram info is used and anything beside
+ * type xen and vga is mapped to cirrus.
+ */
+if (def-nvideos) {
+switch (def-videos[0]-type) {
+case VIR_DOMAIN_VIDEO_TYPE_VGA:
+case VIR_DOMAIN_VIDEO_TYPE_XEN:
+b_info-u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD;
+break;
+case VIR_DOMAIN_VIDEO_TYPE_CIRRUS:
+b_info-u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS;
+break;
+default:
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ %s,
+ _(video type not supported by libxl));
+return -1;
+}
+b_info-video_memkb = def-videos[0]-vram ?
+ def-videos[0]-vram :
+ LIBXL_MEMKB_DEFAULT;
+} else {
+libxl_defbool_set(b_info-u.hvm.nographic, 1);
+}
+
+return 0;
+}
+
int
libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
virDomainDefPtr def,
@@ -1389,6 +1439,15 @@ libxlBuildDomainConfig(virPortAllocatorPtr graphicsports,
if (libxlMakePCIList(def, d_config) 0)
return -1;
+/*
+ * Now that any potential VFBs are defined, it
Re: [libvirt] [PATCH] libxl: don't break the build on Xen=4.5 because of libxl_vcpu_setaffinity()
On Tue, 2014-07-01 at 08:52 +0200, Dario Faggioli wrote: On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote: Eric Blake wrote: Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable. Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push. Thanks Eric, pushed now. Cool! Thanks Everyone, And thanks Dario for the quick fix. WRT Xen's automated testing the new libvirt should get tested today and the result be picked up for a xen-unstable run shortly after, so staging ought to be unblocked by ~tomorrow, barring any other failures. I've added does libvirt need a peemptive update? to my mental checklist for things involved LIBXL_API_VERSION changes. Cheers, Ian. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 29/29] qemu: snapshot: Use storage driver to pre-create snapshot file
On 06/30/14 17:20, Peter Krempa wrote:
Move the last operation done on local files to the storage driver API.
---
src/qemu/qemu_driver.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 281c648..79970f2 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
I forgot to amend the following hunk to this patch before sending:
@@ -12829,7 +12829,6 @@
qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
char *source = NULL;
const char *formatStr = NULL;
int ret = -1;
-int fd = -1;
bool need_unlink = false;
if (snap-snapshot != VIR_DOMAIN_SNAPSHOT_LOCATION_EXTERNAL) {
@@ -12847,7 +12847,7 @@
qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
if (virStorageSourceInitChainElement(newDiskSrc, disk-src, false) 0)
goto cleanup;
-if (virStorageFileInit(newDiskSrc) 0)
+if (qemuDomainStorageFileInit(driver, vm, newDiskSrc) 0)
goto cleanup;
if (qemuGetDriveSourceString(newDiskSrc, NULL, source) 0)
@@ -12863,15 +12863,13 @@
qemuDomainSnapshotCreateSingleDiskActive(virQEMUDriverPtr driver,
}
/* pre-create the image file so that we can label it before handing it
to qemu */
-/* XXX we should switch to storage driver based pre-creation of the
image */
-if (virStorageSourceIsLocalStorage(newDiskSrc)) {
-if (!reuse newDiskSrc-type != VIR_STORAGE_TYPE_BLOCK) {
-fd = qemuOpenFile(driver, vm, source, O_WRONLY | O_TRUNC |
O_CREAT,
- need_unlink, NULL);
-if (fd 0)
-goto cleanup;
-VIR_FORCE_CLOSE(fd);
+if (!reuse newDiskSrc-type != VIR_STORAGE_TYPE_BLOCK) {
+if (virStorageFileCreate(newDiskSrc) 0) {
+virReportSystemError(errno, _(failed to create image file
'%s'),
+ source);
+goto cleanup;
}
+need_unlink = true;
}
/* set correct security, cgroup and locking options on the new image */
Peter
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: raise an error when trying to use readonly ide disks
On Tue, Jul 01, 2014 at 09:40:00AM +0200, Giuseppe Scrivano wrote: Martin Kletzander mklet...@redhat.com writes: If the user updates from QEMU without DRIVE_READONLY to newer one, that supports that flag, than XML with readonly IDE HDD will stop working even though it worked before the update *as requested*. That readonly flag does not reflect how the disk is exposed in the guest; as you said IDE does not have any readonly concept, that is only how the device reacts to writes. Changing the behaviour to: if (disk-readonly virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_READONLY) !(disk-bus == VIR_DOMAIN_DISK_BUS_IDE disk-device == VIR_DOMAIN_DISK_DEVICE_DISK)) virBufferAddLit(opt, ,readonly=on); would keep the backward compatibility. This behaviour makes more sense to me. this behaves in a quite different way that my proposed patch but if readonly/ affects also the SELinux label and we allow the process to run anyway by skipping readonly=on for IDE disks, wouldn't qemu fail in weird ways when trying to write to the file? My case was that it doesn't fail in a new way if you update from older qemu that didn't support the DRIVE_READONLY capability. However it would probably fail differently when there is readonly=on because it would not report an error in the guest. Anyway, thinking about it, qemu doesn't start for some versions of libvirt already with these setting, this just changes the error to a more readable one. So given the circumstances such backward compatibility is not such huge issue (since we already broke it). I, therefore, agree with Dan's ACK. Martin signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][scale] new API for querying domains stats
On Tue, Jul 01, 2014 at 03:09:13AM -0400, Francesco Romani wrote: Hi everyone, I'd like to discuss possible APIs and plans for new query APIs in libvirt. I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM; VDSM is the node management daemon, which is in charge, among many other things, to gather the host and statistics per Domain/VM. Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans to scale much more, and to possibly reach thousands in a not so distant future. At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk), and of course this obviously scales poorly. This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously python 2.x behaves very badly with threads. We are already working to improve our code, but I'd like to bring the discussion here and see if and when the querying API can be improved. We currently use these APIs for our sempling: virDomainBlockInfo virDomainGetInfo virDomainGetCPUStats virDomainBlockStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetMetadata Why do you need to call virDomainGetMetadata so often ? That merely contains a opaque data blob that can only have come from VDSM itself, so I'm surprised you need to call that at all frequently. What we'd like to have is * asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106) This would be just awesome. Either a single callback or a different one per call is fine (let's discuss this!). please note that we are much more concerned about thread reduction then about performance numbers. We had report of thread number becoming a real harm, while performance so far is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) * bulk APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113116) would be really welcome as well. It is quite independent from the previous bullet point and would help us greatly with scale. If we did the first bullet point, we'd be adding another ~10 APIs for async variants. If we then did the second bullet point we'd be adding another ~10 APIs for bulk querying. So while you're right that they are independent, it would be desirable to address them both at the same time, so we only need to add 10 new APIs in total, not 20. For the async API design, I could see two potential designs 1. A custom callback to run per API typedef (void)(*virDomainBlockInfoCallback)(virDomainPtr dom, bool isError, virDomainBlockInfoPtr info, void *opaque); int virDomainGetBlockInfoAsync(virDomainPtr dom, const char *disk, virDomainBlockInfoCallback cb, void *opaque, unsigned int flags); 2. A standard callback and a pair of APIs typedef void *virDomainAsyncResult; typedef (void)(*virDomainAsyncCallback)(virDomainPtr dom, virDomainAsyncResult res); void virDomainGetBlockInfoAsync(virDomainPtr dom, const char *disk, virDomainBlockInfoCallback cb, void *opaque, unsigned int flags); int virDomainGetBlockInfoFinish(virDomainPtr dom, virDomainAsyncResult res, virDomainBlockInfoPtr info); This second approach is the way GIO works (see example in this page https://developer.gnome.org/gio/stable/GAsyncResult.html ). The main difference between them really is probably the way you get error reporting from the APIs. In the first example, libvirt would raise an error before it invoked the callback, with isError set to True. In the second example, the Finish() func would raise the error and return -1. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: don't break the build on Xen=4.5 because of libxl_vcpu_setaffinity()
On mar, 2014-07-01 at 09:01 +0100, Ian Campbell wrote: On Tue, 2014-07-01 at 08:52 +0200, Dario Faggioli wrote: On lun, 2014-06-30 at 15:32 -0600, Jim Fehlig wrote: Eric Blake wrote: Thanks, looks good. I was about to push, but wanted to check with other libvirt devs first since we are in 1.2.6 freeze. Would it be fine to push this? It fixes a libxl driver build failure against xen-unstable. Yes, fixing a build failure is an acceptable fix during hard freeze. Go ahead and push. Thanks Eric, pushed now. Cool! Thanks Everyone, And thanks Dario for the quick fix. Well, it could (and should!) have been quicker, but it collapsed with an update of the test box I devote to Xen+libvirt hack/testing... I've added keep that box in a more good shape to my menta checklist. :-) I've added does libvirt need a peemptive update? to my mental checklist for things involved LIBXL_API_VERSION changes. Me too, and actually, looking at things from this perspective, I think the push gate did a good job _as_it_is_ in highlighting how much careful we should be with the libxl interface, and that things either get fixed quickly or changes be reverted. Just thinking out loud here but, if we did not get the push failure, when would have we discovered this? Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][scale] new API for querying domains stats
On 01.07.2014 09:09, Francesco Romani wrote: Hi everyone, I'd like to discuss possible APIs and plans for new query APIs in libvirt. I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM; VDSM is the node management daemon, which is in charge, among many other things, to gather the host and statistics per Domain/VM. Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans to scale much more, and to possibly reach thousands in a not so distant future. At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk), and of course this obviously scales poorly. I think this is your main problem. Why not have only one thread that would manage list of domains to query and issue the APIs periodically instead of having one thread per domain? This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously python 2.x behaves very badly with threads. We are already working to improve our code, but I'd like to bring the discussion here and see if and when the querying API can be improved. We currently use these APIs for our sempling: virDomainBlockInfo virDomainGetInfo virDomainGetCPUStats virDomainBlockStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetMetadata What we'd like to have is * asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106) This would be just awesome. Either a single callback or a different one per call is fine (let's discuss this!). please note that we are much more concerned about thread reduction then about performance numbers. We had report of thread number becoming a real harm, while performance so far is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) I'm not a big fan of this approach. I mean, IIRC python has this Big Python Lock, which effectively prevents two threads run concurrently. So while in C this would make perfect sense, it doesn't do so in python. The callbacks would be called from the event loop, which given how frequently you dump the info will block other threads. Therefore I'm afraid the approach would not bring any speed up, rather slow down. * bulk APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113116) would be really welcome as well. It is quite independent from the previous bullet point and would help us greatly with scale. I think this one looks better. Especially if you consider my suggestion of having only one thread to serve all domains. So, I'd like to discuss if these additions are (or can be) in the project roadmap, and, if so, how the API could look like and what the possible timeframe could be. Of course I'd be happy to provide any further information about VDSM and its workings. Thoughts very welcome! Thanks and best regards, Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC][scale] new API for querying domains stats
On Tue, Jul 01, 2014 at 11:19:04AM +0200, Michal Privoznik wrote: On 01.07.2014 09:09, Francesco Romani wrote: Hi everyone, I'd like to discuss possible APIs and plans for new query APIs in libvirt. I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM; VDSM is the node management daemon, which is in charge, among many other things, to gather the host and statistics per Domain/VM. Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans to scale much more, and to possibly reach thousands in a not so distant future. At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk), and of course this obviously scales poorly. I think this is your main problem. Why not have only one thread that would manage list of domains to query and issue the APIs periodically instead of having one thread per domain? You suffer from round trip time on every API call if you serialize it all in a single thread. eg if every API call is 50ms and you want to check once per scond, you can only monitor 20 VMs before you take more time than you have available. This really sucks when the majority of that 50ms is a sleep in poll() waiting for the RPC response. This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously python 2.x behaves very badly with threads. We are already working to improve our code, but I'd like to bring the discussion here and see if and when the querying API can be improved. We currently use these APIs for our sempling: virDomainBlockInfo virDomainGetInfo virDomainGetCPUStats virDomainBlockStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetMetadata What we'd like to have is * asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106) This would be just awesome. Either a single callback or a different one per call is fine (let's discuss this!). please note that we are much more concerned about thread reduction then about performance numbers. We had report of thread number becoming a real harm, while performance so far is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) I'm not a big fan of this approach. I mean, IIRC python has this Big Python Lock, which effectively prevents two threads run concurrently. So while in C this would make perfect sense, it doesn't do so in python. The callbacks would be called from the event loop, which given how frequently you dump the info will block other threads. Therefore I'm afraid the approach would not bring any speed up, rather slow down. I'm not sure I agree with your assessment here. If we consider a single API call, the time this takes to complete is made up of a number of parts 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket ...and so on.. If the time for item 2 dominates over the time for items 1 2 (which it should really) then the client thread is going to be sleeping in a poll() for the bulk of the duration of the libvirt API call. If we had an async API mechanism, then the VDSM time would essentially be consumed with 1. Time to write() the RPC call to the socket 2. Time to write() the RPC call to the socket 3. Time to write() the RPC call to the socket 4. Time to write() the RPC call to the socket 5. Time to write() the RPC call to the socket 6. Time to write() the RPC call to the socket 7. wait for replies to start arriving 8. Time to recv() the RPC reply from the socket 9. Time to recv() the RPC reply from the socket 10. Time to recv() the RPC reply from the socket 11. Time to recv() the RPC reply from the socket 12. Time to recv() the RPC reply from the socket 13. Time to recv() the RPC reply from the socket 14. Time to recv() the RPC reply from the socket Of course there's a limit to how many outstanding async calls you can make before the event loop gets 100% busy processing the responses, but I don't think that makes async calls worthless. Even if we had the bulk list API calls, async calling would be useful, because it would let VDSM fire off requests for disk, net, cpu, mem stats in parallel from a single thread. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o-
Re: [libvirt] [RFC][scale] new API for querying domains stats
On 01.07.2014 11:33, Daniel P. Berrange wrote: On Tue, Jul 01, 2014 at 11:19:04AM +0200, Michal Privoznik wrote: On 01.07.2014 09:09, Francesco Romani wrote: Hi everyone, I'd like to discuss possible APIs and plans for new query APIs in libvirt. I'm one of the oVirt (http://www.ovirt.org) developers, and I write code for VDSM; VDSM is the node management daemon, which is in charge, among many other things, to gather the host and statistics per Domain/VM. Right now we aim for a number of VM per node in the (few) hundreds, but we have big plans to scale much more, and to possibly reach thousands in a not so distant future. At the moment, we use one thread per VM to gather the VM stats (CPU, network, disk), and of course this obviously scales poorly. I think this is your main problem. Why not have only one thread that would manage list of domains to query and issue the APIs periodically instead of having one thread per domain? You suffer from round trip time on every API call if you serialize it all in a single thread. eg if every API call is 50ms and you want to check once per scond, you can only monitor 20 VMs before you take more time than you have available. This really sucks when the majority of that 50ms is a sleep in poll() waiting for the RPC response. Unless you have the bulk query API which will take the RTT only once ;) This is made only worse by the fact that VDSM is a python 2.7 application, and notoriously python 2.x behaves very badly with threads. We are already working to improve our code, but I'd like to bring the discussion here and see if and when the querying API can be improved. We currently use these APIs for our sempling: virDomainBlockInfo virDomainGetInfo virDomainGetCPUStats virDomainBlockStats virDomainBlockStatsFlags virDomainInterfaceStats virDomainGetVcpusFlags virDomainGetMetadata What we'd like to have is * asynchronous APIs for querying domain stats (https://bugzilla.redhat.com/show_bug.cgi?id=1113106) This would be just awesome. Either a single callback or a different one per call is fine (let's discuss this!). please note that we are much more concerned about thread reduction then about performance numbers. We had report of thread number becoming a real harm, while performance so far is not yet a concern (https://bugzilla.redhat.com/show_bug.cgi?id=1102147#c54) I'm not a big fan of this approach. I mean, IIRC python has this Big Python Lock, which effectively prevents two threads run concurrently. So while in C this would make perfect sense, it doesn't do so in python. The callbacks would be called from the event loop, which given how frequently you dump the info will block other threads. Therefore I'm afraid the approach would not bring any speed up, rather slow down. I'm not sure I agree with your assessment here. If we consider a single API call, the time this takes to complete is made up of a number of parts 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket 1. Time to write() the RPC call to the socket 2. Time for libvirtd to process the RPC call 3. Time to recv() the RPC reply from the socket ...and so on.. If the time for item 2 dominates over the time for items 1 2 (which it should really) then the client thread is going to be sleeping in a poll() for the bulk of the duration of the libvirt API call. If we had an async API mechanism, then the VDSM time would essentially be consumed with 1. Time to write() the RPC call to the socket 2. Time to write() the RPC call to the socket 3. Time to write() the RPC call to the socket 4. Time to write() the RPC call to the socket 5. Time to write() the RPC call to the socket 6. Time to write() the RPC call to the socket 7. wait for replies to start arriving 8. Time to recv() the RPC reply from the socket 9. Time to recv() the RPC reply from the socket 10. Time to recv() the RPC reply from the socket 11. Time to recv() the RPC reply from the socket 12. Time to recv() the RPC reply from the socket 13. Time to recv() the RPC reply from the socket 14. Time to recv() the RPC reply from the socket Well, in the async form you need to account even the time spent in the callbacks: 1. write(serial=1, ...) 2. write(serial=2, ...) .. 7. wait for replies 8. recv(serial=x1, ...) // there's no guarantee on order of replies 9. callback(serial=x1, ...) 10. recv(serial=x2, ...) 11. callback(serial=x2, ) And it's the callback times I'm worried about. I'm not saying we should not add the callback APIs. What I'm really saying is I have doubts it will help python apps. It will definitely help scaling C applications though. Of course there's a limit to how many outstanding async
Re: [libvirt] libnuma build failure [was: securityselinuxlabeltest test fails on v1.2.5]
On Mon, Jun 30, 2014 at 03:26:07PM -0600, Eric Blake wrote: On 06/30/2014 01:46 PM, Scott Sullivan wrote: I've tested the v1.2.6-rc2 git tag, im getting this build error: CC util/libvirt_util_la-virnuma.lo util/virnuma.c: In function 'virNumaNodeIsAvailable': util/virnuma.c:428: error: 'numa_nodes_ptr' undeclared (first use in this function) util/virnuma.c:428: error: (Each undeclared identifier is reported only once util/virnuma.c:428: error: for each function it appears in.) What version of numactl-devel do you have installed? make[3]: *** [util/libvirt_util_la-virnuma.lo] Error 1 make[3]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rpmbuild/packages/libvirt' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.3Gu7nd (%build) Build works fine on tag v1.2.5-maint. Sounds like we need to make code added in the meantime be conditional to compile to older numa libraries. Guess we have to check for numa_nodes_ptr in the conditional for HAVE_NUMA_BITMASK_ISBITSET, but that's definitely some odd version of numactl. Martin signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh: Allow attach-disk to specify disk target bus
From: Yanbing Du y...@ydu-0.nay.redhat.com
By default, the bus type is inferred from the style of the device
name('target' in this command), e.g. a device named 'sda' will
typically be exported using a SCSI bus. Actually, not only SCSI bus,
but USB/SATA bus also use this kind of device name. So add '--bus'
option for attach-disk command to allow user specify the target bus.
Signed-off-by: Yanbing Du y...@redhat.com
---
tools/virsh-domain.c | 14 --
tools/virsh.pod | 9 +++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index f55dae4..4488250 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -277,6 +277,10 @@ static const vshCmdOptDef opts_attach_disk[] = {
.flags = VSH_OFLAG_REQ,
.help = N_(target of disk device)
},
+{.name = bus,
+ .type = VSH_OT_STRING,
+ .help = N_(target bus of disk device)
+},
{.name = driver,
.type = VSH_OT_STRING,
.help = N_(driver of disk device)
@@ -502,7 +506,7 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
const char *source = NULL, *target = NULL, *driver = NULL,
*subdriver = NULL, *type = NULL, *mode = NULL,
*cache = NULL, *serial = NULL, *straddr = NULL,
-*wwn = NULL;
+*wwn = NULL, *targetbus = NULL;
struct DiskAddress diskAddr;
bool isFile = false, functionReturn = false;
int ret;
@@ -536,6 +540,7 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
vshCommandOptStringReq(ctl, cmd, serial, serial) 0 ||
vshCommandOptStringReq(ctl, cmd, wwn, wwn) 0 ||
vshCommandOptStringReq(ctl, cmd, address, straddr) 0 ||
+vshCommandOptStringReq(ctl, cmd, bus, targetbus) 0 ||
vshCommandOptStringReq(ctl, cmd, sourcetype, stype) 0)
goto cleanup;
@@ -590,7 +595,12 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd)
if (source)
virBufferAsprintf(buf, source %s='%s'/\n,
isFile ? file : dev, source);
-virBufferAsprintf(buf, target dev='%s'/\n, target);
+virBufferAsprintf(buf, target dev='%s', target);
+if (targetbus) {
+virBufferAsprintf(buf, bus='%s', targetbus);
+}
+virBufferAddLit(buf, /\n);
+
if (mode)
virBufferAsprintf(buf, %s/\n, mode);
diff --git a/tools/virsh.pod b/tools/virsh.pod
index b248c9a..3550825 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -2091,7 +2091,7 @@ expected.
=item Battach-disk Idomain Isource Itarget
[[[I--live] [I--config] | [I--current]] | [I--persistent]]
-[I--driver driver] [I--subdriver subdriver] [I--cache cache]
+[I--bus] [I--driver driver] [I--subdriver subdriver] [I--cache cache]
[I--type type] [I--mode mode] [I--sourcetype sourcetype]
[I--serial serial] [I--wwn wwn] [I--rawio]
[I--address address] [I--multifunction] [I--print-xml]
@@ -2099,7 +2099,12 @@ expected.
Attach a new disk device to the domain.
Isource is path for the files and devices. Itarget controls the bus or
device under which the disk is exposed to the guest OS. It indicates the
-logical device name. Idriver can be Ifile, Itap or Iphy for the Xen
+logical device name; the optional Ibus attribute specifies the type of
+disk device to emulate; possible values are driver specific, with typical
+values being Iide, Iscsi, Ivirtio, Ixen, Iusb, Isata, or Isd,
+if omitted, the bus type is inferred from the style of the device name (e.g.
+a device named 'sda' will typically be exported using a SCSI bus).
+Idriver can be Ifile, Itap or Iphy for the Xen
hypervisor depending on the kind of access; or Iqemu for the QEMU emulator.
Further details to the driver can be passed using Isubdriver. For Xen
Isubdriver can be Iaio, while for QEMU subdriver should match the format
--
1.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Facing problems in running QEMU guest agents in Windows 2008 guest machine.
Hi,
I have a CenOS host machine running KVM and a Windows 2008 guest machine. I
am able to run qemu-monitor-command but not qemu-agent-command.
[root@sdsr720-14 Windows_ISO]# virsh qemu-monitor-command --hmp vm_win_05
'info network'
Devices not on any VLAN:
hostnet0: fd=23 peer=net0
net0: model=virtio-net-pci,macaddr=52:54:00:7f:4a:5b peer=hostnet0
[root@sdsr720-14 Windows_ISO]# virsh qemu-agent-command vm_win_05
'{execute:guest-ping}'
[root@sdsr720-14 Windows_ISO]#
[QEMU guest installation]
To install QEMU guest agent, I followed steps mentioned at following URL
http://wiki.qemu.org/Features/QAPI/GuestAgent#Example_usage
[Problem-1]
qemu-ga.exe -s install runs silently, net start qemu-ga gave error.
Following is the snippet from Windows shell.
PS C:\puneet .\qemu-ga.exe -s install
PS C:\puneet net start qemu-ga
The service name is invalid.
More help is available by typing NET HELPMSG 2185.
PS C:\puneet[root@sdsr720-14 Windows_ISO]#
[Problem-2]
When I double click the qemu-ga.exe, it gives the following error.
The application was unable to start correctly (0xc07b). Click Ok to
close the application.
I tried some other possible ways also but could not get them working.
Regards,
~Puneet
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh: enable list inactive domain when using 'list --[no-]autostart
This patch could let us know which domains are marked as [no]autostart without starting them. Signed-off-by: Chen Hanxiao chenhanx...@cn.fujitsu.com --- tools/virsh-domain-monitor.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 8bd58ad..779b67b 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -1869,8 +1869,10 @@ cmdList(vshControl *ctl, const vshCmd *cmd) FILTER(with-managed-save,VIR_CONNECT_LIST_DOMAINS_MANAGEDSAVE); FILTER(without-managed-save, VIR_CONNECT_LIST_DOMAINS_NO_MANAGEDSAVE); -FILTER(autostart,VIR_CONNECT_LIST_DOMAINS_AUTOSTART); -FILTER(no-autostart, VIR_CONNECT_LIST_DOMAINS_NO_AUTOSTART); +FILTER(autostart,VIR_CONNECT_LIST_DOMAINS_AUTOSTART | + VIR_CONNECT_LIST_DOMAINS_INACTIVE); +FILTER(no-autostart, VIR_CONNECT_LIST_DOMAINS_NO_AUTOSTART | + VIR_CONNECT_LIST_DOMAINS_INACTIVE); FILTER(with-snapshot,VIR_CONNECT_LIST_DOMAINS_HAS_SNAPSHOT); FILTER(without-snapshot, VIR_CONNECT_LIST_DOMAINS_NO_SNAPSHOT); -- 1.9.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: enable list inactive domain when using 'list --[no-]autostart
On Tue, Jul 01, 2014 at 06:33:22PM +0800, Chen Hanxiao wrote: This patch could let us know which domains are marked as [no]autostart without starting them. If you want to see inative guests use the --all or --nactive flags. There's no need to overload --autostart/--no-autostart to imply the --all flag. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] new openvz driver (bossonvz)
Helo Daniel, thanks for the initial tips. I have submitted a new (more personal) email so within a few days all should be settled. To the feedback. I did not expect anything less than a request for a batch of smaller git patches. My first post here was merely to raise some public awareness of the driver and this seemed like a logical place where the information should go. I also wanted to know if I should even try to do the preparatory work for the patches considering there is already another OpenVZ driver included in libvirt. I will try to prepare some initial patches next week or so to test the proper way the code should flow upstream. -- David Fabian Cluster Desgin, s.r.o. Dne Po 30. června 2014 11:51:20, Daniel Veillard napsal(a): On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: Hello, Hello, first small rule here, trust is build on persons like most open source projects, so please change your email, I want to communicate with a person not with the name of a company. in the company I work for, we use openvz and qemu/kvm on our clusters side-by-side. To manage our domains, we used libvirt/qemu for qemu/kvm domains and vz tools for openvz domains in the past. This was very inconvinient since the management differed in many ways. So we have decided to unify our management and use libvirt exclusively. Since the openvz driver already included in libvirt lacks features that need, we have implemented a new libvirt backend driver for openvz called the bossonvz driver. it's true that the openvz diver is lagging behind a bit, I didn't see any real update since 2012. That wouldn't be the first time that we have multiple drivers for a given hypervisor, Xen is a precedent at least, though that's not a perfect situation as it dilutes manpower to maintain drivers for the hypervisor. Unlike the openvz driver, bossonvz is a complete, feature-rich stateful libvirt driver. It uses the libvirt driver API exclusively and communicates with the kernel directly, much like the LXC driver. The code is hugely inspired by the LXC driver and the Qemu driver, but adds a bit of functionality to the libvirt core too. More details and the source code can be found at http://bossonvz.bosson.eu/ The driver is completely independent of vz tools, it needs only a running vz kernel. One of the things, we are most proud of, is the possibility to access the domain's tty via VNC (hurray to uniform management web interfaces). Since the code was developed in-house (primarily for internal purposes), it is based on an older libvirt release (1.1.2). There are also some modifications to the libvirt core (virCommand) and the domain file (mount options syntax) which might need some redesign. At the moment I would like to get some feedback on the driver. In the future, I would like to see the driver merged upstream, and am prepared to do the work but I need to know if there is any interest in doing so. The proper way to get feedback on the driver is: 1/ rebase your code to the current version, there is nothing we can do with a patch for 1.1.2 2/ split the changes logically, nobody will review a 44312 line patch, remove garbage from diffing generated files like configure 3/ submit the patches on this list for review, each patch having details about what it does, etc ... best manage all this with git on a branch from the upstream or you will be mad very quickly see how other does, that's standard practice and if you're not familiar with it, learning it won't be a lot time really. 4/ you will need to add patches adding documentation, no doc, no upstream :) If you think it's too much, then don't bother because we will need commitment to maintaining the driver over the years, and the sum of the work will be even larger than those initial steps. What you gain in exchange is integration in upstream, easier maintainance, easier rebase and recognition in the community. Makes sense ? Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Facing problems in running QEMU guest agents in Windows 2008 guest machine.
At Tue, 1 Jul 2014 15:57:07 +0530,
Puneet Bakshi wrote:
Hi,
I have a CenOS host machine running KVM and a Windows 2008 guest machine. I
am able to run qemu-monitor-command but not qemu-agent-command.
[root@sdsr720-14 Windows_ISO]# virsh qemu-monitor-command --hmp vm_win_05
'info network'
Devices not on any VLAN:
hostnet0: fd=23 peer=net0
net0: model=virtio-net-pci,macaddr=52:54:00:7f:4a:5b peer=hostnet0
[root@sdsr720-14 Windows_ISO]# virsh qemu-agent-command vm_win_05
'{execute:guest-ping}'
[root@sdsr720-14 Windows_ISO]#
[QEMU guest installation]
To install QEMU guest agent, I followed steps mentioned at following URL
http://wiki.qemu.org/Features/QAPI/GuestAgent#Example_usage
[Problem-1]
qemu-ga.exe -s install runs silently, net start qemu-ga gave error.
Following is the snippet from Windows shell.
PS C:\puneet .\qemu-ga.exe -s install
PS C:\puneet net start qemu-ga
The service name is invalid.
More help is available by typing NET HELPMSG 2185.
PS C:\puneet[root@sdsr720-14 Windows_ISO]#
[Problem-2]
When I double click the qemu-ga.exe, it gives the following error.
The application was unable to start correctly (0xc07b). Click Ok to
close the application.
The libvirt list is not quite the right mailing list for your
question. This list is for discussion about libvirt
development. Better ask at the qemu *user* list when you have problems
with the qemu guest agent.
BTW, 0xc07b means STATUS_INVALID_IMAGE_FORMAT, which indicates
that either your file is not a valid PE executable or that it's a 32
bit app and tried to load a 64 bit DLL, but that's just a wild guess.
You could use Dependency Walker to track this down.
Claudio
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Facing problems in running QEMU guest agents in Windows 2008 guest machine.
Can somebody point me to the working way of installing quemu guest agents
in Windows 2008 guest machine?
Regards,
~Puneet
On Tue, Jul 1, 2014 at 3:57 PM, Puneet Bakshi bakshi.pun...@gmail.com
wrote:
Hi,
I have a CenOS host machine running KVM and a Windows 2008 guest machine.
I am able to run qemu-monitor-command but not qemu-agent-command.
[root@sdsr720-14 Windows_ISO]# virsh qemu-monitor-command --hmp vm_win_05
'info network'
Devices not on any VLAN:
hostnet0: fd=23 peer=net0
net0: model=virtio-net-pci,macaddr=52:54:00:7f:4a:5b peer=hostnet0
[root@sdsr720-14 Windows_ISO]# virsh qemu-agent-command vm_win_05
'{execute:guest-ping}'
[root@sdsr720-14 Windows_ISO]#
[QEMU guest installation]
To install QEMU guest agent, I followed steps mentioned at following URL
http://wiki.qemu.org/Features/QAPI/GuestAgent#Example_usage
[Problem-1]
qemu-ga.exe -s install runs silently, net start qemu-ga gave error.
Following is the snippet from Windows shell.
PS C:\puneet .\qemu-ga.exe -s install
PS C:\puneet net start qemu-ga
The service name is invalid.
More help is available by typing NET HELPMSG 2185.
PS C:\puneet[root@sdsr720-14 Windows_ISO]#
[Problem-2]
When I double click the qemu-ga.exe, it gives the following error.
The application was unable to start correctly (0xc07b). Click Ok to
close the application.
I tried some other possible ways also but could not get them working.
Regards,
~Puneet
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] new openvz driver (bossonvz)
Hi David, I think it's worth checking also if the technical approach used by thr driver will be compatible with current and future versions, not sure how much Parallels want to certify their current API/ABI kernel wise. Historically libvirt was started because we had similar issues with Xen at the time, so definitely something to check out to estimate the cost of maintaining the driver long term :) thanks, Daniel On Tue, Jul 01, 2014 at 02:37:49PM +0200, Bosson VZ wrote: Helo Daniel, thanks for the initial tips. I have submitted a new (more personal) email so within a few days all should be settled. To the feedback. I did not expect anything less than a request for a batch of smaller git patches. My first post here was merely to raise some public awareness of the driver and this seemed like a logical place where the information should go. I also wanted to know if I should even try to do the preparatory work for the patches considering there is already another OpenVZ driver included in libvirt. I will try to prepare some initial patches next week or so to test the proper way the code should flow upstream. -- David Fabian Cluster Desgin, s.r.o. Dne Po 30. června 2014 11:51:20, Daniel Veillard napsal(a): On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: Hello, Hello, first small rule here, trust is build on persons like most open source projects, so please change your email, I want to communicate with a person not with the name of a company. in the company I work for, we use openvz and qemu/kvm on our clusters side-by-side. To manage our domains, we used libvirt/qemu for qemu/kvm domains and vz tools for openvz domains in the past. This was very inconvinient since the management differed in many ways. So we have decided to unify our management and use libvirt exclusively. Since the openvz driver already included in libvirt lacks features that need, we have implemented a new libvirt backend driver for openvz called the bossonvz driver. it's true that the openvz diver is lagging behind a bit, I didn't see any real update since 2012. That wouldn't be the first time that we have multiple drivers for a given hypervisor, Xen is a precedent at least, though that's not a perfect situation as it dilutes manpower to maintain drivers for the hypervisor. Unlike the openvz driver, bossonvz is a complete, feature-rich stateful libvirt driver. It uses the libvirt driver API exclusively and communicates with the kernel directly, much like the LXC driver. The code is hugely inspired by the LXC driver and the Qemu driver, but adds a bit of functionality to the libvirt core too. More details and the source code can be found at http://bossonvz.bosson.eu/ The driver is completely independent of vz tools, it needs only a running vz kernel. One of the things, we are most proud of, is the possibility to access the domain's tty via VNC (hurray to uniform management web interfaces). Since the code was developed in-house (primarily for internal purposes), it is based on an older libvirt release (1.1.2). There are also some modifications to the libvirt core (virCommand) and the domain file (mount options syntax) which might need some redesign. At the moment I would like to get some feedback on the driver. In the future, I would like to see the driver merged upstream, and am prepared to do the work but I need to know if there is any interest in doing so. The proper way to get feedback on the driver is: 1/ rebase your code to the current version, there is nothing we can do with a patch for 1.1.2 2/ split the changes logically, nobody will review a 44312 line patch, remove garbage from diffing generated files like configure 3/ submit the patches on this list for review, each patch having details about what it does, etc ... best manage all this with git on a branch from the upstream or you will be mad very quickly see how other does, that's standard practice and if you're not familiar with it, learning it won't be a lot time really. 4/ you will need to add patches adding documentation, no doc, no upstream :) If you think it's too much, then don't bother because we will need commitment to maintaining the driver over the years, and the sum of the work will be even larger than those initial steps. What you gain in exchange is integration in upstream, easier maintainance, easier rebase and recognition in the community. Makes sense ? Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com
[libvirt] [PATCH for 1.2.6] securityselinuxlabeltest: Don't create dummy file in the srcdir
At the very beginning of the test we check if the underlying filesystem supports extended attributes as they are used to store fake SELinux labels. In order to check that, a dummy file is created and semi-random attribute is set. However, the file is created under: abs_srcdir /securityselinuxlabeldata/testxattr which has two problems: abs_srcdir is not required to be writable, so it should have been abs_builddir. The second one is - there's no securityselinuxlabeldata folder under abs_builddir. The problem was introduced in caf164f1. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- tests/securityselinuxlabeltest.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/securityselinuxlabeltest.c b/tests/securityselinuxlabeltest.c index 3699d89..455eb74 100644 --- a/tests/securityselinuxlabeltest.c +++ b/tests/securityselinuxlabeltest.c @@ -65,10 +65,11 @@ testUserXattrEnabled(void) const char *con_value = system_u:object_r:svirt_image_t:s0:c41,c264; char *path = NULL; if (virAsprintf(path, %s/securityselinuxlabeldata/testxattr, -abs_srcdir) 0) +abs_builddir) 0) goto cleanup; -if (virFileTouch(path, 0600) 0) +if (virFileMakePath(abs_builddir /securityselinuxlabeldata) 0 || +virFileTouch(path, 0600) 0) goto cleanup; len = setxattr(path, user.libvirt.selinux, con_value, @@ -83,6 +84,7 @@ testUserXattrEnabled(void) cleanup: unlink(path); +rmdir(abs_builddir /securityselinuxlabeldata); VIR_FREE(path); return ret; } -- 1.8.5.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for 1.2.6] securityselinuxlabeltest: Don't create dummy file in the srcdir
On 07/01/2014 02:58 PM, Michal Privoznik wrote: At the very beginning of the test we check if the underlying filesystem supports extended attributes as they are used to store fake SELinux labels. In order to check that, a dummy file is created and semi-random attribute is set. However, the file is created under: abs_srcdir /securityselinuxlabeldata/testxattr which has two problems: abs_srcdir is not required to be writable, so it should have been abs_builddir. The second one is - there's no securityselinuxlabeldata folder under abs_builddir. The problem was introduced in caf164f1. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- tests/securityselinuxlabeltest.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) ACK signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] run domain in paused state
Hi all. I need to construct domain, run it in paused state , attach some devices and unpause it. How can i do that in libvirt api (i'm use ruby). As i see virsh have start --paused option, but how can i specify state in domain xml? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] run domain in paused state
Thanks all, i'm find needed flag. 2014-07-01 17:01 GMT+04:00 Vasiliy Tolstov v.tols...@selfip.ru: Hi all. I need to construct domain, run it in paused state , attach some devices and unpause it. How can i do that in libvirt api (i'm use ruby). As i see virsh have start --paused option, but how can i specify state in domain xml? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] libnuma build failure [was: securityselinuxlabeltest test fails on v1.2.5]
On 06/30/2014 05:26 PM, Eric Blake wrote: On 06/30/2014 01:46 PM, Scott Sullivan wrote: I've tested the v1.2.6-rc2 git tag, im getting this build error: CC util/libvirt_util_la-virnuma.lo util/virnuma.c: In function 'virNumaNodeIsAvailable': util/virnuma.c:428: error: 'numa_nodes_ptr' undeclared (first use in this function) util/virnuma.c:428: error: (Each undeclared identifier is reported only once util/virnuma.c:428: error: for each function it appears in.) What version of numactl-devel do you have installed? This is the version I had installed: numactl-devel-2.0.3-9.el6.x86_64 I've updated to 2.0.7-8 (latest CentOS 6.5 version) and the build error is gone. The original problem (the broken securityselinuxlabeltest) also is corrected on v1.2.6-rc2. Thanks make[3]: *** [util/libvirt_util_la-virnuma.lo] Error 1 make[3]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rpmbuild/packages/libvirt' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.3Gu7nd (%build) Build works fine on tag v1.2.5-maint. Sounds like we need to make code added in the meantime be conditional to compile to older numa libraries. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] Report less errors
On 06/30/2014 03:37 PM, Ján Tomko wrote: Some are distracting and not really helpful. Ján Tomko (4): Track privileged state in udev nodedev driver Only detect PCI Express devices as root in udev nodedev driver Introduce virFileReadAllQuiet Report one error less when getting net dev speed src/libvirt_private.syms | 1 + src/node_device/node_device_udev.c | 10 -- src/util/virfile.c | 15 +++ src/util/virfile.h | 2 ++ src/util/virnetdev.c | 7 --- 5 files changed, 30 insertions(+), 5 deletions(-) This would be nice to have in 1.2.6: The first two patches fix noisy startup of unprivileged daemon and the last two silence an error that gets logged on startup with some network card drivers. Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH for 1.2.6] vboxsnapshotxmltest: Don't write to a file in abs_srcdir
In the test, the snapshot XML is written into a file that's located
under:
abs_srcdir/vboxsnapshotxmldata/testResult.vbox
However, the abs_srcdir doesn't have to be necessarily writable. It
should have been abs_builddir instead. Moreover, the label in the func
creating the file is called 'fail' while it fulfils the duty of
'cleanup' label.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
tests/vboxsnapshotxmltest.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/tests/vboxsnapshotxmltest.c b/tests/vboxsnapshotxmltest.c
index 7795688..85ef96a 100644
--- a/tests/vboxsnapshotxmltest.c
+++ b/tests/vboxsnapshotxmltest.c
@@ -59,42 +59,47 @@ testCompareXMLtoXMLFiles(const char *xml)
char *pathResult = NULL;
int ret = -1;
virVBoxSnapshotConfMachinePtr machine = NULL;
-if (virAsprintf(pathResult, %s/vboxsnapshotxmldata/testResult.vbox,
-abs_srcdir) 0)
+
+if (VIR_STRDUP(pathResult,
+ abs_builddir /vboxsnapshotxmldata/testResult.vbox) 0)
return -1;
+if (virFileMakePath(abs_builddir /vboxsnapshotxmldata) 0)
+goto cleanup;
+
if (virtTestLoadFile(xml, xmlData) 0)
-goto fail;
+goto cleanup;
if (!(machine = virVBoxSnapshotConfLoadVboxFile(xml, (char*
-goto fail;
+goto cleanup;
if (virVBoxSnapshotConfSaveVboxFile(machine, pathResult) 0)
-goto fail;
+goto cleanup;
if (virtTestLoadFile(pathResult, actual) 0)
-goto fail;
+goto cleanup;
if (unlink(pathResult) 0)
-goto fail;
+goto cleanup;
if (!(actual = testFilterXML(actual)))
-goto fail;
+goto cleanup;
if (!(xmlData = testFilterXML(xmlData)))
-goto fail;
+goto cleanup;
if (STRNEQ(actual, xmlData)) {
virtTestDifference(stderr, xmlData, actual);
-goto fail;
+goto cleanup;
}
ret = 0;
- fail:
+ cleanup:
VIR_FREE(xmlData);
VIR_FREE(actual);
virVBoxSnapshotConfMachineFree(machine);
VIR_FREE(pathResult);
+rmdir(abs_builddir /vboxsnapshotxmldata);
return ret;
}
--
1.8.5.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/4] Report one error less when getting net dev speed
On 30.06.2014 15:38, Ján Tomko wrote:
virFileReadAll already logs an error. If reading the 'speed' file
fails with EINVAL, we log an error even though we ignore it. If it
fails with other errors, we log two errors.
Use virFileReadAllQuiet - ignore EINVAL and report just one error
in other cases.
Fixes this error on libvirtd startup:
2014-06-30 12:47:14.583+: 20971: error : virFileReadAll:1297 :
Failed to read file '/sys/class/net/wlan0/speed': Invalid argument
---
src/util/virnetdev.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index a551f98..c3a7384 100644
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1844,6 +1844,7 @@ virNetDevGetLinkInfo(const char *ifname,
char *tmp;
int tmp_state;
unsigned int tmp_speed;
+int rc;
There's no need for this new variable, virFileReadAAllQuiet will set
errno too.
if (virNetDevSysfsFile(path, ifname, operstate) 0)
goto cleanup;
@@ -1891,13 +1892,13 @@ virNetDevGetLinkInfo(const char *ifname,
if (virNetDevSysfsFile(path, ifname, speed) 0)
goto cleanup;
-if (virFileReadAll(path, 1024, buf) 0) {
In fact, simple s/virFileReadAll/virFileReadAllQuiet/ would suffice as well.
+if ((rc = virFileReadAllQuiet(path, 1024, buf)) 0) {
/* Some devices doesn't report speed, in which case we get EINVAL */
-if (errno == EINVAL) {
+if (-rc == EINVAL) {
ret = 0;
goto cleanup;
}
-virReportSystemError(errno,
+virReportSystemError(-rc,
_(unable to read: %s),
path);
goto cleanup;
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/4] Only detect PCI Express devices as root in udev nodedev driver
On 30.06.2014 15:38, Ján Tomko wrote:
This stops the error message spam when running unprivileged
libvirtd:
2014-06-30 12:38:47.990+: 631: error : virPCIDeviceConfigOpen:300 :
Failed to open config space file
'/sys/bus/pci/devices/:00:00.0/config': Permission denied
Reported by Daniel Berrange:
https://www.redhat.com/archives/libvir-list/2014-June/msg01082.html
---
src/node_device/node_device_udev.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index 50bb952..fe3dd26 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -429,10 +429,13 @@ static int udevProcessPCI(struct udev_device *device,
virPCIDeviceAddress addr;
virPCIEDeviceInfoPtr pci_express = NULL;
virPCIDevicePtr pciDev = NULL;
+udevPrivate *priv = NULL;
int tmpGroup, ret = -1;
char *p;
int rc;
+priv = driverState-privateData;
+
I personally prefer the initialization to be done in the declaration.
But I can live with this too.
syspath = udev_device_get_syspath(device);
if (udevGetUintProperty(device,
@@ -544,7 +547,8 @@ static int udevProcessPCI(struct udev_device *device,
data-pci_dev.function)))
goto out;
-if (virPCIDeviceIsPCIExpress(pciDev) 0) {
+/* We need to be root to read PCI device configs */
+if (priv-privileged virPCIDeviceIsPCIExpress(pciDev) 0) {
if (VIR_ALLOC(pci_express) 0)
goto out;
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] Report less errors
On 30.06.2014 15:37, Ján Tomko wrote: Some are distracting and not really helpful. Ján Tomko (4): Track privileged state in udev nodedev driver Only detect PCI Express devices as root in udev nodedev driver Introduce virFileReadAllQuiet Report one error less when getting net dev speed src/libvirt_private.syms | 1 + src/node_device/node_device_udev.c | 10 -- src/util/virfile.c | 15 +++ src/util/virfile.h | 2 ++ src/util/virnetdev.c | 7 --- 5 files changed, 30 insertions(+), 5 deletions(-) ACK to all the patches and safe for 1.2.6. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for 1.2.6] vboxsnapshotxmltest: Don't write to a file in abs_srcdir
On Tue, Jul 01, 2014 at 03:28:49PM +0200, Michal Privoznik wrote:
In the test, the snapshot XML is written into a file that's located
under:
abs_srcdir/vboxsnapshotxmldata/testResult.vbox
However, the abs_srcdir doesn't have to be necessarily writable. It
should have been abs_builddir instead. Moreover, the label in the func
creating the file is called 'fail' while it fulfils the duty of
'cleanup' label.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
tests/vboxsnapshotxmltest.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/tests/vboxsnapshotxmltest.c b/tests/vboxsnapshotxmltest.c
index 7795688..85ef96a 100644
--- a/tests/vboxsnapshotxmltest.c
+++ b/tests/vboxsnapshotxmltest.c
@@ -59,42 +59,47 @@ testCompareXMLtoXMLFiles(const char *xml)
char *pathResult = NULL;
int ret = -1;
virVBoxSnapshotConfMachinePtr machine = NULL;
-if (virAsprintf(pathResult, %s/vboxsnapshotxmldata/testResult.vbox,
-abs_srcdir) 0)
+
+if (VIR_STRDUP(pathResult,
+ abs_builddir /vboxsnapshotxmldata/testResult.vbox) 0)
return -1;
+if (virFileMakePath(abs_builddir /vboxsnapshotxmldata) 0)
+goto cleanup;
+
if (virtTestLoadFile(xml, xmlData) 0)
-goto fail;
+goto cleanup;
if (!(machine = virVBoxSnapshotConfLoadVboxFile(xml, (char*
-goto fail;
+goto cleanup;
if (virVBoxSnapshotConfSaveVboxFile(machine, pathResult) 0)
-goto fail;
+goto cleanup;
if (virtTestLoadFile(pathResult, actual) 0)
-goto fail;
+goto cleanup;
if (unlink(pathResult) 0)
-goto fail;
+goto cleanup;
This unlink should be done in the clean-up as well, otherwise rmdir()
won't remove the directory in case the test fails for example in
virtTestLoadFile().
ACK with that changed.
Martin
if (!(actual = testFilterXML(actual)))
-goto fail;
+goto cleanup;
if (!(xmlData = testFilterXML(xmlData)))
-goto fail;
+goto cleanup;
if (STRNEQ(actual, xmlData)) {
virtTestDifference(stderr, xmlData, actual);
-goto fail;
+goto cleanup;
}
ret = 0;
- fail:
+ cleanup:
VIR_FREE(xmlData);
VIR_FREE(actual);
virVBoxSnapshotConfMachineFree(machine);
VIR_FREE(pathResult);
+rmdir(abs_builddir /vboxsnapshotxmldata);
return ret;
}
--
1.8.5.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] securityselinuxlabeltest test fails on v1.2.5
On 30.06.2014 21:46, Scott Sullivan wrote: On 06/26/2014 05:36 PM, Eric Blake wrote: On 06/26/2014 09:38 AM, Scott Sullivan wrote: On 06/26/2014 10:09 AM, Ján Tomko wrote: On 06/26/2014 03:56 PM, Scott Sullivan wrote: 1) Labelling disks ... internal error: File /home/rpmbuild/packages/libvirt/tests/securityselinuxlabeldata/plain.raw context 'EOPNOTSUPP' did not match epected 'system_u:object_r:svirt_image_t:s0:c41,c264' There was a patch skipping the test if setting xattrs is not supported, but it's not merged yet: https://www.redhat.com/archives/libvir-list/2014-June/msg00402.html Jan Jan, Thanks for this. I've applied the patch and it has solved my issues. Now pushed; it missed 1.2.6-rc1, but should be in rc2, if you want to test that in a couple days. Hi Eric. I've tested the v1.2.6-rc2 git tag, im getting this build error: CC util/libvirt_util_la-virnuma.lo util/virnuma.c: In function 'virNumaNodeIsAvailable': util/virnuma.c:428: error: 'numa_nodes_ptr' undeclared (first use in this function) util/virnuma.c:428: error: (Each undeclared identifier is reported only once util/virnuma.c:428: error: for each function it appears in.) make[3]: *** [util/libvirt_util_la-virnuma.lo] Error 1 make[3]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rpmbuild/packages/libvirt/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rpmbuild/packages/libvirt' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.3Gu7nd (%build) Build works fine on tag v1.2.5-maint. This is very interesting, because it's my code (it's not interesting because of that :P ). I mean, when I was writing the code I checked numactl sources to see if 'numa_nodes_ptr' and 'numa_bitmask_isbitset' symbols were introduced in the same release. And they were indeed. Well, the latter accepts the former as an argument, so checking for the latter should be enough even if the symbols were not introduced at once. But how on earth is numactl exporting the isbitset when numa_nodes_ptr is not exported? Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] Report less errors
On 07/01/2014 04:15 PM, Michal Privoznik wrote: On 30.06.2014 15:37, Ján Tomko wrote: Some are distracting and not really helpful. Ján Tomko (4): Track privileged state in udev nodedev driver Only detect PCI Express devices as root in udev nodedev driver Introduce virFileReadAllQuiet Report one error less when getting net dev speed src/libvirt_private.syms | 1 + src/node_device/node_device_udev.c | 10 -- src/util/virfile.c | 15 +++ src/util/virfile.h | 2 ++ src/util/virnetdev.c | 7 --- 5 files changed, 30 insertions(+), 5 deletions(-) ACK to all the patches and safe for 1.2.6. Thanks, I fixed the small issues you raised and pushed it. Michal Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] new openvz driver (bossonvz)
Hello Daniel, I have started working on Bossonvz slightly more than a year ago. As far as I remember, back then I wanted to base my work on top of the existing Openvz libvirt driver but I was dissappointed by the state of the driver. Our goal was to have a driver that supports online migration and mount points management and after toying with the openvz driver for a while we have decided to start from the scratch. Personaly, I also do not like the idea of domain management by just calling the vz tools binaries and relying on parsing of the resulting outputs. The API stability is a very good question. Of course, to circumvent the vz tools and touching the kernel we had to accept the fact that the kernel API might change in the future. And it will most definitely do. This is not based on any formal proclamation in any way but it is true that in a past year I did not have to change my code because of some incompatibility in the vzkernel API (and I have tested the code with various vz kernels ranging from 042stab068.8 to 042stab084.26). At the moment, since the vz tools are the only user of the API, the vz developers can pretty much do whatever they like with the kernel API. I believe it could be benefitial also to them to have another user of their API. The implementations (vztools and bossonvz) are independent but they share the same kernel. This means that if I start a bossonvz domain, I can use vzlist and I will see the appropriate container. The opposite does not work that way because bossonvz is a stateful driver. So if I start a container by using vzctl, I will not see anything with virsh list. But I would not be able to start a domain with the same veid; libvirt won't let me do that because the kernel API call fails. By default, bossonvz also does not touch any vz tools config files (mainly veid.conf), so various vz tools that rely on the existence of the veid.conf for a running container (vzctl enter) will refuse to co-operate. This is solved by the bossonvz hook which can create stub veid.conf files to silence vzctl. After that, it is no problem to access the domain with vzctl enter (we use it regularly since entering the domain with virsh is not implemented yet). To sum up, the implementations influence one another to some extent but neither is necessary for the other and both can run simultaneuosly side-by-side. One of the goals we would like to reach is to have a uniform management interface for our clients. It means that the virtualization technology (openvz, qemu/kvm) should be abstracted away as much as possible. And because all qemu/libvirt management tools allow the user to see the screen, we wanted the same for bossonvz. The implementation is located in bossonvz_vnc_* files. It is a stand-alone binary that is started as a separate process on the domain's startup by a domain controller (similar to the LXC domain controller). The VNC server binary opens up a tty device in the container via a vzkernel API call but instead of passing the IO through to the host pty device (like the LXC does), it actually intercepts the terminal sequences and renderes them to a memory frame-buffer (all in user-space). On top of that sits a custom VNC server implementation that serves the updated chunks to VNC clients. Everything is done in user-space, no modifications to the upstream vzkernel are necessary. The code heavily uses the libvirt util functions as well as uthash and some functions from libcrypto. Since the VNC server runs on the host, it is invisible to the user in the container. If for some reason the VNC server crashes, the domain controller can start it again without influencing the state of the domain itself. During migration (or a suspend/resume cycle), the state of the server is serialized to a file and stored on the domain's root partition. From there, it is deserialized and loaded when the domain is resumed. Since there is no dependency on the vzkernel API in the VNC server (apart from opening the tty device), there shall be no problem to use the code in the LXC driver. As far as the maintanence is concerned: Our bussinnes is centered around OpenVZ and Qemu/kvm technologies. Primarly, we are prepared to provide a long-term support of the bossonvz driver for every RedHat libvirt release and every stable vzkernel release because we use the driver already in production on RedHat based distros. Had the driver be accepted to the libvirt master with all the features that we need in the company, we are ready to provide support there as well. You are correct that LXC and OpenVZ cover the same thing, container virtualization. However, until LXC offers the same level of features as OpenVZ provides, we will use our bossonvz driver in the company. -- David Fabian Cluster Design, s.r.o. Dne Po 30. června 2014 10:31:26, Daniel P. Berrange napsal(a): On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: Hello, in the company
[libvirt] [PATCH 0/2] Gluster: tweak two small issues
Peter Krempa (2): conf: storage: Add volume feature formatter for gluster pools storage: gluster: Fix header reader function src/conf/storage_conf.c | 2 ++ src/storage/storage_backend_gluster.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] storage: gluster: Fix header reader function
Advance the right pointer to actually append to the buffer. We were lucky that all reads were completed in one try. --- src/storage/storage_backend_gluster.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/storage/storage_backend_gluster.c b/src/storage/storage_backend_gluster.c index cab23b0..1a2b4ec 100644 --- a/src/storage/storage_backend_gluster.c +++ b/src/storage/storage_backend_gluster.c @@ -173,7 +173,7 @@ virStorageBackendGlusterReadHeader(glfs_fd_t *fd, } if (r == 0) return nread; -buf += r; +s += r; maxlen -= r; nread += r; } -- 1.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] conf: storage: Add volume feature formatter for gluster pools
Libvirt didn't output feature flags for images stored on native gluster.
Fix this trivially by adding a feature formatter callback.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1095035
---
src/conf/storage_conf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c
index 8b6fd79..c8df5b2 100644
--- a/src/conf/storage_conf.c
+++ b/src/conf/storage_conf.c
@@ -258,6 +258,8 @@ static virStoragePoolTypeInfo poolTypeInfo[] = {
.defaultFormat = VIR_STORAGE_FILE_RAW,
.formatToString = virStorageFileFormatTypeToString,
.formatFromString = virStorageVolumeFormatFromString,
+ .featureFromString = virStorageFileFeatureTypeFromString,
+ .featureToString = virStorageFileFeatureTypeToString,
}
},
{.poolType = VIR_STORAGE_POOL_MPATH,
--
1.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 for 1.2.6] build: link libvirt_conf with libxml
Since there is code using functions from the libxml library, libvirt_conf should have that in LIBADD so it can be linked against even without libvirt_util (which usually deals with the error itself, since libvirt_util has libxml in LIBADD). The same applies to storage_backend.c. Signed-off-by: Martin Kletzander mklet...@redhat.com --- This is a v2 of: https://www.redhat.com/archives/libvir-list/2014-June/msg01322.html If this gets ACKed for th 1.2.6 release, please push this as well since I won't be available before DV makes the release, thank you. --- src/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Makefile.am b/src/Makefile.am index 35720be..047d4c6 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -991,6 +991,7 @@ libvirt_la_BUILT_LIBADD += libvirt_conf.la libvirt_conf_la_SOURCES = $(CONF_SOURCES) libvirt_conf_la_CFLAGS = $(AM_CFLAGS) libvirt_conf_la_LDFLAGS = $(AM_LDFLAGS) +libvirt_conf_la_LIBADD = $(LIBXML_LIBS) noinst_LTLIBRARIES += libvirt_cpu.la libvirt_la_BUILT_LIBADD += libvirt_cpu.la @@ -1452,7 +1453,7 @@ libvirt_driver_storage_impl_la_CFLAGS = \ $(AM_CFLAGS) libvirt_driver_storage_impl_la_LDFLAGS = $(AM_LDFLAGS) libvirt_driver_storage_impl_la_LIBADD = -libvirt_driver_storage_impl_la_LIBADD += $(SECDRIVER_LIBS) +libvirt_driver_storage_impl_la_LIBADD += $(SECDRIVER_LIBS) $(LIBXML_LIBS) if WITH_BLKID libvirt_driver_storage_impl_la_CFLAGS += $(BLKID_CFLAGS) libvirt_driver_storage_impl_la_LIBADD += $(BLKID_LIBS) -- 2.0.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] odd message from latest libvirt.git
On 07/01/2014 01:51 AM, Ján Tomko wrote: On 07/01/2014 06:29 AM, Eric Blake wrote: # ./run daemon/libvirtd 2014-07-01 04:27:19.913+: 1160: info : libvirt version: 1.2.6 2014-07-01 04:27:19.913+: 1160: error : virFileReadAll:1297 : Failed to read file '/sys/class/net/wlp3s0/speed': Invalid argument This is probably a kernel bug in Fedora 20; but we shouldn't be polluting the logs just because of the kernel being unable to read a file that it claims exists: # ls -l /sys/class/net/wlp3s0/speed -r--r--r--. 1 root root 4096 Jun 28 07:41 /sys/class/net/wlp3s0/speed # cat /sys/class/net/wlp3s0/speed cat: /sys/class/net/wlp3s0/speed: Invalid argument Patches 3 and 4 from this series of mine deal with that error: https://www.redhat.com/archives/libvir-list/2014-June/msg01453.html Good to know; let's get that series reviewed and in for 1.2.6 then. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] odd message from latest libvirt.git
On 07/01/2014 05:10 PM, Eric Blake wrote: On 07/01/2014 01:51 AM, Ján Tomko wrote: On 07/01/2014 06:29 AM, Eric Blake wrote: # ./run daemon/libvirtd 2014-07-01 04:27:19.913+: 1160: info : libvirt version: 1.2.6 2014-07-01 04:27:19.913+: 1160: error : virFileReadAll:1297 : Failed to read file '/sys/class/net/wlp3s0/speed': Invalid argument This is probably a kernel bug in Fedora 20; but we shouldn't be polluting the logs just because of the kernel being unable to read a file that it claims exists: # ls -l /sys/class/net/wlp3s0/speed -r--r--r--. 1 root root 4096 Jun 28 07:41 /sys/class/net/wlp3s0/speed # cat /sys/class/net/wlp3s0/speed cat: /sys/class/net/wlp3s0/speed: Invalid argument Patches 3 and 4 from this series of mine deal with that error: https://www.redhat.com/archives/libvir-list/2014-June/msg01453.html Good to know; let's get that series reviewed and in for 1.2.6 then. It's pushed already, Michal reviewed it. Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Gluster: tweak two small issues
On 07/01/2014 04:57 PM, Peter Krempa wrote: Peter Krempa (2): conf: storage: Add volume feature formatter for gluster pools storage: gluster: Fix header reader function src/conf/storage_conf.c | 2 ++ src/storage/storage_backend_gluster.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) ACK for 1.2.6 Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 for 1.2.6] build: link libvirt_conf with libxml
On 07/01/2014 05:09 PM, Martin Kletzander wrote: Since there is code using functions from the libxml library, libvirt_conf should have that in LIBADD so it can be linked against even without libvirt_util (which usually deals with the error itself, since libvirt_util has libxml in LIBADD). The same applies to storage_backend.c. Signed-off-by: Martin Kletzander mklet...@redhat.com --- This is a v2 of: https://www.redhat.com/archives/libvir-list/2014-June/msg01322.html If this gets ACKed for th 1.2.6 release, please push this as well since I won't be available before DV makes the release, thank you. --- src/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) ACK and pushed. Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH for 1.2.6] qemu: copy: Accept 'format' parameter when copying to a non-existing img
We have the following matrix of possible arguments handled by the logic
statement touched by this patch:
| flags _REUSE_EXT | !(flags _REUSE_EXT)
---++--
format| (1)| (2)
---++--
!format| (3)| (4)
---++--
In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
user requests to use a pre-existing image in 1 and 3 and libvirt shall
create a new image in 2 and 4.
The difference between cases 3 and 4 is that for 3 the format is probed
from the user-provided image, whereas in 4 we just use the existing disk
format.
The current code would treat cases 1,3 and 4 correctly but in case 2 the
format provided by the user would be ignored.
The particular piece of code was broken in commit 35c7701c64508f975dfeb8
but since it was introduced a few commits before that it was never
released as working.
---
src/qemu/qemu_driver.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 775f6ab..d45a161 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15356,29 +15356,34 @@ qemuDomainBlockCopy(virDomainObjPtr vm,
/* XXX Allow non-file mirror destinations */
mirror-type = VIR_STORAGE_TYPE_FILE;
+if (format) {
+if ((mirror-format = virStorageFileFormatTypeFromString(format)) =
0) {
+virReportError(VIR_ERR_INVALID_ARG, _(unrecognized format '%s'),
+ format);
+goto endjob;
+}
+} else {
+if (!(flags VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT)) {
+mirror-format = disk-src-format;
+} else {
+/* If the user passed the REUSE_EXT flag, then either they
+ * also passed the RAW flag (and format is non-NULL), or it is
+ * safe for us to probe the format from the file that we will
+ * be using. */
+mirror-format = virStorageFileProbeFormat(dest, cfg-user,
+ cfg-group);
+}
+}
+
+/* pre-create the image file */
if (!(flags VIR_DOMAIN_BLOCK_REBASE_REUSE_EXT)) {
int fd = qemuOpenFile(driver, vm, dest, O_WRONLY | O_TRUNC | O_CREAT,
need_unlink, NULL);
if (fd 0)
goto endjob;
VIR_FORCE_CLOSE(fd);
-if (!format)
-mirror-format = disk-src-format;
-} else if (format) {
-mirror-format = virStorageFileFormatTypeFromString(format);
-if (mirror-format = 0) {
-virReportError(VIR_ERR_INVALID_ARG, _(unrecognized format '%s'),
- format);
-goto endjob;
-}
-} else {
-/* If the user passed the REUSE_EXT flag, then either they
- * also passed the RAW flag (and format is non-NULL), or it is
- * safe for us to probe the format from the file that we will
- * be using. */
-mirror-format = virStorageFileProbeFormat(dest, cfg-user,
- cfg-group);
}
+
if (!format mirror-format 0)
format = virStorageFileFormatTypeToString(mirror-format);
if (VIR_STRDUP(mirror-path, dest) 0)
--
1.9.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v1.2.[1-5]-maint] qemu: blockcopy: Don't remove existing disk mirror info
On 06/26/2014 07:51 AM, Eric Blake wrote:
From: Peter Krempa pkre...@redhat.com
When creating a new disk mirror the new struct is stored in a separate
variable until everything went well. The removed hunk would actually
remove existing mirror information for example when the api would be run
if a mirror still exists.
(cherry picked from commit 02b364e186d487f54ed410c01af042f23e812d42)
This fixes a regression introduced in commit ff5f30b.
Signed-off-by: Eric Blake ebl...@redhat.com
Conflicts:
src/qemu/qemu_driver.c - no refactoring of commit 7b7bf001
---
As Peter's patch resolves a regression, I'd like to backport it to
the maint branches; however, that means redoing the patch.
src/qemu/qemu_driver.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 59185c6..591864f 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -15203,6 +15203,7 @@ qemuDomainBlockCopy(virDomainObjPtr vm,
struct stat st;
bool need_unlink = false;
char *mirror = NULL;
+int mirrorFormat;
Uninitialized...
virQEMUDriverConfigPtr cfg = NULL;
/* Preliminaries: find the disk we are editing, sanity checks */
@@ -15290,10 +15291,10 @@ qemuDomainBlockCopy(virDomainObjPtr vm,
goto endjob;
VIR_FORCE_CLOSE(fd);
if (!format)
-disk-mirrorFormat = disk-src.format;
+mirrorFormat = disk-src.format;
but here, if the user did not request reusing a file but DID request
raw, mirrorFormat is still uninitialized...
} else if (format) {
-disk-mirrorFormat = virStorageFileFormatTypeFromString(format);
-if (disk-mirrorFormat = 0) {
+mirrorFormat = virStorageFileFormatTypeFromString(format);
+if (mirrorFormat = 0) {
virReportError(VIR_ERR_INVALID_ARG, _(unrecognized format
'%s'),
format);
goto endjob;
@@ -15303,11 +15304,11 @@ qemuDomainBlockCopy(virDomainObjPtr vm,
* also passed the RAW flag (and format is non-NULL), or it is
* safe for us to probe the format from the file that we will
* be using. */
-disk-mirrorFormat = virStorageFileProbeFormat(dest, cfg-user,
- cfg-group);
+mirrorFormat = virStorageFileProbeFormat(dest, cfg-user,
+ cfg-group);
}
-if (!format disk-mirrorFormat 0)
-format = virStorageFileFormatTypeToString(disk-mirrorFormat);
+if (!format mirrorFormat 0)
+format = virStorageFileFormatTypeToString(mirrorFormat);
and here we are using the uninitialized value :(
It looks like this has been broken ever since v1.0.0 (when blockcopy was
first introduced), so it is not a regression that we have been
mishandling 'virsh blockcopy $dom vda /path/to/file --raw', but
disk-mirrorFormat was at least initialized to 0 compared to my patch
using an uninitialized value. Peter will be proposing a patch soon,
which must make it into 1.2.6.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] odd message from latest libvirt.git
On 07/01/2014 09:14 AM, Ján Tomko wrote: On 07/01/2014 05:10 PM, Eric Blake wrote: On 07/01/2014 01:51 AM, Ján Tomko wrote: On 07/01/2014 06:29 AM, Eric Blake wrote: # ./run daemon/libvirtd 2014-07-01 04:27:19.913+: 1160: info : libvirt version: 1.2.6 2014-07-01 04:27:19.913+: 1160: error : virFileReadAll:1297 : Failed to read file '/sys/class/net/wlp3s0/speed': Invalid argument This is probably a kernel bug in Fedora 20; but we shouldn't be polluting the logs just because of the kernel being unable to read a file that it claims exists: # ls -l /sys/class/net/wlp3s0/speed -r--r--r--. 1 root root 4096 Jun 28 07:41 /sys/class/net/wlp3s0/speed # cat /sys/class/net/wlp3s0/speed cat: /sys/class/net/wlp3s0/speed: Invalid argument Patches 3 and 4 from this series of mine deal with that error: https://www.redhat.com/archives/libvir-list/2014-June/msg01453.html Good to know; let's get that series reviewed and in for 1.2.6 then. It's pushed already, Michal reviewed it. Serves me right for reading my inbox out-of-order :) Thanks again for the fix. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Gluster: tweak two small issues
On 07/01/14 17:22, Ján Tomko wrote: On 07/01/2014 04:57 PM, Peter Krempa wrote: Peter Krempa (2): conf: storage: Add volume feature formatter for gluster pools storage: gluster: Fix header reader function src/conf/storage_conf.c | 2 ++ src/storage/storage_backend_gluster.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) ACK for 1.2.6 Jan Pushed; Thanks. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for 1.2.6] qemu: copy: Accept 'format' parameter when copying to a non-existing img
On 07/01/2014 09:31 AM, Peter Krempa wrote: We have the following matrix of possible arguments handled by the logic statement touched by this patch: | flags _REUSE_EXT | !(flags _REUSE_EXT) ---++-- format| (1)| (2) ---++-- !format| (3)| (4) ---++-- In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The user requests to use a pre-existing image in 1 and 3 and libvirt shall s/shall/will/ create a new image in 2 and 4. The difference between cases 3 and 4 is that for 3 the format is probed from the user-provided image, whereas in 4 we just use the existing disk format. With the further caveat that if the _SHALLOW flag was requested, we are guaranteed the probe is safe (a shallow image implies a backing file, but raw cannot have a backing file, and probing is only a security hole if raw is probed) The current code would treat cases 1,3 and 4 correctly but in case 2 the format provided by the user would be ignored. The particular piece of code was broken in commit 35c7701c64508f975dfeb8 but since it was introduced a few commits before that it was never released as working. --- src/qemu/qemu_driver.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-) ACK. I'll take care of pushing the fix to the affected maint branches, but yours needs to go in for 1.2.6. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] new openvz driver (bossonvz)
Pavel and James to CC On 30/06/14 17:39, Daniel Veillard veill...@redhat.com wrote: On Mon, Jun 30, 2014 at 10:31:26AM +0100, Daniel P. Berrange wrote: On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: [...] - What do you see as the long term future of the driver ? I've already asked whether there's any risk from future OpenVZ releases potentially breaking things. Historically the idea with the kernel's namespace support was that the OpenVZ forked kernel would be able to go away. IIUC, the openvz userspace can already run on top of a plain mainline kernel, albeit with reduced features compared to when it runs on openvz kernel fork. If we assume the trend of merging OpenVZ features into mainline continues, we might get to a point where OpenVZ kernel fork no longer exists. At that point I wonder what would be the compelling differences between BossonVZ and the LXC driver ? ie why would we benefit from 2 container drivers for the same kernel functionality. Good point ! My recollection of talking with James Bottomley is indeed that all the special features are being migrated as part of the commonly agreed upon set of kernel primitives put in the kernel for containers. So I hope that this driver will indeed work based on those primitives and not the Parallels specific extensions, as those may vanish sooner or later. What kernels do you support, only CentOS-6 modified ones ? Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH for 1.2.6] qemu: copy: Accept 'format' parameter when copying to a non-existing img
On 07/01/14 17:42, Eric Blake wrote: On 07/01/2014 09:31 AM, Peter Krempa wrote: We have the following matrix of possible arguments handled by the logic statement touched by this patch: | flags _REUSE_EXT | !(flags _REUSE_EXT) ---++-- format| (1)| (2) ---++-- !format| (3)| (4) ---++-- In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The user requests to use a pre-existing image in 1 and 3 and libvirt shall s/shall/will/ create a new image in 2 and 4. The difference between cases 3 and 4 is that for 3 the format is probed from the user-provided image, whereas in 4 we just use the existing disk format. With the further caveat that if the _SHALLOW flag was requested, we are guaranteed the probe is safe (a shallow image implies a backing file, but raw cannot have a backing file, and probing is only a security hole if raw is probed) The current code would treat cases 1,3 and 4 correctly but in case 2 the format provided by the user would be ignored. The particular piece of code was broken in commit 35c7701c64508f975dfeb8 but since it was introduced a few commits before that it was never released as working. --- src/qemu/qemu_driver.c | 37 + 1 file changed, 21 insertions(+), 16 deletions(-) ACK. I'll take care of pushing the fix to the affected maint branches, but yours needs to go in for 1.2.6. Pushed; Thanks. Peter signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] new openvz driver (bossonvz)
On 07/01/2014 07:43 PM, Dmitry Mishin wrote: Pavel and James to CC On 30/06/14 17:39, Daniel Veillard veill...@redhat.com wrote: On Mon, Jun 30, 2014 at 10:31:26AM +0100, Daniel P. Berrange wrote: On Fri, Jun 27, 2014 at 03:16:51PM +0200, Bosson VZ wrote: [...] - What do you see as the long term future of the driver ? I've already asked whether there's any risk from future OpenVZ releases potentially breaking things. Historically the idea with the kernel's namespace support was that the OpenVZ forked kernel would be able to go away. IIUC, the openvz userspace can already run on top of a plain mainline kernel, albeit with reduced features compared to when it runs on openvz kernel fork. If we assume the trend of merging OpenVZ features into mainline continues, we might get to a point where OpenVZ kernel fork no longer exists. At that point I wonder what would be the compelling differences between BossonVZ and the LXC driver ? ie why would we benefit from 2 container drivers for the same kernel functionality. Good point ! My recollection of talking with James Bottomley is indeed that all the special features are being migrated as part of the commonly agreed upon set of kernel primitives put in the kernel for containers. So I hope that this driver will indeed work based on those primitives and not the Parallels specific extensions, as those may vanish sooner or later. First of all -- great Thanks to the Bosson team for this work :) Unfortunately, I must say that our plan is to deprecate the OpenVZ kernel API for containers eventually. Current plan is the API for OpenVZ and PCS products would be the PCS SDK (the GPL-compatible version will be announced soon) and the libcontainer project. Thanks, Pavel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: don't break the build on Xen=4.5 because of libxl_vcpu_setaffinity()
Dario Faggioli wrote: Just thinking out loud here but, if we did not get the push failure, when would have we discovered this? Good question. I could have been days (or even weeks) before I stumbled across it. ATM, I don't have any automated builds of libvirt.git master against xen.git master :-/. Adding it to my list... Thanks for your work on the push gate Ian! Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] util: Introduce flags field for macvtap creation
Currently, there is one flag passed in during macvtap creation
(withTap) -- Let's convert this field to an unsigned int flag
field for future expansion.
Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com
---
src/lxc/lxc_process.c |2 +-
src/qemu/qemu_command.c |3 ++-
src/util/virnetdevmacvlan.c | 24 +++-
src/util/virnetdevmacvlan.h |8 +++-
4 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c
index 0aef13a..ab0c5d0 100644
--- a/src/lxc/lxc_process.c
+++ b/src/lxc/lxc_process.c
@@ -333,7 +333,7 @@ char *virLXCProcessSetupInterfaceDirect(virConnectPtr conn,
net-ifname, net-mac,
virDomainNetGetActualDirectDev(net),
virDomainNetGetActualDirectMode(net),
-false, false, def-uuid,
+0, false, def-uuid,
virDomainNetGetActualVirtPortProfile(net),
res_ifname,
VIR_NETDEV_VPORT_PROFILE_OP_CREATE,
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 63f322a..314d8a3 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -171,6 +171,7 @@ qemuPhysIfaceConnect(virDomainDefPtr def,
char *res_ifname = NULL;
int vnet_hdr = 0;
virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
+unsigned int macvlan_create_flags = VIR_NETDEV_MACVLAN_CREATE_WITH_TAP;
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_VNET_HDR)
net-model STREQ(net-model, virtio))
@@ -180,7 +181,7 @@ qemuPhysIfaceConnect(virDomainDefPtr def,
net-ifname, net-mac,
virDomainNetGetActualDirectDev(net),
virDomainNetGetActualDirectMode(net),
-true, vnet_hdr, def-uuid,
+macvlan_create_flags, vnet_hdr, def-uuid,
virDomainNetGetActualVirtPortProfile(net),
res_ifname,
vmop, cfg-stateDir,
diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
index cb85b74..bfbecbf 100644
--- a/src/util/virnetdevmacvlan.c
+++ b/src/util/virnetdevmacvlan.c
@@ -790,6 +790,7 @@ virNetDevMacVLanVPortProfileRegisterCallback(const char
*ifname,
* @macaddress: The MAC address for the macvtap device
* @linkdev: The interface name of the NIC to connect to the external bridge
* @mode: int describing the mode for 'bridge', 'vepa', 'private' or
'passthru'.
+ * @flags: OR of virNetDevMacVLanCreateFlags.
* @vnet_hdr: 1 to enable IFF_VNET_HDR, 0 to disable it
* @vmuuid: The UUID of the VM the macvtap belongs to
* @virtPortProfile: pointer to object holding the virtual port profile data
@@ -797,14 +798,15 @@ virNetDevMacVLanVPortProfileRegisterCallback(const char
*ifname,
* interface will be stored into if everything succeeded. It is up
* to the caller to free the string.
*
- * Returns file descriptor of the tap device in case of success with @withTap,
- * otherwise returns 0; returns -1 on error.
+ * Returns file descriptor of the tap device in case of success with
+ * flags VIR_NETDEV_MACVLAN_CREATE_WITH_TAP, otherwise returns 0; returns
+ * -1 on error.
*/
int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname,
const virMacAddr *macaddress,
const char *linkdev,
virNetDevMacVLanMode mode,
- bool withTap,
+ unsigned int flags,
int vnet_hdr,
const unsigned char *vmuuid,
virNetDevVPortProfilePtr
virtPortProfile,
@@ -813,9 +815,12 @@ int virNetDevMacVLanCreateWithVPortProfile(const char
*tgifname,
char *stateDir,
virNetDevBandwidthPtr bandwidth)
{
-const char *type = withTap ? macvtap : macvlan;
-const char *prefix = withTap ? MACVTAP_NAME_PREFIX : MACVLAN_NAME_PREFIX;
-const char *pattern = withTap ? MACVTAP_NAME_PATTERN :
MACVLAN_NAME_PATTERN;
+const char *type = (flags VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) ?
+macvtap : macvlan;
+const char *prefix = (flags VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) ?
+MACVTAP_NAME_PREFIX : MACVLAN_NAME_PREFIX;
+const char *pattern = (flags VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) ?
+MACVTAP_NAME_PATTERN : MACVLAN_NAME_PATTERN;
int c, rc;
char ifname[IFNAMSIZ];
int retries, do_retry = 0;
@@ -903,7 +908,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char
*tgifname,
goto disassociate_exit;
}
-if (withTap) {
+if (flags VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) {
if ((rc = virNetDevMacVLanTapOpen(cr_ifname, 10)) 0)
goto disassociate_exit;
@@ -925,7 +930,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char
*tgifname,
[libvirt] [PATCH 0/2] (for 1.2.7) network: Bring netdevs online later
The following patchset introduces code to defer setting netdevs online (and therefore registering MACs) until right before beginning guest CPU execution. The first patch introduces some infrastructure changes in preparation of the actual function added in the 2nd patch. Associated BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1081461 Changes since RFC: * Add a separate patch to introduce a flags field for macvlan/macvtap creation. * Use macvlan/tap IFUP flags to skip virNetDevSetOnline (for qemu only). * Add hotplug support. * For macvlan, save the current virNetDevVPortProfileOp in virDomainNetDef during qemuPhysIfaceConnect. As Laine mentioned, could use this field in a future patch to eliminate passing virNetDevVPortProfileOp everywhere. * Add qemu_interface.c and qemu_interface.h to encapsulate new functions. Matthew Rosato (2): util: Introduce flags field for macvtap creation network: Bring netdevs online later src/Makefile.am |1 + src/conf/domain_conf.h |2 ++ src/lxc/lxc_process.c |3 +- src/qemu/qemu_command.c |9 -- src/qemu/qemu_hotplug.c |7 + src/qemu/qemu_interface.c | 65 +++ src/qemu/qemu_interface.h | 33 ++ src/qemu/qemu_process.c |4 +++ src/util/virnetdevmacvlan.c | 32 + src/util/virnetdevmacvlan.h | 10 ++- 10 files changed, 150 insertions(+), 16 deletions(-) create mode 100644 src/qemu/qemu_interface.c create mode 100644 src/qemu/qemu_interface.h -- 1.7.9.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] network: Bring netdevs online later
Defer MAC registration until net devices are actually going
to be used by the guest. This patch does so by setting the
devices online just before starting guest CPUs.
Signed-off-by: Matthew Rosato mjros...@linux.vnet.ibm.com
---
src/Makefile.am |1 +
src/conf/domain_conf.h |2 ++
src/lxc/lxc_process.c |3 +-
src/qemu/qemu_command.c |6 +++-
src/qemu/qemu_hotplug.c |7 +
src/qemu/qemu_interface.c | 65 +++
src/qemu/qemu_interface.h | 33 ++
src/qemu/qemu_process.c |4 +++
src/util/virnetdevmacvlan.c |8 --
src/util/virnetdevmacvlan.h |2 ++
10 files changed, 126 insertions(+), 5 deletions(-)
create mode 100644 src/qemu/qemu_interface.c
create mode 100644 src/qemu/qemu_interface.h
diff --git a/src/Makefile.am b/src/Makefile.am
index 35720be..e3d2e36 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -687,6 +687,7 @@ QEMU_DRIVER_SOURCES =
\
qemu/qemu_domain.c qemu/qemu_domain.h \
qemu/qemu_cgroup.c qemu/qemu_cgroup.h \
qemu/qemu_hostdev.c qemu/qemu_hostdev.h \
+ qemu/qemu_interface.c qemu/qemu_interface.h \
qemu/qemu_hotplug.c qemu/qemu_hotplug.h \
qemu/qemu_hotplugpriv.h \
qemu/qemu_conf.c qemu/qemu_conf.h \
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 1122eb2..8375106 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -921,6 +921,8 @@ struct _virDomainNetDef {
virNetDevBandwidthPtr bandwidth;
virNetDevVlan vlan;
int linkstate;
+/* vmOp value saved if deferring interface start */
+virNetDevVPortProfileOp vmOp;
};
/* Used for prefix of ifname of any network name generated dynamically
diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c
index ab0c5d0..3083ed3 100644
--- a/src/lxc/lxc_process.c
+++ b/src/lxc/lxc_process.c
@@ -302,6 +302,7 @@ char *virLXCProcessSetupInterfaceDirect(virConnectPtr conn,
virNetDevBandwidthPtr bw;
virNetDevVPortProfilePtr prof;
virLXCDriverConfigPtr cfg = virLXCDriverGetConfig(driver);
+unsigned int macvlan_create_flags = VIR_NETDEV_MACVLAN_CREATE_IFUP;
/* XXX how todo bandwidth controls ?
* Since the 'net-ifname' is about to be moved to a different
@@ -333,7 +334,7 @@ char *virLXCProcessSetupInterfaceDirect(virConnectPtr conn,
net-ifname, net-mac,
virDomainNetGetActualDirectDev(net),
virDomainNetGetActualDirectMode(net),
-0, false, def-uuid,
+macvlan_create_flags, false, def-uuid,
virDomainNetGetActualVirtPortProfile(net),
res_ifname,
VIR_NETDEV_VPORT_PROFILE_OP_CREATE,
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 314d8a3..a5662f5 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -196,6 +196,9 @@ qemuPhysIfaceConnect(virDomainDefPtr def,
net-ifname = res_ifname;
}
+/* Save vport profile op for later */
+net-vmOp = vmop;
+
virObjectUnref(cfg);
return rc;
@@ -294,7 +297,7 @@ qemuNetworkIfaceConnect(virDomainDefPtr def,
{
char *brname = NULL;
int ret = -1;
-unsigned int tap_create_flags = VIR_NETDEV_TAP_CREATE_IFUP;
+unsigned int tap_create_flags = 0;
bool template_ifname = false;
int actualType = virDomainNetGetActualType(net);
virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
@@ -354,6 +357,7 @@ qemuNetworkIfaceConnect(virDomainDefPtr def,
goto cleanup;
}
} else {
+tap_create_flags |= VIR_NETDEV_TAP_CREATE_IFUP;
if (qemuCreateInBridgePortWithHelper(cfg, brname,
net-ifname,
tapfd, tap_create_flags) 0) {
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 5e8aa4e..98e7764 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -49,6 +49,7 @@
#include virstoragefile.h
#include virstring.h
#include virtime.h
+#include qemu_interface.h
#define VIR_FROM_THIS VIR_FROM_QEMU
@@ -854,6 +855,9 @@ int qemuDomainAttachNetDevice(virConnectPtr conn,
if (networkAllocateActualDevice(vm-def, net) 0)
goto cleanup;
+/* Set device online immediately */
+qemuInterfaceStartDevice(net);
+
actualType = virDomainNetGetActualType(net);
if (actualType == VIR_DOMAIN_NET_TYPE_HOSTDEV) {
@@ -2030,6 +2034,9 @@ qemuDomainChangeNet(virQEMUDriverPtr driver,
goto cleanup;
}
+/* Set device online immediately */
+qemuInterfaceStartDevice(newdev);
+
newType = virDomainNetGetActualType(newdev);
if (newType ==
Re: [libvirt] RFC: 'old' event for leaseshelper.c when lease renews
I cleared some more queries regarding leasesfile-ro option. Once can read the conversation at http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008656.html. TL;DR: (i) We have to change the leasehelper program to honor the event 'init' and print leases info in dnsmasq leases format (so that dnsmasq knows about previous leases if it is restarted for some reason). Bummer. When 'init' is sent to the leases helper program, the interface name is not known :'( so the helper program doesn't know which *.status file it has to read and print to stdout. Simon came up with the following hack: The most obvious nasty hack to make this work would be to have a set of filesystem links to the real lease-change script, each with a different name, and configure each dnsmasq to call a unique link. The script then checks argv[0] to find the name it was called by and then transforms that into the name of the corresponding database file. So we have something like scripts/interface1 is a link to /lib/libvirt/lease-change- script scripts/interface2 is a link to /lib/libvirt/lease-change-script and start dnsmasq with dnsmasq --interface=interface1 --dhcp-script=scripts/interface1 and the script finds the basename of argv[0[: scripts/interface1 - interface1 and prepends the directory where the lease files are interface1 -leasefiles/interface1 That works in the absence on the DNSMASQ_INTERFACE variable. Is this hack acceptable? -- Nehal J Wani -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4 0/5] Another version of active commit
On 06/23/2014 05:30 PM, Eric Blake wrote: Rebased to latest libvirt.git, and still waiting on Jeff's qemu patches to go into qemu.git before I can push any of these, https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg04060.html but reposting because of a feature Adam had been requesting: Patch 3/5 is new, and adds a new activecommit/ marker to the 'virsh capabilities' output if qemu is detected as supporting active commit. I've resolved some of Peter's review comments in patches 1 and 2 (patch 1 underwent a bit of a rewrite to differentiate the qemu capability probe from normal use of the interface, and 2 dropped mention of RHEL 6.3 except in the commit message). At this point, I haven't altered 4 or 5, although I still need to do something about getting a persistent domain definition updated after a pivot changes the file in use by a running domain. qemu.git (and therefore the upcoming qemu 2.1 release) now has everything we need: commit 7676e2c597000eff3a7233b40cca768b358f9bc9 Author: Jeff Cody jc...@redhat.com Date: Mon Jun 30 15:14:15 2014 +0200 block: make 'top' argument to block-commit optional Now that active layer block-commit is supported, the 'top' argument no longer needs to be mandatory. Change it to optional, with the default being the active layer in the device chain. [kwolf: Rebased and resolved conflict in tests/qemu-iotests/040] Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Benoit Canet ben...@irqsave.net Signed-off-by: Jeff Cody jc...@redhat.com Signed-off-by: Kevin Wolf kw...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com but I'd rather wait until after the 1.2.6 release to push this series since I still don't have persistent XML manipulation working, and since we may want to rework how feature advertisement works. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv6 1/7] qemu: caps: Add capability for change-backing-file command
On 06/26/2014 07:36 AM, Peter Krempa wrote: This command allows to change the backing file name recorded in the metadata of a qcow (or other) image. The capability also notifies that the block-stream and block-commit commands understand the backing-file attribute. --- src/qemu/qemu_capabilities.c | 2 ++ src/qemu/qemu_capabilities.h | 1 + 2 files changed, 3 insertions(+) Upstream qemu.git (and therefore qemu.git) now has everything we need for this; but I'd still rather wait until after the 1.2.6 release (in part so that the active-commit stuff can go in first, to minimize rebase churn): commit fa40e65622352012dccd435147f28161375a6815 Author: Jeff Cody jc...@redhat.com Date: Tue Jul 1 09:52:16 2014 +0200 block: add QAPI command to allow live backing file change This allows a user to make a live change to the backing file recorded in an open image. The image file to modify can be specified 2 ways: 1) image filename 2) image node-name Note: this does not cause the backing file itself to be reopened; it merely changes the backing filename in the image file structure, and in internal BDS structures. It is the responsibility of the user to pass a filename string that can be resolved when the image chain is reopened, and the filename string is not validated. A good analogy for this command is that it is a live version of 'qemu-img rebase -u', with respect to changing the backing file string. [Jeff is offline so I respun this patch in his absence. Dropped image filename since using node-name is preferred and this is a new command. No need to introduce the limitations of finding images by filename. --Stefan] Reviewed-by: Eric Blake ebl...@redhat.com Reviewed-by: Kevin Wolf kw...@redhat.com Signed-off-by: Jeff Cody jc...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@redhat.com -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fwd: [PATCH] qemu: Add cmd_per_lun, max_sectors to virtio-scsi
Hi Mike Co, -- Forwarded message -- From: Mike Perez thin...@gmail.com Date: Fri, Jun 27, 2014 at 7:39 PM Subject: Re: [libvirt] [PATCH] qemu: Add cmd_per_lun, max_sectors to virtio-scsi To: Ján Tomko jto...@redhat.com Cc: Eric Blake ebl...@redhat.com, libvir-list@redhat.com, berra...@redhat.com, n...@daterainc.com n...@daterainc.com On Thu, Jun 5, 2014 at 6:57 AM, Ján Tomko jto...@redhat.com wrote: On 05/23/2014 12:06 AM, Eric Blake wrote: On 05/22/2014 12:22 PM, Mike Perez wrote: This introduces two new attributes cmd_per_lun and max_sectors same with the names QEMU uses for virtio-scsi. An example of the XML: controller type='scsi' index='0' model='virtio-scsi' cmd_per_lun='50' max_sectors='512'/ I'm not a fan of underscore (why type the shift key, when a dash will do). The libvirt xml name does not have to exactly match the qemu option name, so maybe there's some room for bikeshedding what names we should actually present to the user. IMO using underscores here would be consistent with other disk-related options like read_iops_sec; dashes are mostly used for network-related options. We could also use camelCase [1], or just roll a dice. Well underscores are originally what I had in my first patch [1]. Eric what do you think? Can we please keep the libvirt names consistent for virtio-scsi parameters with what is already defined in qemu..? (Paolo CC'ed) From qemu/include/hw/virtio/virtio-scsi.h: #define DEFINE_VIRTIO_SCSI_PROPERTIES(_state, _conf_field) \ DEFINE_PROP_UINT32(num_queues, _state, _conf_field.num_queues, 1), \ DEFINE_PROP_UINT32(max_sectors, _state, _conf_field.max_sectors, 0x),\ DEFINE_PROP_UINT32(cmd_per_lun, _state, _conf_field.cmd_per_lun, 128) AFAICT, having different names between qemu + libvirt parameters can only add confusion. --nab -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
