> It's working fine with backup-restore.
>
> I have check the code of rbd block driver,
>
> and it's seem to miss the bdrv_co_write_zeroes feature.
>
> (Which is not use by backup-restore).
in block/backup.c:
if (buffer_is_zero(iov.iov_base, iov.iov_len)) {
if (job->dump_cb)
I think shared storage is the correct solution. If you want the feature,
you'll have to provide the shared storage which is not difficult to do,
otherwise current local storage works ok.
This would keep things as simple as possible, which is quite good for
reliable logs.
On 06/10/14 10:43, D
From: Dan Hunsaker
The PVE2 API supports suspend/resume of VMs (and now CTs), but the web UI
doesn't make these options available. This patch adds Suspend and Resume
items to the CmdMenus of OpenVZ and QEMU guests. I considered adding the
options to the toolbar, but since it is already pretty f
The previous patchset was generated by ignoring whitespace differences rather
than removing the whitespace changes from the local commits themselves, and
therefore would require the `--ignore-whitespace` smitch to `git apply`. This
patchset removes the whitespace from the source commits, eliminati
From: Dan Hunsaker
Suspend/resume support for VMs has been in the PVE2 API for some time,
but even though vzctl supports suspend/resume (what they call checkpoint/
restore), the API doesn't yet support suspend/resume for CTs. This patch
adds that support.
Signed-off-by: Dan Hunsaker
---
PVE/A
From: Dan Hunsaker
Now that the API supports CT suspend/resume, it makes sense to have pvectl
support it, too. It *does* use different names than vzctl does, but it
seems to make sense to be consistent with the API naming in a PVE utility.
Signed-off-by: Dan Hunsaker
---
bin/pvectl | 2 ++
1
From: Dan Hunsaker
With the new mobile interface, we need to implement UI changes in two
places. This lets us simplify our mobile interface so it isn't cluttered
with options that mobile browsers can't easily handle, usually due to size.
This patch implements Suspend and Resume of VMs and CTs vi
Am 08.10.2014 um 09:34 schrieb Eneko Lacunza:
> I think shared storage is the correct solution. If you want the feature,
> you'll have to provide the shared storage which is not difficult to do,
> otherwise current local storage works ok.
>
> This would keep things as simple as possible, which is
> Am 08.10.2014 um 09:34 schrieb Eneko Lacunza:
> > I think shared storage is the correct solution. If you want the
> > feature, you'll have to provide the shared storage which is not
> > difficult to do, otherwise current local storage works ok.
> >
> > This would keep things as simple as possible
