On 2011-11-21 9:51, MATSUDA, Daiki wrote:
Sorry, I confirmed the snapshot file is not wrong.
I moved the snapshot file created under /dev as /dev/VG1/abc.xx to
other place and fixed the config file re-writed by libvirt to use
moved snapshot file abc.xx. So, the domain starts with no
Sorry, I confirmed the snapshot file is not wrong.
I moved the snapshot file created under /dev as /dev/VG1/abc.xx to
other place and fixed the config file re-writed by libvirt to use moved
snapshot file abc.xx. So, the domain starts with no problem.
Regards
MATSUDA Daiki
On
Checking the source of the disk will exclude the case when the source
disk is block device while the snapshot target is given manually by the
users with snapshot-create --xmlfile or virsh snapshot-create-as
--diskspec. Why not check the snapshot directory where it will be
created?
On
On 11/17/2011 02:11 AM, shu ming wrote:
Checking the source of the disk will exclude the case when the source
disk is block device while the snapshot target is given manually by the
users with snapshot-create --xmlfile or virsh snapshot-create-as
--diskspec. Why not check the snapshot
On Wed, Nov 16, 2011 at 08:45:34AM -0700, Eric Blake wrote:
On 11/15/2011 08:20 PM, Dave Allan wrote:
After working on this some more, I think that identifying problematic
file systems, like devtmpfs, is too tricky to be portable. But I think
we can meet halfway - right now, the libvirt
On 11/17/2011 08:04 AM, Dave Allan wrote:
After an offline conversation with Eric about why file type is a good
proxy for a filesystem that is unsuitable for a snapshot, I'm in
agreement with this patch. The argument boils down to
1) block devices are really the only non-regular files that
On 11/15/2011 08:20 PM, Dave Allan wrote:
After working on this some more, I think that identifying problematic
file systems, like devtmpfs, is too tricky to be portable. But I think
we can meet halfway - right now, the libvirt code blindly generates a
filename if one was not provided,
On Mon, Nov 14, 2011 at 04:02:21PM -0700, Eric Blake wrote:
On 11/13/2011 09:08 PM, MATSUDA, Daiki wrote:
NACK. There is nothing inherently wrong with the source file not being
a qcow2 file. The whole point of creating a runtime snapshot is that
the original file (of _any_ format) becomes
(2011/11/16 0:35), Dave Allan wrote:
On Mon, Nov 14, 2011 at 04:02:21PM -0700, Eric Blake wrote:
On 11/13/2011 09:08 PM, MATSUDA, Daiki wrote:
NACK. There is nothing inherently wrong with the source file not being
a qcow2 file. The whole point of creating a runtime snapshot is that
the
On 11/15/2011 03:48 PM, MATSUDA, Daiki wrote:
I tested some cases and found it.
1. The guest use the raw disk volume or LVM2 volume, such as following
the config file using raw disk volume created by RHEL 6.1 Virt Manager.
disk type='block' device='disk'
driver name='qemu'
On 11/15/2011 04:18 PM, Eric Blake wrote:
2. Do the 'virsh snapshot-create abc --disk-only' with libvirt-0.9.6 or
upper.
But here, since you failed to use the --xmlfile option with XML
describing the new qcow2 file name (or used snapshot-create-as with the
--diskspec option), you are asking
On Tue, Nov 15, 2011 at 05:26:59PM -0700, Eric Blake wrote:
On 11/15/2011 04:18 PM, Eric Blake wrote:
2. Do the 'virsh snapshot-create abc --disk-only' with libvirt-0.9.6 or
upper.
But here, since you failed to use the --xmlfile option with XML
describing the new qcow2 file name (or
On 11/13/2011 09:08 PM, MATSUDA, Daiki wrote:
NACK. There is nothing inherently wrong with the source file not being
a qcow2 file. The whole point of creating a runtime snapshot is that
the original file (of _any_ format) becomes the backing file of a new
qcow2 file, so that the original
On 11/06/2011 09:14 PM, MATSUDA, Daiki wrote:
I made the patch for the problem to take the snapshot but qcow2. It use
the 'qemu-img' command, I know that it is not essential solution. But I
think it is better than to link qemu's libraries.
Regards
@@ -9002,6 +9021,13 @@
On Mon, Nov 07, 2011 at 01:14:12PM +0900, MATSUDA, Daiki wrote:
Hi, Eric.
On 09/29/2011 11:26 PM, MATSUDA, Daiki wrote:
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines
On 11/06/2011 09:14 PM, MATSUDA, Daiki wrote:
I made the patch for the problem to take the snapshot but qcow2. It use
the 'qemu-img' command, I know that it is not essential solution. But I
think it is better than to link qemu's libraries.
Regards
@@ -9002,6 +9021,13 @@
Hi, Eric.
On 09/29/2011 11:26 PM, MATSUDA, Daiki wrote:
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines and tried to take
disk snapshot by virsh command ( snapshot-create
On 09/29/2011 11:26 PM, MATSUDA, Daiki wrote:
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines and tried to take
disk snapshot by virsh command ( snapshot-create DOMNAME
(2011/09/30 14:26), MATSUDA, Daiki wrote:
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines and tried to take
disk snapshot by virsh command ( snapshot-create DOMNAME
On 09/29/2011 11:26 PM, MATSUDA, Daiki wrote:
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines and tried to take
disk snapshot by virsh command ( snapshot-create DOMNAME
I tried the new snapshot function implemented by Eric Blake.
It works very well for QCOW2 disk image system.
But I often use LVM2 volume for QEMU virtual machines and tried to take
disk snapshot by virsh command ( snapshot-create DOMNAME --disk-only).
So, finally qemu monitor command
21 matches
Mail list logo
