Hey all,
I have a simple user question. I have a few LVM based KVM guests and
wan't to backup them to files. The simple and nasty way would be to
create a complete output file with dd, which wastes very much space. So
I would like to create a backup of the LVM to a file which only locates
the
Il 12/10/2012 00:37, Rusty Russell ha scritto:
> "Michael S. Tsirkin" writes:
>> On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
>>> OK. Well, Anthony wants qemu to be robust in this regard, so I am
>>> tempted to rework all the qemu drivers to handle arbitrary layouts.
>>> They co
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
> I have a simple user question. I have a few LVM based KVM guests and
> wan't to backup them to files. The simple and nasty way would be to
> create a complete output file with dd, which wastes very much space.
> So I would like to cre
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have a few LVM based KVM guests and
wan't to backup them to files. The simple and nasty way would be to
creat
On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
> >> For writes, the standard seems to be a commit latch. We could abuse the
> >> generation count for this: the driver writes to it to commit config
> >> changes.
> >
> > I think this will work. There are a couple of things that bothe
On 10/11/2012 10:31 PM, Marcelo Tosatti wrote:
> On Thu, Oct 11, 2012 at 09:06:12PM +0800, Xiao Guangrong wrote:
>> On 10/10/2012 11:11 PM, Marcelo Tosatti wrote:
>>
>>>
>>> Why does is_error_pfn() return true for mmio spte? Its not an "error",
>>> after all.
>>>
>>> Please kill is_invalid_pfn and
"Michael S. Tsirkin" writes:
> On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
>> >> For writes, the standard seems to be a commit latch. We could abuse the
>> >> generation count for this: the driver writes to it to commit config
>> >> changes.
>> >
>> > I think this will work. Th
On Fri, Oct 12, 2012 at 08:21:50PM +1030, Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > On Fri, Oct 12, 2012 at 08:59:36AM +1030, Rusty Russell wrote:
> >> >> For writes, the standard seems to be a commit latch. We could abuse the
> >> >> generation count for this: the driver writes to
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp wrote:
> Am 12.10.2012 10:58, schrieb Lukas Laukamp:
>
>> Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
>>>
>>> On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have a few LVM based KVM guests
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 08:52:32AM +0200, Lukas Laukamp wrote:
I have a simple user question. I have
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp wrote:
> Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 10:58, schrieb Lukas Laukamp:
>>>
Am 12.10.2012 10:42, schrieb Stefan Hajnoczi:
>
> On Fri, Oct 12,
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp wrote:
Am 12.10.2012 10:58, schrieb Lukas Laukamp:
Am 12.10.2012 10:42, schrieb Stefan Hajnocz
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
> Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
>>>
On Fri, Oct 12, 2012 at 11:17 AM, Lukas Laukamp
wrote:
>
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas L
On Fri, 12 Oct 2012 09:07:46 +1030
Rusty Russell wrote:
> "Michael S. Tsirkin" writes:
> > On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
> >> OK. Well, Anthony wants qemu to be robust in this regard, so I am
> >> tempted to rework all the qemu drivers to handle arbitrary layout
On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp wrote:
> Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
>>>
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp
wrote:
>
>
Am 12.10.2012 14:59, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas La
Hello Michael,
Thanks for the review!
On 10/11/2012 08:41 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 09, 2012 at 04:05:18PM +0800, Asias He wrote:
>> vhost-blk is an in-kernel virito-blk device accelerator.
>>
>> Due to lack of proper in-kernel AIO interface, this version converts
>> guest's I/O
On Fri, Oct 12, 2012 at 3:02 PM, Lukas Laukamp wrote:
> Am 12.10.2012 14:59, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 1:51 PM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
>>>
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp
wrote:
>
>
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi wrote:
> I would leave them raw as long as they are sparse (zero regions do not
> take up space). If you need to copy them you can either convert to
> qcow2 or use tools that preserve sparseness (BTW compression tools are
> good at this).
note tha
Am 12.10.2012 16:36, schrieb Javier Guerra Giraldez:
On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi wrote:
I would leave them raw as long as they are sparse (zero regions do not
take up space). If you need to copy them you can either convert to
qcow2 or use tools that preserve sparseness (BT
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:11, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 11:17 AM, Lukas L
This was part of [PATCH v6 00/16] Allow changing of Hypervisor CPUIDs.
Since it is no longer in use by any of the patches in v7, I have split it off.
Don Slutz (1):
target-i386: Add missing kvm bits.
target-i386/cpu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
--
T
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp wrote:
> Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
>>>
On Fri, Oct 12, 2012 at 12:16 PM, Lukas Laukamp
wrote:
>
>
On Fri, Oct 12, 2012 at 4:36 PM, Javier Guerra Giraldez
wrote:
> On Fri, Oct 12, 2012 at 9:25 AM, Stefan Hajnoczi wrote:
>> I would leave them raw as long as they are sparse (zero regions do not
>> take up space). If you need to copy them you can either convert to
>> qcow2 or use tools that pres
Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp wrote:
Am 12.10.2012 12:47, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:16 PM, Lukas La
Currently "-cpu host,-kvmclock,-kvm_nopiodelay,-kvm_mmu" does not
turn off all bits in CPUID 0x4001 EAX.
The missing ones are KVM_FEATURE_STEAL_TIME and
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT.
This adds the names kvm_steal_time and kvm_clock_stable for these
bits.
Signed-off-by: Don Slutz
---
This was part of [PATCH v6 00/16] Allow changing of Hypervisor CPUIDs.
Since it is no longer in use by any of the patches in v7, I have split it off.
Don Slutz (1):
target-i386: Add missing kvm bits.
target-i386/cpu.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
--
T
Also known as Paravirtualization CPUIDs.
This is primarily done so that the guest will think it is running
under vmware when hypervisor-vendor=vmware is specified as a
property of a cpu.
Patches 1 to 3 define new cpu properties.
Patches 4 to 6 Add QOM access to the new properties.
Patches 7 to 9
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization level or maximim cpuid function present in
this leaf.
This is the EAX value for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
http:/
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization vendor.
This is EBX, ECX, and EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
This is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/wind
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is the EAX value for 0x4001.
QEMU knows this is KVM_CPUID_FEATURES (0x4001) in some builds.
This is based on:
Microsoft Hypervisor CPUID Leaves:
Part of "target-i386: Add way to expose VMWare CPUID"
These are modeled after x86_cpuid_get_xlevel and x86_cpuid_set_xlevel.
Signed-off-by: Don Slutz
---
target-i386/cpu.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/t
Part of "target-i386: Add way to expose VMWare CPUID"
These are modeled after x86_cpuid_set_vendor and x86_cpuid_get_vendor.
Since kvm's vendor is shorter, the test for correct size is removed and zero
padding is added.
See http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html for
d
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is just the EAX value for 0x4001.
QEMU knows this is KVM_CPUID_FEATURES (0x4001) in some builds.
When exposing VMWare CPUID this needs to be set t
Part of "target-i386: Add way to expose VMWare CPUID"
At this stage it is used to set the cpu object's hypervisor level to
the default for Microsoft's Hypervisor.
Also known as Paravirtualization level or maximim cpuid function
present in this leaf. This is the EAX value for 0x4000.
This is
Part of "target-i386: Add way to expose VMWare CPUID"
At this stage it is used to set the cpu object's hypervisor vendor
to the default for Microsoft's Hypervisor ("Microsoft Hv").
Also known as Paravirtualization vendor.
This is EBX, ECX, EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SI
Part of "target-i386: Add way to expose VMWare CPUID"
At this stage it is used to set the cpu object's hypervisor features
to the default for Microsoft's Hypervisor ("Hv#1").
Also known as kvm festures or Hypervisor vendor-neutral interface
identification.
This is the EAX value for 0x4001.
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization level.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
Signed-off-by: Don Slutz
---
target-i386/kvm.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization vendor.
This is EBX, ECX, and EDX data for 0x4000.
QEMU knows this is KVM_CPUID_SIGNATURE (0x4000).
If hypervisor vendor is set then add kvm's
signature at KVM_CPUID_SIGNATURE_NEXT (0x4100).
Signe
Part of "target-i386: Add way to expose VMWare CPUID"
QEMU knows this as KVM_CPUID_FEATURES (0x4001) in some builds.
If hypervisor features are set, then pass adjusted
cpuid_kvm_features as EAX in 0x4101.
This is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/
Part of "target-i386: Add way to expose VMWare CPUID"
This is EAX and EBX data for 0x4010.
Add new #define CPUID_HV_TIMING_INFO for this.
The best documentation I have found is:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/22643
And a test under ESXi 4.0 shows that VMware is s
Part of "target-i386: Add way to expose VMWare CPUID"
Also adds some other known names (kvm, hyperv) to Hypervisor vendor.
This allows "hypervisor-vendor=vmware3" instead of
"hypervisor-vendor=VMwareVMware,hypervisor-level=2,hypervisor-features=0".
And "hypervisor-vendor=vmware" instead of
"hype
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization level.
QEMU knows this as KVM_CPUID_SIGNATURE (0x4000) in kvm on linux.
This does not provide vendor support in tcg yet.
>From http://lkml.indiana.edu/hypermail/linux/kernel/1205.0/00100.html
kvm has this
Part of "target-i386: Add way to expose VMWare CPUID"
Also known as Paravirtualization vendor.
This change is based on:
Microsoft Hypervisor CPUID Leaves:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542428%28v=vs.85%29.aspx
Linux kernel change starts with:
http://fixunix.com
Part of "target-i386: Add way to expose VMWare CPUID"
This is EAX and EBX data for 0x4010.
Add new #define CPUID_HV_TIMING_INFO for this.
The best documentation I have found is:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/22643
And a test under ESXi 4.0 shows that VMware is s
On Fri, Oct 12, 2012 at 9:26 PM, Lukas Laukamp wrote:
> Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
>
>> On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp wrote:
>>>
>>> Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
>>>
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Laukamp
wrote:
>
>
Am 12.10.2012 22:43, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 9:26 PM, Lukas Laukamp wrote:
Am 12.10.2012 21:13, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 8:14 PM, Lukas Laukamp wrote:
Am 12.10.2012 13:36, schrieb Stefan Hajnoczi:
On Fri, Oct 12, 2012 at 12:50 PM, Lukas Lau
On Fri, Oct 12, 2012 at 3:56 PM, Lukas Laukamp wrote:
> I think that it must be possible to create an image with a size like the
> used space + a few hundret MB with metadata or something like that.
the 'best' way to do it is 'from within' the VM
the typical workaround is to mount/fsck a LVM sna
49 matches
Mail list logo
