Hi,
As far as I mind - IMHO problem is in acpi code creation (own bytecode
language). After integrating this interaction into standard suspend/resume
signals - there will only problem of guest suspend support for real hardware.
So, nothing special.
You're right - it is nothing special... but t
As far as I mind - IMHO problem is in acpi code creation (own bytecode
language). After integrating this interaction into standard suspend/resume
signals - there will only problem of guest suspend support for real hardware.
So, nothing special.
Jens Kristian Søgaard пишет:
> Hi,
>
>> IMHO interac
Speed is not critical even for usual snapshot. I don't look into qemu code, but
x86 arch normal fork process is in splitting virtual address space and
copy-on-write both "compacted" copies. So, "snapshot" is momental in time (mean
not copy nothing real RAM, just fix descriptors), but forked copy ca
Hi,
IMHO interaction QEMU & kernel's FREEZER (part of hibernation & cgroups) can
solve many of problems. It can be done via QEMU host-2-guest sockets and scripts
That would require a cooperating VM. What I was looking at was how to do
this for non-cooperating VMs.
--
Jens Kristian Søgaard,
Hi,
I`ve thought of the same mechanism a lot ago. After couple of tests I
have concluded that coredump should be done not to Ceph directly, but
to the tmpfs catalog to decrease VM` idle timeout(explicitly for QEMU,
I see that more like as an implementation detail - i.e. the state is
initially
If I understood you right, your approach is a suspend VM via ACPI
mechanism, then dump core, then restore it - this should be longer
than simple coredump due timings for guest OS to sleep/resume, which
seems unnecessary. Copy-on-write mechanism should reduce downtime to
very acceptable values but u
Freezer in guest agent? Exists or todo?
Dzianis Kahanovich пишет:
> IMHO interaction QEMU & kernel's FREEZER (part of hibernation & cgroups) can
> solve many of problems. It can be done via QEMU host-2-guest sockets and
> scripts
> or embedded into virtual hardware (simulate real "suspend" behavi
IMHO interaction QEMU & kernel's FREEZER (part of hibernation & cgroups) can
solve many of problems. It can be done via QEMU host-2-guest sockets and scripts
or embedded into virtual hardware (simulate real "suspend" behavior).
Andrey Korolyov пишет:
> Hello,
>
> I`ve thought of the same mechanis
Hello,
I`ve thought of the same mechanism a lot ago. After couple of tests I
have concluded that coredump should be done not to Ceph directly, but
to the tmpfs catalog to decrease VM` idle timeout(explicitly for QEMU,
if other hypervisor able to work with Ceph backend and has COW-like
memory snaps
Hi guys,
I was wondering if anyone has done some work on saving qemu VM state
(RAM, registers, etc.) on Ceph itself?
The purpose for me would be to enable easy backups of non-cooperating
VMs - i.e. without the need to quiesce file systems, databases, etc.
I'm thinking an automated process w
10 matches
Mail list logo
