From: "Daniel P. Berrange" <berrange@redhat.com>
To: Gal Hammer <ghammer@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID
Date: Mon, 6 Oct 2014 10:06:57 +0100 [thread overview]
Message-ID: <20141006090657.GA18003@redhat.com> (raw)
In-Reply-To: <1410953992-14542-1-git-send-email-ghammer@redhat.com>
On Wed, Sep 17, 2014 at 02:39:50PM +0300, Gal Hammer wrote:
> Hi,
>
> A two parts patch to add a QEmu support for Microsoft's Virtual Machine
> Generation ID device.
>
> The first one add a new ACPI directive which allow to use a 16-bytes
> buffer in an ACPI table. This buffer is for storing the VM's UUID.
>
> The second is the ACPI tables changes and the actual device.
>
> Your comment are welcomed.
There are some rules on when the VM generation ID *must* change
Virtual machine is paused or resumed: No
Virtual machine reboots: No
Virtual machine host reboots: No
Virtual machine starts executing a snapshot (every time): Yes
Virtual machine is recovered from backup: Yes
Virtual machine is failed over in a disaster recovery environment: Yes
Virtual machine is live migrated: No
Virtual machine is imported, copied, or cloned: Yes
Virtual machine is failed over in a clustered environment: No
Virtual machine's configuration changes: Unspecified
Now this can largely be accomplished by libvirt by simply changing the
value of the -vmgenid command line parameter, because most of these
scenarios involve the spawning of a new QEMU process. The exception
I think is when a running guest is reverted to a previous snapshot,
because that is done via a monitor command and not restarting QEMU.
So for this VM Generation ID work to be considered complete we need
to have a way to dynamically change the VM generation ID on the fly,
atomatically with reverting snapshots from the POV of the guest.
eg we must load the snapshot state, change the generation ID, and
only then start CPUs again.
IOW I think this patch series is incomplete wrt the Microsoft spec
on generation ID semantics.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2014-10-06 9:07 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-17 11:39 [Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID Gal Hammer
2014-09-17 11:39 ` [Qemu-devel] [PATCH 1/2] i386: Add an ACPI_EXTRACT_NAME_BUFFER16 directive Gal Hammer
2014-10-02 12:20 ` Michael S. Tsirkin
2014-09-17 11:39 ` [Qemu-devel] [PATCH 2/2] i386: Add a Virtual Machine Generation ID device Gal Hammer
2014-10-02 12:49 ` Michael S. Tsirkin
2014-10-02 13:14 ` Gal Hammer
2014-10-02 13:30 ` Michael S. Tsirkin
2014-10-01 8:58 ` [Qemu-devel] [PATCH 0/2 V5] Virtual Machine Generation ID Markus Armbruster
2014-10-02 8:32 ` Gal Hammer
2014-10-02 8:46 ` Michael S. Tsirkin
2014-10-02 12:12 ` Michael S. Tsirkin
2014-10-02 12:16 ` Michael S. Tsirkin
2014-10-06 9:06 ` Daniel P. Berrange [this message]
2014-10-06 12:48 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141006090657.GA18003@redhat.com \
--to=berrange@redhat.com \
--cc=ghammer@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).