Hi,
I am confused about the main thread, monitor thread and migration
thread. Hope somebody can give me a help.
I observe that when a VM (smp=1, which is a file server) boots up,
there are two threads for qemu (e.g. i use "top" and "ps" to monitor).
I think one thread is for the vcpu. The
On Fri, Sep 17, 2010 at 3:15 PM, Chris Wright wrote:
> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>> On Fri, Sep 17, 2010 at 2:52 PM, Cam Macdonell wrote:
>> > On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
>> >> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>> >>> After fixing the resour
* Cam Macdonell (c...@cs.ualberta.ca) wrote:
> On Fri, Sep 17, 2010 at 2:52 PM, Cam Macdonell wrote:
> > On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
> >> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
> >>> After fixing the resource_size_t return value with
> >>> pci_resource_alignment, I
Am 14.09.2010 um 22:53 schrieb Blue Swirl:
How about with the attached patch? If yes, does it work even with /
bin/sh?
LC_ALL=C /usr/xpg4/bin/sh ./tracetool --nop --check-backend
works fine,
LC_ALL=C sh ./tracetool --nop --check-backend
./tracetool: bad substitution
On Fri, Sep 17, 2010 at 2:52 PM, Cam Macdonell wrote:
> On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
>> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>>> After fixing the resource_size_t return value with
>>> pci_resource_alignment, I see one other strange behaviour only when
>>> using 4GB
On Fri, Sep 17, 2010 at 2:04 PM, Chris Wright wrote:
> * Cam Macdonell (c...@cs.ualberta.ca) wrote:
>> After fixing the resource_size_t return value with
>> pci_resource_alignment, I see one other strange behaviour only when
>> using 4GB of RAM and a 2GB BAR. I haven't found any other combination
* Cam Macdonell (c...@cs.ualberta.ca) wrote:
> After fixing the resource_size_t return value with
> pci_resource_alignment, I see one other strange behaviour only when
> using 4GB of RAM and a 2GB BAR. I haven't found any other combination
> of RAM/BAR size that triggers this bug. I am using 2.6.
On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> From: Anthony PERARD
>
> Xen currently uses a different BIOS (hvmloader + rombios) therefore the
> Qemu acpi_piix4 implementation wouldn't work correctly with Xen.
> We plan on fixing this properly but at the moment we are just adding a
> new Xen specif
After fixing the resource_size_t return value with
pci_resource_alignment, I see one other strange behaviour only when
using 4GB of RAM and a 2GB BAR. I haven't found any other combination
of RAM/BAR size that triggers this bug. I am using 2.6.36-rc3.
ACPI Error: The DSDT has been corrupted or r
On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> From: Anthony PERARD
>
> This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
> a call to qemu_ram_ptr_unlock, the pointer may be unmap from QEMU when
> used with Xen.
>
> Signed-off-by: Anthony PERARD
> ---
> cpu-common.h | 1
On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> From: Anthony PERARD
>
> Open and bind event channels; map ioreq and buffered ioreq rings.
In general, because of CPUState accesses and cpu_in/out use, this
looks like CPU code, specifically x86. Could this belong to
target-i386/xen.c instead, much lik
On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> From: Anthony PERARD
>
> The mapcache maps chucks of guest memory on demand, unmaps them when
> they are not needed anymore.
>
> Each call to qemu_get_ram_ptr makes a call to qemu_map_cache with the
> lock option, so mapcache will not unmap these ram_pt
On 09/17/2010 06:11 AM, Kevin O'Connor wrote:
> On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote:
>> On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
>>> On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
This uses a new cmos port at 0x5e that shall read zero to be b
block/nbd.c: use default port number when none is specified
qemu-nbd.c: use IANA-assigned port number: 10809
Signed-off-by: Laurent Vivier
---
block/nbd.c |2 --
qemu-nbd.c |6 +++---
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 5e9d6cb
On Fri, Sep 17, 2010 at 11:15 AM, wrote:
> From: Anthony PERARD
>
> This patch introduces Xen specific call in piix_pci.
>
> The specific part for Xen is in write_config, set_irq and get_pirq.
>
> Signed-off-by: Anthony PERARD
> Signed-off-by: Stefano Stabellini
> ---
> hw/piix_pci.c | 10 +
On Fri, Sep 17, 2010 at 11:14 AM, wrote:
> From: Anthony PERARD
>
> Introduce a new emulated PCI device, specific to fully virtualized Xen
> guests. The device is necessary for PV on HVM drivers to work.
>
> Signed-off-by: Anthony PERARD
> Signed-off-by: Stefano Stabellini
> ---
> Makefile.t
On 09/17/2010 12:30 PM, Alex Williamson wrote:
Nearly any operation on virtqueues require multiple reads/writes
to virtqueue ring descriptors using guest physical addresses
(ld*/st*_phys). These are expensive and result in
phys_page_find_alloc() and qemu_get_ram_ptr() showing up at the top
of pr
Nearly any operation on virtqueues require multiple reads/writes
to virtqueue ring descriptors using guest physical addresses
(ld*/st*_phys). These are expensive and result in
phys_page_find_alloc() and qemu_get_ram_ptr() showing up at the top
of profiles run under virtio net/block workloads.
We
Am 17.09.2010 19:06, schrieb Anthony Liguori:
> On 09/17/2010 11:18 AM, Kevin Wolf wrote:
>> Note that the flush is omitted intentionally in qcow2_free_clusters. If
>> anything, we can leak clusters here if we lose the writes.
>>
>> Signed-off-by: Kevin Wolf
>>
>
> Cluster leaking gets picked
On 09/17/2010 11:18 AM, Kevin Wolf wrote:
Note that the flush is omitted intentionally in qcow2_free_clusters. If
anything, we can leak clusters here if we lose the writes.
Signed-off-by: Kevin Wolf
Cluster leaking gets picked up by bdrv_check though, right?
I think I've convinced myself
On 09/17/2010 11:18 AM, Kevin Wolf wrote:
For copy on write (this includes any cluster allocations that don't fill the
whole cluster with one request), what qcow2 does looks like this:
1. Allocate new clusters (increase refcounts)
2. bdrv_flush
3. Copy sectors before the first touched one
4. bdr
Am 17.09.2010 18:13, schrieb Laurent Vivier:
> This patch allows to reduce the boot time from an NBD server from 225 seconds
> to
> 5 seconds (time between the "boot cd:0" and the kernel init) for the
> following command lines:
>
> ./qemu-nbd -t ../ISO/debian-500-powerpc-netinst.iso
> and
> ./ppc
We always have a sync for the refcount update when a new cluster is
allocated. If we move this past the COW, we can save an additional sync.
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-cluster.c
Signed-off-by: Kevin Wolf
---
block/qcow2-cluster.c |3 +++
block/qcow2-refcount.c |4 ++--
block/qcow2-snapshot.c |2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
index 91fa9ac..66969c2 100644
--- a/block/qcow2-clust
Note that the flush is omitted intentionally in qcow2_free_clusters. If
anything, we can leak clusters here if we lose the writes.
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-refcount.c b/b
Signed-off-by: Kevin Wolf
---
block/qcow2-refcount.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 4c19e7e..7dc75d1 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -444,7 +444,7 @@ static int w
For copy on write (this includes any cluster allocations that don't fill the
whole cluster with one request), what qcow2 does looks like this:
1. Allocate new clusters (increase refcounts)
2. bdrv_flush
3. Copy sectors before the first touched one
4. bdrv_flush
5. Copy sectors after the last touch
This patch allows to reduce the boot time from an NBD server from 225 seconds to
5 seconds (time between the "boot cd:0" and the kernel init) for the
following command lines:
./qemu-nbd -t ../ISO/debian-500-powerpc-netinst.iso
and
./ppc-softmmu/qemu-system-ppc -cdrom nbd:localhost:1024
This patch
added a output from `kstat -p e1000*` ..
call for more info if needed ..
regards by daniel
ps. summary: everything seems fine (link statistics and so) but
receiving just doesn't work .. transmitting works
** Attachment added: "here it is"
https://bugs.launchpad.net/qemu/+bug/638955/+attachme
On 09/17/2010 01:50 AM, Mathias Krause wrote:
Am 16.09.2010 19:20 schrieb Anthony Liguori:
Instead of using FILE, I'd suggest using a BlockDriver to read and write
the data.
I'll fix that as soon as I figured how to use this interface.
I think it would be very nice to add write
Am 17.09.2010 14:30, schrieb ext Jan Kiszka:
Am 17.09.2010 14:26, Peter Lieven wrote:
Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
Am 16.09.2010 15:57, schrieb ext Peter Lieven:
Hi,
I found the following assertion in my log files after a system reset was
executed
kvm: ls
On Fri, Sep 17, 2010 at 07:53:12AM -0500, Anthony Liguori wrote:
> On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
> >On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
> >>This uses a new cmos port at 0x5e that shall read zero to be backwards
> >>compatible.
> >It looks okay to me. C
On 09/16/2010 08:47 PM, Kevin O'Connor wrote:
On Wed, Sep 15, 2010 at 07:15:28PM +0200, Andrea Arcangeli wrote:
Subject: add 40-48 bit RAM range to seabios
From: Andrea Arcangeli
Needed to show>1TB RAM to guests.
This uses a new cmos port at 0x5e that shall read zero to be backwards
compa
Am 17.09.2010 um 14:38 schrieb Jan Kiszka:
> Am 17.09.2010 14:31, Peter Lieven wrote:
>>
>> Am 17.09.2010 um 14:30 schrieb Jan Kiszka:
>>
>>> Am 17.09.2010 14:26, Peter Lieven wrote:
Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
> Am 16.09.2010 15:57, schrieb ext Peter Liev
Am 17.09.2010 14:51, Peter Lieven wrote:
>
> Am 17.09.2010 um 14:38 schrieb Jan Kiszka:
>
>> Am 17.09.2010 14:31, Peter Lieven wrote:
>>>
>>> Am 17.09.2010 um 14:30 schrieb Jan Kiszka:
>>>
Am 17.09.2010 14:26, Peter Lieven wrote:
>
> Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
>Am 16.09.2010 20:54, schrieb Laurent Vivier:
>> This patch allows to reduce the boot time from an NBD server from 225
>seconds to
>> 5 seconds (time between the "boot cd:0" and the kernel init) for the
>> following command lines:
>>
>> ./qemu-nbd -t ../ISO/debian-500-powerpc-netinst.iso
>> and
>
Am 17.09.2010 14:31, Peter Lieven wrote:
>
> Am 17.09.2010 um 14:30 schrieb Jan Kiszka:
>
>> Am 17.09.2010 14:26, Peter Lieven wrote:
>>>
>>> Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
>>>
Am 16.09.2010 15:57, schrieb ext Peter Lieven:
> Hi,
>
> I found the following assertion
I'm new here and exploring options for a product I'm tasked to build.
I need to create a virtual machine appliance (guest: linux, host: win
xp/vista/7). I must minimize the install process as much as possible.
Installing Qemu + appliance VM as two separate install processes is too
much for th
Am 17.09.2010 um 14:30 schrieb Jan Kiszka:
> Am 17.09.2010 14:26, Peter Lieven wrote:
>>
>> Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
>>
>>> Am 16.09.2010 15:57, schrieb ext Peter Lieven:
Hi,
I found the following assertion in my log files after a system reset was
exec
Am 17.09.2010 14:26, Peter Lieven wrote:
>
> Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
>
>> Am 16.09.2010 15:57, schrieb ext Peter Lieven:
>>> Hi,
>>>
>>> I found the following assertion in my log files after a system reset was
>>> executed
>>>
>>> kvm: lsi_scsi: error: ORDERED queue not imp
Am 17.09.2010 um 13:36 schrieb Bernhard Kohl:
> Am 16.09.2010 15:57, schrieb ext Peter Lieven:
>> Hi,
>>
>> I found the following assertion in my log files after a system reset was
>> executed
>>
>> kvm: lsi_scsi: error: ORDERED queue not implemented
>> last message repeated 5 times
>> kvm: ls
I think I must be missing something. On 27th August, Stefano posted
two messages whose subjects were
[PATCH 1 of 2] Introduce a new 'connected' xendev op called when
Connected.
and
[PATCH 2 of 2] Move the xenfb pointer handler to the connected method
and I still don't see them. Are the
Am 16.09.2010 15:57, schrieb ext Peter Lieven:
Hi,
I found the following assertion in my log files after a system reset
was executed
kvm: lsi_scsi: error: ORDERED queue not implemented
last message repeated 5 times
kvm: lsi_scsi: error: Unimplemented message 0x0d
kvm: lsi_scsi: error: Unimple
On 17.09.2010, at 13:14, anthony.per...@citrix.com wrote:
> From: Anthony PERARD
>
> This options will check if the target is build with Xen support.
>
> Signed-off-by: Anthony PERARD
> Signed-off-by: Stefano Stabellini
> ---
> Makefile.target |3 +++
> hw/xen.h| 10 ++
>
** Description changed:
Positng the issue here since I did not get any reply on the ML.
I was trying to update some windows XP (SP3) images in kvm.
It worked fine several times but last time I added mass storage
drivers to sysprep and now on the second boot after reseal (the first
Hi Kevin,
On 17.09.2010 12:44, Kevin Wolf wrote:
> Hi Mathias,
>
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>>> Using QEMU's block devices instead of a simple file would be
>>> more consistent with the rest of QEMU and allow reading the
>>> CMOS data not only from a file but also from an URL
From: Anthony PERARD
Xen currently uses a different BIOS (hvmloader + rombios) therefore the
Qemu acpi_piix4 implementation wouldn't work correctly with Xen.
We plan on fixing this properly but at the moment we are just adding a
new Xen specific acpi_piix4 implementation.
This patch is optional;
From: Anthony PERARD
Open and bind event channels; map ioreq and buffered ioreq rings.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/xen_common.h |1 +
xen-all.c | 381 +++
2 files changed, 382 insertions(
From: Anthony PERARD
The mapcache maps chucks of guest memory on demand, unmaps them when
they are not needed anymore.
Each call to qemu_get_ram_ptr makes a call to qemu_map_cache with the
lock option, so mapcache will not unmap these ram_ptr.
Signed-off-by: Anthony PERARD
---
Makefile.target
From: Anthony PERARD
This tells to the xen management tool that the machine can begin run.
Signed-off-by: Anthony PERARD
---
xen-all.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/xen-all.c b/xen-all.c
index 13672f0..6a62ecd 100644
--- a/xen-all.c
From: Anthony PERARD
This patch introduces Xen specific call in piix_pci.
The specific part for Xen is in write_config, set_irq and get_pirq.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/piix_pci.c | 10 +-
hw/xen.h |6 ++
xen-all.c | 29
From: Anthony PERARD
This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
a call to qemu_ram_ptr_unlock, the pointer may be unmap from QEMU when
used with Xen.
Signed-off-by: Anthony PERARD
---
cpu-common.h |1 +
exec.c | 29 ++---
xe
From: Anthony PERARD
Introduce a new emulated PCI device, specific to fully virtualized Xen
guests. The device is necessary for PV on HVM drivers to work.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |1 +
hw/hw.h |3 +
hw/pci_id
From: Anthony PERARD
Introduce two functions qemu_shutdown_requested_get and
qemu_reset_requested_get to get the value of shutdown/reset_requested
without reset it.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
sysemu.h |2 ++
vl.c | 10 ++
2 files chan
From: Anthony PERARD
Introduce a 8259 Interrupt Controller for target-xen; every set_irq
call makes a Xen hypercall.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
hw/xen_common.h |2 ++
hw/xen_machine_fv.c |5 ++---
xen-all.c | 12
3
From: Anthony PERARD
This options will check if the target is build with Xen support.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |3 +++
hw/xen.h| 10 ++
qemu-options.hx |9 +
vl.c| 16
x
From: Anthony PERARD
Update the libxenctrl calls in Qemu to use the new interface, otherwise
Qemu wouldn't be able to build against new versions of the library.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
configure|5 +
hw/xen_backend.c | 10 +
From: Anthony PERARD
Add the Xen FV (Fully Virtualized) machine to Qemu;
this is groundwork to add Xen device model support in Qemu.
Signed-off-by: Anthony PERARD
Signed-off-by: Stefano Stabellini
---
Makefile.target |3 +
hw/xen_machine_fv.c | 157 +++
From: Anthony PERARD
Hi all,
this is the third version of the patch series that adds xen device
model support in qemu.
This is the list of changes we made on top of the last version:
- we finally removed the special target for Xen and use the i386 target.
- we removed xenstore management, we h
On 17.09.2010 12:58, Stefan Weil wrote:
> Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Am 16.09.2010 18:49, Stefan Weil schrieb:
>>> Are there use cases where having a smaller CMOS size is better?
>>> For example, when I want to emulate a system with 128 byte CMOS?
>>> The size of CMOS could be
On Wed, Sep 15, 2010 at 10:33:26PM +0200, Hervé Poussineau wrote:
> IEEE 802.3 standard requires Ethernet frames to be at least 64 bytes long.
> If it is not the case, they will be considered as runt frames, and may be
> ignored by netcard and/or OS
>
> Signed-off-by: Hervé Poussineau
Applied,
On Mon, Sep 13, 2010 at 11:01:30PM +0200, Hervé Poussineau wrote:
> Packets with TTL=1 may be directed to local network (DHCP/DNS servers for
> example), so don't discard them
> This is required by old versions of NetBSD which send DHCP DISCOVER packets
> with TTL=1
>
> Signed-off-by: Hervé Pous
Am 17.09.2010 08:42, schrieb Mathias Krause:
Am 16.09.2010 18:49, Stefan Weil schrieb:
The intention of this patch is ok. Loading CMOS with initial data
is needed. I just want to add two questions / remarks how the
implementation might be improved.
Are there use cases where having a smaller CMO
Hi Mathias,
Am 17.09.2010 08:42, schrieb Mathias Krause:
>> Using QEMU's block devices instead of a simple file would be
>> more consistent with the rest of QEMU and allow reading the
>> CMOS data not only from a file but also from an URL or other
>> sources.
>
> Thanks for the hint. Since this i
Am 16.09.2010 20:54, schrieb Laurent Vivier:
> This patch allows to reduce the boot time from an NBD server from 225 seconds
> to
> 5 seconds (time between the "boot cd:0" and the kernel init) for the
> following command lines:
>
> ./qemu-nbd -t ../ISO/debian-500-powerpc-netinst.iso
> and
> ./ppc
reproduced with latest vanilla qemu-kvm ..
i've just build it without any optimalizations like this: `./configure
--prefix=$HOME/chroot/opt/qemu-kvm-0.13rc1; make`
(qemu) info version
info version
0.12.91 (qemu-kvm-0.13.0-rc1)
it acts just same .. i'm trying at first to hunt down what has happe
Am 16.09.2010 17:40, schrieb Anthony Liguori:
> On 09/15/2010 11:06 AM, Juan Quintela wrote:
>> Anthony Liguori wrote:
>>
>>> The use of protocols in backing_files is currently broken because of some
>>> checks for adjusting relative pathnames.
>>>
>>> Additionally, there's a spurious read whe
Public bug reported:
Git commit: abdfd9500e07fab7d6ffd4385fa30a065c329a39
Host: Linux 64bit Debian
Guest: NetBSD5.0.2/i386
Networking works only when ACPI is disabled in the guest. Without it the
network card (wm0) is not detected.
Boot: qemu -hda netbsd5.0.2-i386 -boot c -enable-kvm
Configure:
On Thu, Sep 16, 2010 at 7:54 PM, Laurent Vivier wrote:
> This patch allows to reduce the boot time from an NBD server from 225 seconds
> to
> 5 seconds (time between the "boot cd:0" and the kernel init) for the
> following command lines:
>
> ./qemu-nbd -t ../ISO/debian-500-powerpc-netinst.iso
> a
On 09/17/2010 09:47 AM, Stefan Weil wrote:
> Am 17.09.2010 09:15, schrieb Stefan Weil:
>> Am 16.09.2010 23:56, schrieb Frans de Boer:
>>> Dear Reader,
>>>
>>> When I switch with SHIFT-CTRL-ALT-2 to the monitor mode, the resolution
>>> of the used window goes back to 640*480. There a lot of command
On 09/17/2010 01:40 AM, Luiz Capitulino wrote:
> On Thu, 16 Sep 2010 23:49:51 +0200
> Frans de Boer wrote:
>
>
>> Dear reader,
>>
>> Using qemu-kvm-0.13-rc1 and having the boot partition as if=virtio,
>> causes the attached blue screen when booting Windows XP SP3.
>> Changing the interface to i
Am 17.09.2010 09:15, schrieb Stefan Weil:
Am 16.09.2010 23:56, schrieb Frans de Boer:
Dear Reader,
When I switch with SHIFT-CTRL-ALT-2 to the monitor mode, the resolution
of the used window goes back to 640*480. There a lot of command
available and typing help lists then all. in one long list w
Am 16.09.2010 23:56, schrieb Frans de Boer:
Dear Reader,
When I switch with SHIFT-CTRL-ALT-2 to the monitor mode, the resolution
of the used window goes back to 640*480. There a lot of command
available and typing help lists then all. in one long list without pause
to examine the commands. Is th
> This bug seems to be solved and closed here: http://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=574051
>
> Is it solved in 0.12.5 or 0.13.0rc1 yet?
>
> ** Bug watch added: Debian Bug tracker #574051
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574051
>
#cd qemu-snapshot
#date
Fri Se
74 matches
Mail list logo
