Re: QEMU P2P migration speed
Il 06/02/2014 14:40, Andrey Korolyov ha scritto: Took and build 1.6.2 and faced a problem - after a couple of bounce iterations of migration (1-2-1-2) VM is not able to migrate anymore back in a probabilistic manner with an error 'internal error unexpected migration status in setup'. Error may disappear over a time, or may not disappear at all and it may took a lot of tries in a row to succeed. There are no obvious hints with default logging level in libvirt/qemu logs and seemingly libvirt is not a cause because accumulated error state preserves over service restarts. Also every VM is affected, not ones which are experiencing multiple migration actions. Error happens on 3rd-5th second of the migration procedure, if it may help. You need to update libvirt too. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] PPC: KVM: fix RESUME_GUEST checks
On Thu, 6 Feb 2014 18:39:30 +0100 Alexander Graf ag...@suse.de wrote: On 06.02.2014, at 17:36, Greg Kurz gk...@linux.vnet.ibm.com wrote: As discussed in this thread: http://patchwork.ozlabs.org/patch/309166/ We need some consistency in the way we check whether the guest should resume or not because: - new RESUME_GUEST_XXX values may show up - more locations in KVM may need to perform a similar check This serie introduces a helper and patches the locations where it should be called. There is yet another location in __kvmppc_vcpu_run, but it is assembly and cannot call a C inlined function. Thanks, applied all to kvm-ppc-queue. I think the splitting on this one is quite excessive - a single patch would've done :). Alex Heh... I paranoid ! :) Thanks Alex ! -- Greg -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: file_ram_alloc: unify mem-path,mem-prealloc error handling
Il 04/02/2014 19:41, Marcelo Tosatti ha scritto:
-mem-prealloc asks to preallocate memory residing on -mem-path path.
Currently QEMU exits in case:
- Memory file has been created but allocation via explicit write
fails.
And it fallbacks to malloc in case:
- Querying huge page size fails.
- Lack of sync MMU support.
- Open fails.
- mmap fails.
Have the same behaviour for all cases: fail in case -mem-path and
-mem-prealloc are specified for regions where the requested size is
suitable for hugepages.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
diff --git a/exec.c b/exec.c
index 9ad0a4b..1da1ba7 100644
--- a/exec.c
+++ b/exec.c
@@ -996,7 +996,7 @@ static void *file_ram_alloc(RAMBlock *block,
hpagesize = gethugepagesize(path);
if (!hpagesize) {
-return NULL;
+goto error;
}
if (memory hpagesize) {
@@ -1005,7 +1005,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (kvm_enabled() !kvm_has_sync_mmu()) {
fprintf(stderr, host lacks kvm mmu notifiers, -mem-path
unsupported\n);
-return NULL;
+goto error;
}
/* Make name safe to use with mkstemp by replacing '/' with '_'. */
@@ -1023,7 +1023,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (fd 0) {
perror(unable to create backing store for hugepages);
g_free(filename);
-return NULL;
+goto error;
}
unlink(filename);
g_free(filename);
@@ -1043,7 +1043,7 @@ static void *file_ram_alloc(RAMBlock *block,
if (area == MAP_FAILED) {
perror(file_ram_alloc: can't mmap RAM pages);
close(fd);
-return (NULL);
+goto error;
}
if (mem_prealloc) {
@@ -1087,6 +1087,12 @@ static void *file_ram_alloc(RAMBlock *block,
block-fd = fd;
return area;
+
+error:
+if (mem_prealloc) {
+exit(1);
+}
+return NULL;
}
#else
static void *file_ram_alloc(RAMBlock *block,
Reviewed-by: Paolo Bonzini pbonz...@redhat.com
Will apply soon.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [libvirt] Looking for project ideas and mentors for Google Summer of Code 2014
On Fri, 02/07 15:01, Fam Zheng wrote: I'd like to add persistent dirty bitmap as an idea but I seem to have no account on wiki, so I'll just reply here, please help with review and update the page if it makes sense. (Who could create an account for me, BTW?) Now I've got two because Paolo and Kevin helped me at the same time :). Thank you! Fam -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Looking for project ideas and mentors for Google Summer of Code 2014
Il 07/02/2014 11:41, Giorgio Zoppi ha scritto: Hi all, I would like to add fault tolerance mechanism. I'm assuming you would contribute as a student rather than a mentor, since I am not familiar with contributions from you to either libvirt or QEMU. In that case, do not worry. The page is only listing project ideas from the mentors, and it is certainly possible for student to propose their own projects. This has already happened in the past. Thanks, Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QEMU P2P migration speed
On 02/07/2014 12:14 PM, Paolo Bonzini wrote: Il 06/02/2014 14:40, Andrey Korolyov ha scritto: Took and build 1.6.2 and faced a problem - after a couple of bounce iterations of migration (1-2-1-2) VM is not able to migrate anymore back in a probabilistic manner with an error 'internal error unexpected migration status in setup'. Error may disappear over a time, or may not disappear at all and it may took a lot of tries in a row to succeed. There are no obvious hints with default logging level in libvirt/qemu logs and seemingly libvirt is not a cause because accumulated error state preserves over service restarts. Also every VM is affected, not ones which are experiencing multiple migration actions. Error happens on 3rd-5th second of the migration procedure, if it may help. You need to update libvirt too. Paolo Ok, I will do, but looks like libvirt version(1.0.2) in not relevant - it meets criteria set by debian packagers and again, 'broken state' is not relevant to the libvirt state history, it more likely to be qemu/kvm problem. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QEMU P2P migration speed
Il 07/02/2014 14:07, Andrey Korolyov ha scritto: Ok, I will do, but looks like libvirt version(1.0.2) in not relevant - it meets criteria set by debian packagers and again, 'broken state' is not relevant to the libvirt state history, it more likely to be qemu/kvm problem. It is relevant, qemu introduced a new migration status before active (setup) and libvirt doesn't recognize it. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/11] ARM: LPAE: provide an IPA capable pmd_addr_end
On Fri, Feb 07, 2014 at 04:04:56AM +, Christoffer Dall wrote:
On Thu, Feb 06, 2014 at 10:43:28AM +, Catalin Marinas wrote:
On Wed, Feb 05, 2014 at 07:55:45PM +, Marc Zyngier wrote:
The default pmd_addr_end macro uses an unsigned long to represent
the VA. When used with KVM and stage-2 translation, the VA is
actually an IPA, which is up to 40 bits. This also affect the
SMMU driver, which also deals with stage-2 translation.
Instead, provide an implementation that can cope with larger VAs
by using a u64 instead. This version will overload the default
one provided in include/asm-generic/pgtable.h.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/include/asm/pgtable-3level.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index 03243f7..594867b 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -262,6 +262,11 @@ static inline int has_transparent_hugepage(void)
return 1;
}
+#define pmd_addr_end(addr, end)
\
+({ u64 __boundary = ((addr) + PMD_SIZE) PMD_MASK;
\
+ (__boundary - 1 (end) - 1)? __boundary: (end);\
+})
I see why you need this but it affects all the other uses of
pmd_addr_end() with 32-bit VA. It would be slight performance, I don't
think it's noticeable.
A different approach could be something like (untested):
#define pmd_addr_end(addr, end) \
({ __typeof__(addr) __boundary = ...
...
})
What about the pgd_addr_end(), do we need this or it's not used by KVM?
What about pud_addr_end(), is that defined as a noop on LPAE, or?
I would be in favor of introducing them all using your approach to avoid
somebody being inspired by the KVM code when dealing with IPAs and
breaking things unknowingly.
I had a brief chat with Marc yesterday around this and it may be safer
to simply introduce kvm_p*d_addr_end() macros. You already do this for
pgd_addr_end() since it cannot be overridden in the generic headers.
--
Catalin
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QEMU P2P migration speed
07.02.2014 19:32, Paolo Bonzini wrote: Il 07/02/2014 14:07, Andrey Korolyov ha scritto: Ok, I will do, but looks like libvirt version(1.0.2) in not relevant - it meets criteria set by debian packagers Then Debian's qemu packaging it's wrong, QEMU 1.6 or newer should conflict with libvirt 1.2.0. I've no idea when qemu breaks libvirt. I found out - just by a chance - that qemu 1.3+ breaks libvirt 1.0, and I stated this in the deps. But the thing that 1.6 requires libvirt 1.2 is news for me. I'll add this requiriment to the debian package. At any rate, there's no libvirt 1.0 in debian. Current stable has 0.9, and current testing has 1.2.1, and this version is also available in backports for stable. 1.2 was the first version past 0.9 which were backproted to stable. There's no other versions of libvirt in debian. So whomever installed that mess did that on their own, it is definitely not supported on debian ;) Thanks, /mjt and again, 'broken state' is not relevant to the libvirt state history, it more likely to be qemu/kvm problem. It is relevant, qemu introduced a new migration status before active (setup) and libvirt doesn't recognize it. That's why you need at least 1.2.0. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/11] ARM: LPAE: provide an IPA capable pmd_addr_end
On Fri, Feb 07, 2014 at 03:44:01PM +, Catalin Marinas wrote:
On Fri, Feb 07, 2014 at 04:04:56AM +, Christoffer Dall wrote:
On Thu, Feb 06, 2014 at 10:43:28AM +, Catalin Marinas wrote:
On Wed, Feb 05, 2014 at 07:55:45PM +, Marc Zyngier wrote:
The default pmd_addr_end macro uses an unsigned long to represent
the VA. When used with KVM and stage-2 translation, the VA is
actually an IPA, which is up to 40 bits. This also affect the
SMMU driver, which also deals with stage-2 translation.
Instead, provide an implementation that can cope with larger VAs
by using a u64 instead. This version will overload the default
one provided in include/asm-generic/pgtable.h.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/include/asm/pgtable-3level.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/pgtable-3level.h
b/arch/arm/include/asm/pgtable-3level.h
index 03243f7..594867b 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -262,6 +262,11 @@ static inline int has_transparent_hugepage(void)
return 1;
}
+#define pmd_addr_end(addr, end)
\
+({ u64 __boundary = ((addr) + PMD_SIZE) PMD_MASK;
\
+ (__boundary - 1 (end) - 1)? __boundary: (end);
\
+})
I see why you need this but it affects all the other uses of
pmd_addr_end() with 32-bit VA. It would be slight performance, I don't
think it's noticeable.
A different approach could be something like (untested):
#define pmd_addr_end(addr, end) \
({__typeof__(addr) __boundary = ...
...
})
What about the pgd_addr_end(), do we need this or it's not used by KVM?
What about pud_addr_end(), is that defined as a noop on LPAE, or?
I would be in favor of introducing them all using your approach to avoid
somebody being inspired by the KVM code when dealing with IPAs and
breaking things unknowingly.
I had a brief chat with Marc yesterday around this and it may be safer
to simply introduce kvm_p*d_addr_end() macros. You already do this for
pgd_addr_end() since it cannot be overridden in the generic headers.
Sounds good to me. We should introduce all of them then.
Thanks,
-Christoffer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Discard is not working
07.02.2014 04:03, Paolo Bonzini wrote: Michael, can you look at this? Paolo Messaggio originale From: chickenmar...@freenet.de To: kvm@vger.kernel.org Hello, after reading the invitation for some one-off questions without subscribing excuse my disturbing, please. At first my setup of host: * in general Debian Wheezy * Kernel: 3.11-0.bpo.2-amd64 (http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-amd64) * LVM 2.02.98 (http://packages.debian.org/jessie/lvm2) * thin-provisioning-tools 0.2.8-1 (http://packages.debian.org/jessie/thin-provisioning-tools) * Qemu-KVM: 1.7.0 (http://packages.debian.org/jessie/qemu-kvm) The new kernel and dirty things from Jessie are for working thin volumes with discard on my ssd. Everything's fine up to this point. Afterwards I start a guest (also Debian Wheezy) over the following command (over libvirt) as root (for test only): kvm [...] -drive file=/dev/ssd0/sarabi,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 [...] Neither lsblk -D nor the try of fstrim ends positive. Both say that discard is not supported. I read that guests need at least kernel 3.4 to support discard (and virtio-scsi). But the same backports kernel 3.11 did not changed anything. This is the first time I tried to deal with discard. I've no discard-capable hardware, so never bothered to even look how it works (or not). I fired up my sample linux guest here, using 3.10 kernel on host and 3.2 kernel on guest, using something similar to what your command looks like: -device megasas,id=scsi0 \ -drive file=test.raw,if=none,id=sd0,discard=unmap \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=sd0 Note: this is a plain file (test.raw) on an ext4 filesystem on a device without discard support (regular rotational hard drive). In the guest, I can see discard granularity (4K) for that drive in lsblk -D output. fstrim does not error out, but I don't know if it actually does something or not. The same result can be observed with 3.10 kernel in guest, and with other scsi devices/drivers (eg lsi53c895a). However, when I export the same test.raw file using virtio, like this: -drive file=test.raw,if=virtio,discard=unmap it doesn't work: guest does not see the virtio drive as discardable. Did I understand something wrong? Is the command wrong? Are any requirements not met? So I've no idea what's going on here... ;) Thanks, /mjt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MSI interrupt support with vioscsi.c miniport driver
Hi Yan, So recently I've been doing some KVM guest performance comparisons between the scsi-mq prototype using virtio-scsi + vhost-scsi, and Windows Server 2012 with vioscsi.sys (virtio-win-0.1-74.iso) + vhost-scsi using PCIe flash backend devices. I've noticed that small block random performance for the MSFT guest is at around ~80K IOPs with multiple vioscsi LUNs + adapters, which ends up being well below what the Linux guest with scsi-mq + virtio-scsi is capable of (~500K). After searching through the various vioscsi registry settings, it appears that MSIEnabled is being explicitly disabled (0x), that is different from what vioscsi.inx is currently defining: [pnpsafe_pci_addreg_msix] HKR, Interrupt Management,, 0x0010 HKR, Interrupt Management\MessageSignaledInterruptProperties,, 0x0010 HKR, Interrupt Management\MessageSignaledInterruptProperties, MSISupported, 0x00010001, 0 HKR, Interrupt Management\MessageSignaledInterruptProperties, MessageNumberLimit, 0x00010001, 4 Looking deeper at vioscsi.c code, I've noticed that MSI_SUPPORTED=0 is explicitly disabled at build time in SOURCES + vioscsi.vcxproj, as well as VioScsiFindAdapter() code always ends setting msix_enabled = FALSE here, regardless of MSI_SUPPORTED: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L340 Also looking at virtio_stor.c for the raw block driver, MSI_SUPPORTED=1 appears to be the default setting for the driver included in the offical virtio-win iso builds, right..? Sooo, I'd like to try enabling MSI_SUPPORTED=1 in a test vioscsi.sys build of my own, but before going down the WDK development rabbit whole, I'd like to better understand why you've explicitly disabled this logic within vioscsi.c code to start..? Is there anything that needs to be addressed / carried over from virtio_stor.c in order to get MSI_SUPPORTED=1 to work with vioscsi.c miniport code..? TIA! --nab -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Discard is not working
Hello, I did not get response to my private mail address. So I'm subscribed now. Bye Markus Original-Nachricht Betreff:Discard is not working Datum: Wed, 05 Feb 2014 23:53:56 +0100 Von:chickenmar...@freenet.de An: kvm@vger.kernel.org Hello, after reading the invitation for some one-off questions without subscribing excuse my disturbing, please. At first my setup of host: * in general Debian Wheezy * Kernel: 3.11-0.bpo.2-amd64 (http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-amd64) * LVM 2.02.98 (http://packages.debian.org/jessie/lvm2) * thin-provisioning-tools 0.2.8-1 (http://packages.debian.org/jessie/thin-provisioning-tools) * Qemu-KVM: 1.7.0 (http://packages.debian.org/jessie/qemu-kvm) The new kernel and dirty things from Jessie are for working thin volumes with discard on my ssd. Everything's fine up to this point. Afterwards I start a guest (also Debian Wheezy) over the following command (over libvirt) as root (for test only): kvm [...] -drive file=/dev/ssd0/sarabi,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 [...] Neither lsblk -D nor the try of fstrim ends positive. Both say that discard is not supported. I read that guests need at least kernel 3.4 to support discard (and virtio-scsi). But the same backports kernel 3.11 did not changed anything. Did I understand something wrong? Is the command wrong? Are any requirements not met? Bye Markus -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QEMU P2P migration speed
Il 07/02/2014 14:07, Andrey Korolyov ha scritto: Ok, I will do, but looks like libvirt version(1.0.2) in not relevant - it meets criteria set by debian packagers Then Debian's qemu packaging it's wrong, QEMU 1.6 or newer should conflict with libvirt 1.2.0. and again, 'broken state' is not relevant to the libvirt state history, it more likely to be qemu/kvm problem. It is relevant, qemu introduced a new migration status before active (setup) and libvirt doesn't recognize it. That's why you need at least 1.2.0. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Discard is not working
Hello, I played around with raw images now. Megasas is not supported by libvirt. The default controller crashs during installation while accessing to disk. qemu-system-x86_64: /build/qemu-j0uSxv/qemu-1.7.0+dfsg/hw/scsi/lsi53c895a.c:541: lsi_do_dma: Assertion `s-current' failed. So I took Debian Testing (Jessie with kernel 3.12) to use virtio-scsi over following options. -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 \ -drive file=/home/vm/trim.raw,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 Result of this: fstrim works. Take a look into lsblk -D: DISC-ZERO=0? I read DISC-ZERO has to be 1 to propagate discard. Switch back to my thin volume vm. DISC-ZERO=0 and fstrim works! Booting from old kernel 3.2 - works too. LVM recognize the increasing of thin volume after discard. Conclusion of my issues: Did I understand something wrong? Yes! Discard granularity (DISC-GRAN) of lsblk -D is the important number. It must not be 0B. I did so much the last weeks. Maybe the error of fstrim occurs before getting thin volumes work. Thanks a lot for your help (and hint to try it with an image)! Bye Markus Am 07.02.2014 17:36, schrieb Michael Tokarev: 07.02.2014 04:03, Paolo Bonzini wrote: Michael, can you look at this? Paolo Messaggio originale From: chickenmar...@freenet.de To: kvm@vger.kernel.org Hello, after reading the invitation for some one-off questions without subscribing excuse my disturbing, please. At first my setup of host: * in general Debian Wheezy * Kernel: 3.11-0.bpo.2-amd64 (http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-amd64) * LVM 2.02.98 (http://packages.debian.org/jessie/lvm2) * thin-provisioning-tools 0.2.8-1 (http://packages.debian.org/jessie/thin-provisioning-tools) * Qemu-KVM: 1.7.0 (http://packages.debian.org/jessie/qemu-kvm) The new kernel and dirty things from Jessie are for working thin volumes with discard on my ssd. Everything's fine up to this point. Afterwards I start a guest (also Debian Wheezy) over the following command (over libvirt) as root (for test only): kvm [...] -drive file=/dev/ssd0/sarabi,if=none,id=drive-scsi0-0-0-0,format=raw,discard=unmap -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=2 [...] Neither lsblk -D nor the try of fstrim ends positive. Both say that discard is not supported. I read that guests need at least kernel 3.4 to support discard (and virtio-scsi). But the same backports kernel 3.11 did not changed anything. This is the first time I tried to deal with discard. I've no discard-capable hardware, so never bothered to even look how it works (or not). I fired up my sample linux guest here, using 3.10 kernel on host and 3.2 kernel on guest, using something similar to what your command looks like: -device megasas,id=scsi0 \ -drive file=test.raw,if=none,id=sd0,discard=unmap \ -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=sd0 Note: this is a plain file (test.raw) on an ext4 filesystem on a device without discard support (regular rotational hard drive). In the guest, I can see discard granularity (4K) for that drive in lsblk -D output. fstrim does not error out, but I don't know if it actually does something or not. The same result can be observed with 3.10 kernel in guest, and with other scsi devices/drivers (eg lsi53c895a). However, when I export the same test.raw file using virtio, like this: -drive file=test.raw,if=virtio,discard=unmap it doesn't work: guest does not see the virtio drive as discardable. Did I understand something wrong? Is the command wrong? Are any requirements not met? So I've no idea what's going on here... ;) Thanks, /mjt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Discard is not working
Il 07/02/2014 17:36, Michael Tokarev ha scritto: However, when I export the same test.raw file using virtio, like this: -drive file=test.raw,if=virtio,discard=unmap it doesn't work: guest does not see the virtio drive as discardable. Did I understand something wrong? Is the command wrong? Are any requirements not met? So I've no idea what's going on here... ;) Thanks Michael for the experiments! I missed this email. virtio-blk does not support discard, so this is expected. Regarding lsblk -D, DISC-ZERO is never true in VMs (not yet at least!), but the important one is DISC-GRAN. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Speed disk virtio
On 02/04/2014 08:21 AM, XliN wrote: Good day. Very little speed drives Virtio. Drivers are the latest guest on the system Windows server 2008. Host system centos 6.5. What latest? There are a few different places to get drivers (Fedora site, RHEL subscription, build yourself, etc). From the graphs, it looks like the speed isn't too bad at times. But it's hard to tell with the information you've given about your particular config. I mean 50MB/s isn't bad for a single rotating disk on raw storage. But we don't know what kind of setup you have since you didn't tell us. All that can be tried, but failed to increase the speed. And there I have a database running. All? You should try being specific about what you've tried. How you are running the guest. The underlying hardware. Command line options. Too much detail is better than none (which is about what you've given us). Screenshots test speed drives http://itmages.ru/image/view/1471772/feec35c3 http://itmages.ru/image/view/1471774/2b0baeae http://itmages.ru/image/view/1471785/9fffb8f5 Thanks in advance. Apply nowhere else. I'm not really sure what this test that you've run is. For all I know, your results look spectacular. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] asmlinkage, kvm: Make kvm_rebooting visible
kvm_rebooting is referenced from assembler code, thus needs to be visible. Cc: g...@redhat.com Cc: pbonz...@redhat.com Cc: kvm@vger.kernel.org Signed-off-by: Andi Kleen a...@linux.intel.com --- virt/kvm/kvm_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 03a0381..b5ec7fb 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -102,7 +102,7 @@ static void kvm_release_pfn_dirty(pfn_t pfn); static void mark_page_dirty_in_slot(struct kvm *kvm, struct kvm_memory_slot *memslot, gfn_t gfn); -bool kvm_rebooting; +__visible bool kvm_rebooting; EXPORT_SYMBOL_GPL(kvm_rebooting); static bool largepages_enabled = true; -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
